iMXRT1010 crashes when enabling interrupt

youngSheldon — Fri, 08 Dec 2023 12:46:09 GMT

Hello everyone,

My setup used when having the problems:

I am using the EVK for iMXRT1010, (PCB: revA, sch: Rev C)
MCUXpresso IDE v11.8.0 [Build 1165] [2023-07-26] for windows
a FreeRTOS based application although the problems occurs way before using any of its features
Failing code is autogenerated (peripherals.c)
Externally, except board defaults, I have active an LPUART1 and a GPIO pin set to capture a GPT value via in interrupt.

I am running a code that enables GPIO1 interrupts as shown below.

The problem occurs when the code gets to BOARD_InitBootPeripherals(); with the call hierarchy:

BOARD_InitBootPeripherals(); in main.c
- BOARD_InitPeripherals(); in peripherals.c
  - GPIO1_init(); in peripherals.c
    - EnableIRQ(GPIO1_GPIO_COMB_16_31_IRQN); fsl_common_arm.h
      - NVIC_EnableIRQ(interrupt); in fsl_common_arm.h
        NVIC_EnableIRQ(interrupt); <-> __NVIC_EnableIRQ in core_cm7.h
        NVIC->ISER[(((uint32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)IRQn) & 0x1FUL)); in core_cm7.h This is the instruction where all crashes

The behaviour is as follows:

communication with the board crushes
the board does not boot anymore and I need to do a board recover, but wait:
what's worse it that this is chaotic: sometimes (the same) code works, sometimes a reset is enough to recover the board but most of the times I need to recover the board by loading a blinky() firmware via serial download to recover the board

I tried this on 2 EVKs, 3 desktop computers and 3 IDE revisions, all ended up with the same behaviour.

So, what am I doing wrong or what am I missing???

application entry point:

int main(void) { /* Init board hardware. */ BOARD_ConfigMPU(); BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals();//this is the entry to the rabbit hole // suppressed code lines }

sample code from autogenerated: peripherals.c. Last line is where the rabbit hole leads.

static void GPIO1_init(void) { /* Make sure, the clock gate for GPIO1 is enabled (e. g. in pin_mux.c) */ /* Enable interrupt GPIO1_Combined_0_15_IRQn request in the NVIC. */ EnableIRQ(GPIO1_GPIO_COMB_0_15_IRQN); /* Enable interrupt GPIO1_Combined_16_31_IRQn request in the NVIC. */ EnableIRQ(GPIO1_GPIO_COMB_16_31_IRQN); }

I can share the full code if needed for debug.

Re: iMXRT1010 crashes when enabling interrupt

youngSheldon — Sat, 09 Dec 2023 07:03:25 GMT

I possibly found the root cause, after a quick chat with a friend (credit goes to him). If anything changes, I'll update the post.

I was missing the IRQ definition for 0_15 pins as I wasn't actually using them in my app, and it works so far. IRQ was probably triggered by a pull up/down before LINK could control the MCU. It also makes sense to have the code break when initializing 16_31 IRQ, as it needed some CLK time to trigger 0_15 IRQ.

I added the first 2 lines to existing code:

#define GPIO1_LoIrqHandler GPIO1_GPIO_COMB_0_15_IRQHANDLER #define GPIO1_LoIRQ GPIO1_GPIO_COMB_0_15_IRQN #define GPIO1_HiIrqHandler GPIO1_GPIO_COMB_16_31_IRQHANDLER #define GPIO1_HiIRQ GPIO1_GPIO_COMB_16_31_IRQN

and defined a minimal IRQ function, just enough to take care of the IRQ flags:

void GPIO1_LoIrqHandler(void) { /* Get pins flags */ uint32_t pins_flags = GPIO_GetPinsInterruptFlags(GPIO1); /* Clear ins flags */ GPIO_ClearPinsInterruptFlags(GPIO1, pins_flags); /* Add for ARM errata 838869, affects Cortex-M4, Cortex-M4F Store immediate overlapping exception return operation might vector to incorrect interrupt. */ #if defined __CORTEX_M && (__CORTEX_M == 4U) __DSB(); #endif }

topic iMXRT1010 crashes when enabling interrupt in i.MX Processors

iMXRT1010 crashes when enabling interrupt

Re: iMXRT1010 crashes when enabling interrupt