AnsweredAssumed Answered

Application code breaks bootloader

Question asked by squires.daniel.001 on Feb 25, 2015
Latest reply on Feb 25, 2015 by Clive One
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 0x8010000

The 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?

Outcomes