Being stucked at 0xf7fe

[FErma]

Hi all,

We have developed an application with STM32F072RBT6 MCU. The sections in flash shown below,

Bootloader 0x08000000 - 0x080047FF

EEPROM Emu 0x08004800 - 0x08004FFF

Main App 0x08005000 - 0x0800FD02

Enabled Interrupts: SMBUS, RTC-Wakeup, ExtInt, Can, ADC, DMA

Main app is usually busy with talking via CANBUS, reading/writing data via I2C-SPI-SMBUS, and does some periodic jobs triggered by RTC wake up. Whole system works well for a while(sometimes 1 hour, sometimes 4-5 hours), than suddenly communication with CANBUS is breaked down. When I pause debugging I see that PC is at 0x80025c6: 0xe7fe B.N in dissassembly section. As I research 0xe7fe stands for infinite loop, and it seems to be in Bootloader section.

When I debug with Bootloader code and same error happened, I see PC is at RTC_IRQ_Handler which is at 0x80025c6. Despite RTC is not enabled at Bootloader, Main App is jumped to bootloader's interrupt location(or it can be complately different issue)

Jump process from Bootloader to Main app is same as ST example code, and Vector table relocation from flash to SRAM is also done in Main app(Since complate system works for long time without any problem I dont think having any problem while jumping process)

Do you have any idea about what can cause the problem, or how can I go further to see what is causing this issue?

Thanks in advance

[TDK]

Stack or heap overflow? Do you use dynamic memory allocation?

All of the unused irq handlers get mapped to the same infinite loop default handler by default. You can look at VECTACTIVE bits in SCB->ICSR to figure out which IRQ is active, if any. Doesn't seem like it should be jumping to a handler outside of your application, but maybe that will shed some light.

[FErma]

Thanks for your answer,

I don't think there is a issue related to stack overflow. SP initial address is 0x20000F50 and min value of stack pointer while code is running is 0x20000E00 and Stack size is 0x600.

I will share content of vector tables placed in different memory locations.

Vector Table of Bootloader at 0x08000000

Vector Table of Main App at 0x08005000

Vector Table Relocated to Sram at 0x20000000

Vector Table at Remapped Address at 0x00000000 while system working properly.

When we get same error which is stucking at 0x08000ECE Vector table is as seen below

 

The black selection in secreenshots shows RTC Irq handler addresses of RTC peripheral. It seems while main app is running properly, suddenly vector table is mapped to flash, and PC is jumped to Bootloader's RTC Irq handler address. Have you experienced similar issue before?

Any help is greatly appreciated.

[Tesla DeLorean]

I'd assume some sleep/standby code that causes the chip to reset the mapping.

Best to disassemble the code and look at what's actually built in there.

Instrument the code so you have some idea of flow and interaction causing this to occur.

[FErma]

Hi clive1,

​

Thanks for your reply,

​You may be right since we use sleep mode with regulator in normal mode. I will try to diassemble the code and examine, however I have confused about working for hours(waking up every 100ms with RTC, can request, button press, etc) with no problem, than at a time finding vector table mapped to flash just before RTC interrupt fired.

Hope I can find a way to overcome this issue.

Best regards.

[Tesla DeLorean]

RTC interrupt (combined EXTI lines 17, 19 and 20), RTC ALARM, TAMPER, WAKEUP respectively.

Populate the Loader's handler, and have it read the EXTI to see which interrupt is precipitating the call.

[FErma]

Just to check if problem is related to RTC, I commented out MX_RTC_Init() and problem seems to be solved. Now I will try what you recommended.