Interrupts stop working after some time (even after hard reset)

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Interrupts stop working after some time (even after hard reset)

1,710件の閲覧回数
anthony1
Contributor I

I'm working on a project with an i.MX RT1020 EVK using NXP's SDK and FreeRTOS. I'm encountering some strange behaviour with interrupts.

  1. After first programming the board, the interrupts (attached to push buttons) work fine (lets say the up, down, left, right buttons)
  2. After some while, a few of the interrupts stop working (only up button works)
  3. Even after multiple resets and even after removing the power and reconnecting, these interrupts do not work
  4. Even after reprogramming the board, the interrupts do not work, HOWEVER
  5. The interrupts work again if I program the board with a different firmware and reprogram back to the original.

It's a very strange problem. Perhaps some sort of non-volatile memory is being corrupted. Perhaps the IVT? (but shouldn't that be fixed by reprogramming?)

Any help would be appreciated.

The relevant code for setting up my interrupts is listed below. Note, I have this set up for all the buttons, with four interrupt handlers, but I'm only showing one below.

void init(void) {     gpio_pin_config_t sw_config = { kGPIO_DigitalInput, 0, kGPIO_IntRisingOrFallingEdge };     // button1->rail = GPIO1    // button1->pin = 29U    GPIO_PinInit(button1->rail, button1->pin, &sw_config);     EnableIRQ(GPIO1_Combined_0_15_IRQn);     GPIO_PortEnableInterrupts(button1->rail, 1U << button1->pin);     GPIO_PortClearInterruptFlags(button1->rail, 1U << button1->pin);     // Repeat for other buttons} void GPIO1_Combined_0_15_IRQHandler(void) {     PRINTF("Interrupt!\r\n");     isr_callback(); // Do stuff    GPIO_PortClearInterruptFlags(button1->rail, 1U << button1->pin); }

EDIT: I'm not sure how to post code in this forum without messing up the formatting, so I'll attach the file that contains the fragment.

EDIT 2: Added full_interrupt_code.zip, see my comment below

ラベル(1)
タグ(1)
0 件の賞賛
返信
7 返答(返信)

1,505件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi,

Yes, it seems so strange. But I don't think interrupt vector table is modified by unknow operation. If so, hardfault will happen. I read your code, but I didn't find problem, only seems you use GPIO1 pin29, but  enabled GPIO1_Combined_0_15_IRQn. I think this may not the real situation in your code.  Another suggestion is clear interrupt flag right after go into interrupt. If your call back function is too long, next interrupt will be stuck.

If the problem is still there, would you mind to share your code here?

Regards,

Jing

0 件の賞賛
返信

1,505件の閲覧回数
anthony1
Contributor I

Thanks for your response, I appreciate it. I'll post the entirety of the interrupt handling code as an attachment to this message.
I've also done further debugging and found some potentially useful information: I can force this issue by calling 

xTaskGetTickCountFromISR() from the ISR! Strangely, the non-FromISR version doesn't cause this issue usually...? (Note: This isn't the only thing that causes this strange issue. It's just a way that I can reliably recreate it)

I've demonstrated this in my code with the following line:

PRINTF("Ticks: %d\r\n", xTaskGetTickCountFromISR()); // This BREAKS it!

I'll experiment with clearing the interrupt flag immediately after the interrupt routine begins, and post my results accordingly.

Attached to first post (since I don't see an option to attach here) 

full_interrupt_code.zip, contains:

GPIO.c -> Handles setting up interrupts. When an interrupt occurs, it calls a handler function found in switch_controller.c

switch_controller.c -> Detects which button is pressed/released and prints it out.

Thanks for your help!

0 件の賞賛
返信

1,505件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi,

If you want to attach something, see "Use advanced editor".

0 件の賞賛
返信

1,505件の閲覧回数
anthony1
Contributor I

Hi Jing, are you unable to see the attachment in the original post? I agree, this forum isn't well designed to share code.  I have attached the zip file to this message as well using the advanced editor.

0 件の賞賛
返信

1,503件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi,

I can't figure out problem from these 2 .c files.

Does the interrupt really happen? If you set breakpoint in

void GPIO1_Combined_0_15_IRQHandler(void)
void GPIO1_Combined_16_31_IRQHandler(void)
void GPIO3_Combined_0_15_IRQHandler(void)
void GPIO5_Combined_0_15_IRQHandler(void)

can you catch interrupt. If no, that means the interrupt on these pins are disabled. Please check the GPIO register and NVIC register.

Regards,

Jing

0 件の賞賛
返信

1,503件の閲覧回数
anthony1
Contributor I

Hi Jing,

The interrupts happen at first. I can set breakpoints and catch them all. After some time, the interrupts stop working and are no longer caught, as I mentioned originally. This persists through a hard reset.

What part of non-volatile memory is responsible for this? Why is it not cleared when I reprogram the board and perform a chip erase?

Thanks

0 件の賞賛
返信

1,504件の閲覧回数
jingpan
NXP TechSupport
NXP TechSupport

Hi Anthony,

The interrupt vector table address is determined by your project. It can be in external SPI flash, or internal SRAM.

Can you send me your whole project? Let me debug for you. You can send to my email, jing.pan@nxp.com.

Regards,

Jing

0 件の賞賛
返信