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.
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
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
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!
Hi,
If you want to attach something, see "Use advanced editor".
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
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
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