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.

TMS320F280049C:SCI communication problem

Part Number: TMS320F280049C
Other Parts Discussed in Thread: TMS320F280049, TMS320F28027

We encountered a problem about serial port communication when using TI's DSPTMSF280049 chip.

There are two chips in our project, A and B respectively, and B is the chip of TI's DSPTMSF280049.

Firstly, A and B communicate normally through SCI. For the reason that A wants to upgrade,
A temporarily stops transmitting data to B, while B does not reply data to A.

After about 16 seconds, A finished the upgrade and began to transmit data to B, but B failed to reply the data to A.
B could not send data until power-on again.

Secondly, we modified the program of DSPTMSF280049 chip. chip B will always sent data whether or not it received data from A.

It was found that after the upgrade of chip A, data was sent to chip b. chip B could not receive the data of chip A, but it could send the data normally.

In other words, the SCI module of chip DSPTMSF280049 can send data but cannot receive data after it has not received data for about 16 seconds.

Finally, we modified the program of chip DSPTMSF280049. After no data is received for 3 seconds, The SCI module of chip B is forced to be reinitialized,
and then everything returned to normal. Chip DSPTMSF280049 could send and receive data normally.

But we can't modify the program of chip B because it has been solidified into the product.

May I ask the chip TMS320F280049 why there is such a problem?

We used TMS320F28027 on the old product, and the application layer program of SCI module is exactly the same as that of TMS320F280049,
but it can still send and receive data normally after it has not received SCI data for a long time.

Why are these two chips different?(TMS320F28027 and TMS320F280049)

We would appreciate your prompt reply.

  • Hi JG L,

    What is the status of the serial communications bus during the upgrade of MCU B?  

    It seems like the most likely explanation is that you are getting some type of RX error on the bus during the upgrade of MCU B.  Break-detect would be the most likely: some extended period of the bus going low.  Can you connect to JTAG of the C2000 MCU A and check the SCI RX status register? 

    If this is the case, the solution could be as simple as adding an external pull-up on the MCU B SCI TX pin to ensure there are no issues while the MCU is upgraded.  You could also write some code on MCU A to recover from an RX error in the SCI (which entails resetting the module when an RX error is detected).  

  • Part Number: TMS320F280049

    Hi team,

    When customer use TMS320F280049,  UART didn't received data for 16S, the UART is down.

    At the same software structure, TMS320F28027 is OK. Could you explain this for us? Thanks.

    Here is the scenario:

    There are two TMS320F280049, the name is DSP-A and DSP-B, those two DSP communicate though UART;

    scenario 1. DSP-A is updated by other CPU, it take 16s, DSP-A and DAP-B didn't communicate for 16S, after 16S pass, DSP-A update success, it start to communicate with DSP-B though UART, now, the UART of DSP-B is down, those two DSP can't communicate though UART; after re-power DSP-B, DSP-B can work well with DSP-A;

    scenario 2. Changing the firmware based on scenario 1, DSP- B sent data to DAP-A all the time, DSP-A is updated by other CPU,  it takes 16s to complete, when the DSP- B didn't receive data after 16s, the UART is down, DSP-A can't communicate with DSP-B though UART;

    scenario 3. Changing the firmware based on scenario 1, DSP-B is initialized when UART didn't received after 3s, DAP- A is updated by other CPU, it takes 16s to complete, then it communicate with DSP-B though B. It works well. 

  • Hi Songzhen,

    This appears to be duplicated with the following thread:

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/887244

  • Hi JG L,

    Were you able to resolve this issue via clearing or preventing an RX error, or other means?