OpenBootLoader Advice / Best Practice

[DenzilDexter]

Hello Forum,
I would appreciate some advice regarding bootloaders. Apologies in advance as this is mostly new to me. I have been researching the pre-programmed ST System Bootloader and OpenBootLoader (OBL) to try and figure out whether they are appropriate for firmware update in our product. Our product will most likely contain multiple STM32U5 MCUs connected together on a CAN bus. Firmware update will be performed from a Windows PC either connected to the same CAN bus or via USB to the 'main' MCU. The main 'MCU' is likely to have a 64MB filesystem available to it.

Assuming we decide to use the ST SystemBootloader then these questions come to mind:

• I guess the general approach is - get the MCU running the SystemBootLoader, Update the firmware, Re-boot to new firmware.
• What's the usual way to get the system to boot to the SystemBootLoader? I have read that this is possible using 'boot option bytes' but what set's them? In AN2606 it talks about how to activate the Bootloader on 
  Page 31: Bootloader Activation and for the STM32U585 - it's Pattern 12 - How is this pattern applied and when?
• I cannot see a way to verify the image on the target. The bootloader simply receives data over whichever bus is activated and writes it to flash. If I wanted/needed to validate the image on the target (e.g. via a digital signature) then I guess that would exclude the use of the SystemBootloader.
• What's the recommneded way of updating each MCU's firmware? I see the SystemBootloader can only cope with 1 CAN node so I'm unsure of what to do to update all of them. I can obviously devise a scheme to do something proprietary but I was hoping to avoid that if there's a standardised approach.

Assuming we decide to use the OpenBootloader at the start of flash and the application at an offset from that like this:

----------------------
      (ROM)
SystemBootloader --|
----------------------   <-| Jump (option byte settings)
     (Flash)
OpenBootLoader --| On Go Command
---------------------- <-| Jump
     (Flash)
   Application
----------------------

The SystemBootloader loads runs OpenBootloader. This, so far as I can tell by looking at the code, will sit forever waiting for the GO command which is not want we want if an application has already been programmed. How should we approach this? It seems to me that there needs to be a mechanism to tell OpenBootLoader to just jump to the application but I'm 0% sure of this as I have no experience. What would be the right way?

Any advice much appreciated.
/P

[Saket_Om]

Hello @DenzilDexter 

Please refer to this article to implement your boot process. 

[Javier1]

I ve been down this road already a couple of times.

>>Our product will most likely contain multiple STM32U5 MCUs connected together on a CAN bus. 
https://community.st.com/t5/stm32-mcus-products/is-the-stm-system-bootloader-trough-canbus-just-not-woking-when/m-p/165204

System bootloader (Trough classic CAN or FDCAN) doesnt like multi node canbus buses so not suitable for your application unless you do some trick disabling the canbus of every non-being-updated node.

Go straight to develop your own CAN bootloader (maybe based on openBL so you can use CUBEprogrammer and stlink)

>> I cannot see a way to verify the image on the target.
Cube Programmer verifies (by reading back) after writting to flash, see my cubeprogrammer logs from today using my own openBL based bootloader

  15:16:19 : STM32CubeProgrammer API v2.18.0 | Windows-64Bits 
  15:16:27 : UR connection mode is defined with the HWrst reset mode
  15:16:27 : ST-LINK FW  : V3J8M1B5
  15:16:27 : Voltage     : 0.00V
  15:16:27 : Bridge Freq : 48000 KHz
  15:16:27 : Baudrate    : 125 Kbps
  15:16:27 : BL version  : 2.0
  15:16:27 : Device ID   : 0x469
  15:16:28 : UPLOADING OPTION BYTES DATA ...
  15:16:28 :   Bank          : 0x00
  15:16:28 :   Address       : 0x1fff7800
  15:16:28 :   Size          : 36 Bytes
  15:16:28 :   Bank          : 0x01
  15:16:28 :   Address       : 0x1ffff808
  15:16:28 :   Size          : 36 Bytes
  15:16:28 :   Bank          : 0x02
  15:16:28 :   Address       : 0x1fff7828
  15:16:28 :   Size          : 4 Bytes
  15:16:28 :   Bank          : 0x03
  15:16:28 :   Address       : 0x1ffff828
  15:16:28 :   Size          : 8 Bytes
  15:16:28 : UPLOADING ...
  15:16:28 :   Size          : 1024 Bytes
  15:16:28 :   Address       : 0x8000000
  15:16:28 : Read progress:
  15:16:28 : Data read successfully
  15:16:28 : Time elapsed during the read operation is: 00:00:00.208
  15:16:49 : Opening and parsing file: nucleog474_blinky.elf
  15:16:49 : Memory Programming ...
  15:16:49 :   File          : nucleog474_blinky.elf
  15:16:49 :   Size          : 5.80 KB 
  15:16:49 :   Address       : 0x08008000 
  15:16:49 : Erasing memory corresponding to segment 0:
  15:16:49 : Erasing internal memory sectors [16 18]
  15:16:49 : Download in Progress:
  15:17:06 : File download complete
  15:17:06 : Time elapsed during download operation: 00:00:17.085
  15:17:06 : Verifying ...
  15:17:06 : Read progress:
  15:17:08 : Download verified successfully 
  15:17:08 : RUNNING Program ... 
  15:17:08 :   Address:      : 0x08008000
  15:17:08 : Start operation achieved successfully

>> I see the SystemBootloader can only cope with 1 CAN node
Exactly, some people use UART and start shapped conections
 

>>This, so far as I can tell by looking at the code, will sit forever waiting for the GO command which is not want we want if an application has already been programmed. How should we approach this?

You could implement a software timeout or configure the IWDG (openbootloader already did half of the work there)
To stay 1s or 2s waiting for bootloading commands and after that jumping to your APP  (if memory is not empty and checksum is alright )

[DenzilDexter]

Thanks Saket, I had seen that.

[DenzilDexter]

Javier, thanks for taking the time to reply in such detail.  I think we will go down the route of modifying OpenBootLoader to meet our needs.  Our current thinking is that the bootloader (BL) will jump to the application if one has been programmed (magic # in flash at some predefined address) - otherwise it will sit waiting to be asked to do something.  We will incorporate into the application the means to jump to the BL on command.  

Our main MCU will control the firmware update of the other MCUs in the system over CAN using a mechanism of our own making.  I have CANopen working on an STM32 F303K8TX and so maybe we'll use the SDO protocol in it - otherwise we'll just transmit CAN frames.

On the subject of image validation I was thinking more about whether the image supplied by the PC is one that should be programmed onto the devices - so rather than a simple CRC I had envisaged a digital signature.  This would be validated before programming even began.  Any thoughts on this would be welcome.