Feature request: Exporting CubeMX projects to labeled schematics

I am beginning to like ST’s CubeMX tool. Despite being non-free software, it runs smoothly and also under Linux. The benefit, CubeMX offers during the inital stages of the hardware and software design process, is not to be underrated. CubeMX simplifies not only the MCU selection, but also helps with the pin assignment, so that one could quickly get started designing a PCB.

Screenshot of CubeMX during customization of MCU pin functions

Could – In reality one still has to create a project e.g. in KiCad, add a symbol for the selected MCU and attach a ton of labels for all the selected pin functions.

Why, I was thinking, isn’t this automated? Why isn’t it possible to export a KiCad schematic directly from the CubeMX tool? Or by means of a separate tool, which converts the .ioc project file to a schematic?

So I took a look into that .ioc file and found, that it’s a text-based format:

...
Mcu.Family=STM32F3
Mcu.Name=STM32F303C(B-C)Tx
Mcu.Package=LQFP48
Mcu.Pin0=PF0-OSC_IN
Mcu.Pin1=PF1-OSC_OUT
Mcu.Pin10=PB11
Mcu.Pin11=PA8
Mcu.Pin12=PA9
Mcu.Pin13=PA10
Mcu.Pin14=PA11
Mcu.Pin15=PA12
...

Should be easy enough to write a small parser for that. KiCad’s schematic files are text-based, too, and open source anyway.

Veröffentlicht unter Bug reports & Feature requests, Mikrocontroller | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar

Getting started with joysticks

In my experience, remote controlled toys and robot arms are best controlled using a haptic device, such as a joysticks. But how can one write a program, that makes use of a joystick? For only 5€ I got an old but fancy-looking Saitek joystick on the flee market. It registers under Linux without problems. Now what?

Quick googling turned up this site. So I started by running jstest-gtk:

The first thing to do, is to select the joystick, click „Properties“ and perform a calibration:

Wow, after the calibration the joystick already appears usable:

Veröffentlicht unter Modellbau, Tagebuch | Verschlagwortet mit , | Hinterlasse einen Kommentar

Flashing a CANtact firmware using ST’s DfuSe client

The CANtact USB-CAN adapter offers a simple way to update the device’s firmware: Just place a jumper on the BOOT pin onboard the PCB, plug the device to a USB port and you’re all set for flashing via USB-DFU. This works via the USB bootloader, which is present in board’s ST microcontroller’s ROM.

Under Linux there is a simple console command, which will upload your .bin file to the desired flash address via DFU: dfu-util (see also this post). A Windows version of the tool exists, too, which can be downloaded from here. However, many Windows users are more inclined to use a colourful GUI, rather than console commands. Such users may be better served by ST’s proprietary DfuSe utility. Also, using dfu-util under Windows might make it necessary to enable libusb for the CANtact using the Zadig USB driver installer, which might be too complicated for the average Windows user.

If you have an account registered at ST.com, you can download the DfuSe utility from here (There’s a download button at the bottom of the page below „Get software“). Unzip the archive and run the Setup.exe.

Once installation has completed, you will have two executables: One to create or extract .dfu files and one to flash them onto the device. Start the second one by clicking the „DfuSe Demo“ icon on the Desktop or the Windows menu.

If you attach a CANtact in DFU mode to your PC, the software will recognize it and show some information about. In order to flash a .dfu firmware image, proceed with the following steps:

  • Select target „Internal Flash“ in the „Actions“ box
  • Select „Verify after download“: This will read back the written target memory area after flashing and evaluates, if the write was successful.
  • Click „Choose“ to select the .dfu file, you wish to upload
  • Click „Upgrade“

If nothing goes wrong, the write and verification processes will take no longer than a couple of seconds and it will look like this:

Congratulations, you have updated your CANtact’s firmware!

Unplug the USB, remove the BOOT jumper and continue using your adapter as you’re used to.

Veröffentlicht unter CAN, Mikrocontroller, Tagebuch | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

First time playing with the Spartan-3E starter kit

Recently, a group at a local university agreed to lend me an old FPGA board for a couple of months – the Xilinx Spartan-3E starter board. It’s rather old (like 10 years at least) but still relevant, I think, since it has lots of connectors, LEDs, buttons and stuff, enabling to quickly getting started with FPGA experiments.

A first Verilog blinking LED example was quickly written and synthesized, so I powered and attached the board to a Windows PC. The first thing to notice, is that the board identifies as what is otherwise known as „Xilinx Platform Cable USB“.

That adapter, which can be bought also as a standalone product, seems to be onboard on the Spartan-3E starter kit. It consists of a Cypress FX2LP microcontroller, an I²C EEPROM with the former’s firmware and a Xilinx CoolRunner-II CPLD.

The next finding is, that the onboard JTAG chain has three TAPs: Not only the Spartan-3E (XC3S500E), but also a Xilinx Platform Flash (XCF04S) and a Xilinx CoolRunner-II CPLD (XC2C64A). This can be seen, when scanning the chain using ChipScope Pro Analyzer:

I wanted to see, what’s happening, when use this program to flash my blinky bitstream to the FPGA, so I hooked up an oscilloscope to the JTAG signals:

From the scope capture (yellow=TCLK, blue=TDI, pink=TMS) several things can be seen:

  • The clock frequency is 3MHz.
  • Transmission is segmented in blocks of four bits.
  • The clock is active high.
  • TMS as well as TDI are sampled at the rising edge of the clock.
Veröffentlicht unter FPGA, JTAG, Tagebuch | Verschlagwortet mit , | Hinterlasse einen Kommentar

Probing a New Bright 40MHz remote control

So, the weather is getting better and it is time to bring the outdoor toys back to life!

One of my toys is New Bright’s Mud Slinger Jeep Wrangler, which I got cheap in a returned toys sale. For the fun of it, I opened the case of the remote control and probed around with an oscilloscope. Some of my findings I documented on a page in my Wiki.

The remote control’s insides make a rather cheap impression, but it contains a 40 MHz quartz oscillator, which can be observed oscillating, when a remote control button is pressed, at several locations on the board, e.g. on the top pin of transistor Q1.

In the scope capture we can see 28 complete sine waves in 13.8 divs with 50ns/div, making for a frequency of 40.6MHz.

The antenna’s solder point is also showing continuous activity, while a button is pressed. The time resolution is now 1ms/div:

Surprisingly, for every button the same sequence seems to appear. The oscilloscope used was rather cheap, so I didn’t manage to trigger to the transmission start (or to the same point within a sequence twice for that matter). But all buttons initiate transmission sequences consisting of alternating four long and four short 40MHz bursts, and all are ending with four short bursts.

All buttons have a different effect on the car, so there must be a difference in the signal. Maybe the oscilloscope resolution wasn’t high enough to see that difference time-wise or maybe there is a difference in the sequence itself, that’s not seen due to the small time window monitored.

Veröffentlicht unter Funk, Modellbau, Tagebuch, Zerlegen & Reparieren | Verschlagwortet mit , | Hinterlasse einen Kommentar

CANtact USB-DFU won’t start without BOOT jumper

Recently, I thought it would be nice, if the CANtact USB-CAN adapter (which features a STM32F042 Cortex M0-based MCU) could start the USB firmware download procedure without me having to phyiscally place a jumper on the board’s BOOT pin (see also: GitHub issue #9). That way one wouldn’t have to open up the case every time a new firmware is available.

Commit 59b2813 implements a function jump_to_st_usb_bootloader(); which should do just that and can be invoked via USB. For some reason though, the adapter still won’t register on the PC as a USB DFU device. Instead it reboots into the regular firmware.

Why is that?

Regularly, the MCU maps either the so called „System Memory“ ROM i.e. the USB DFU bootloader at 0x1fffc400 or the regular firmware memory at 0x08000000 to address 0x00000000, depending on whether the jumper on the BOOT pin is present or not. That way stack pointer and vector table are set accordingly and the corresponding reset handler service routine is executed.

The system configuration register SYSCFG->CFGR1 allows to remap those memory areas after startup and I confirmed, that after the corresponding call in line 38 the memory at address 0x00000000 changes and afterwards reflects the ROM content. I also confirmed, that the processor’s stack pointer register is changed to the new value after the call in line 41 and that after line 49 code execution jumps to the ROM address range. Since the bootloader is not Open Source, unfortunately, I was unable to debug the issue any further from that.

What could be the issue?

  • Does the bootloader re-sample the BOOT pin and exit, if it has an unexpected value?
  • Does the bootloader have trouble with settings made to peripheral registers in the regular firmware?
    • I tried to rule this out by invoking jump_to_st_usb_bootloader(); in the main(); before performing any hardware initialization – the issue persists.
  • Is it an exception that triggers the MCU reset or is the reset invoked on purpose?
Veröffentlicht unter Bug reports & Feature requests, CAN | Verschlagwortet mit , , , , , , , | Hinterlasse einen Kommentar

Notes on fxload

To flash firmware into Cypress FX2(LP) microcontrollers, a tool is required. Several exist, fxload being the most widely used. Unfortunately, simply installing fxload via the Debian package is not sufficient to get started. The Debian package is heavily outdated (a version from 2008) and doesn’t seem to work anymore with recent installations of Debian/Linux. I had to dive a little bit into the topic, which is what I would like to summarize here.

fxload is originally a part of the Linux Hotplug Project on SourceForge. That project, however, seems abandoned, the last activity happening in 2013. For some reason I didn’t even manage to clone the CVS(!) reposity.

Fortunately, a git-converted fork of the repo by Github user esden exists. Noteworthy are also accesio’s additions, which enable compilation for MacOS. Most notable though is, that since 2012, fxload has also been added as an example application to the libusb project. In the latter repository it has even been maintained (last commit July 2017).

Compiling fxload from the libusb repository actually appears to results in a working executable. Here’s what you need to do to compile it:

  • git clone https://github.com/libusb/libusb
  • cd libusb
  • ./autogen.sh
  • make
  • cd examples/
  • ./fxload
  • cp -av fxload /usr/local/bin/

There’s no need to install the rest of the project. You can just place the generated fxload executable in your /usr/local/bin and you’re all set for development.

Veröffentlicht unter Mikrocontroller | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

New gadgets arrived: Cypress EZ-USB FX2LP Development Board

Today I finally received my new (noname) development board for the Cypress CY7C68013A MCU.

It features the CY7C68013A-56PVXC, a mini-USB port, the AMS1117-3.3 3.3 Volt LDO, a 24 MHz crystal, the Atmel ATMTC169-24C128N EEPROM, two buttons, two jumpers, two LEDs plus power LED and two 2×10 pin 2.54mm headers breaking out the MCU’s pins.

In the coming days I will try to compile a simple LED blinky using SDCC and possibly Wolfgang Wieser’s cycfx2prog or fxload from the Linux Hotplug Project. For both of them Windows ports exist:

Read more about fxload in my next post.

For firmware development there exists a library called fx2lib.

Also interesting to know: The Sigrok FX2lafw firmware enables using this MCU and board as logic analyzer and cheap oscilloscope:

The board isn’t a new product or design, nor is the MCU. But it can still be found in products, e.g. on the Spartan-3E starter kit, where it functions as USB interface respectively CPLD and FPGA programmer.

People have written about the board, e.g.:

Thanks you, Peter! He also has a board schematic on his blog post (I didn’t find a better image quality, sorry, but it’s readable with a little effort):

Missing in this schematic are the LEDs though (on the top right in the first picture), which are:

  • LED D1, connected to PA0, active low
  • LED D2, connected to PA1, active low
  • Jumper J1: Enables 3V3 on D1 and D2
  • Jumper J2: Connected to EEPROM but unclear function:
    • Enable/Disable EEPROM power supply?
    • EEPROM Write-Protection?
    • Select EEPROM memory region?
    • Select EEPROM’s I2C address?
Veröffentlicht unter Mikrocontroller | Hinterlasse einen Kommentar

5V-Netzteil: Stecker durch Kabel ersetzt

In Vorbereitung der Inbetriebnahme der Pintsch Bamag-Alarmlampe (siehe spätere Blog-Posts) kam die Frage auf, woher der steuernde Mikrocontroller seine 5Volt Spannungsversorgung bekommen soll. Die „professionelle“ Lösung wäre ein PCB mit AC/DC-Wandler, z.B. Recom RAC05-05SK. Die einfachere Lösung besteht darin, ein handelsübliches 5VDC-Netzteil so anzupassen, dass es seine 230VAC am Eingang vom Stromanschluss der Alarmlampe beziehen kann.

Zweiteres wurde durchgeführt (und mittlerweile erfolgreich angewandt). Dazu wurde das Netzteil geöffnet, der dankenswerterweise modulare Netzstecker abgeschraubt und stattdessen (dem erwarteten Stromfluss angemessen dick ausgelegte) Adern direkt am Netzteil-PCB angeschlossen. Diese wurden durch die Netzstecker-Öffnungen herausgeführt und letztere mit Heißkleber abgedichtet.

Hier ein paar Bilder vom Netzteil-Umbau:

Zu erkenne ist u.a., dass der Hersteller auf den Verbau einer Sicherung, obwohl im Design vorgesehen, verzichtet hat.

Komponenten u.a.:

Veröffentlicht unter Zerlegen & Reparieren | Hinterlasse einen Kommentar

Contacting Xilinx support is only for „approved“ people

I was surprised to find out, that in order to being able to contact Xilinx’s support, one must not only have a Xilinx account, but also have applied with that account for being able to write to Xilinx support. So, in essence, you can only ask Xilinx questions, if Xilinx grants you the right to ask them 😉 What kind of nonsense is that?

This fact alone is reason enough for me, not to buy their products. Not being able to write them straight away in case there is a problem and risking to not get any support in the end is simply not acceptable.

Praised be Lattice, where everybody can get all the support one needs! 🙂

Veröffentlicht unter FPGA | Hinterlasse einen Kommentar