Bootloader Issues

[lee_trueman]

Posted on January 21, 2013 at 10:50

having difficulty getting a custom bootloader working. Basically this is a MSD device bootloader, using USB MSD and SDIO Sdcard drivers and Chan FATFS. Note MSD only runs if there is not a valid binary file on disk.

Bootloader is compiled with normal compiler and linker settings its size is 90K.

i.e.

VEC_TAB_OFFSET 0x0FLASH (rw) : ORIGIN = 0x08000000, LENGTH = 512K

Applications flashed by the bootloader use the following and are around 180K

i.e

VEC_TAB_OFFSET 0x20000

FLASH (rw) : ORIGIN = 0x08020000, LENGTH = 384K

What we are seeing is that a small application that just flashes a LED in a C main while loop works fine, but when we try our own application it fails to run. We know the application is working fine as can build it to run standalone without bootloader and it works fine.

Thus this seems like it is a issue with the core state when a larger application is launched, possibly interrupts too ?

[lee_trueman]

Posted on January 22, 2013 at 11:56

The application runs perfect when compiled to run without bootlooader. i.e when linked to 0x8000000 and VET_TAB_OFFSET is 0x0.

But as soon as the application is compiled to run in the application space i.e 0x8020000 and VET_TAB_OFFSET is 0x20000, i get this issue.

[frankmeyer9]

Posted on January 22, 2013 at 14:30

But as soon as the application is compiled to run in the application space i.e 0x8020000 and VET_TAB_OFFSET is 0x20000, i get this issue.

Does your relocated vector table at OFFSET=0x20000 contain a valid SVC handler routine ? Set a breakpoint, and step into.

[Tesla DeLorean]

Posted on January 22, 2013 at 15:33

Probably want to double check what SCB->VTOR is set too, and then dump out the unsigned longs in the vector table and double check they point into the right area of memory.

If I suspected the boot loader was a potential problem I'd probably try to vector into the application immediately from the ResetHandler in the boot loader and remove potential initialization issues as a culprit.

[lee_trueman]

Posted on January 24, 2013 at 17:51

Hi Clive,

i've no resolved this, so thought i ould post the reason for the fault.In the bootlooader NVIC prority group as set to 1, note the call to NVIC_PriorityGroupConfig or's the passed prority. The issue i had as that the freertos port for Cortex M3 requires 4bits of prority, thus calling NVIC_PriorityGroupConfig in the application after it had been called in the bootloader set the grouping wrong hence the hard fault.So one can conclude that you need to be care around core/interrupt init :)