Issue with Bootloader Jump to Application on STM32F072RBT6 – Stalling at HAL_Delay()

[shyamparmar]

I am currently working on the STM32F072RBT6 microcontroller and have developed a bootloader that successfully jumps to a specified location. The bootloader is located at address 0x08000000, and the main application is at 0x08006000.

 

The bootloader is able to jump to the main application, but when the main application starts, it stops at the very first HAL_Delay() statement.

 

Could you please help me troubleshoot this issue and suggest any possible solutions? Any assistance would be greatly appreciated.

Thanks in advance! 

 

below the mention function for jump bootloader to application code:

static void goto_application(void){

void (*app_reset_handler)(void ) = (void (*) (void))(*(volatile uint32_t *)(0x08006000 + 4));

__disable_irq();

__set_MSP((*(volatile uint32_t *)0x08006000));

__enable_irq();

app_reset_handler();

}

 

 

[Andrew Neil]

---

@shyamparmar wrote:

when the main application starts, it stops at the very first HAL_Delay() statement.

---

Has the tick source for HAL_Delay been properly configured & enabled?

[shyamparmar]

@Andrew Neil  Yes, HAL_Delay() is proper configured & enabled.

[waclawek.jan]

Besides jumping to application, you also need to solve the issue with vector table, for the interrupts (including SysTick which provides the tick for the delay function) to work properly.

In Cortex-M0, there is no way to redirect the vector table (in all other Cortex-Mx there's a VTOR register in the processor for this purpose); so the only option is to copy the vector table to RAM, and remap RAM to 0x0000'0000. Search this forum for details, this has been discussed here multiple times.

JW

[gbm]

Have you relocated the vector table to RAM? The bootloader/app problem with F0/Cortex-M0 is covered in many thread on this forum - just look at them.

[Tesla DeLorean]

You've been asking the same questions for a week or more.

The issue is at the other side. It's not at the jump/transfer point.

It is in your application, how it manages interrupts and how it relocates the vectors.

As told multiple times, you need to move the table to the base of RAM, 0x20000000, and them remap that at zero.

Look at any working IAP example for the platform.

Start looking and presenting the right code, you're look in the WRONG place.

[Tesla DeLorean]

https://github.com/STMicroelectronics/STM32CubeF0/blob/3a24f060afe69d8be7442a312d1e069b4529aba6/Projects/STM32091C_EVAL/Applications/IAP/IAP_Binary_Template/Src/main.c#L69

 /* Relocate by software the vector table to the internal SRAM at 0x20000000 ***/ 

 /* Copy the vector table from the Flash (mapped at the base of the application
 load address 0x08004000) to the base address of the SRAM at 0x20000000. */
 for(i = 0; i < 48; i++)
 {
 VectorTable[i] = *(__IO uint32_t*)(APPLICATION_ADDRESS + (i<<2));
 }

 /* Enable the SYSCFG peripheral clock*/
 __HAL_RCC_SYSCFG_CLK_ENABLE(); 
 /* Remap SRAM at 0x00000000 */
 __HAL_SYSCFG_REMAPMEMORY_SRAM();

[shyamparmar]

@Tesla DeLorean Sorry but i already tried this before the jump to application then also it stops at the very first HAL_Delay() statement.

/* Copy the vector table from the Flash (mapped at the base of the application
 load address 0x08004000) to the base address of the SRAM at 0x20000000. */

 for(i = 0; i < 48; i++)
 {
 VectorTable[i] = *(uint32_t*)(0x08006000 + (i<<2));
 }

 /* Enable the SYSCFG peripheral clock*/
 __HAL_RCC_SYSCFG_CLK_ENABLE(); 

 /* Remap SRAM at 0x00000000 */
 __HAL_SYSCFG_REMAPMEMORY_SRAM(); 

 goto_application();

 

static void goto_application(void)
{
	void (*app_reset_handler)(void) = (void (*)(void))(*(volatile uint32_t *)(0x08006000 + 4));
	__disable_irq();
	__set_MSP((*(volatile uint32_t *)0x08006000));
	__enable_irq();
	 app_reset_handler();
}

 

[Shirley.Ye]

you can try to set the breakpoint at the  SysTick_Handler to see if it can be reached.

 

this can be used to check if the vector is correctly set or not.