Hello,
I have 2 LPC2478s communicating with one another via UART3 (TTL line). Occasionally, because of some unknown reason at this time, one of the processors is handling a UART3 interrupt at intervals as high as 10 microsecond so obviously it cannot do much except that (but all the paths through the ISR acknowledge the interrupt, as far as I can see). I am trying to offer at least a workaround (this failure is relatively rare) until the root cause is found, but the following has failed: 1. Disabling UART3 peripheral and interrupt line. 2. Initialize UART3 peripheral (including installation of interrupt handler).
What I see if that even my test program, that triggers these steps deliberately in order to see if this is a good strategy to deal with the above mentioned problem, causes the processor to be flooded with interrupts and the normal communication is never restored - even if the transmitting processor is disabled. Can you offer me an alternative?
Have you tried to log the status register of the UART on each interrupt?
Allocate a ring buffer and write down these registers - when the processor gets into this loop you should be able to turn off the interrupts completely and then dump this array to see what bits you are constantly hit with.
Maybe you get an interrupt bit that you have accidentaly configured as enabled, but do not have a handler for in your ISR. So your code may work well until you get a parity error or a framing error or overrun or a FIFO overflow or similar. So all goes well until you either get some spurious noise on the serial data lines or you get a CPU peak that makes you fail your real-time requirements.
I'm a bit surprised that you can't deactivate this interrupt line or get the interrupt source to cool down with a reinitialization of the device.
But figuring out what interrupt bits that are constantly set when you enter the ISR should be able to give some indications why you get these interrupts. Then it will be much easier to figure out how to either fix an existing bug or how to recover.
Per,
Thanks for your reply. Very busy now, will respond somewhat later!
Well, I managed to reset to peripheral - but it seems that resetting the contents of the hardware TX buffer inside the ISR causes spurious interrupts that cannot be acknowledged (I don't understand why). Either way, I don't need to reset the TX buffer. I think I have a solution - I will test more tomorrow! Thanks again for your time.