STM32 where to start?

[bd139]

Ok I’m not new to STM32. I got a nucleo32-412KB board and managed to build something not totally insignificant so far (FreeRTOS/I2C/LED mux etc) but it has been quite frankly horrible. I come from an AVR-gcc background and I need more grunt and a decent debugger.

Problem so far have been mostly related to the CubeMX stuff which periodically just toasts everything I have done when I change pin config. Also the board itself is an arduino compatible unit which has solder links and stuff all over it and some damn weird behaviour which took me ages to work out. Also HAL is horrible.

So the question is where can I find something with the following requirements;

1. Not too big STM32. Something that FreeRTOS will be happy on. Five tasks, 64k or so flash (mostly LUT), not much stack. I2C, 24 GPIO pins, not a lot more. Long lifetime so I don’t have to throw everything in the bin in the near future.
2. On a dead simple breakout board with crystals and external ST Link that doesn’t pretend to be arduino friendly.
3. Command line tool chain for Linux.

If anyone has any references or pointers or better ideas I’d appreciate it. 

[krish2487]

Ok I’m not new to STM32. I got a nucleo32-412KB board and managed to build something not totally insignificant so far (FreeRTOS/I2C/LED mux etc) but it has been quite frankly horrible. I come from an AVR-gcc background and I need more grunt and a decent debugger.

Problem so far have been mostly related to the CubeMX stuff which periodically just toasts everything I have done when I change pin config. Also the board itself is an arduino compatible unit which has solder links and stuff all over it and some damn weird behaviour which took me ages to work out. Also HAL is horrible.

So the question is where can I find something with the following requirements;

1. Not too big STM32. Something that FreeRTOS will be happy on. Five tasks, 64k or so flash (mostly LUT), not much stack. I2C, 24 GPIO pins, not a lot more. Long lifetime so I don’t have to throw everything in the bin in the near future.
2. On a dead simple breakout board with crystals and external ST Link that doesn’t pretend to be arduino friendly.
3. Command line tool chain for Linux.

If anyone has any references or pointers or better ideas I’d appreciate it. 

Hello, I have seen this thread a couple of days and made note mentally to get back to it.. but got distracted with something else.

I do not have any specific advice except for the STM32cube nuking user code part.

The CubeMX software has

Code: [Select]

// User code here

//Exit user code here
sections in the boilerplate code generated. If your code is present in there.. then any regeneration after modification should preserve the user code.
It has been a while since I worked with CubeMX but this is what I recall was the behaviour!
Hope this helps..

[bd139]

Thanks for the reply. I got that far. Occasionally it nukes stuff inside the marked up blocks which is annoying. 

[AlfBaz]

So the question is where can I find something with the following requirements;

1. Not too big STM32. Something that FreeRTOS will be happy on. Five tasks, 64k or so flash (mostly LUT), not much stack. I2C, 24 GPIO pins, not a lot more. Long lifetime so I don’t have to throw everything in the bin in the near future.
2. On a dead simple breakout board with crystals and external ST Link that doesn’t pretend to be arduino friendly.
3. Command line tool chain for Linux.

1&2. I've used the f4's with FReeRTOS without a problem in particular the f407 and f429. You can get the STM32F4DISCOVERY dev boards for cheap, they're going for around $20 and have an on board stlink which can be used for the onboard MCU and for external mcu's

3. GNU ARM Toolchain should do the trick. It's a gcc fork by ARM. I originally set up a command line environment on windows so it should be a breeze on a linux machine. Some loathe gdb but I find it works well both on the cmd line and through eclipse, which is now my main setup.

Unfortunately, for me at least, all of the stuff I've developed is based on the old std peripherals libraries and newer chips such as the f7's don't have the std periph libs so you have to bite the bullet and go with cubemx.
Apparently you can just use the low level funcs and avoid all the abstracted stuff. Having said that the last time I looked people were saying cubemx had improved. At any rate if you want to use some of the more complex peripherals you're probably going to have to suffer hal unless you want to roll your own libs

[SiliconWizard]

As I repeatedly say - don't use CubeMX. Done. You may have a slightly steeper learning curve at first, but you'll quickly be glad you made the switch.

[bd139]

Yeah I'm done with that now. I've managed to get some stuff up from bare metal now compiling with GCC and makefile. Thanks for help so far everyone. Much appreciated.

Now onto working out how to program / debug the device!

[krish2487]

Also,
just look into libopencm3.
It is fairly mature and supports a lot of STM32 families. And the learning curve is not too steep.
:-)

[SiliconWizard]

Yeah I'm done with that now. I've managed to get some stuff up from bare metal now compiling with GCC and makefile. Thanks for help so far everyone. Much appreciated.

Now onto working out how to program / debug the device!

Have fun!

[Karel]

I guess you'll need also this:

Code: [Select]

git clone --depth 1 --no-checkout https://github.com/STMicroelectronics/STM32CubeF4.git

git checkout HEAD Drivers/CMSIS/Core/Include

git checkout HEAD Drivers/CMSIS/Device/ST/STM32F4xx/Include

Those are the header files that describes the internal of the MCU.

You'll also need some minimal startup code and a linker file.

I use the ones generated by System Workbench and adapted them to my needs.

I also use a modified makefile that once was generated by it as well. It speeds up things a lot.

[krish2487]

@karel
It looks very very interesting and promising. If it is not too much trouble, can you post a simple Blinky example using the files you have mentioned??
I would like to go more bare metal than libopencm3, and this looks like the way. But I am not so much proficient with linker scripts and makefiles.
I am looking for a barebones example that I can adapt to other families that I use and work with.
:-)

Thank you and my apologies for hijacking the thread.

I guess you'll need also this:

Code: [Select]

git clone --depth 1 --no-checkout https://github.com/STMicroelectronics/STM32CubeF4.git

git checkout HEAD Drivers/CMSIS/Core/Include

git checkout HEAD Drivers/CMSIS/Device/ST/STM32F4xx/Include

Those are the header files that describes the internal of the MCU.

You'll also need some minimal startup code and a linker file.

I use the ones generated by System Workbench and adapted them to my needs.

I also use a modified makefile that once was generated by it as well. It speeds up things a lot.

[Doctorandus_P]

If you want to get down to the absolute minimum, then "pandafruits" is a really excellent tutorial. It's a small website, with about 4 pages of text, and it handles stuff like writing your own linker script, statup code  and makefile to getting GDB working from the commandline.

Even if you normally work with those bigger frameworks, but are curious about the underlying mechanisms it is an excellent tutorial for the nitty gritty details most people just take for granted.

Another nice tutorial to get started with the Blue Pill is from:
https://jeelabs.org/2018/getting-started-bp/


Mini Davey Jones (long time no see) made a youtube vid about working with C++ templates for I/O. The video is quite nice although not complete, but it does show some of the power of templates.


Other experiments with templates for STM32 are from XPCC, Kvasir and Bmptk, and Jeenode already mentioned above.

[Karel]

I attached a "boilerplate" project with a blinky led and serial port example.
The serial port uses dma for rx, interrupts for tx.

For some unknown reason, the forum board does not accept tar.gz files so I renamed it to tar.zip.
After downloading the file, rename it back to tar.gz before trying to extract.

This example is made for the STM NUCLEO-L452RE evaluation board (Digikey: 497-17008-ND).
It comes with an STlink programmer on a break-out board connected to the dev board.
It costs only $15 so I strongly recommend to buy it and make sure this boilerplate works before
you start to modify it for your particular project and MCU.

You need the compiler toolchain which comes with the installation of the free System Workbench,
you can download it here (registration required):

https://www.openstm32.org

After installation of System Workbench, install the latest updates: in Eclips go to Help -> Check for Updates

Check if the following rules have been added to your /etc/udev/rules.d/ directory: (they are needed for the STlink programmer)

49-stlinkv1.rules
49-stlinkv2-1.rules
49-stlinkv2.rules
49-stlinkv3.rules

Restart your pc to make sure they are active.

Edit the files environment.txt and programmer/program_target.sh and adapt the path so that they point to the correct location.
(replace all instances of "<put your path here>") (it depends on where you have installed System Workbench)

Now you can start!

Usage:

open a terminal and cd to the boilerplate directory

source environment.txt   (to add the toolchain bin directory to the PATH variable)

make

./programmer/program_target.sh


now the green led of the devboard will blink


use "make clean" to remove all files generated by the make command



You will need the following documentation:

datasheet: STM32l452RE.pdf

errata: ES0388 STM32L452xx device limitations.pdf

programming, register descriptions, peripherals etc.: RM0394 STM32L43xxx STM32L44xxx STM32L45xxx STM32L46xxx advanced ARM-based 32-bit MCUs.pdf

UM1724 User manual STM32 Nucleo-64 boards

You can download them here: https://www.st.com and search for STM32l452RE and NUCLEO-L452RE

[krish2487]

Thank you.
That is very nice and helpful of you @karel! :-)

[Karel]

I tried also the ARM reference compiler which can be found here

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

but the linker script and startup code are not compatibel.

Is there some GNU tool-chain wizzard here who can fix this?

[Canis Dirus Leidy]

So the question is where can I find something with the following requirements;
1. Not too big STM32. Something that FreeRTOS will be happy on. Five tasks, 64k or so flash (mostly LUT), not much stack. I2C, 24 GPIO pins, not a lot more. Long lifetime so I don’t have to throw everything in the bin in the near future.
2. On a dead simple breakout board with crystals and external ST Link that doesn’t pretend to be arduino friendly.
3. Command line tool chain for Linux.

ChibiOS (Can run even on STM32F030F4)? It has it's own HAL, so you don't need any CubeMX. Here is some tutorials: https://www.playembedded.org/blog/category/articles/chibios-stm32/getting-started/ and example of pure command line compiling and debugging: http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:community:guides:work_without_ide

[mark03]

Another thing you might like to look into, if you grok GDB, is the "black magic probe."  This is like a JTAG adapter but instead of messing with OpenOCD and all that stuff, it implements the GDB remote debugging protocol over a virtual serial port on the host PC side, and SWD JTAG on the target side.  It works quite well.  You can buy ready-made / packaged units to support the developer, or just flash the firmware (it's open source on github) onto a spare Nucleo or Discovery board and use that.

[Karel]

Yesterday I installed STM32CubeIDE. It's a mix of STM32CubeMX and System Workbench.
Actually, STM32CubeIDE copied the GNU toolchain from System Workbench 

So, the boilerplate I provided can be used also with that tool chain (that comes with STM32CubeIDE).

Just modify the path's to:

<your path>/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.linux64_1.0.0.201904181610/tools/bin/

[chriva]

I've been using CoIDE for years but it's sadly discontinued. It has usable debugger support and does all the heavy lifting (generating projects and makefiles, fetching startup files etc) for you.

It's completely useless for newer chips and and is definitely not recommended in the long run since it's getting harder and harder to find but it would help you in the getting started compartment. You can use any hardware libraries you want and it'll make the hard stuff happen automagically if you want it to.


You still have to call functions/implement your own code to initialise hardware and pins etc but you don't have to deal with makefile generation and startup files.

[Doctorandus_P]

Recently I bumped into the book:

/STM32_Beginning_Developing_with_FreeRTOS_libopencm3_and_GCC from Warren Gay aka  VE3WWG

ISBN-13 (pbk): 978-1-4842-3623-9
ISBN-13 (electronic): 978-1-4842-3624-6
https://doi.org/10.1007/978-1-4842-3624-6
Library of Congress Control Number: 2018945101

It's got practical examples for most (all?) of the peripherals, and uses nothing but a Blue pill, a ST-Link V2 and open source software.

Even with EUR30 for the book it's much more (cost and time) effective than collection all kinds of bits and pieces of info from around the 'web.

Nowaday's STM Cube seems to be the "default" way to go. It's got a gui for clicking together clock sources, pll settings and Pin usage (including alternate pin functions), but it's not "polished" yet. I've heared some stories about configuration files getting overwritten and other problems.

LibOpenCM3 is an pretty simple and low level library for interfacing with the STM32 peripherals. It's got just enough abstraction that you do not have to mess directly with hardware registers if you don't want to, but is cleanly written and is close enough to the hardware registers that (with a decent IDE) you're a few mouse clicks away to see in the code what register manipulation is done to initialize a peripheral.

I've looked into the older STM32 stuff from ST, and then you get stuff as declaring a structure, setting some bytes in that structure, and then calling some initialization function with that structure as parameter. It sure is "flexible", but it looks like Yuch!
I've also followed code 4 or 5 function calls deep with the only result an empty function with the comment "you can add your code here". Duh, I just wasted another 10 minutes following that trail to a dead end.

LibOpenCM3 is short, straight to the point and easy to understand. A disadvantage of LibOpenCM3 seems that there is not much development is going on. The project seems sort of dead, and may also be incomplete even for supported microcontrollers. Despite this, it still may be a good start to get acquatinted with STM32 because it's so simple and neatly written. Also the book mentioned earlier helps a lot.

[Sal Ammoniac]

Another option for STM32 is Segger's Embedded Studio IDE. It's free for non-commercial use and is fast and efficient (it's not based on Eclipse) and runs on Windows, Linux, and MacOS. It does, however, only work with J-Link debug probes, but that's not a problem for Nucleo and Discovery boards because Segger provides firmware for the boards that turn the on-board ST-Link into a J-Link.

https://www.segger.com/products/development-tools/embedded-studio/

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[HackedFridgeMagnet]

I've used CubeMX and the HAL on quite a few projects mainly f4 and f7. It's been fine. USB, Ethernet, HTTP,  SPI, ADC, GPIO, DMA, RS485, RS232, FreeRTOS. Also a bit of Bluetooth and LORA.
Just put your code in the places it says user code and the code generator wont overwrite them.
I think it would've taken me ?? to write these libraries myself so I am pleased to be able to access them.

Importantly use source control (I use SVN ) to watch any changes generated by the code generator.

My biggest problem was with the F7 as some STM32F7s have a hardware problem for the debugger stepping past code with interrupts firing.
Apparently it is now fixed but my supply of chips are still the bugged ones.

[S. Petrukhin]

If you want to fully own and control the processor, and not guess what surprises CubeMX, HAL and other dark friends give you, take the wonderful compiler mikroPascal, or mikroC, or even mikroBasic by MikroElektronika from Serbia. You won't get a connection to CubeMX, but you will get full programming power with step-by-step debugging on a chip. In addition, this company produces the one in the world's wireless  programmer Codegrip.

[Kjelt]

If CubeMX really overwrites your code then use version control like Git or svn.
Check in your code before you start Cube to make some changes and afterwards do a folder/file compare to review all changes. Revert everything (the parts) that went wrong only keep the relevant Wanted changes and continue.

Another option I haven't tried myself yet is to use as others suggested above the gcc toolchain from Arm and export the Cube stuff to gmake export. Should work what I read. At least you can build the code a few years from now, but not make changes with Cube anymore (probably).

I do not like the Cube diarea of crap output much but it seems to have some nice extras like ip-stack, GUI lcd stack etc. Perhaps I will give it a retry.

[bikeNomad]

An excellent (free and open-source) option that I've been recommending for some years is the ARM mbed system. https://os.mbed.com/
They support a wide variety of STMicro boards (see https://os.mbed.com/platforms/?q=&Target+vendor=STMicroelectronics).
It has an RTOS, support for Bluetooth, Wifi, Lora, etc. and is cross-platform and written in relatively modern C++.
They now have an IDE called Mbed studio that does a decent job of debugging, editing, and project management.
Mbed Studio comes with a free copy of the ARMC6 compiler, but can be told to work with GCC or IAR toolchains as well.

[Kjelt]

I looked at mbed five years ago , was there not a big catch that you needed some special bootloader or something?