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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

1,181 Views
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

Labels (1)
Tags (1)
0 Kudos
7 Replies

976 Views
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 Kudos

976 Views
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 Kudos

976 Views
jingpan
NXP TechSupport
NXP TechSupport

Hi,

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

0 Kudos

976 Views
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 Kudos

974 Views
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 Kudos

974 Views
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 Kudos

975 Views
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 Kudos