TMS320F28032: SCI communication interruption problem

Hi Foriner,

Apologies in advance for all the questions, but please let me know your answers to the following

1. How often does the communication failure occur and what exactly do you mean by "communication failure problems"? What is the output/telling you what is wrong?
2. Can you provide some more details regarding the symptoms of the issue?
3. Are you scoping the SCI waveforms during communication and during failure to see what is happening?
4. Are you able to connect to the devices and check the SCI registers? I'd like to know if any error flags are set during the communication issue as well as the waveforms if possible. or if you can connect and see where the program goes during failure.
5. What is the context of the communication (what data is being sent between the devices as well as size/amount of data)?
6. If you could share the SCI initialization configurations as well, that would be helpful.
7. Are you programs based on any C2000Ware examples? If yes, which? If not, it would be good to double check some of your program with our examples as a reference.

Best Regards,

Allison

Allison Nguyen said:

How often does the communication failure occur and what exactly do you mean by "communication failure problems"? What is the output/telling you what is wrong?

At present, the probability may be between 0.1% and 1%, we have designed the log recording function in the power product software, and found that the abnormal module recorded the abnormal scifail, which led to the shutdown, in addition, the monitoring of the power module also monitored the scifail alarm, and our scifail alarm mechanism was continuously monitored for 10s without receiving information, and under normal circumstances, we would exchange SCI information once in 10ms

Allison Nguyen said:

Can you provide some more details regarding the symptoms of the issue?

Allison Nguyen said:

Are you scoping the SCI waveforms during communication and during failure to see what is happening?

We have only reproduced scifail once in the black box case of the lab module, and then it was automatically restored, and the white box waveform has not been reproduced once after hooking，We looked at the SCI waveform when it was working normally, and the TX and RX were standard and we didn't find any abnormalities

So now the possible speculations: 1) SCI data loading is too blocked? 2) The baud rate does not match or has there been a shift for a while? 3) Problems with the SCI module itself? 4) The baud rate of 115200 is too high and the error rate is high?

Allison Nguyen said:

Are you able to connect to the devices and check the SCI registers? I'd like to know if any error flags are set during the communication issue as well as the waveforms if possible. or if you can connect and see where the program goes during failure.

At present, it cannot be reproduced on the test board, and the production product is very random, and we found this problem through logs

Allison Nguyen said:

• What is the context of the communication (what data is being sent between the devices as well as size/amount of data)?
• If you could share the SCI initialization configurations as well, that would be helpful.
• Are you programs based on any C2000Ware examples? If yes, which? If not, it would be good to double check some of your program with our examples as a reference.

// Initialize SCI-A:
SciaRegs.SCICCR.all = 0x0027; // 1 stop, odd parity,8 char, async mode, idle-line
// bit0,1:enable TX, RX, bit5:Writing a 0 to this bit initializes the SCI state machines
SciaRegs.SCICTL1.all = 0x0003;
SciaRegs.SCICTL2.all = 0x0000;
SciaRegs.SCIHBAUD = 0x0000; // @LSPCLK = 15MHz (60Mhz/4)
//SciaRegs.SCILBAUD = 0x0030; // 15 000 000/(38400*8) - 1 = 47.8
SciaRegs.SCILBAUD = 15; // 15 000 000/(115200*8) - 1 = 15.27

// 10 Complete current RX/TX sequence before stopping
SciaRegs.SCIPRI.all = 0x10;
SciaRegs.SCICTL1.all = 0x0023; // enable TX, RX, re-enable the SCI

// Initialize the SCI FIFO
// SCI Reset,SCI FIFO enable,Transmit FIFO reset,Transmit FIFO clear
SciaRegs.SCIFFTX.all = 0xE040;
// Receive FIFO reset,Receive FIFO interrupt clear,
SciaRegs.SCIFFRX.all = 0x2044;
SciaRegs.SCIFFCT.all = 0x0; 

Hello,

Thanks for the responses. It is unfortunately difficult to guess at what is happening with the problem occurring at a random cadence and without being able to connect to the device and reproduce it or see the SCI line activity. But I did want to be sure to refer you to an SCI debug FAQ. Please be sure to review it in case it applies to you. I would also add that the SCI initialization procedure order can play a role. Please double check your init with what is suggested there.

Another question is are you using the internal oscillator or an external oscillator? The baud rate calculations should be fine (there is negligible error inherent to the SCI module with these clock and baud register values) unless there is some other error being introduced in the hardware that could disrupt the communication.

Also perhaps I missed something, but can you explain what the black box/white box are referring to here?

Foriner said:

We have only reproduced scifail once in the black box case of the lab module, and then it was automatically restored, and the white box waveform has not been reproduced once after hooking，

Have you been able to try other debug techniques such as setting GPIOs for specific error flags? Or some other way to check the status of the program/registers when it fails?

Is there any other detail or definition of an "abnormal sci fail"? I'm not sure what that implies about the SCI module. Is the only information about this the fact that no data was received for 10ms? Also, is this only happening on one of the devices (and if so, do you believe the issue is on receiving end or transmitting end)? Or are you saying both devices are responsible for an error?

Best Regards,

Allison

Allison Nguyen said:

Have you been able to try other debug techniques such as setting GPIOs for specific error flags? Or some other way to check the status of the program/registers when it fails?

The difficulty now is that we can't reproduce the problem in the lab, but the problem is repeatedly recorded in the module log at the customer's site, and it is not convenient for the customer's site to stop the test

The black box means closed product testing, and we recognize the status indication of SCIFAIL from the CAN communication. White-box testing means that we hook both SCI TX and RX out with an oscilloscope

At present, we have found that many modules, DSPs at both ends of the SCI have the problem that they cannot receive each other's SCI data

What I would like to ask is, under what circumstances will the SCI unit of the DSP die and not work, and what if the SCI can be reset correctly in this case and it will be restored?

Is there an update on this issue？

Foriner said:

What I would like to ask is, under what circumstances will the SCI unit of the DSP die and not work, and what if the SCI can be reset correctly in this case and it will be restored?

Hi Foriner,

Could you also answer:

Allison Nguyen said:

are you using the internal oscillator or an external oscillator? T

It is again difficult to assess the issue without more information on the context and symptoms, and there are many cases where the SCI module can run into issues as described in the FAQ I linked in a previous post, but this can be due to configuration, timing, interrupt issues, etc. A few more questions

• Did you check the initializations like I previously asked?
• Can you also please also show me the interrupt ISRs code?
• Are there any other processes in the devices that are disrupted when SCI fails (are you monitoring other GPIOs, power lines etc. when then fails happen)?
• Are the devices resetting at any point during communication?
• Are you using any other interrupts in the devices?

Best Regards,

Allison