Sometimes you don’t have access to the module programming port when it is embedded in the middle of an array, and you don’t want to use the SWD pins; or sometimes you design your array so that programming ports are connected to other ports; sometimes you’re just feeling lazy and don’t want to reach each module to update its firmware individually! For all these cases, our platform provided you with a feature to remotely update a module via another using ST factory bootloader and the STM32CubeProgramming tool. Check this article to have a review of all firmware update methods in Hexabitz.

Usage

The same command used for normal bootloader update is used for remote update. There are two basic forms:

#3.update

Where you remotely update module 3 via another module. Note in this case module programming port (marked with asterisk) must be in the shortest path to the module. An example of this is updating module 2 in the array below while connecting to module 1, port 1.

The other format (via-port remote update) is:

update via #3 p5

Where you remotely update the module that has its programming port connected to module 3, port 5. This format is useful in two situations:

• If the module you want to program is not a part of the array topology (i.e., it doesn’t have an ID and topology). Similar case happens when the module doesn’t have a firmware.
• If the module programming port is not on the shortest path from where you are sending the command. An example of this is updating module 3 or 5 via module 1 in the array below. Programming ports are marked with red circles. It’s obvious that the shortest path from module 1 to module 3 (the yellow route) ends up in port 3 of module 3 which is not the programming (factory bootloader) port. In order to reach port 2 of module 3 (the orange route), you can use the command:

  update via #4 p3

Note: After remote updates, you need to power cycle the entire array to restore normal operation.

How does it work?

The remote update command backend stacks up serial ports and DMA streams to construct a bidirectional pipeline between the port connected to ST Flash Loader tool and the programming port of the target MCU (which will be running ST factory bootloader through that port). However, a few things must happen first, in the correct order, before establishing a successful connection:

1. The source module sends a message to the target module, asking it to jump to its bootloader. In the remote update format #n.update, n is the target module. In the remote via-port update format update via #n pm, the target module is the one connected to module n, port m. Note that if you want to update firmware on an empty module (or one that doesn’t run any Hexabitz firmware) and the module is not in its bootloader mode, you must manually force it into that mode.
2. Baud rate for all involved serial ports must be changed to 57600 in order to be compatible with ST bootloader settings.
3. Parity for all involved serial ports must change to EVEN to be compatible with ST bootloader settings.
4. The last port before the target must swap its pins, since the serial port in ST bootloader will restore its normal pinout configuration.
5. Finally, a bidirectional DMA stream must be established. The stream is set up with infinite timeout and number of bytes. Thus, once you’re done with the update, you must power cycle the array to restore everything to normal operation.

Examples

The video below shows a step-by-step guide of remote updating module 2 in the array above from module 1, port 1.