MODM7AE70 trap in IRQ handler

[KE5FX]

I'm looking into a crash that occurred in a long-term test last night after several hours. Is there a way to tell what ISR or other mechanism caused this trap 4A to occur?

Code: Select all

-------------------Trap information-----------------------------

Trap Vector        =  (4A)

xPSR               = 6000004A
PriMask            = 01
FaultMask          = 00
BasePri            = 00
Faulted PC         = 70040844

-------------------Register information-------------------------
R0     =00200000 R1     =0000001F R2     =20001220 R3     =00000001
R4     =00000004 R5     =00000005 R6     =00000006 R7     =00000007
R8     =00000008 R9     =00000009 R10    =0000000A R11    =0000000B
IP[R12]=00000000 SP[R13]=70073860 LR[R14]=700404E1 PC[R15]=70040844
XPSR   =21000000
-------------------RTOS information-----------------------------
Priority masking indicates trap from within ISR or CRITICAL RTOS section

Current task prio  = 0000003F
Current task TCB   = 20001220
This looks like a valid TCB
The current running task is: Idle#3F
-------------------Task information-----------------------------
Task    | State    |Wait| Call Stack
Enet#26|Fifo      |0005|7000666E,70040E26,70006A78,70011228,000004A4
Config Server#28|Semaphore |0254|7000666E,70040E26,70006990,70004998,700049F0,7003A166,70045012,000004A4
Measurement#3A|Semaphore |C345|7000666E,70040E26,70006990,700264A8,000004A4
SCPI#3B|Semaphore |0001|7000666E,70040E26,70006990,70004998,70004A28,70004A54,70028CBA,000004A4
SCPI processor#3C|Fifo      |0004|7000666E,70040E26,70006A78,70026220,7002CE04,000004A4
Stream#3D|Semaphore |0001|7000666E,70040E26,70006990,70004998,70004A28,70004A54,70029424,000004A4
Main#3E|Semaphore |C345|7000666E,70040E26,70006990,7002DF46,000004A4
Idle#3F|Running   |    |70040844,000004A4

-------------------Process Stack Dump----------------------------
70073840: 00200000 0000001F 20001220 00000001 00000000 700404E1 70040844 21000000
70073860: 00000003 000004A5 70000001 00000000 00000000 00000001 00000001 20001000
70073880: 0000003F 0000001F 10000000 00000000 00000004 00000005 00000006 00000007
700738A0: 00000008 00000009 0000000A 0000000B 00000001 2040E1C0 000004A5 000004A4
700738C0: 21010000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
700738E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073900: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073920: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073940: 00000000 00000000 00000000 00000000 700542DC 00000002 00000001 00000000
70073960: 00000000 00000000 00200000 0000001F 20001220 00000003 00000004 00000005
70073980: 00000006 00000007 00000008 00000009 0000000A 0000000B 00000000 70073868
700739A0: 000004A5 000004A4 21000000 00000000 00000000 00000000 00000000 00000000
700739C0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
700739E0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073A00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073A20: 00000000 00000000 00000000 00000000 00000000 00000001 700542DC 00000002
70073A40: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073A60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073A80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
70073AA0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

-------------------Stack dump------------------------------------
20001000: 00000000 00000003 00000000 00000003 00000000 00000003 00000000 7007ACE0
20001020: 0000000F 0000000F 0000000F 00000000 00000000 00000000 00000000 00000000
20001040: 00000000 00000000 7007A038 00000009 00000000 00000000 00000000 00000000
20001060: 00000000 00000000 00000008 00000000 00000000 20000000 00000000 00000000

I only have one ISR (PIOD_Handler at address 7002A01C) and I don't immediately see why it should trigger a fault.
The only suspicious thing about PIOD_Handler is that it enables (but does not initiate) a DMA transfer that's hardwired to channel 0:

Code: Select all

extern "C" void PIOD_Handler(void)              // Falling edge interrupt: use the inactive half-cycle to rearm the DMA transfer for
{                                               // the next rising edge
   if (!(PIOD->PIO_ISR & PIO_PD24))
      {                                         
      return;                                   
      }

   if (++write_ptr >= N_BUFF_SAMPLES)
      {
      write_ptr = 0;  // (declared volatile and accessed with the interrupt disabled)
      }

   if (write_ptr == read_ptr)
      overruns++;

   PIOA->PIO_PCMR  = PIO_PCMR_DSIZE_WORD;       // Reset PDC state before enabling DMA controller to avoid fetching a bogus initial nibble
   PIOA->PIO_PCMR  = PIO_PCMR_DSIZE_WORD | PIO_PCMR_PCEN;
                               
   auto *CH = &XDMAC->XDMAC_CHID[PDC_DMA_CH];   // Load next buffer's destination address and allow read access to current one
   CH->XDMAC_CDA   = (U32) ADC_capture_buffer[write_ptr];   

   XDMAC->XDMAC_GE = 1 << PDC_DMA_CH;           // Enable the DMA channel
}

The 70040844 address it shows is just the WFE instruction in OSTaskIdle(), so not too enlightening.

As far as I know nothing else in the system is using DMA, unless the Ethernet interface does. Unfortunately the transfer in question is time-critical and has to run in the highest-priority slot, due to being used to read an ADC at 32 MHz. Can this type of trap occur as a result of a conflict with another DMA channel used by the OS itself?