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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

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

507 次查看
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

标签 (1)
标记 (3)
0 项奖励
回复
2 回复数

412 次查看
davenadler
Senior Contributor I

Sorry, mistake in my analysis above.
When transmitter stops, line reverts to idle condition (see trailing edge of blue receive trace above). Idle condition is equivalent to stop-bit (so long as it is longer than 1 bit-time). Thus it is correct to interpret the transmission as 0x1FF as shown on my scope - no framing error.

So, the hardware bug is:
Nine-bit 0x1FF address reads OK, then IDLE does not work.

Can someone review the VHDL or Verilog for the LPUART and see what's going on?
This is also very easy to replicate (just send an 0x1FF and try detecting line IDLE).

NXP, anybody there? @EdwinHz?

0 项奖励
回复

322 次查看
davenadler
Senior Contributor I

NXP? Anybody there? @EdwinHz ? @Omar_Anguiano ?

0 项奖励
回复