spurious interrupts not simlated in arm7

Of course this can be done!

In my program, the ADC is requesting an interrupt, while the current instruction is to write AD config register, which will clear the interrupt request. After this very instruction, a spurious interrupt is generated!!

This problem confused me for quite a few days, because I rely too much on Keil's simulator, who cannot find the problem.

I DO hope keil will support suprious interrupt.

Of course this can be done!

In my program, the ADC is requesting an interrupt, while the current instruction is to write AD config register, which will clear the interrupt request. After this very instruction, a spurious interrupt is generated!!

This problem confused me for quite a few days, because I rely too much on Keil's simulator, who cannot find the problem.

I DO hope keil will support suprious interrupt.

If you simulate the hardware correctly, then presumably the interrupt stays clear -- if that's what it's supposed to do.

If you've got a floating signal or whatever on the board that causes spurious interrupts, how is the simulator supposed to know that?

I suppose you could add a DLL that just generated random interrupts at random intervals, to see if the software could handle it correctly.

Perhaps we're not using the same definition of "spurious interrupt".

"I suppose you could add a DLL that just generated random interrupts at random intervals..."

Or maybe us a Signal Function - see the uVision Manual

"Perhaps we're not using the same definition of 'spurious interrupt'"

Very possible.
Expecting to get a detailed answer from a terse, 6-word question with virtually no explanation of the problem is somewhat optimistic...!

The dictionary says:

"false and not based on the truth"

http://www.dictionary.cambridge.org/define.asp?key=HW*11909&dict=CLD2

So, if the simulator did generate spurious interrupts, that would be a bug in the simulator!

I always get surprised/amused when someone expect the simulator to do anything but simulate. In Las Vegas there are, I do not know how many, Elvises, they are simulators.

If you want the real thing use the real thing. Would you buy a record by an Elvis simulator.

Erik

"Expecting to get a detailed answer from a terse, 6-word question with virtually no explanation of the problem is somewhat optimistic...!"

Actually, we were being told about it, not asked about it. ;-)

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;
}