STM32F429xx/39xx Native Bootloader

[afduarte]

Posted on August 13, 2014 at 16:18

Hello guys,

Ive been looking into the STM32F429xx/39xx native bootloader.To serve as a guide, here are the steps to be able to use the native bootloader:1. Jump to BTL mode, in this MCU version the best way (personally) is actually by performing a MASS FLASH erase in the APP code, activate the BFB2 option byte, and execute a soft reset (AN2006 page 78).2. Use the ST Flash Loader demo app, using UART 1 or UART 3 (specified IOs).---Now im developing a C♯ application instead of using the STM Flash Loader, and i successfully implemented all commands, but what happens if something hangs in the BTL firmware serial main loop, how can i reset the MCU to be able to resync the UART.For instance after an RDU command (0x926D) if the following command is not an SYNC 0x7F), the BTL stops replying and the only way is to perform a hard reset.Put it simple is there any way to perform a native bootloader reset, or re-initialization, via software, i cant find in the documentation.Thanks. #bootloader #stm32f429/39

[Tesla DeLorean]

Posted on August 13, 2014 at 17:36

Yes, after the 0x92 command completes it resets the part. You must then send the 0x7F to establish the baud rate. If the part misinterprets that, it will be using the wrong baud rate to communicate with you.

The loader firmware does have a watchdog time out, so I'd assume it can do the 0x7F calibration over again at some point.

[afduarte]

Posted on August 14, 2014 at 10:34

Hi Clive, 

Thank you for the quick reply.Yes i would assume too, but even after 1min the watchdog has not kicked in, so i assume its been patched anyway.Now this behavior can actually cause problems in production. An user can after an failure in the host APP, can no be able to resync the BTL UART... Making a remote update a dangerous procedure. So i would recommend in the next iteration of the native BTL, maybe lock the baudrate, and maybe add a command to reset the BTL app, just for the sake of automatically restart all internal pointers and variables to make the process of retry to load the App easier.Thanks,AD

[afduarte]

Posted on August 14, 2014 at 17:43

Hi guys,

After successfully build a C# App to make a serial update using the native bootloader, found another, quite obvious problem with the native bootloader firmware.If the Host App fails to complete the write sequence, the current BTL firmware will accept the incomplete written data as a valid App and jump to App code.And after that there is no way an operator can enter in BTL mode, except using the BOOT pins.Cheers,AD

[Tesla DeLorean]

Posted on August 14, 2014 at 17:49

If the Host App fails to complete the write sequence, the current BTL firmware will accept the incomplete written data as a valid App and jump to App code.

And after that there is no way an operator can enter in BTL mode, except using the BOOT pins. Understand that the loader doesn't ever run or jump to anything, the BOOT pins shadow a specific memory at zero during boot, and the processor starts whichever one you pick. If you put broken code on the part it will run that. If you want to alter the behaviour and checksum an application image you'd put your own loader at the front of the flash, and have it validate secondary application code before jumping to it. If you have a singular monolithic firmware image, place some validation code in the ResetHandler path, near the front, and have it do some magic if a trailing checksum is missing or invalid. Production programming assumes you have access to BOOT and NRST pins.

[afduarte]

Posted on August 14, 2014 at 18:06

Hi Clive,

Yes agree, im definitely taking the path of building my own BTL firmware to suit my needs...''If you have a singular monolithic firmware image, place some validation code in the ResetHandler path, near the front, and have it do some magic if a trailing checksum is missing or invalid.''True, still if you are using the native BTL, you are going to end in a endless loop, unless you actually jump to another backup App (lets say in the other mem bank) ...

[Tesla DeLorean]

Posted on August 14, 2014 at 18:19

True, still if you are using the native BTL, you are going to end in a endless loop, unless you actually jump to another backup App (lets say in the other mem bank) ...

It's all going to depend on exactly how much code you burned on the part before your programming app ''failed''. It's certainly possible with strategic code placement, and a plan, to have enough code there to de-brick the device. Wouldn't part of the programmers task be to actually verify the data written to the part? And you are not required to fill the memory in a linear fashion.

[afduarte]

Posted on August 15, 2014 at 10:44

There are always things a programmer cant control such as power failures. In that case with the native bootloader without a backup application and without access to the hardware pins the operator is in trouble.

Off course a good programmer can always take that into account and make extensions to the native functionality.