USART receiving 8-bit data with parity

[Robert Ritchey]

I am supposed to be receiving 8-bit data with even parity.  The blocks are defined with a header of 'F0', this is S.Bus data if anyone knows that that is.  I setup a simple program that just does receive data.  I get data but nowhere does it show an 'F0'.  Am I supposed to use 'LL_USART_ReceiveData8' or 'LL_USART_ReceiveData9' to read this data?  Is the parity supposed to be read with the data and discarded?  It's not at all clear how the parity is handled. 

[Robert Ritchey]

It seems to show repeating data.  I can post a screen shot of the data later today.  It doesn't matter what the pullup is, its driven by a totem-pole output.  Yes, I realize it uses the TX pin as the input, that is what I have connected. 

[Robert Ritchey]

Yes, the Framing Error and Parity Error get incremented.  I mention this in an earlier post.  You can see what I get if you go back and look.  The code path I have defined is straight through, no branches.  Look at my code again to see how I process it. 

[waclawek.jan]

Read out and check/post the UART registers content. Check the real system clock, too, and by that I don't mean just to look at what you've clicked in CubeMX, but actually measure it in some way. One good way to do that may be to transmit some pattern e.g. 0b0101010101 through the UART (with disconnected other transmitter of course), and observe using oscilloscope/LA.

JW

[Robert Ritchey]

I checked the clock, it is 64MHz.  I did it by configuring a timer channel to divide the system clock by 16 and output a square wave.  It showed a 250nsec period, or 16 MHz.  I also captured the USART registers.  They look fine but I am posting them. 

[Ozone]

Have you observed the s-bus signal on a scope, and compared with the spec ?
I think a logic analyser would do as well, AFAIK sigrok/pulseview even support protocol interpreters.

[waclawek.jan]

UART registers look OK indeed.

At this point you probably need some means to observe the line (oscilloscope, LA).

Btw. Does the transmitter transmit continuously? If yes and the receiver is enabled somewhere in the middle of a continuous stream, it might be a nontrivial task to synchronize.

JW

[Robert Ritchey]

Yes, I have looked at it on the scope and the protocol is correct and frequence is correct.  I can definitely see the "0F* and the bit timing looks OK. 

[Robert Ritchey]

I have looked at it on the scope.  The bit timing seems OK, and I definitely can see the "0F".   I thought it would resynchronize with the stream since there is a large gap between blocks (~5ms) of the 25 bytes sent.  Maybe that is the next place to look. 

[Robert Ritchey]

By the way, here are some of the values I have captured.  You can see its repeating, just not the right values.  Also, do either of you know if the IDLE bit is set when it's not set to interrupt?  It doesn't say.  I keep expecting to see an IDLE when I am polling but it does not seem to get set. 

[Ozone]

Which suggests to me that the UART settings are not quite correct.
As said, I have no experience with S.Bus as such, I even had to read it up first.
One site I came across emphasized that "the s.bus signal is inverted", i.e. bit values a inverted on the bus. This is not uncommon, though. Many RS232 driver stages are inverting, which result in inverting it twice ...

Another thing I'm not sure of is the 9-bit data length you have set.
I would check with the reference manual of the C0x device. I know older STM32 variants allowed only 1 parity bit directly, and one had to set 9 databits to get a 2-bit parity. But the the existance of a respective define suggests to me the C0x UART can handle 2 parity bits directly.

As a side note, you description suggests you failed to properly capture a "reference" transfer package.
I would try to transmit a (similiar) package from the C0x code, and compare the signal with the reference. This should tell you if the UART settings are correct.