stm32f103ret6 bootloader cannot go to application correctly

[Jian Chen]

Posted on November 28, 2017 at 14:34

Hi,

In my stm32f103ret6 bootloader firmware, I am able to load the application code to memory area 0x08009000 to 0x08011BE0.

The linker file of bootloader specifies:

define symbol __ICFEDIT_intvec_start__ = 0x08000000; define symbol __ICFEDIT_region_ROM_start__ = 0x08000000; define symbol __ICFEDIT_region_ROM_end__   = 0x08008FFF;

The linker file of application specifies:

define symbol __ICFEDIT_intvec_start__ = 0x08009000; define symbol __ICFEDIT_region_ROM_start__ = 0x08009000; define symbol __ICFEDIT_region_ROM_end__   = 0x0807FFFF;

But after I jump to application from the bootloader, the application firmware does not run.  What is wrong? The jump is as follows: =========================================================

#define FLASH_USER_START_ADDR ((uint32_t)0x08009000)

      HAL_RCC_DeInit();        

      SysTick->CTRL = 0;        

      SysTick->LOAD = 0;        

      SysTick->VAL = 0;        

      __disable_interrupt();                

      JumpAddress = *(__IO uint32_t*) (FLASH_USER_START_ADDR + 4);        

      JumpToApplication = (pFunction) JumpAddress;        

      __set_MSP(*(__IO uint32_t*) FLASH_USER_START_ADDR);        

      JumpToApplication();

[Tesla DeLorean]

Posted on November 28, 2017 at 14:39

Perhaps you can use a debugger and step across the transition and determine what goes wrong and how far it gets into your app code.

Make sure something enables interrupts on the other side and that you set the vector table address correctly in SystemInit()

[Jian Chen]

Posted on November 28, 2017 at 17:05

Thanks for the reply. 

In the bootloader firmware, after I step into

JumpToApplication(); the debugger keeps running(cannot step into the statements) and when I stop the debugger, it stop at the memory address inside application firmware area; but it is hex code, I don't know where it stops in the application.

In the application firmware, I set the vector table in SystemInit() to be at SCB->VTOR = ((uint32_t)0x08009000);  which is the start of application code.  If I load application firmware with debugger, then it is running well.

Which part I did wrong?

[Tesla DeLorean]

Posted on November 28, 2017 at 17:55

You might have to step in disassembly view, and familiarize yourself with the layout of your code, as built, by looking at the .MAP file.

You should not call the app from an IRQ Handler, and personally I wouldn't disable the interrupts at a CPU level. Consider having a working Hard Fault Handler so you can see if you have some faulting condition.

[Jian Chen]

Posted on November 28, 2017 at 22:42

Now the bootloader jumps to application firmware and the application main while loop works(I see the pin toggles in the while loop).  But none of the interrupts in the application firmware works.  Any answers on that?

[Tesla DeLorean]

Posted on November 28, 2017 at 22:53

You explicitly disable interrupts going in, do you enable them again? 

__disable_interrupt();  

You need to double check the value in SCB->VTOR when it hits main(), you should perhaps output diagnostics via USART at this point, inspecting registers, etc.

You should not call the app from IRQ context, ie an EXTI or USART IRQ Handler, or HAL callback.

[Jian Chen]

Posted on November 29, 2017 at 15:26

I forgot to put __enable_interrupt(); in the application firmware.  It fix the problem.  Thanks for the help!