Failed assertCONFIG due to invalid interrupt priority

anealca wrote on Friday, August 16, 2019:

I am using FreeRTOS on an NXP54628 Cortec M4 processor and trying to add SD card support.
I have TCP/IP and emWIN running well.
When I run the SD code as a host, I get an interrupt priority assertion:

  1. The extracted priority index is greater than the available priorities (58>56)
    CODE: __asm volatile( “mrs %0, ipsr” : “=r”( ulCurrentInterrupt ) );
    Line 483 in the port.c function vPortValidateInterruptPriority()
    This reports 0x3A as the 8 bit priority index (ulCurrentInterrupt)
  2. The pointer into the priority registers has been changed?
    CODE: static const volatile uint8_t * const pcInterruptPriorityRegisters = ( const volatile uint8_t * const ) portNVIC_IP_REGISTERS_OFFSET_16;
    Line 165 port.c is correct setting the base address to 0xE000E400
    But the pointer’s address has been changed to point to 0x20028000 somewhere ERROR
    This is a restricted area in the memory map of this processor asn cannot be read or written

1) Hard coding a priority into address 0xE000E43A (priority 3)
2) Hard code the pointer to that correct base address
When I do these 2 actions the SD detection and folder creation doesn’t give this config assertion

What have I done wrong setting up this port?

aggarg-aws wrote on Saturday, August 17, 2019:

Exception number and priorities are different as you can see here:

I checked the startup file for LPC54608 and the exception number 58 corresponds to SDIO_IRQHandler. So you are in SDIO_IRQHandler ISR.

The value change of pcInterruptPriorityRegisters seems like a memory corruption as this value should not change. Would you please put a data breakpoint to check when this gets changed?


anealca wrote on Saturday, August 17, 2019:

Gaurav… That makes sense since that is the IRQ I was expecting… the pcInterruptPriorityRegisters is a constant so it is not supposed to be changable… Not sure how to add a data breakpoint… will look into it… Adrian…

anealca wrote on Saturday, August 17, 2019:

I find that by the time a debug session stops at the first line in main() it has already been changed…

aggarg-aws wrote on Saturday, August 17, 2019:

That’s strange. Put a breakpoint in the Reset_Handler and set a data breakpoint for the location of pcInterruptPriorityRegisters. I would expect the value of pcInterruptPriorityRegisters to change to correct value when the startup code initializes it (i.e. copies the initial value from flash to RAM). The value of pcInterruptPriorityRegisters should change again and this should indicate the cause of memory corruption.

The instructions about how to set data breakpoint depend on the IDE you are using. Which IDE are you using?


anealca wrote on Tuesday, August 20, 2019:

I am using the NXP IDE MCUxpresso v10.3 and can set a breakpoint for code but am not sure how to set it for a varaible change…