iMXRT1010 crashes when enabling interrupt

[youngSheldon]

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.

[youngSheldon]

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
}