cancel
Showing results for 
Search instead for 
Did you mean: 

CAN bootloader: Go command works only for some uploads

Krix N
Associate II
Posted on August 23, 2017 at 15:45

I have managed to update firmware via CAN and the SSTM32 builtin bootloader.

I have a 40Kbyte firmware that works fine, after firmware upload I can run it with the 'Go' command.

I have another 66Kbyte firmware that also uploads just fine, and the MCU acknowledges the 'Go' command but the firmware fails to run. But I know the firmware was uploaded just fine, since it runs when I reboot the MCU.

The firmware upload procedure I use is:

1) global erase

2) read out some data to confirm erase

3) write new firmware (address 0x08000000 ...)

4) read out (some) data to confirm write

5) Go to address 0x08000000 ...

The manual talks about 'vector table' as a possible reason. For both firmware builds, the file STM32L452RETx_FLASH.ld

contains the line

FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K

... which I assume reflects the firmware 'run' address.

What am I doing wrong?

Disclaimer: I am a STM32 newbee. Really. Have not worked much with MCUs and firmware at all.

#can #bootloader #vectortable #go-command
3 REPLIES 3
Posted on August 23, 2017 at 17:15

It is probably running but crashing, or stuck in some unbounded loop.

I'd debug this with instrumentation of the Reset_Handler and down stream code, ie enable the USART in the first dozen instructions of code executed by the CPU.

I would also ensure that the Hard Fault Handler output useful data if it ended up there.

Check clock/pll loops, check watchdogs

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on August 25, 2017 at 08:47

Thanks for your input, Clive.

>> It is probably running but crashing

Yeah, I just wonder why the same firmware doesn't crash when I afterwards reset the controller. Then I can verify that the downloaded firmware is actually there and runs just fine. So somehow the 'Go' way of running it must be different than the hard reset way.

>> I'd debug this with ...

At this time I don't have any experience with debugging and checking the way you suggest. It will probably be both good and fun to learn, but I am not sure if I can set aside the time right now. Are there any tutorials for dummies on stuff like that?

Otherwise I might need to give up for now and pay someone to look at it.

Thanks again.

Posted on August 25, 2017 at 17:14

Part resets with chip clocking from HSI or MSI depending on model, other sources and PLL will be off. BOOT pins map FLASH and SCB->VTOR properly.

The Go like sources a clock from HSE, and is running from the PLL.

Look for obvious loops in the clock startup and selection code where things may become stuck. Look for code that has expectations for registers to be set in specific ways, and how these might differ if the part is already up and running successfully.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..