Secondary boot loader + internal boot loader

[ECost]

Hello,

I am considering to develop a small secondary boot loader for STM32F030xx.

My idea is this BL checks the CRC of the application image and jumps to it if CRC matches. A second fallback image would be jumped to should the primary one be invalid (e.g. previous update attempt failed due to power loss) so that the device would be capable of minimally work to allow for a new update attempt.

The BL would call STM32 built-in BL if it detected a magic value on the USART data register. Update could also be started by the application itself, which could directly call the built-in BL or pass a magic number to the secondary BL for it to call the built-in BL.

However, I would not like to reinvent the wheel. Is there some BL that does something similar that I could adapt?

FWIW I looked at AN4657 and I noticed it uses ymodem protocol instead of using the built-in BL. Any reason for that? Is there any advantage of the former of the latter?

Thank you

[Tesla DeLorean]

>>Any reason for that? Is there any advantage of the former of the latter?

Well X/Y-MODEM is in every terminal application of any merit, and a far more efficient/robust algorithm. The ST loader algorithm is supported by a smaller subset of apps, although I've written my own for production programming and recovery tools.

[ECost]

Hello, Clive, thanks for you quick response. It makes sense.

But this X/YMODEM version looks more like a proof of concept as the protocol, unlike STM32's BL, does not support commands (lock/unlock/go/upload/download etc.). Using it for offline upgrade would require some tweaks and creating some protocol extension.

I agree STM32 bootloader protocol does not seem very robust. Is there any alternative?

Again, thanks for your help.

[Tesla DeLorean]

>>Is there any alternative?

Well you can use it as a staging loader, ie use it to push a more feature rich loader into RAM and then run that. If you have larger NAND/NOR devices you'll need your own external loader for that. If your board has Ethernet you can stand that up and pull images, or use an SD Card

You can make your own IAP implementation do anything you want. I tend to provide recover methods via RS232, so X-MODEM allows for an OS agnostic update method, and not requiring additions drivers or software to support in the field. You can sign the image with a hash or CRC, and also compress and encrypt as desired.

[ECost]

>>You can make your own IAP implementation do anything you want. 

The problem is that it is more software (firmware) to design/write/debug/validate. :sad_but_relieved_face: ;)

Also, I like the idea of using the built-in BL in production as you mentioned above. I saw some utilities such as ST's flash loader and STM32Flash that, if I understood it right, may directly "talk" with the BL and provide a starting point.

I did some research before and could not find anything close to what I was thinking and it seems from your answers that I will not. So I will have to do some code as this wheel has not yet been invented or it was invented but not made available as an open source project.

FWIW I have considered OpenBLT (I have used in another life) but it would still involve dealing with two different protocols.

[Tesla DeLorean]

ST's protocol is documented, not hard to cook from scratch.

[ECost]

>>Well you can use it as a staging loader, ie use it to push a more feature rich loader into RAM

About this comment, is not it possible to run from flash? I mean, whatever the path I chose, the secondary boot loader would be in a page that would never be erased and the application(s) located on upper blocks. No block erase.

[Tesla DeLorean]

The point of using RAM is that it tends to be inherently faster, doesn't stall the processor and the content transient, and thus harder to take and reverse engineer. If you're trying to avoid consuming your FLASH with code that's only used in the 0.0001% use case, you store it in the PC based flasher and push it across when needed, and for the specific parts if your BOM covers multiple potential memory devices over the product life-span.