Problem with EXTI4_15_IRQHandler when running after custom bootloader

[Eduard Furlender]

Posted on July 28, 2017 at 10:03

Hello, I have a working program running on STM32F072R8 CPU that works with external device and gets data via external interrupt (EXTI4_15_IRQHandler function). The collected data is forwarded later via USB port to computer. Recently I started a modification in order to implement firmware update using custom boot-loader. I successfully implemented both boot-loader and main module based on the IAP sample project. The problem is that USB and timer IRQ still work, but the program gets no EXTI4_15_IRQHandler call anymore. Only if I run it with J-Link debugger, the program gets the external interrupt. Or if I revert the code to run from usual memory location (without boot-loader). How can I solve the problem?   

[Tesla DeLorean]

Posted on July 28, 2017 at 13:58

Make sure you are properly relocating the vector table to RAM, and remapping it.

Don't transfer control from the loader to the app under interrupt context.

[Eduard Furlender]

Posted on July 29, 2017 at 07:58

Thank you for quick answer! I know this is not the problem. The relocating mechanism is done exactly like in the IAP example and timer and USB interrupts work, so the vector table is relocated correctly. I copy the vector table in main function, so this is not under interrupt context, I create another copy in local data area and then in main function periodically compare them. The new vector table area is not modified. I use special area in flash memory in order to store processing steps and later retrieve the area to computer for analyzing, so I know exactly how the program runs.

Any other suggestion?

[waclawek.jan]

Posted on July 29, 2017 at 10:21

Check the relevant GPIO/EXTI/NVIC registers. Check how far did the interrupt propagate through checking the pending registers in EXTI and NVIC. Try to force the interrupt manually in EXTI or NVIC. Try to change the priority levels.

JW

[Eduard Furlender]

Posted on July 29, 2017 at 10:53

Thank you for suggestions! Where can I find examples of how to do that?

[waclawek.jan]

Posted on July 29, 2017 at 17:59

Probably nowhere. This is to be done after reading and understanding the relevant manuals' relevant chapters (EXTI, SYSCFG, GPIO in RM0091, NVIC in PM0215) and to be done at register level. Most could be done/checked directly in the debugger - except that you say that when debugger is on everything works. This in itself is weird, but I don't know the debuggers' internal enough to know how to investigate that.

So upon some stimulus - a keypress perhaps - you should read out all the relevant registers and output them through the same way you do with the captured data as you've described.

Changing priority level should be easy - you've set it somehow initially in your way, haven't you. So change it to the priority of the timer interrupt, if it still does not work then interrupt priorities were not the problem.

There is also something other which should be easy to try - to move to a different EXTI (and different pin of course).

Forcing an interrupt manually is to set respective bit in EXTI_SWIER or NVIC_ISPR. You can do it upon detecting a keypress for example, in main(), or other external stimulus, or periodically.

You also may want to create a minimal version of the application to exclude as much influnces from that as possible.

JW

PS how do you verify that ' the program gets no EXTI4_15_IRQHandler call anymore'?

[Eduard Furlender]

Posted on July 30, 2017 at 15:17

Thank you for detailed directions of what to look for and where! Will dig that manuals.

I added call to function that stores number of call to flash (unique number for different calls). The function stores the number to flash and advances pointer to write (up to 1000 times). Then I read the content of this flash area and analyze, where the function was called.. If I put the call in all interrupt handlers - so I know timer and USB interrupts are called and EXTI.. isn't called.When the program runs under debugger, the EXTI... interrupt handler leaves its footprint. I have a PC program that sends command to clear the flash area in order to prepare for new debug session, or sends command to upload data from the debug area (unused area starting with 0x0800 E000) to PC. When the program runs from normal location (without bootloader), the EXTI.. interrupt handler call are recorded. Hope this explains.

[Tesla DeLorean]

Posted on July 30, 2017 at 15:28

Instrument the code, and output via a serial port, perhaps other aspects are precluding the interrupt from functioning. Flash is rather slow, helps if you're completely blind, but better ways of getting visibility.

Make sure you explicitly enable all clocks (GPIO, SYSCFG, EXTI, etc) and GPIO pins you use, the debugger may enable things to suit its own needs. Dump RCC/GPIO registers.

Confirm other interrupts of high/lower priority are functioning. Have viable Hard Fault Handler on both loader and application.

[Eduard Furlender]

Posted on July 31, 2017 at 08:52

Thank you for suggestions! However I have a custom board without serial port connector. You are right - I was completely blind without the writing debug info to flash option. I am going to reconsider the approach in order to avoid vector table remapping - put updating module into higher memory area.