LPUART hardware bugs (framing error not detected and blocks idle detect)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPUART hardware bugs (framing error not detected and blocks idle detect)

89 Views
davenadler
Senior Contributor I

Summary

When incoming data is improperly framed, no framing error is raised, and line idle detection stops working.

Detail

For the incoming waveform shown below, the LPUART stops functioning after the last incomplete byte (which is missing a stop bit). There are two apparent hardware bugs:

  1. When the stop bit is not detected, a framing error should be raised, but it is not.
  2. After this incomplete byte, the line idle detect function no longer works; an idle line does not set the IDLE bit

The waveform below happens frequently on RS485 networks. Transmitting nodes often do not have a good way to switch out of transmit mode, usually because DMA transfer complete interrupts indicate data completely sent to holding register and shift register (and in some hardware FIFO), but not data shifted out completely. A common kludge in this situation is to DMA extra bytes (to fill holding register and shift register), then switch out of transmit mode on the DMA complete interrupt. This sometimes means one of the dummy bytes is partially transmitted down the wire before the node switches out of transmit mode. Hence the waveform below is common (note extra start bit at the end)...

NXP:
Do you have any hardware-savy engineer that can confirm these hardware bugs?
Any possible work-around?
Are the RT parts still supported?

PS: This is the cause of the difficulty in this never-answered question:
Trouble-getting-an-LPUART-IDLE-interrupt  
My code works perfectly except when the sending node transmits an incomplete frame, in which case the idle line is never detected...

Stop-start bit pairs are circled in the image below from a commercial 9-bit RS485 network:

RS485_NSP_message.JPG

Labels (1)
Tags (3)
0 Kudos
Reply
0 Replies