STM32F407 Start application from Bootloader

[raffin]

Posted on October 06, 2017 at 13:00

Hi. 

    I have a STM32F407 application, developed with standard libraries which is launched by a bootloader. The application is loaded at flash address 0x08020000, the bootloader, once recognized a valid application at that address, reset the stack pointer and then set the PC to jump to the first instruction 

/* ----------------------------------------------- */

/* Jump to user application */ JumpAddress = *(__IO uint32_t*) (USER_FLASH_FIRST_PAGE_ADDRESS + 4);/* +4 perché è lì che c'è il main */ Jump_To_Application = (pFunction) JumpAddress; /* Initialize user application's Stack Pointer */ __set_MSP(*(__IO uint32_t*) USER_FLASH_FIRST_PAGE_ADDRESS);

//Stop Systtick

SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0;

HAL_NVIC_DisableIRQ(TIM2_IRQn);

HAL_NVIC_DisableIRQ(ETH_IRQn); HAL_NVIC_DisableIRQ(EXTI0_IRQn); __disable_irq();

Jump_To_Application();

everything is fine. 

Now I have a second application very similar to the first, which has been developed with HAL libraries. 

I can debug this application with no problems but when I flash the bin at the location 0x08020000 with the same bootloader as before flashed at 0x08000000, it does not start (or probably it crashes during the init).

When the bootloader  jumps to the application, in fact, it hangs up. I am not able to debug the application from bootloader (is it possible with STM32_SW4?) but what I can check is that: 

1) The application 

JumpAddress

 corresponds to the address i red from the 4th byte fo the bin file. 

2) The stack pointer is set correctly as in the first 4 bytes of the bin which is the end address of the SRAM.

3) The isr_vector table is placed at 0x08020000 as I see from the .map

*(.isr_vector .isr_vector.*)

.isr_vector 0x08020000 0x188 ..\obj\startup_stm32f4xx.o 0x08020000 g_pfnVectors

What could the cause of this behaviour?

[Tesla DeLorean]

Posted on October 06, 2017 at 16:24

Not sure why you couldn't step into the App, even if the code only displays as a disassembly, the addresses will follow those in the .MAP if you want to follow along. Also it to *stop* your code in the debugger you should be able to see where it is stuck. If you still can't get better tools.

Have the Hard Fault and Error Handlers output some useful status via USART or GPIO, rather than inane while(1); loop.

Add check-points along the way, check if it completes SystemInit(), RCC/PLL settings, etc. Assume Loader initializes USART, simple SR.TXE, DR interaction can output single chars as you proceed past certain points. Understand flow, understand where it hangs up.

Who re-enables the IRQ? Does SCB->VTOR get set correctly?

[raffin]

Posted on October 10, 2017 at 17:24

Hi Clive One, 

    thank you for your reply. At the beginning it seems to me that the problem was in the jump from the bootloader to the application. Nevertheless following your suggestion, using some led as indicator, I found that the problem was in one of the task of the application. I have not found the cause of the crash and I have no idea of the reason why when I debug this does not happen. In any case I am quite confident I will find it. 

Regarding the original question, I am not sure I can jump using disassembly from the bootloader to the application without providing to the debugger the .bin file of the application, even with 'better tools'. For sure, using the STM32_SW4, when I jump to the application while debugging the bootloader, I get a message 'No debug context' and I can not go further. 

Thank you.