cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a workaround for the 'Additional reset needed after power off/on to enable connection to the BL interfaces' bootloader bug of STM32H743?

JArwe.1
Associate II

I would like to use the integrated Bootloader of the STM32H743 for updating the firmware over I2C. I don't have access to BOOT or RESET pins at the I2C master side, so my desired procedure would be:

  1. Send a command over I2C to my firmware. Once my firmware receives this command it performs a jump to bootloader (like described here: https://community.st.com/s/article/STM32H7-bootloader-jump-from-application)
  2. Use the bootloader commands to erase and flash the new firmware
  3. Use the bootloader Go command to jump back to my firmware

I have this procedure implemented, but I am having some issues, specifically directly after Power-On of the system. Basically, after performing step 1, the bootloader just doesn't respond on the I2C interface. Once I do a manual reset (via RESET pin) and repeat step 1, the bootloader now responds and the rest of the procedure works just fine. Everything then works fine until the next power cycle.

I assume this is related to the 'Known limitation' listed in Chapter 48.3 of AN2606:

Additional reset needed after power off/on to enable connection to the BL interfaces

I tried a couple of stuff, my findings are:

  • Using the BOOT pin instead of the software jump to bootloader does not make a difference
  • A normal reset while the STM32 is NOT in bootloader does not seem sufficient; the reset seemingly has to be performed while the device is already in bootloader (but not responding on I2C)

Of course once the device is at the customer, a manual reset is not an option. This leaves me in a difficult situation, as I don't have any possibility to reset the STM32 over the I2C bus once it is in bootloader and not responding.

My question now is: Is there any way to make this procedure work despite the bug in the bootloader? Some way to prepare the chip in the firmware before doing the jump to bootloader to work around this bug?

Thanks!

0 REPLIES 0