MRT and SCT interrupt handling on LPC812

[lpcware]

Content originally posted in LPCWare by matterama on Wed Jan 08 17:30:16 MST 2014
Hi all,

Just wanted to get some thoughts on it some odd behavior...

I have an SCT configured that is reading in a pulse train that has typical pulse transitions occurring at 1 millisecond.  Works great.

I also have an MRT configured to perform a software serial port output.  I am outputting data on that bus at an off-nominal baud rate (100 kbps).  I had to do a SWUART because of this off-nominal rate and the fact that the other two UARTS are being used.  Since the fractional baud rate divider on the LPC800 unfortunately applies to all 3 UARTS, unless they are all multiples of each other you are limited.  (The other two ports are running at 57,600 baud).

Every 10 milliseconds an interrupt fires that clears a flag allowing transmission of a 20 byte message out  the SW UART.

To recap:
1) SCT reading 1 msec pulse train sequence
2) MRT firing off at 10 msec allowing output message on the SWUART
3) MRT then firing off at 10 microsecond repetitive timer to output the bits of the message

IN GENERAL, things are working.  However, the output byte stream sometimes (every 1 to 3 seconds) gets corrupted in a peculiar way.  The bit widths should be 10 micro seconds.  Sometimes it looks like there are inadvertent 10 or 20 microsecond delays that occur.

If I turn off the SCT and output fixed messages on the SWUART, it works fine, no glitches.  And, I've confirmed that the incoming SCT message has no glitches. 

From this, I have to assume there is some issue where the SCT interrupt is being serviced when the MRT interrupt fires off perhaps.  But if this was true, it seems like it should not ever fire off again (the MRT) because the interrupt would not be cleared.

Anyway, anyone have any general thoughts on this or interrupt handling specific to the LPC812?

Thanks

[lpcware]

Content originally posted in LPCWare by matterama on Sat Jan 11 09:34:34 MST 2014
Thanks Marc,

It turned out to be a variant of number 2 I believe.  You spurred me to look harder at the incoming pulse train.  It is from a different device and turns out it has extra pulse sets that can occur, tacked on to the expected train!  I'll have to figure out what this is, but the decoder was trying to process that while outputting a message on the SWUART, so there was some delays and conflict that I was not seeing and since they occur sporadically, hard to catch at the same time on the scope..

BTW, the original setup for exporting the bytes was thru a simple bitshift routine (so a byte would be moved into a temp holder, then shifted out on each SWUART interrupt).  When that byte was gone, the next byte would move into the shifter.  Pretty hacky, but works if nothing else is interrupting it


Thanks for your help everyone...

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Fri Jan 10 15:09:50 MST 2014
You have not clarified how the received message r (pulse train) and the SWUART output  s correlate.
It sounds, like you're outputting the received message on the SWUART, or some debugging output
as a function of r .

Sending s takes 20bytes*10bits/byte*10us/bit = 2ms.
MRT channel m1 starts transmission of s every 10ms.
Another MRT channel m2 (repetitive) does the bit outputs, 10us. This is the SWUART.

1. possibility:
If m1 an m2 were started very close to each other, they end up being triggered very close (in time) to each other (at least every 10ms). As m1 clears a flag that is interpreted by m2 you end up with the question, how the MRT handler for both m1 and m2 should be implemented. Which one handle first?
However, from the times calculated above (2ms<->10ms) I see, that this ISR should never face the condition that the flag should be set because a new message has just arrived and the condition, that the flag must be reset because the last bit will be sent. I would check that with an ASSERT() or similar to be absolutely sure about it.
If you started/stopped the MRT m2, I would not be so optimistic about that part. Then, I wouldn't bet a used 1N4148 on it. At a rate of 10us and other ISRs to handle...

2.possibility:
The SCT decoder decodes r at 1ms avg. You don't say much about the length of train to decode.
So because of your program's misbehaviour, let's assume you get the next message r as early as 2ms. Right at the time when the last bit of the previous message is about to leave the SWUART.

How does SWUART shift out up to 20bytes 8 bits, each? There's no machine data type that holds that much data. How do you encode the number of remaining bits inside MRT m2? How do you update that message or append the next? Both contents and length without the high-speed MRT m2 interfering? 32bits you can do with an (atomic) write, everything bigger needs more care. 20bytes are five times as much plus the length encoding...


My guess is: you have a race condition while updating your output message and/or length, if not already withing the MRT handler. 2. possibility much more likely.

[lpcware]

Content originally posted in LPCWare by rocketdawg on Thu Jan 09 09:18:48 MST 2014
most likely a priority inversion due to nested vector interrupt priorities.
SCT and UARTs have higher priority than MRT.
if the CPU is executing in an SCT or UART interrupt, then the MRT interrupt will not be serviced until these finish.
the MRT ISR can also be interrupted by UART or SCT