ARMmbed/mbed-os-example-bootloader

Booting application after update doesn't work if using application header

Closed this issue · 3 comments

NiallBegley commented

Description

Device: STM32F469I-DISCO
Toolchain: GCC-ARM
Tools: mbed cli version 1.8.2. Output of mbed config --list:

GCC_ARM_PATH=/home/devadmin/Downloads/gcc-arm-none-eabi-7-2017-q4-major/bin/
ARM_APTH=/home/devadmin/ARM_Compiler_5.06u6/bin
[mbed] Local config (/home/devadmin/new/mbed-os-example-blinky):
TOOLCHAIN=GCC_ARM
TARGET=DISCO_F469NI

I had to make a few changes to the target files (copied almost exactly from this commit: ARMmbed/mbed-os@4d0535a), but I've gotten this bootloader example working just fine on my STM32f469I-DISCO when using the example blinky project without a header, but as soon as I compile the application with the header and use this application in conjunction with the bootloader the boot after update fails. Here is the flow of my process:

  1. Follow the steps outlined in the bootloader example, including adding mbed_lib.json (directly copy-pasted) to both the bootloader project and the blinky project, adding the restrict_size, bootloader_img, etc.
  2. Compile the bootloader
  3. Compile and flash the main application which includes the bootloader and header
  4. Change something trivial in the main blinky application such as changing the frequency of the blinking.
  5. Recompile the main blinky application without flashing
  6. Copy this new, changed mbed-os-example-blinky_application.bin to SD card (I've also tried mbed-os-example-blinky_update.bin but my understanding from other github issues is that right now these two files are identical)
  7. Plug in SD card to device, restart.
  8. I see the following output:

Mounted sd card 0
Firmware update found
Flashed 100%
Starting application at 0x08040080

It's worth noting the very first line of the main() in my blinky application is a printf, which I am not seeing. I've tried inserting printfs earlier in the boot process but it looks like that is too early because I just get garbled text. As far as I can tell, the F469I is not supported by pyOCD so I can't actually debug the boot process.

Now, something I noticed very early on is that when the header is in place the newly flashed update will only boot if the "updated" firmware is the exact same image that has already been flashed to the board. If I change a single byte of the blinky application and attempt to flash that, it won't work. This to me indicates some code somewhere is checking the hash of the updated firmware against the firmwareHash that exists in the header file originally calculated on the old firmware. However, even if I remove all the header data and replace it with garbage data, it still behaves in the same way. Additionally, I can't seem to find any code in the boot code that uses any of the values out of the header, let alone the hash value.

I'm pretty much all out of ideas at this point, so I'd really appreciate some help. Is this something specific to this board I'm doing wrong? Something to do with flash alignment that I'm missing?

Issue request type

[X] Question
[ ] Enhancement
[ ] Bug

c1728p9 commented

Hi @NiallBegley, the update logic unconditionally applies the update if it is present. From your description it sounds like something is going wrong during flashing. One thing you could try to debug this further is printing out the contents of the newly programmed flash from the bootloader. You could then see what the difference is when you update to the exact same image vs when you update to a modified image.

linlingao commented

@NiallBegley Please reopen if you still face issues.