TMS320F28377D: UART Auto baud detection doesn't work correctly

Part Number: TMS320F28377D

Hi,

On the customer’s product in the field, the error has recently occurred on Autobaud detection of UART communication between F28377D and FPGA even though there is no error before.

They’re using 100kbps at the boot and the Autobaud detect is used. They have confirmed that “A” with 100kbps was returned after FPGA sent “A” with 100kbps, from 2 years ago to this year

However, the error has occurred recently on almost every systems that F28377 returns “A” with 105kbps.

1. Is there any change on Autobaud function or device recently ?
2. There is the following description in the Note in the page 2315 of the TRM.

this slew rate can limit reliable autobaud detection at higher baud rates (typically beyond 100k baud) and cause the autobaudlock feature to fail.

They’re using 100kbps. Is 100kbps OK ? or Does this cause the autobaudlock feature to fail ?

Thanks and regards,

Hideaki

Hi Hideaki,

There is no change to the autobaud detection feature (or the SCI itself) on F2837x between now and the past 2 years. Were they able to reproduce this on more than one part and more than one board - ABA swap?

Best Regards,

Delaney 

Hi Delaney,

Thank you for your answer. They found that their setting value of baud rate seems to be problem.

 RE: TMS320F28377D: PERx. LSPCLK Frequency in boot sequence 

Again, let us confirm the following Note.in the page 2315 of the TRM.

Is it OK to use 104.16Kbps which they're now setting ?

Also, from the formula SCI Asynchronous Baud = LSPCLK / ((BRR + 1) *8), if LSPCLK is 2.5MHz at boot time, it can set the Baud as 156kbps or 78kbps (104.16Kbps is impossible).

Should the host FPGA send the data with 78kbps baud rate ?

Since INTOSC is quite variable, they are concerned that even if it is sent at 78kbps, it will be misjudged depending on the judgment method.

Thanks and regards,

Hideaki 

Hi Matsumoto-san, 

Please note that due to the holiday season, there may be some delay in responses. 

Best Regards,
Aishwarya

Hi Aishwarya,

Thank you for your reply. Yes, understood. It would be appreciated if we can receive an answer soon.

Thanks and regards,

Hideaki

Hi Hideaki,

Apologies for the delay. 

Hideaki Matsumoto said:

Is it OK to use 104.16Kbps which they're now setting ?

I have sent an email to the design team to understand better where this limitation comes from.

Hideaki Matsumoto said:

Should the host FPGA send the data with 78kbps baud rate ?

Yes, I would suggest a configuration of 78kbps at boot time. At this baud rate, the known error (based on the LSPCLK=2.5MHz and baud rate match) would be 0.16%. SCI communication will work correctly until an error of 4.1%. With a +/- 3% error of INTOSC, the max expected error would be 3.16%, which doesn't exceed 4.1%, so they shouldn't see communication errors. I would still make sure they minimize the noise on the SCIRX pin as much as possible though. 

Best Regards,

Delaney

Hi Delaney,

Thank you for your reply. The customer has evaluated the SCI communication with 78.125kbps which you suggested.

Then, F28377 responded as 78.09kbps.

As you mentioned that SCI communication will work correctly until an error of 4.1%, they tried 3% and 4% earlier speed, but they were not able to receive a response from F28377.

Is it true that 4.1% error should be acceptable ?

Is it the specification ? described in the datasheet ? 

Thanks and regards,

Hideaki

Hi Hideaki,

The 4.1% error calculation is not a data sheet spec, but rather a number we have come up with internally based on the design of the SCI module and how it does majority voting / logic level interpretation. Some questions about how they are doing this test:

For the SCIRX pin, what GPIO qualification settings are configured?

How are they adding an error of 3% or 4%? Are they changing the transmitting device's baud rate to the errored amount? There would still be a potential added error relating to oscillator + any error for the oscillator on the other device. I'm guessing that the actual error % between the two devices during their test is greater than 4.1%.

Best Regards,

Delaney

Hi Delaney,

Thank you for your answer, but let me confirm a little more because the customer’s issue has not yet been solved. Also, I replied to your questions at the bottom of this post.

We read the TRM about SCI Auto-Baud and Autobaud-Detect Sequence, but the customer and myself would like to know the auto-baud mechanism and sequence in detail.

https://www.ti.com/document-viewer/ja-jp/lit/html/SPRUHM8K#GUID-FAFB1E54-21F1-4DDB-A459-5EF2574FFFC2/TITLE-SPRUH18SPRU0518989

Could you share the detail information of Auto-Baud ?

We want to know how the auto-baud detect logic can detect and set a baud rate.

At SCI boot sequence, I think SCI has the following conditions. Correct ?

    INTOSC2: 10.0MHz
    LSPCLK:   2.5MHz (LOSPCP /4 at SCI boot sequence)

    Then, the auto-baud module of SCI on F28 can set the following baud rate / cannot set other baud rate than below.

    BRR       Baud rate
    1            156.250k
    2            104.167k
    3            78.125k
    4            62.500k
    .             .
    .             .

On this condition and in theory,

If a Host starts communication with F28377 via SCI @91.146k baud rate, what’s happen ? F28 cannot detect the baud rate ? It outputs nothing ?

If a Host communicates @80.469k (78.125k + 3%), what’s happen ? Does F28 start SCI communication @78.125k baud rate ?

If a Host communicates @75.781k (78.125k - 3%), what’s happen ?

If a Host communicates @82.031k (78.125k + 5%), what’s happen ?  F28 cannot set 78.125k baud rate ?

If a Host communicates @74.219k (78.125k - 5%), what’s happen ?  It can set 78.125k baud rate ?

Delaney Woodward said:

For the SCIRX pin, what GPIO qualification settings are configured?

As this is SCI boot sequence, I think GPIO is set by ROM bootloader. Am I correct ?

Delaney Woodward said:

How are they adding an error of 3% or 4%? Are they changing the transmitting device's baud rate to the errored amount? There would still be a potential added error relating to oscillator + any error for the oscillator on the other device. I'm guessing that the actual error % between the two devices during their test is greater than 4.1%.

They are observing the waveform by oscilloscope, so 3% or 4% error includes the error for the oscillator on the host FPGA.

Thanks and regards,

Hideaki 

Hi Hideaki,

I have sent a follow-up email to the design team asking about this since I still haven't received a response. 

Hideaki Matsumoto said:

They are observing the waveform by oscilloscope, so 3% or 4% error includes the error for the oscillator on the host FPGA.

  

I'm still a little confused, they are scoping the signal, but how are they calculating the error? Are they comparing the waveform against a transmitted signal from the F2837x device?

Best Regards,

Delaney

Hi Delaney,

Did you get any feedback from the design team ?

Regarding how to make the error, the host FPGA uses an 80MHz crystal oscillator to make the Baud rate. Therefore, if it is 78.9kbps which is 1% earlier than 78.125kbps which TI proposed, it is generated by 1014 division of 80MHz.

Since the crystal oscillator accuracy on FPGA is 50ppm, They think that the error on the FPGA side does not need to be taken into account in this communication.

Thanks and regards,

Hideaki

Hi Hideaki,

I see, if the FPGA is using a crystal oscillator, then the error introduced by the oscillator on that side would be negligible. There still could be some known error associated with the baud rate + clock speed the FPGA is using, similar to the F28377 device. This would be something else to check - can the FPGA generate exactly a 78kbps baud rate?

From my understanding: The SCI boot sequence uses the autobaud detection feature of SCI to read in the letter 'A' (using a mechanism similar to the eCAP module) and calculates the bit timings based on the captured signal. Then based on this calculation, SCI automatically sets its baud rate registers to match (as closely as possible) the calculated baud rate. If the baud rate being sent by the other device has some known error when used by the F28377 (for example 78kpbs has 0.16% known error at LSPCLK=2.5MHz), then the 'A' sent back by the SCI boot sequence firmware will include this error, and therefore actually generate characters at a baud rate of 78.125 kbps. Any future communication between the two devices with this baud rate setting will have the F28377 using a baud rate of 78.125 kbps and the other device using exactly 78 kbps (assuming no known error on other device). This difference plus any associated INTOSC2 error, which is +/-3%, means that the max baud rate difference between the two devices would have an error of 3.16%. There is also the potential for some added error associated with environmental factors like temperature, age etc. that could push this error % higher - but it doesn't sound like these should be an issue in this specific case.   

What I need to know from design:

1. Is there any other error introduced by the autobaud detection logic when 'A' is input to the F28377 - what is the tolerance of the detection logic?
2. Why is this 100k limitation present?
3. How does the autobaud detection logic work?

I will let you know when I get a response from them. 

Best Regards,

Delaney

Hi Delaney,

Thank you for your reply. Have you not yet gotten the response from the design team ?

We really need the following information as soon as possible. Please continue to support this.

Delaney Woodward said:

• Is there any other error introduced by the autobaud detection logic when 'A' is input to the F28377 - what is the tolerance of the detection logic?
• Why is this 100k limitation present?
• How does the autobaud detection logic work?

Hideaki Matsumoto said:

At SCI boot sequence, I think SCI has the following conditions. Correct ?

    INTOSC2: 10.0MHz
    LSPCLK:   2.5MHz (LOSPCP /4 at SCI boot sequence)

    Then, the auto-baud module of SCI on F28 can set the following baud rate / cannot set other baud rate than below.

    BRR       Baud rate
    1            156.250k
    2            104.167k
    3            78.125k
    4            62.500k
    .             .
    .             .

On this condition and in theory,

If a Host starts communication with F28377 via SCI @91.146k baud rate, what’s happen ? F28 cannot detect the baud rate ? It outputs nothing ?

If a Host communicates @80.469k (78.125k + 3%), what’s happen ? Does F28 start SCI communication @78.125k baud rate ?

If a Host communicates @75.781k (78.125k - 3%), what’s happen ?

If a Host communicates @82.031k (78.125k + 5%), what’s happen ?  F28 cannot set 78.125k baud rate ?

If a Host communicates @74.219k (78.125k - 5%), what’s happen ?  It can set 78.125k baud rate ?

Thanks and regards,

Hideaki

Hi Hideaki,

I have received responses from design and was able to meet with them this morning. They are still looking into some things, but to update, my current understanding is the below:

The note in the TRM is talking about slew rate error added by external components on the board that effects the duty cycle of the received signal. At high baud rates, this error is more likely to affect the communication / cause communication issues. Design is still looking into why this 100kbps number was used in the documentation specifically, but it may have been chosen arbitrarily as a anything less than 100kbps being a "lower" baud rate. 

The autobaud mechanism runs on the LSPCLK, reading in logic low or logic high levels on each LSPCLK edge. There is still a "known error" associated with the baud rate set via the autobaud mechanism since the LSPCLK frequency only has certain baud rates it can achieve at 0% error. For LSPCLK=2.5MHz, these would be the baud rates you have listed: 156.250k, 104.167k, 78.125k. 62.5k etc. 

Assuming no oscillator error:

Hideaki Matsumoto said:

If a Host starts communication with F28377 via SCI @91.146k baud rate, what’s happen ? F28 cannot detect the baud rate ? It outputs nothing ?

Baud rate registers are set to 104.167kbps baud rate once the 'A' or 'a' at 91.146k is sent. The SCI ROM boot will then echo back the character at 104.167kbps baud rate.

Hideaki Matsumoto said:

If a Host communicates @80.469k (78.125k + 3%), what’s happen ? Does F28 start SCI communication @78.125k baud rate ?

Correct.

Hideaki Matsumoto said:

If a Host communicates @75.781k (78.125k - 3%), what’s happen ?

It will set the baud rate registers for 78.125kbps and communicate at that baud rate. If there is 0% oscillator error, it should be able to correctly receive messages being transmitted at 75.781kbps coming from the other device. If the oscillator error is >1%, they will see communication issues.

Hideaki Matsumoto said:

If a Host communicates @82.031k (78.125k + 5%), what’s happen ?  F28 cannot set 78.125k baud rate ?

The f28377 will set the 78.125kbps baud rate. However, when it then receives messages coming from the transmitting device at 82.031kbps baud rate, they will not be read in correctly since the error is too high for the SCI module to read in each bit correctly (greater than 4.1%), with or without oscillator error.

Hideaki Matsumoto said:

If a Host communicates @74.219k (78.125k - 5%), what’s happen ?  It can set 78.125k baud rate ?

Same thing here as the above.

If there is error in the oscillator during the reception of the initial 'A' or 'a' character, I'm still looking into what would happen with the baud rate set and discussing with design / other experts. I will update tomorrow.

Best Regards,

Delaney

Hi Delaney,

Thank you so much for answering some our questions. Let me confirm a little more.

Delaney Woodward said:

f a Host starts communication with F28377 via SCI @91.146k baud rate, what’s happen ? F28 cannot detect the baud rate ? It outputs nothing ?

Baud rate registers are set to 104.167kbps baud rate once the 'A' or 'a' at 91.146k is sent.

Delaney Woodward said:

If a Host communicates @82.031k (78.125k + 5%), what’s happen ?  F28 cannot set 78.125k baud rate ?

The f28377 will set the 78.125kbps baud rate.

From above your answer,

Host communicates @91.146k  =>  F28 sets 104.167kbps baud rate.

Host communicates @82.031k  =>  F28 sets 78.125kbps

How about 89.843k (78.125k + 15%) from Host ?  F28377 will set 78.125k ? or 104.167k baud rate ?

Could you tell us in a little more detail how the baud rate is decided ?

What is the boundary line which lower or higher frequency is chosen ? 

Thanks and regards,

Hideaki

Hi Hideaki,

I'm not sure if it would round up or down in that case - my assumption is that the autobaud calculates the BRR the same way that the SCI_setBaud() function does:

I will ask the design team about this as well.

Best Regards,

Delaney