Application code breaks bootloader

[Daniel Squires]

Posted on February 25, 2015 at 13:34

I've seen a number of similar threads but I don't think any quite cover the problem I am having here using an STM32F407.

I have implemented my own bootloader for updating via CANOpen SDO protocols. This works fine provided it is used straight after powerup to load the application code into flash.The bootloader lives at 0x8000000 and the application code currently lives at 0x8010000The application code runs if present after a short timeout.Once flashed the application code runs perfectly fine, however if I reset from application code (either with the hardware reset button or NIVIC_SystemReset()) back to the bootloader, something goes wrong in the bootloader whereby it no longer recognises the fw update command. Oddly other things in the bootloader such as flashing LED sequences to indicate bootloader mode - work fine.When I trace through the code in the Debugger I can see that after the interrupt fires having received a CAN packet the function pointer to deal with the fw update cmd is NULL, so it is not recognised as a command, however other parts of the CANopen code still work as expected.If I power off the device, and then back on, the bootloader once again works fine until the application has been allowed to run.I am at a bit of a loss as to why the code would be effected in this way, I could understand if one of the peripherals was left in a weird state, but they all seem to be behaving, and I have tried using the deinit functions where relevant to force them back to a power on state.I assumed this was something to do with the vector tables but they seem to all be ok, the reset from application does indeed run the bootloader, and both the bootloader and application code have their own vector initialisation, (the application one is of course offset to be at the start of its flash space).Somewhat bizarrely, if I enable a USB_CDC setup with debug statements in many steps of what the bootloader is doing so I can see in a terminal on the PC what it is doing it will work everytime  after an application code reset or hw reset.It seems as if something in memory is not initialised properly after reset, even hw reset, and I wonder if anybody can suggest what this might be?

[Tesla DeLorean]

Posted on February 25, 2015 at 14:18

The processor is not responsible for doing anything to memory at reset.

You might want to watch when the C runtime code actually initializes statics (zeros/copies into RAM). In the CMSIS model the SystemInit() code is called prior to the __main or _cstartup type code, and prior to your own main() Yes, double check the values in SCB->VTOR, interrupts left enabled, RTOS privilege issues.