[TM4C123x, LM3S808] UART start bit verification

Purely anecdotal - but indeed your understanding as stated here - well describes the (known) behavior of past (non vendor) MCU's UART handling.

Performing the more consequential "clock-bit checks" adds silicon (does it not) and thus many (most) avoid - although I seem to recall one vendor device to perform, "3 such, Start Bit checks."

Vendor's expert - armed w/much "insider info" - has been known to arrive - w/(some) regularity - likely will clarify/confirm...

May I note that - nearing 10 years here (this forum) - I cannot recall such question!     Perhaps the addition of "differential line driver" (i.e. RS422/485) will reduce the incidence of such "mistaken" Start bits - due to (likely) signal glitching.   

Hello Kawada-san,

Yes, that would be a correct interpretation.

Regards
Amit

Hi Amit,

Thanks for the confirmation.

Now let me explain some background:
In my customer's environment, TivaC sometimes gets wrong start bit waveform (with incorrect baud rate), but TivaC does not notice it.
Of cause, I know the wrong start bit itself should be fixed, but my customer wants to know why TivaC does not notice it .
If TivaC would check the start bit with the above interpretation (only 1 checking for start bit verification), my customer is saying that the start bit waveform should be detected with the wrong waveform -- I'm trying to get the actual waveform. I'll get back to you later.

Best Regards,
Kawada

Hello Kawada-san

Indeed knowing what the Start bit looks like for the incorrect Baud is important. Also can the customer check if the any of the error flags are getting set or not

Regards
Amit

cb1_mobile said:

Perhaps the addition of "differential line driver" (i.e. RS422/485) will reduce the incidence of such "mistaken" Start bits - due to (likely) signal glitching.  

UART communication has - and continues to enjoy - greater "robustness" through the use of differential line drivers & receivers.

Techniques (otherwise) mentioned cannot really correct nor reduce the "source disturbance" - thus they are likely sub-optimal.

Method earlier presented - "differential signalling" (thus far kicked to the curb) - provides significant noise reduction - far better enabling even a, "simple test for Start bit" to succeed...,

Is it not better to "prevent the error" - rather than "test for its presence?"

Hi,

Here is the waveform.
The left one is normal case. In this case, Uart works fine.
The right one is wrong start bit case. In this case, Uart does not detect the start bit.
(As for error flags, I'm asking the same to the customer. I would update you once I got the information)

Please note baudrate is 115.2khz for both case.
As you see in the waveform, the wrong start bit should be regarded as a start bit if the datasheet description is really correct, but actually,
TivaC does not detect it... So once again, I need to go back to my first question -- Does TivaC Uart really detect start with 1 clock (4th or 8th, depending on Uart configuration) verification ?

Best Regards,
Kawada

(As for error flags, I'm asking the same to the customer. I would update you once I got the information)

I got the information from my customer. I'll share as below.

Error flags were not asserted with incoming wrong start bit.
If TivaC verified it as a start bit, something erroneous data should be received, but it did not happen. So, TivaC Uart looks ignoring this wrong start bit.

Best Regards,
Kawada

Hello Kawada-san

It could be possible. I haven't checked the design but this being an asynchronous protocol, the voting logic may disregard the transmission.

Regards
Amit

Likely I should,  "know better - shut up - go away!"       (such "has" been suggested - more than once...)

Yet - has simple logic (somewhat) escaped this thread?      And such escape shows no sign of abating - does it?

Thus - here are what I believe to be serious "flaws" in the (persistent) thrust of this thread:     (ready your arrows)

a) Is not "noise" - impressed upon the UART_RX - a most reasonable cause for "Start Bit" corruption?     If so - the past (still avoided) correction, "Switch (from the assumed, single-ended) to differential line driver"  offers great resistance to multiple noise sources - while greatly expanding signal fidelity & range!

b) As "noise" is the "usual suspect" during any such UART_RX data corruption - why such intense interest upon, "ONLY the Start bit?"     Are not all subsequent bits - encapsulated w/in the serial word - equally vulnerable?      All suggestions - beyond those of this author - miss that (unfortunate) fact - do they not?

c) And to this clear "over-focus" upon MCU's, "Start bit handling" - as a current presidential candidate exclaimed, "What difference does it make?"      LM3S808 is dead/buried - is it not?     And TM4C123x is "unlikely" to alter its, "Start bit handling" - is it not?     So - if I may - what IS the point?

Is it "wrong" to expose - with hard facts - a post which operates "outside" of reasonable logic?       (at least one here - thinks not!)

Hello Amit,

Thanks for your comments.
I agree that the clock is asynchronous against incoming waveform and the start bit might not be verified in the wrong waveform case.
I think this can happen.

But this implies another aspect -- we could also say this wrong waveform could be regarded as a start bit when such waveform is being streamed to TivaC Uart Rx.
We are in x16 Baud mode and we should have a chance to verify the start bit with internal 8th clock.
This is probability issue, right ?
With this wrong waveform, my customer has tried several times to check if the start bit is recognized or not, but actually, they could not.

Do you have any comments on this ?
Hopefully, I would like you to re-check the mechanism of start bit detection is really correct in Uart HW design point of view.



Hi Cb1,
Thanks for your help and interest. I would like to focus on the above thing -- mechanism of start bit detection is really correct in Uart HW design point of view. Thank you for your understanding.

Best Regards,
Kawada

Greetings Kawada-san,

We feel your pain - yet sometimes one must accept that, "what is - is!"

LM3S808 is long departed and the odds of TM4C123 having its internals (altered)...?     (you fill in that blank)

Differential line pair has worked very, very well for my small tech firm - and for the earlier firm (partnered w/Tottori Sanyo) which we took public...

Sometimes the "mission" (i.e. delivering a robust product) must rise above "acute curiosity" - which may be quickly "satisfied" via "classic" work-around...

Hello Amit,

Thank you very much for the clarification. I understood.

So, this is last question and inputs from my customer.

Q: This behavior is applicable to both LM3S808 and TM4C1231. Correct, right ?
     My customer has already shipped their products to the market, which LM3S808 and TM4C1231 are embedded.

Once this is clarified, I'll close this thread with verified answer.

Also it would be good if you can share this information with your team and update the datasheet descriptions at the next data sheet update cycle.
I think it may be okay for you to update only for TM4C1231 datasheet.  LM3S808 is too old device for that.

Best Regards,
Kawada

Thanks, Amit.

I close this thread.