1. Home
  2. Docs
  3. How-To
  4. Update module firmware
  5. Remote Bootloader Update

Remote Bootloader Update

Sometimes you don’t have access to module programming port when it is embedded in the middle of the 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 connect to each module to update its firmware! For all these cases, we added a feature to remotely update a module via another one using ST factory bootloader and the ST Flash Loader Demonstrator tool. Check this article for 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. 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 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. Example of this is updating module 3 or 5 via module 1 in the array below. Programming ports are marked with red circles. It can be seen that 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, you can use the command (the orange route):
    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 target MCU (which will be running ST factory bootloader through that port). However, few things must happen first, in the correct order, before a successful connection:

  1. The source module sends a message to 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 Hexabitz firmware) and the module is not in its bootloader mode, you must manually force it into that mode.
  2. Baudrate for all involved serial ports must change to 57600 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 setup 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.

Was this article helpful to you? Yes No

How can we help?