STM32H755ZI bricks after firmware upload or when firmware upload crashes

[kps98]

Hi all,

We’re a small startup developing a commercial product using an STM32H755ZI, and we’re getting ready to ship. One of the key things we want to bulletproof before launch is firmware recovery for end users, especially in case the firmware upload fails (e.g., they unplug during flashing, or the update crashes). At the moment we erase the flash memory and uploads elf files using dfu utils. It works most of the times but we've noticed that when it fails there is no way of getting the device running again unless st-link is used. Even having a switch for boot pin is not helping.

Here are our questions:

• Is relying on the dfu utils safe and recommended for production units?

• What are the best practices for implementing this kind of user-friendly recovery flow?

• Are there better tools or alternatives to dfu-util for desktop apps?

Any help or advice would be really appreciated. Thanks!

[kps98]

It was not jumping to DFU even with boot0 pin. I am now working on a custom bootloader which jumps to dfu or app based on image.

[kps98]

Yes, i'm using system DFU bootloader. Can you please elaborate or guide me to what i should do in the option bytes. Thanks

[Pavel A.]

> Using STM cube programmer is not an option as we need it to update firmware using our software. 

The CubeProgrammer has API for developing custom solutions. It supports the SWD connection and DFU mode as well. And external loaders.

0 Kudos

[Pavel A.]

> I am looking into custom boot loader now. Haven't coded that before, looks like a huge learning curve. 

Correct, so if possible leave this for latter. Consider outsourcing it so you won't be distracted from your main projects.

.

[kps98 · Accepted solution]

Thanks for the response everyone. I kind of wrote a simple bootloader for this. I split the flash into different sections. sector 1 was assigned for boot loader, then i assigned 384KB each for two different slots for M7, and two slots of 512KB each for M4. Then I added CRC and Magic number to the bin file that i upload. When i upload my firmware, it goes to slot B for both cores. Then my bootloader checks if the CRC and magic number is valid or not. If it is valid i copy my slot B to slot A. This way i will always have a backup version. My new code is always stored to slot B if it's not valid it won't be used and customers can still get firmware upgrade later as slot A makes sure that device runs. Even if the copying between slots fails i will still have a valid copy of firmware in Slot B which will be copied upon restart. I also check if CRC values of slots are same or not. If they are the same i won't copy code from slot B. Using write protect, i made sure that bootloader can't be erased. So even if both slots fail i can still upgrade firmware through bootloader.