MCU’s are typically reprogramming, so there are several considerations when designing the hardware:
- easy hookup for development
- In-system programming
Development
Although there are cheaper ways, the STLINK-V3 is only $35, and is compatible with Zephyr with no configuration, so highly recommended that a header for this programer be placed on all STM32 MCU designs for easy programming and debugging during development.
One source of this header is the Amphenol FCI 20021121-00010C4LF. This is a 1.27mm pitch, 10-pin connector, so does not take up much space. The pinout is:
The recommended signals on the PCB are:
The header should be oriented on the PCB such that the STLINK cable naturally flows to the closest edge of the board (as shown above). Then the cable does not get in the way, and you always know how to orient the connector on the header.
In-system programming (ISP)
The second consideration is how to update the MCU in the field. There are many ways to do this. Bootloaders like MCUBoot can be used. Transports to get the firmware to the MCU might include USB client, serial, network, SD card, etc.
The STM32 parts also include an Embedded boot loader (AN2602). This built-in bootloader can also be used to program the device in-system over USART1-3, I2C1-3, SPI1-2, CAN1, and USB (full speed). Supposedly the dfu-util program can be used to program devices over USB.
The flow chart for the bootrom operation for the SMT32L43xxx is shown below:
MCUBoot
MCUBoot is an advanced, secure bootloader that has been integrated with Zephyr. The ESP32 devices appear to have MCUBoot already integrated. Other devices may require more work. MCUBoot is attractive if you have extensive security requirements (signing, etc).
Customer Zephyr based bootloader
Yet another approach is to create a custom bootloader based on your existing Zephyr application. The advantage of this approach is you already have the OS configured for your hardware, and adding a few routines to to read the image and write it to flash is not a huge project – often easier than integrating other bootloaders. However, adding security to this approach can be a lot of work.
The ideal solution
The ideal solution would be if Zephyr supported a number of bootloader functions in a modular fashion so that you could build in just the pieces you need.
In-system architecture decisions
Different systems have different needs, but perhaps the most fundamental question is our you going to download a complete image, verify it, and then flash it, or program the MCU block-by-block (DFU style) and simply start over if the programming fails. If you have a Host system always connected, then the DFU approach makes a lot of sense as it is built-in and simple. However, for a stand-alone MCU application that downloads the update over the network, you want to make sure the update is complete and valid before programming it. Additionally, you may need to consider the possibility of programming being interrupted due to power loss and other events.
If the MCU is used to manage the power of the host processor, which is a common application for MCUs (system management), then the DFU approach may not be the best. Rather, the Host downloads an update to the MCU which is stored in SPI flash, then the MCU reboots into the bootloader to finish the update, and the Host is powered off during this time.