Is this a fake UART idle line?

[SGonz.2]

Hello!

I'm working with UART+DMA+IdleDetection. I receiving long frames of data(250-300 bytes) 250 times per second at 921600bps without HT & TC interrupt from several sensors and one Arduino, then I send them by USB . Sometimes, I receive overwritten lines, for example, I should receive something like:

-$171518,89,-4,-1004,88,182,-999,-52,58,-42,426,1585

-$INO000,117,41,-1004,117,53,-990,-258,-129,87,-365,975

But I'm receiving this:

-$171518,89,-4,-1004,88,1$INO000,117,41,-1004,117,53,-990,-258,-129,87,-365,975

-82,-999,-52,58,-42,426,1585

I checked with my logical analyzer and found that in the point where the arduino frame starts, the aceletometer sends a "longer" 0 bit.

Is this may considered as idle line? I understood that idle line is triggered when you don't receive a byte, not a bit.

Also, this fake idle line makes sense to me, because if I zoom out, remembering that I not using HT and CT interrupt so my code sends data when it detects idle line, I think it's detecting and idle line in the red arrow, sends data until that point, the arduino frame ends and sends arduino data, then detects the acelerometer data ends again and sends the rest.

 

So, finally, is this fake idle line? I'm concerned because this can solve a lot of problems in my project and makes sense to me, but I need to check if this is the real reason.

Thank you!

[Paul1]

The Highlighted section between the two scope cursors of first picture:

- You said: [the aceletometer sends a "longer" 0 bit]

- To me it looks like a longer High/1 on the top trace (detailed in Yellow), as in a Stop bit followed by some High idle time till next start bit (normal for Async Data)

- The stretched stop bit may be when the STM or other device is preparing the next byte to send, to get rid of the delay use DMA UART Tx to send multiple bytes with no delays.

or am I looking at the wrong thing?

Paul

[SGonz.2]

-Well, the highlighted section its a High/1, but in UART is Low/0 or a steady line.

-But is that high idle time enought to end the reception of data? And is it necessary? For example other bits doesn't have that idle time.

-The problem is that the acelerometer aceletometer is sending that data and to take the pictures it was directly connected to the logical analyzer), and I can't make changes in it like send bytes without delays

[Paul1]

UART Hi Voltage = Data1 (At MCU Pin)

RS232/RS485 Hi Voltage = Data0 (Driver Inverts)

It looks like you are probing at the MCU Pin, not RS232 Driven Levels. Please confirm the signals you are probing: MCU pin or RS232.

You are using Arduino with ATMega MCU?

This is ST forum. What ST part number are you using?

Paul

[Paul1]

Are all the senders sending data by exact timing, or do some send according to "activity/motion"? If activity then you can't really trust "idle" to be a consistent thing.

Consider using data framing to trigger your processing.

It looks like data starts with "-$" and ends with NewLine (CR==0x0D or LF==0x0A or both CRLF)

-$171518,89,-4,-1004,88,182,-999,-52,58,-42,426,1585

-$INO000,117,41,-1004,117,53,-990,-258,-129,87,-365,975

So in your code you could wait for "-$" and capture data till NewLine, possibly capturing several lines if there is a group of recognizable lines (Detectable start and end conditions).

Also set you code to handle glitches: in case a NewLine is corrupted set your code to restart upon "-$" even if CR wasn't received.

If your devices can be set to add a checksum that would allow detecting corruption, much more reliable.

Paul

[SGonz.2]

All the senders sends data by exact timming

Ok! I'm going to capture data until NewLine. But, am I right when I say the MCU detects an idle line in this case?

I can't set a checksum in the devices :(

[Paul1]

In what document/section are you seeing "detect idle line"? (There are differences in some devices). I would expect "UART idle line" to be several byte times. Is it configurable time/bits/bytes? Certainly a fraction of a bit shouldn't flag as an idle as some devices output two stop bits.

Are you using interrupt or DMA receive? At your data rate I'd recommend DMA. If anything has higher interrupt priority it could cause you to miss Rx bytes. Best is device with receive FIFO, but I don't think device you picked has a UART Rx FIFO.

Paul

[S.Ma]

Make your system idle free, console to batch script may break idle concept. Make specific protocol headers to sync up. Use sw fifo buffers to avoid clogging and chocking.