Bootloader and main application similar to IAP not working

[DBurr]

Hi,

I have my own bootloader application similar to the IAP example provided by ST that runs and determines which of 2 main applications to run then launches the application. The bootloader is working fine and the main application is working fine but when I combine them the main application always ends up hard faulting. If I launch the main application from STM32CubeMX IDE it starts fine but then if I restart the whole processor, the bootloader runs then launches the main application but it always hard faults at the same point. If I have the main application running from the beginning of flash it works fine and no hard faults.

I've tried de-initing all peripherals that are used in the bootloader, that doesn't seem to make a difference. The only thing that is still running is the SysTick timer.

Are there any registers that would allude to why the hard fault has occurred?

How can I ensure that everything is at a nice clean state when the main application runs?

I should mention that the main application is a FreeRTOS project and the hard fault occurs when initializing the default task.

Thanks,

Doug Burrell

[DBurr]

Some more info, the call that happens just before the hard fault is "signal handler called at 0xfffffff1".

Is there a way to set up where to boot from next and then initiate a system reset?

[berendi]

> The only thing that is still running is the SysTick timer.

Why? Disable it.

> I've tried de-initing all peripherals

Don't trust HAL functions (ever), verify the registers that they are in their reset state. Use the RCC *RSTR registers, see the reference manual.

Verify that all interrupts are actually disabled in the NVIC->ICER* registers (see the description in the PM0253 Programming manual)

Verify that SCB->VTOR always points to the vector table of the application. Stupid SystemInit() code tends to write the wrong value there, despite the correct one (g_pfnvectors) being available to it. Don't trust SystemInit().

> Are there any registers that would allude to why the hard fault has occurred?

If it always hard faults at the same point, why don't you set a breakpoint there, and examine what happens there.

STM32CubeIDE has a fault analyzer pane, I don't know if it's any good, but you might try.

The exception stack frame is documented in the programming manual.

> How can I ensure that everything is at a nice clean state when the main application runs?

Don't trust generated code, don't trust libraries, don't trust example code, even when they come from the MCU vendor. Verify everything in the reference manual and in the programming manual.

[DBurr]

Thanks, it turned out it was the SysTick timer. I've also de-inited everything else just for good measure.

[Tesla DeLorean]

>>Are there any registers that would allude to why the hard fault has occurred?

Yes, most of us aren't using a while(1) loop to diagnose failure.

https://community.st.com/s/question/0D50X00009XkeRmSAJ/halbased-fsmc-setup-code-causing-hard-fault-periph-library-doesnt

[Pavel A.]

> Some more info, the call that happens just before the hard fault is "signal handler called at 0xfffffff1".

This number is a special 'cookie' of interrupt handlers. Confusing but normal.

Use the Fault Analyzer of the IDE. To see the actual place where the fault occurred, double click on PC or LR in the registers pane.

-- pa

[Piranha]

> How can I ensure that everything is at a nice clean state when the main application runs?

Drop that complex and fail-prone approach from ST's examples and implement a simpler and much cleaner one described in my post in this topic:

https://community.st.com/s/question/0D50X0000AFpTmUSQV/using-nvicsystemreset-in-bootloaderapplication-jumps

[DBurr]

Thanks, I appreciate the feedback. So far as long as everything gets de-initialized before passing execution to the main application, then there are no problems.