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.

TMDSCNCD28388D: SCI communication issue

Part Number: TMDSCNCD28388D

Hi team,

Uses SCIA on the 28388D controlcard ( version B) to communicate with the PC serial port, configured as follows:

The Controlcard plugs directly into the customer's own interface board with a UT3232 chip-based SCI communication circuit (3.3V powered); the computer USB is connected to the chip via a USB-to-serial port. The output of the chip is connected to GPIO35, GPIO36 on the controlcard, and the pins are configured as SCIA_RX. SCIA_TX; receives signals from the computer serial debugger.

The 5-V power supply for the controlcard comes from the interface board, and the gnd signal is also connected to the gnd signal on the interface board at various points on the gold finger.

Checking the SCIA_RX signal from the UT3232 chip to the controcard (that is, the signal to be received by the 28388D) through the oscilloscope, there were some issues:

If the controlcard is not plugged into the interface board, the waveforms are basically same each time the same set of data is sent multiple times (5 bytes at a time) through the serial interface debug software, so the data is transmitted exactly the same.

However, when the SCIA_RX signal is tested in the same place after the controlcard is plugged in, the displayed waveform is much different each time the program is run on 28388 and different data is received each time. And actually the same data is sent. 

The customer suspects it's related to the hardware. And the customer also attempts to power the UT3232 chip on the interface board with the 3.3-V voltage on the controlcard, but the problem remains.

Could you help check this issue? Thanks.

Best Regards,


  • Hi Cherry,

    Thanks for your question, I will provide a follow up upon returning from US holiday. 



  • Hi Vince,

    Thanks and expecting your response!

    Thanks and Best Regards,


  • Hi Cherry,

    Thanks for the question, I have a few questions and potential suggestions (I have highlighted the main questions in bold below for easier reading):

    1. Regarding the following statement:

    If the controlcard is not plugged into the interface board, the waveforms are basically same each time the same set of data is sent multiple times

    Could you elaborate on which board is being measured for waveforms in the above statement? When disconnected, is the controlcard sending the data correctly, or the interface board sending data correctly?

    If it is the control card sending data properly, then the issue is likely with the interface board hardware. If the interface board is sending data properly, the issue is still likely the circuit on the control board, but specifically the circuit where the control-card connects.

    2. My guess is that this could be a level-shifting issue of some kind. Could you provide the schematic for the full circuit from TX/RX pin of C2000 to DP/DM pins of the serial USB cable? I want to see what could be causing the issue.

    3. Please review the "hardware" section in the FAQ I wrote (located here). I believe it will likely speed the debug time significantly on this issue!

    I look forward to your responses.



  • Hi Vince,

    I am the customer that asked  Cherry for the issue. 

    "Could you elaborate on which board is being measured for waveforms in the above statement? When disconnected, is the controlcard sending the data correctly, or the interface board sending data correctly?

    The answer is, when disconnected, it means the control card is disconnected from the interface board, the interface board sending data correctly. but when connected, the data is wrong.

    The circuit on interface card is shown as below,

    The scope on pin 9 of UT3232 is observed when control card connected or not. 

  • Hi,

    Thanks for your follow-up, and for providing the circuit!

    Given what you have mentioned and shown in the circuit, I am leaning towards two potential issues. Please see the action items highlighted in bold below.

    No pullup issue:

    The first potential issue is that there is no pullup on the RX pin (as described in the FAQ thread below):

    Basically, some transceivers may not drive the SCI_RXD pin high between bytes (during idle time). This can cause the SCI_RXD pin (pin 9 of your schematic) to float between +V and GND, occasionally going low between bytes.

    This can be corrected by adding a pull-up on the RX pin on BOTH the SCI_RXD side, AND the RS232_RX side (just in case the USB-to-RS232 side doesn't have an RX pull-up in its board, though it probably should).

    Can you test adding a weak pullup (10k is a good starting point, but may need to get tweaked for application) to both SCI_RXD (and optionally, RS232_RX) pins?

    For more reasoning on why this is an issue, see the FAQ thread above.

    RS232 voltage too high:

    Another potential issue could be that the voltage on SCI_RXD is too high. You mentioned trying 3.3V for supply, but could you verify that the actual output being received on SCI_RXD is MAXIMUM 3.3V?

    Can you please provide a scope capture of the SCI_RXD pin, with peak/minimum voltages visible

    If the SCI_RXD pin (GPIO35/36 of device) is receiving 5V, this can cause problems, as described in the device datasheet.

    Let me know if you have any questions! I look forward to your response.



  • Thanks, Vince,

    Based on your comments, I have modified the circuit shown as below:

    I have added three resistors, R6, R7, R8; Initially, R6=R7=R8=10k, but no improvement is achieved, the issue remains; 

    And I modified R6 from 10k to 12k, 8.45k, or even 5.1k, the issue still remains (R7, R8 are kept as 10k).

    The scope on pin 9 (SCI_RXD) is as below:

    It shows maximum 3.3V on the pin. At the moment, the data sent from PC host is : 10 40 59 99 9A; but at every time sending, the scope on the pin 9 is different. 

    So are there any other potential measures to fix the issue?

  • Hi,

    Thank you for taking the scope capture and trying the pull-up resistors.

    The scope capture provides two insights:

    1. The line is correctly returning to high between bytes, so a pull-up is likely not necessary for this particular transceiver (though it won't cause any issues either, so you can keep/remove it as you see fit).

    2. The data has a lot of "noise" in the packet. See image below. Could you provide the baud rate that is expected to be sent? It looks like high frequency data mixed with low frequency data. At the end of the packet, the pulse width of a bit seems to be around 0.2 ms (~5Kbaud), meanwhile the beginning of the packet has very high frequency (smaller than resolution of image).

    Can you connect a second probe to the RS232_RX line at the same time, so that we can see the input and output of the transceiver? I want to see if the transceiver is adding in this noise.

    This data is not really readable by any device, it is not proper format for a UART or SCI packet, so whatever the cause is of this extra noise is the cause of the problems.



  • Hi Vince,

    Thank you for your comments.

    Based on your comments, I try to test the waveform on RS232_RX pin, but there is nothing on the line, at the same time the SCI_RX pin has the waveform pasted in the previous reply. I check the rs232 plug contact, and finally, I have found that RS232_RX contact is broken and disconnected. Therefore, I repaired the contact and once again have a test, then SCI works normally. The issue is fixed successfully. The waveforms on SCI_RX and RS232_RX are shown as below:

    Ch1 is SCI_RX waveform; Ch2 is RS232_RX waveform. 

    If the same data is sent from PC host RS232 port, the same waveform will be output from SCI_RX pin to DSP. 

    But for Ch2, from the scope above, the waveform amplitude seems a little bit strange. 

    And finally, I removed R6, R7, R8 resistors, the same result is achieved as that in the above scope.

    Thank you for your excellent answers step by step.

  • Hi,

    Glad to hear it is working for you now!

    I would suggest to also make sure that the waveform on the RS232_RX side is cleaned up a bit, it seems like there is a lot of capacitance or slow ramping (could be the broken trace is still slightly disconnected).

    But I am happy to hear all is working properly now!

    If I was able to help you resolve the issue, could you please mark the post that helped the most with "This resolved my issue"? This will help others who have similar questions. Thanks!



  • ok, Thank  you very much. RS232_RX waveform is not very good, it may be caused by long wire from PC to board? it is about 2 meters. 

  • Hi,

    Correct! The longer wire can definitely be a contributor to this, either due to high impedance/parasitic of the wire, or noise received on the line.