spurious interrupts not simlated in arm7

What do you mean by 'support'a spurious interrupt? Do you want to generate a spurious interrupt for test purposes? Are you having a nesting problem in your ADC interrupt routine? It sound to me that you are servicing the ADC interrupt only to have another ADC interrupt before the first interrupt routine is complete. Is this the case?
Does the 'spurious' interrupt occur at the same level as the ADC? Is it IRQ or FIQ?
If we are able to assist you, we need a lot more info or at least I need a better understanding of your problem.
Spurious interrupts are always a potential problem in embedded MCU. With the good old C51, we would put a software trap at each unused interrupt vector during software/hardware debug. Later we would replace the trap with an immediate return for production devices.
With ARM, the problem of undesirable nesting MUST be addressed for reliable operation.

What do you mean by 'support'a spurious interrupt? Do you want to generate a spurious interrupt for test purposes? Are you having a nesting problem in your ADC interrupt routine? It sound to me that you are servicing the ADC interrupt only to have another ADC interrupt before the first interrupt routine is complete. Is this the case?
Does the 'spurious' interrupt occur at the same level as the ADC? Is it IRQ or FIQ?
If we are able to assist you, we need a lot more info or at least I need a better understanding of your problem.
Spurious interrupts are always a potential problem in embedded MCU. With the good old C51, we would put a software trap at each unused interrupt vector during software/hardware debug. Later we would replace the trap with an immediate return for production devices.
With ARM, the problem of undesirable nesting MUST be addressed for reliable operation.

Please refer to the philips LPC2134 datasheet for details on spurious interrupt.

In my case, it happened in both serial port and ADC. I will give the details.

1. End of AD conversion will trigger the interrupt.
2. One of the instructions, which is in the main function, is to write ADC register. This intruction takes 2 machine circles.
3. Just as the instruction is been executed, the "end of ADC" occurs, and the core get an interrupt request.
4. But after the instruction, the interrupt is cleared by the instruction. So when the core responses to the interrupt request, the VIC cannot identify who is generating the request, and thus the spurious interrupt is generated.
5. if the VICDefVectAddr in not initialized to a valid handler, then the process will start from address 00000000.


In the case of serial port, the similar situation occurs:

1. we call printf, which will in turn call putchar
2. putchar will check whether the serial port is sending in progress
3. if the serial port is sending, then just add the new byte to a queue;
4. otherwise just write

U0THR = byte;

By the way, I resolve the problems by
1. use the software interrupt to start serial port transmission.

void __irq UART0Isr (void)
{
	uint8 i;
	VICSoftIntClear = 1<<ISN_UART0;
        .....
}
void putch(uint8 dat)
{
	while( ! uart0_xmit_queue.Add(dat))
	{
	}
	if((U0LSR & 0X20) == 0X20)
	{
		VICSoftInt = 1<<ISN_UART0;
	}
}

void __irq DefIrq()
{
}

void SetDefaultIrq()
{
	VICDefVectAddr = (uint32)DefIrq;
}