Skip to main content
ELin.4
ELin.4
Associate II
June 24, 2021
Solved

No interrupt after the interrupt vector table relocated to SRAM. STM32F072CBTx

  • June 24, 2021
  • 2 replies
  • 4066 views

Hi, there

I am developing a bootloader to upgrade the firmware through CAN. I have done it successfully with a STM32L431CCUx platform. Everything works when the SCB->VTOR is available.

When it comes to this Cortext-M0 core (STM32F072), which has no VTOR, I realized that I need to the followings:

  1. Reserve the beginning 196 bytes of SRAM to store the Interrupt Vector Table. See ReserveSRAM.png. I did this in the beginning of SystemInit(). I've also tried it in the beginning of main(), failed the same.
  2. Copy the Interrupt Vector Table of the application to the beginning of SRAM. My application codes starts at 0x08014000. See CopyMemories.png.
  3. Remap 0x20000000 to 0x00000000. See SYSCFG_CFGR1.png.

However, after I've done all these, the interrupt subroutines in the application code are never called. The SysTick timer interrupt, and any other interrupt if enabled, is always pending. See NVIC.png. The break point at the interrupt handler is never hit. I can trace the firmware from my bootloader all the way to the main application and everything seems to be working fine. The main application hangs inside the HAL SPI driver to wait for the interrupt that never came.

Can anybody point out what I'm missing ?

Thanks,

Regards,

Eric

This topic has been closed for replies.
Best answer by Tesla DeLorean

>>I did disable all the interrupts before entering the main application.

And did you ever enable them again, most code assumes the processor starts with them enabled, because it does.

The "Disable The Interrupts" mantra in the context it should be used here is that you've turned them off at the sources, so the app doesn't suddenly have to deal with a mess that the loader left behind whilst lacking any initialization or context/instances. ie where is hUart3 and why is it USART3 interrupting..

2 replies

waclawek.jan
waclawek.jan
Super User
June 25, 2021

Maybe you jump to the application from the bootloader in an interrupt. That is then the same as disabling all interrupts with lower or equal priority.

JW

ELin.4
ELin.4Author
Associate II
June 25, 2021

Hi, JW

This is how I jump from the bootloader to the application:

typedef   void   (*pFunction)(void);

 // jump to the main application.

 __disable_irq();

 uint32_t appStack = (uint32_t) *((volatile uint32_t*)0x08014000);

 pFunction appEntry = (pFunction) *(volatile uint32_t*) (0x08014000 + 4);

 __asm volatile ("MSR msp, %0" : : "r" (appStack) : );

 appEntry();

I did disable all the interrupts before entering the main application. I could see that the jump enters to the Reset_Handler() of the main application.

Is this looked all right with you ?

Eric

Tesla DeLorean
Tesla DeLoreanBest answer
Guru
June 25, 2021

>>I did disable all the interrupts before entering the main application.

And did you ever enable them again, most code assumes the processor starts with them enabled, because it does.

The "Disable The Interrupts" mantra in the context it should be used here is that you've turned them off at the sources, so the app doesn't suddenly have to deal with a mess that the loader left behind whilst lacking any initialization or context/instances. ie where is hUart3 and why is it USART3 interrupting..

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
waclawek.jan
waclawek.jan
Super User
June 25, 2021

> what I am missing here

__enable_irq()

JW

Terms & ConditionsAccessibility statement