Bootloader Hardfault on App Entry. Is my application program configured correctly?

[Waller.George]

Hi all,

I'm currently working on a bootloader for the STM32L052 MCU. I have a very simple bootlader at this early stage in the development. I have a simple application program that consists of a flashing LED, it compiles to a 4KB .bin file. I then convert this bin file to a uint8_t array to store in the RAM of the bootloader so I can simply test the writing of the program into flash without developing a UART protocol etc. The final version will be using NFC to download the code.

I have the bootlader program starting at 0x0800 0000 in the FLASH and the application at 0x0800 F000. The bootloader simply writes the array into this location of memory, then sets the MSP to the first 32bit work of the application address and casts the second word as a function and calls it to launch the application. I have used the AN4657 as reference.

However when the application is launched, I get a Hard Fault exception. I think this is due to the way I have the application project setup or perhaps the way I have converted the .bin to a uint8_t array. First, if I run the application directly on the processor the first debug point isn't at the start of the program, but at an offset. I assume this is the startup code. Also, the first work of the bin file isn't the correct value for the stack pointer. In the bin file it's 0x0200 0200 but it should be 0x2000 2000 for my 8KB of RAM.

Attached are my bootloader source files. Could anyone give me some pointers on how I should configure my application project? Should the FLASH start and end be different? Things like that.

Thanks!

[Waller.George]

So I have found out my bin file to array conversion wasn't correct however I have fixed this now.

If the application jumps to 0x0800F000 it Hard Faults. Debugging just the application code starts at 0x0800FCC4. If I use this address from the bootloader it still crashes.

[Tesla DeLorean]

It is a vector table containing addresses, 0x0800F000/4 is NOT executable code, you can't jump to it

appEntry = (pFunction)(*(uint32_t*)(FLASH_APP_STRT_ADDR + 4)); // Want to LOAD the content at the address

Step the code and compare to the Reset_Handler code in startup.s, in main() you need to relocate the Vector Table to RAM before enabling interrupts. See the IAP examples for the F0 platforms.

void BTFlashJumpToApp()
{
	appEntry = (pFunction)(uint32_t*)(FLASH_APP_STRT_ADDR + 4);
 
 // Initialize user application's Stack Pointer
 __set_MSP(*(uint32_t*)(FLASH_APP_STRT_ADDR));
 
 // Start the application
 appEntry();
}

[Waller.George]

Thank you Clive, this comment demonstrated the main issue with my code. Your other issues were very helpful, thanks again.

[Waller.George]

Okay, I have fixed the issue causing the Hard Fault. I wasn't resetting the VTOR on entry to the application. However, now after some instructions of the application the PC jumps to 0xfffffffe which is a hard fault. This happens on the execution of the first POP instruction (pulling data off the stack). I think this maybe due to the memory setup. But again I'd appreciate a guide to creating the application and what settings I should use. I currently have the stack located at 0x20002000 for the 8KB of RAM.

[Tesla DeLorean]

The CM0+ code should have set up SCB->VTOR in SystemInit() , ST uses defines, processes I've described before would use the linker and the symbol for the vector table to do this automatically, so as the address in the linker script or scatter file changed the correct code would be built.

You need to make sure the loader doesn't have interrupts running (like SysTick, USART, etc.), you want to turn them off at the peripheral, not use __disable_irq

You also need to start the application from foreground mode, not interrupts or callbacks.

I would also make sure to load SP with the __initial_sp in Reset_Handler. Using 0x20002000 would be fine, different tool chains do different things, and often change the value later, or as part of the RTOS startup.

ISP examples should be reviews, and tested to confirm understanding.