TMS320F28388D: SCI Receive FIFO Problem

Hi,

user6365229 said:

For example: send 8 lengths at a time, receive 8 times, occasionally, receive 255, cause receive interrupt, do not understand the reason.

What have you connected on the other side of SCI. Have you matched the SCI configuration between the sender and receiver. 

user6365229 said:

Add a DEVICE_DELAY_US(1000) delay ,so bbb value is correct; Do not understand the reason.

You are querying the FIFO status and then doing a Char Blocking FIFO which is not the correct sequence. can you please look into the SCI examples in C2000Ware package and follow similar sequence. 

user6365229 said:

Current RxLevel Value is 7，But Tx Data is 8，  The received data is out of order The next time we receive 7 characters, the data is still in disorder.Do not understand the reason.

Receive is equal to or greater than 7 interrupts

Please provide some more information on your test environment on what you have connected to the other side of SCI and are you matching the configurations on both sides? 

Regards,

Sudharsanan

Hi,Sudharsanan

Problem 1,

My other end is connected to the serial assistant, and can receive data, but the second character received is 255, which leads to the stop, and f28388d is used. In addition, the routine in the library can reproduce the problem. Set level to 1 and send 5 characters to try out.

Problem 2:

That is, executing character blocks FIFO. How to rewrite it? Please make it clear!

Problem 3:

Using the routine in C2000 library,

method 1: after receiving the interrupt, the interrupt function is interfutlevel = 7, and the serial port assistant is used to send the length of 8 characters twice.

Method 2: send the length of 8 characters by interlputlevel = 7.

Both methods can be tried out. Please try them. thank!

Due to the urgency of the project, this problem has not been solved for many days, please support more.

Ti,customers

user6365229 said:

Problem one：

SCI FIFO receiving uses SCI_ setFIFOInterruptLevel(SciModuleCfg->SciBase, SCI_ FIFO_ TX16, SCI_ FIFO_ Rx1); use receivedchar = SCI_ readCharBlockingFIFO(SCIA_ Base）; receive
For example: send 8 lengths at a time, receive 8 times, occasionally, receive 255, cause receive interrupt, do not understand the reason.

I do not know your SCI configuration, so could you provide this information, along with scope plots of the TX/RX of the device? Without that, I can only guess. However, this definitely sounds like the host system (not the C2000) is occasionally sending too many bytes at once (maybe another program is accidentally interfering with your host system). Please debug the below questions first though, as those can definitely be part of the issue if you don't time things correctly.

user6365229 said:

Problem two：
SCI_getRxFIFOStatus(uint32_t base)，This functions gets the current number of words in the receive FIFO。
This function should have nothing to do with interruptlevel
But to receive the correct number, add a DEVICE_DELAY_US(1000) delay; the crystal oscillator is 20MHz. If it is not received, it will always be 0
example：
bbb = SCI_getRxFIFOStatus(SCIBase);
DEVICE_DELAY_US(1000);
for(i=0;i<bbb;i++)
{
array[i] = CI_ readCharBlockingFIFO(SCIA_ Base)
}
Add a DEVICE_DELAY_US(1000) delay ,so bbb value is correct; Do not understand the reason.

I do not know your baud rate, but my guess is that you are using a low baud rate. If you are sending 8 characters at 9600 baud rate, then each character will take:
8 bits*(1/9600) = ~840 microsecond PER CHARACTER. So when you wait 1000 us, all the bits finally arrive. That is why you need a delay.

***Please provide your baud rate and SCI configuration settings.***

user6365229 said:

Problem three:

Example：

if((HWREGH(SCIBase + SCI_O_FFRX) & SCI_FFRX_RXFFINT) == SCI_FFRX_RXFFINT)
{
SCI_readCharArray(SCIBase, array, RxLevel);
}
Current RxLevel Value is 7，But Tx Data is 8， The received data is out of order The next time we receive 7 characters, the data is still in disorder.Do not understand the reason.
Receive is equal to or greater than 7 interrupts，

Again, this sounds like a configuration issue on the host side. The byte order that the host system TRANSMITS may be different than what you enter into the host.

The best way for us to help debug this is doing the following:
1. Scope captures of the RX/TX pins of the C2000 device
2. Swapping the non-C2000 device for another C2000 device running our C2000Ware firmware (that way our team will be able to assist with BOTH sides of the communication link)

For any questions that are dealing with the non-C2000 device, we cannot directly assist unfortunately.

Regards,

Vince