Blinkenlights To Bootloader: A Guide To STM32 Development

While things like the Arduino platform certainly opened up the gates of microcontroller programming to a much wider audience, it can also be limiting in some ways. The Arduino IDE, for example, abstracts away plenty of the underlying machinations of the hardware, and the vast amount of libraries can contribute to this effect as well. It’s not a problem if you just need a project to get up and running, in fact, that’s one of its greatest strengths. But for understanding the underlying hardware we’d recommend taking a look at something like this video series on the STM32 platform.

The series comes to us from [Francis Stokes] of Low Byte Productions who has produced eighteen videos for working with the STM32 Cortex-M4 microcontroller. The videos start by getting a developer environment up and blinking LEDs, and then move on to using peripherals for more complex tasks. The project then moves on to more advanced topics and divides into two parts, the development of an application and also a bootloader. The bootloader begins relatively simply, and then goes on to get more and more features built into it. It eventually can validate and update firmware, and includes cryptographic signing (although [Francis] notes that you probably shouldn’t use this feature for production).

One of the primary goals for [Francis], apart from the actual coding and development, was to liven up a subject matter that is often seen as dry, which we think was accomplished quite well. A number of future videos are planned as well. But, if you’re not convinced that the STM32 platform is the correct choice for you, we did publish a feature a while back outlining a few other choices that might provide some other options to consider.

15 thoughts on “Blinkenlights To Bootloader: A Guide To STM32 Development

  1. They seem like great chips.

    Part of my job is swapping out counterfeit STM32F103C8T6 chips. It’s not that the fakes are hard to spot (Thanks Hackaday!), just that they take forever to program and usually can’t be accomplished without a few power cycles and dedicated erase cycles. Read: Frustration and cursing. And they all have the same internal serial number. Thankfully Digikey has real ones back in stock now.

    1. STM32 parts are not very good. The peripherals are poorly designed. It’s all let down by their mediocre and buggy CubeIDE, and even worse HAL library.

      Bare metal programming helps avoid some of the HAL issues, but because the peripherals are mostly awful it’s no fun. Microchip SAM is a much better bet, being designed by Atmel who have much nicer peripherals.

  2. Great job doing such a good series.

    However calling this “baremetal” is a bit funny. This is actually the “normal” way to write software for STM32 or basically any microcontroller.

    Baremetal in this case would be doing this without ANY libraries and using direct memory addresses to access registries and perephials.

  3. if you want actual bare metal stm32 i put together an intro. assembly and custom ldscript. i don’t mind that people use libraries and stuff…i’m even coming to the idea that on these arm embedded chips it’s probably the way to go. but if you really want bare metal, it’s a chip that’s pretty amenable to that as well:

    http://galexander.org/stm32

    (note, this is for the stm32f103, which is cortex-m3)

  4. kuro68k does not know what is good for him. Microchip Studio sucks bad !!! Most IDE’s use Eclipse. Microchip Studio uses visual studio which I have encountered many problems with. The Atmel Start feature is weak at best. Cube IDE is very nice, MCUXpresso is good. Moun River studio is fine. I like ARM, Risc-V. But Atmel/Microchip is not in my toolbox.

  5. @07:50 it is mentioned (for the first time) that this series is based around LibOpenCM3. I’m pretty much divided about diving into LibOpenCM3. Their website is … mostly empty, with a link to a github repository, that was last updated in 2015, now 8 years ago.

    On the plus side, it is a pretty thin layer. Just the minimum necessary to get you going without too much fuss and make your code reasonably portable (that is, if the LibOpenCM3 library was further developed to support more uC’s. And because it’s such a thin layer, you can use it for your own libraries, and then just intermingle it with other things such HAL, or Cube without having too much impact on code bloat.

    And for anyone interested in LibOpenCM3, I highly recommend the book:
    “Beginning STM32: Developing with FreeRTOS, libopencm3 and GCC” by Warren Gay.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.