STM32Cube and Atollic TrueSTUDIO

This evening before bed time I decided to give STM32CubeMX and Atollic TrueSTUDIO (built on Eclipse) a go in order to generate a simple project to run on the STM32 board I use for development.
Whenever I try a new build tool-chain and libraries for such board, the first gain I am looking for is a simple setup of the USB port as Virtual COM port.
Honestly, this was rather easy to do with STM32CubeMX and TrueSTUDIO, although under Windows 10 it took a few connection attempts before the system correctly enumerated the USB device. I had a few errors with Windows 10 complaining about not being able to retrieve the descriptor from the USB device, but the error went away eventually and the peripheral started working fine.

The USB device (VCP) generated through STM32 Cube didn't enumerate properly in the beginning under Windows 10

The USB device (VCP) generated through STM32 Cube didn’t enumerate properly in the beginning under Windows 10

The USB device (VCP) eventually started working

The USB device (VCP) eventually started working

Indeed I can see that VID and PID match the ones configured within the CDC descriptor source code:

Default VID and PID of the USB device created by STM32 Cube when selecting the CDC VCP class

Default VID and PID of the USB device created by STM32Cube when selecting the CDC VCP class

As you can see, within the generated source code VID and PID occur as decimal numbers instead of hexadecimal. I was puzzled as to why the generated code uses decimal values, but I guess it’s STM32 developer’s preference to use decimal values. Pretty much the whole rest of the world uses hexadecimal values here…

I was also quite intimidated by a forum post about how broken the STM32Cube software ecosystem is that I decided not to go too far too quickly with this build tool-chain and set of libraries. I will definitely go through the following stages in order to build some confidence, but at the moment my expectations are quite low:

  1. toggle the onboard LED (yes, always start with that as it’s the Hello World of embedded systems when you try a new development framework!),
  2. get a loopback on the VCP,
  3. bridge one of the UART ports to the VCP,
  4. have a go at SPI, I2C, etc.

Should I find too many frustrated comments online about using STM32Cube for any of the above, I think I will save myself the frustration and move away from it. I’ve already had a disappointing experience with the mbed library for this MCU (bug with the SPI communication) that I ‘d be OK going on working with my own startup code, register definitions and Makefile as I’ve done so far.

I was looking for portability and a readily usable USB device stack without having to bang my head on somebody else’s bugs. Have I just found it? More to come…

This entry was posted in Technical and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s