Hi all! I’d like to share some news on Mbed CE changes over the last couple months! There’s still a boatload to do, but little by little, things are happening.
STM32H5 Support
Thanks to @JohnnyK 's hard work, we now have partial support for the STM32H5 processor architecture! There’s still a ton to do, but core functionality, such as the ADC, PWM outputs, I2C, and SPI (including DMA SPI) is tested and working. Over time we hope to improve support further, such as adding Ethernet and USB compatibility. I’m super stoked because this is the first completely new MCU family that Mbed CE has added support for !
STM32H7 Improvements
I’ve been turning my attention recently to the STM32H7 family of devices, as these are some of the most popular and capable microcontrollers used with Mbed OS (and are especially commonly used in Arduino products). Despite this, they were badly in need of some love and refactoring, as there were a number of issues with their linker scripts, clock configurations, and other code.
Now, each sub-family of STM32H7 devices uses one single clock configuration file and linker script. No more copypasta, and development and bugfixes for these devices will be way easier. After extensive research, I created a doc page that outlines exactly which of these chips we support and how they are related to each other in terms of memory and features.
Compilation and Build Fixes for Many Targets
Over the past two years of work on Mbed CE, with extensive rewriting of the build system, and without access to a large percentage of the target devices, how many Mbed targets do you think had their builds broken by accident? Well, I’ll give you a hint, it was more than 0. But it should be close to 0 now, because we have implemented a large matrix of CI builds that compile Mbed for at least one MCU in every single target family. Many of these builds were indeed broken, and they are fixed now! So, using Mbed with Cypress, Maxim, Renesas, and Nuvoton boards should be much more likely to just work now.
Speaking of Nuvoton, I’m incredibly excited to welcome @ccli8 as a contributor to Mbed CE! @ccli8 is an engineer at Nuvoton and has been helping test out Mbed CE on a number of different Nuvoton boards. They’ve added a full set of upload method configuration files for all Nuvoton targets and have fixed a number of issues with building and uploading that prevented TFM-enabled boards from working with Mbed CE.
Memory Bank Information
Last but not least, my main focus for the past couple of months has been bringing memory bank information to Mbed CE. To recap my previous post, this has never properly been supported in Mbed CLI 2 and a new implementation of this feature has been sorely needed. Mbed now tracks which flash and RAM banks exist on each MCU and passes this to the source code and the build process. Not only does this let certain parts of the Mbed code and linker scripts be written a lot more cleanly, but it also lets us do something really cool with the build report. The memory map script can now display each memory bank and its fill percentage!
RAM Bank SRAM_D2: 278528(+0)/294912 bytes used, 94.4% (+0.0%) used
RAM Bank SRAM_D1: 16064(+0)/524288 bytes used, 3.1% (+0.0%) used
RAM Bank SRAM_D3: 0(+0)/65536 bytes used, 0.0% (+0.0%) used
RAM Bank SRAM_DTC: 256(+0)/131072 bytes used, 0.2% (+0.0%) used
RAM Bank SRAM_ITC: 0(+0)/65536 bytes used, 0.0% (+0.0%) used
RAM Bank SRAM_BKUP: 0(+0)/4096 bytes used, 0.0% (+0.0%) used
ROM Bank IROM1: 139280(+0)/2097152 bytes used, 6.6% (+0.0%) used
When I used Mbed in the past, I often struggled to understand exactly how much memory existed on my device and how it was allocated into banks. I hope that this report will clear things up a lot going forward!
Changes to be aware of
The memory bank information PR is a pretty huge change to certain Mbed internals, and unfortunately is a breaking change for custom target users. For right now, custom targets will need to do one of the following when used with the latest version of Mbed CE:
- Declare a
"device_name"
property in their target JSON that matches an MCU name known to Mbed (see the MCU description file’s top level keys for the list of valid names)
- Extend a target built in to Mbed that declares a
"device_name"
property
- Declare their own
"memory_banks"
property that declares memory banks to Mbed. This method should be used if the MCU used in the custom target is not one known to Mbed OS. See section 4 of the proposal linked above for formatting examples for this section.
The other thing to be aware of is that, when updating to new versions of Mbed CE that support memory bank information, everyone will need to delete and recreate their CMake build directories. This will make sure that the memory bank information gets generated. The latest version of Mbed CE now generates an error if it suspects you’ve forgotten to do this.
Well, that’s all I got for now, but we are still working away on new changes! My most immediate priority is a rewrite of the STM32H7 ethernet driver, because I’ve discovered… well, a lot of sketchiness, and it prevents Ethernet from working on these devices in certain cases. I am also continuing to work on finishing up the CI test shield and putting together a larger device testing operation.