Guidance on tracking down spurious interrupts

Discussion created by FridgeFreezer on Dec 22, 2010
Latest reply on Jan 18, 2011 by Piotr Mazur

I've read a couple of good posts on here, particularly from mjb, but I still don't quite have a full grasp on how to track down a problem I'm currently having with spurious interrupts.


Setup is MCF52259 on our own PCB, CW7.2 with USB Multilink, code is in C.


As it stands, the micro is (randomly) getting spurious interrupts from somewhere - which may or may not be the UART (see below).


As per mjb's post on the subject, I have a spurious_isr() routine which captures various registers and then sits in an infinite loop:


__interrupt__ void spurious_int(void) // Handles spurious interrupts{ static uint32 test[16]; uint8 i = 0;  test[0] = MCF_INTC0_IPRH; // Pending interrupts high test[1] = MCF_INTC0_IPRL; // Pending interrupts low test[2] = MCF_INTC0_IMRH; // Interrupt mask high test[3] = MCF_INTC0_IMRL; // Interrupt mask low test[4] = MCF_INTC0_IRLR; // Interrupt Request Level Register test[5] = MCF_INTC0_IACKLPR; // IACKLPR Interrupt Acknowledge Level and Priority Register test[6] = MCF_INTC0_SWIACK; // Software IACK Register test[7] = MCF_INTC0_L1IACK; // Level 1 IACK register test[8] = MCF_INTC0_L2IACK; // Level 2 IACK register test[9] = MCF_INTC0_L3IACK; // Level 3 IACK register test[10] = MCF_INTC0_L4IACK; // Level 4 IACK register test[11] = MCF_INTC0_L5IACK; // Level 5 IACK register test[12] = MCF_INTC0_L6IACK; // Level 6 IACK register test[13] = MCF_INTC0_L7IACK; // Level 7 IACK register test[14] = (test[0] & test[2]); // High mask & pending interrupts test[15] = (test[1] & test[3]); // Low mask & pending interrupts         while (1)        {     nop();        }    }


Now the bits I can't work out:

When it drops into the spurious_isr I don't know how to read the status register (SR) in C, I can't see a #define for it and don't have the asm knowledge to get it. I can't see any way to find out which interrupt number triggered the spurious interrupt, as it doesn't seem to be showing up in the debug data (below).



The results when it drops into the ISR are:

IPRH: 0x00000000

IPRL: 0x00008000


IMRL: 0XFF839F56

IRLR: 0x00000000

IACKLPR: 0x00000000

SWIACK: 0x00000000

L1IACK: 0x00000000

L2IACK: 0x00000018

L3IACK: 0x00000018

L4IACK: 0x00000018

L5IACK: 0x00000018

L6IACK: 0x00000018

L7IACK: 0x00000018


Which points to interrupt 15 - UART2. The strange thing is UART2 has a full ISR the same as the other two UARTS, and although the UART is enabled it is not currently connected to anything so should be seeing no activity. If it did get any spurious data (from a floating pin etc.) then it would be ignored and the UART cleared (MCF_UART_UCR(2) = MCF_UART_UCR_RESET_ERROR:smileywink:


Can anyone point me in the direction of how to extract the data on the interrupt source so I can debug this?