This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28023: BRKDT issue in F28023

Part Number: TMS320F28023

Dear c2000 expert,

I'm using F28023's UART peripheral, and configure the baud rate as 600 bits/s, 8bit data, one bit parity, and one stop bit. 

But I found that sometimes if the other device send data 0x00, that will cause BRKDT bit set. Sometimes it's normal that RXRDY get set, but NO BRKDT.

Below is the waveform of what I have got:

1. BRKDT bit set after receiving 10 consecutive low bits(1 start bit + 8 data bit + 1 parity bit), but RXRDY is not get set.

CH1(Blue): TX pin, CH4(Green): IO shows RXRDY, CH3(Purple): IO shows BRKDT

2. BRKDT bit is not set after receiving 10 consecutive low bit(1 start bit + 8 data bit + 1 parity bit), but RXRDY get set.

CH1(Blue): TX pin, CH4(Green): IO shows RXRDY, CH3(Purple): IO shows BRKDT

0x00 will have 10 consecutive low bits(1 start bit + 8 data bit + 1 parity bit), is it the condition that BRKDT bit get set? 

Can you please help me understand why there are differences between those 2 waveform?

I would like to know how can I make the device receive correct 0 value with parity bit. Thanks...

Regards,

Jack

  • Jack,
    what is your LSPCLK?
    How large is your percent error from 600 bits/S?

    Regards,
    Cody
  • Cody,

    My LSPCLK is 12.5MHz.

    This device gives me the max error +/- 3% under -40'C - 125'C. But the above test result is at room temperature.

    I got actual baud rate 602.4 in room temperature. That gives 0.4% error.

    Regards,
    Jack
  • Hi Cody,

    After disabling the parity bit, the BRKDT condition will still happened, but this time, the RXRDY will also get set. Here is the test result:

    CH1(Blue): RX pin, CH4(Green): IO shows RXRDY flag, CH3(Purple): IO shows BRKDT flag

    Regards,

    Jack

  • Dear c2000 expert,

    Is there anyone who can help on this?

    From above test, I've got
    - With even parity, when received 0(there will be 10 consecutive low bits ), the BRKDT sometimes get set, RXRDY is not get set sometimes.
    - Without parity bit, when received 0, BRKDT sometimes get set, and RXRDY also get set.

    I'd like to know how does BRKDT get set? Sometimes BRKDT get set, sometimes not, after receive 10 consecutive low bits, why?

    Why the BRKDT get set while received 9 continuous low bits? How to make device receive correct 0 value with even parity?

    Regards,
    Jack
  • Cody and c2000 team,

    Any feedback about this issue? My product is waiting for the solution then pass to factory. Hope someone could help on this.

    Jack
  • Jack,

    I am looking into this, I will post my results after I have confirmed them. See my notes/ questions below.

    Note at a baud of 600 I expect a baud period of 1.66mS it looks like your waveform is using a bit time of 1.68mS. But this is close enough that it shouldn't cause a problem.

    What are you using as a clock source? Clock jitter might be causing some of your problems.

    What type of GPIO qualification are you using on the RX pin? (it should be asynchronous).

    Regards,
    Cody

  • Jack,

    I have done quite a bit of characterization and debug on my end. I was able to reproduce similar results to yours!

    When using an accurate oscillator for SYSCLK and a precise baud rate input(from my PC) I experience no issues. The behavior you are describing occurs when either:

    1. The error in the incoming signal's baud rate becomes too high(in my case I saw this happen around +/-4.4% from the ideal, however I think this number will vary some device to device).
    2. If my Oscillator's frequency was off... that would caused SYSCLK's frequency to be incorrect, so LSPCLK's frequency was incorrect, so the baud rate of the SCI was incorrect and I began seeing Framing and Break Detect errors. 

    Ultimately based on my tests I think you shouldn't have any issues receiving 10 consecutive low bit times if your clock frequencies are accurate. Please verify your oscillator's frequency, this can easily be done by setting up XCLKOUT.

    Another way to test sending 0x00 with 1 stop bit and even parity is to just provide a low pulse to the SCI module, This can be done with a function generator. Start with the ideal period for 10 bit times of 16.66mS(for a baud of 600) and increase/ decrease this until the SCI module receives the correct value. Please tell me the range for which the device receives the correct value. Also, for the test make sure the device is configured with 8 data bits, 1 stop bit, and even parity.

    I am eager to hear your findings! Hope it helps!

    Regards,
    Cody

  • Cody,

    Thanks for your reply.

    What are you using as a clock source? Clock jitter might be causing some of your problems.
    Jack - > I used internal oscillator as clock source, but this test is under room temperature, that shouldn't have any problem.

    And after switching to use external XTAL oscillator, this issue is still happened. I have test the single bit time in TX pin, it's about 16.8 ns, I think the oscillator may not be the root cause.

    What type of GPIO qualification are you using on the RX pin? (it should be asynchronous).
    Jack-> Yes, it is asynchronous type.

    Can you please let me know what is buad range(% error) that could make device receive correct value? Thanks...

    Regards,
    Jack
  • Typo error:

    And after switching to use external XTAL oscillator, this issue is still happened. I have test the single bit time in TX pin, it's about 1.68 ms, I think the oscillator may not be the root cause.

    Here it is the test waveform:

    CH1: RX pin, CH2: TX pin, CH3: IO shows RXRDY flag, CH4: IO shows BRKDT flag

  • Jack,

    I don't have an exact %error that will be acceptable. However, when using the internal oscillator for my testing yesterday my system could tolerate up to a 4.4% error around the ideal bit time of 1.66 mS.

    "I have test the single bit time in TX pin, it's about 1.68 ms, I think the oscillator may not be the root cause." this statement confused me, are you measuring this single bit time on F28023's Tx pin?

    Can you please describe how TX and RX is connected in your system?

    • What is providing messages to the SCI's RX pin?
    • Are you looping back signals from the SCI's Tx pin to the SCI's Rx pin?

    I will look into other alternatives to my oscillator theory, but for now please characterize what pulse width the SCI module receives a 0x00 message correctly. I have tried this test on my end and I received the correct value of 0x00, with no Errors, when the low pulse width is between 15.93mS-17.39mS (which equates to 16.66mS+/-4.4%). If I went below 15.93mS I would get a parity error, if I went above 17.39mS I would receive a framing error and a break detect error.

    If the SCI module doesn't ever receive 0x00 correctly, even when you vary the low pulse width, we have another problem altogether. If that happens please describe the behavior, and what values are received.

    Regards,
    Cody