AnsweredAssumed Answered

Hi,  I have a customer using the K22 and struggling with the SPI port being very busy but also trying to use UART0.  UART0 is showing bus overruns.  It looks like UART0 gets to a state where it cannot clear it's interrupts.  If the customer uses UART1 ins

Question asked by Richard Lysaght on Mar 3, 2016
Latest reply on Mar 3, 2016 by Mark Butcher

Hi,

I have a customer using the K22 and struggling with the SPI port being very busy but also trying to use UART0.  UART0 is showing bus overruns.  It looks like UART0 gets to a state where it cannot clear it's interrupts.  If the customer uses UART1 instead, it works fine.  Is UART0 different enough from UART1 that this is possible?

Here is the note from the customer:

What seems to be the symptoms we see:

SPI activates.  The SPI interface is a fairly exhaustive interface since we use that for WiFi so when it’s busy it’s REALLY BUSY.  The bus that is on UART0 then starts getting challenged so the error trap in its event handler for that bus shows overruns of the physical FIFO.  That UART1 seems unaffected, and we also use UART1, it seems very specific to UART0 encountering problems.

 

We haven’t ruled out a software defect that would cause UART0 to suffer, just seems that if it suffers that UART1 would also suffer.

 

The problem is challenging enough because the UART0 very often reaches a state where its ISR cannot clear the interrupt sense(s) and so it gets stuck servicing the UART0 ISR over and over and over…til we watchdog reset.

 

When that happens, from the debug session that shows the activity in the UART0 ISR, it appears that the Transmit Complete and Transmit Byte sent interrupt status flags are both set.  But when it gets to where it would want to process these flags, it appears as if the TX interrupt has been disabled and so it rejects any notion of processing those flags.

 

Outcomes