LAUNCHXL-F28P65X: SCI Communication issues

Ashwin Bhaskar said:

ISR Issues with FIFO Status Check: The SCI_getRxFIFOStatus function does not seem to work within the RX FIFO ISR. I attempted to access the FIFO status directly using (HWREGH(base_addr + SCI_O_FFRX) & SCI_FFRX_RXFFST_M) >> SCI_FFRX_RXFFST_S;, but this also fails. Is there a reason why direct hardware access wouldn't work inside the ISR, or am I missing something?

Can you explain what you mean when you say it fails? One thing to keep in mind is that CPU is running much faster than the SCI baud rate. It is possible that the FIFO is simply empty because no new RX character has been received when you read the FIFO status.

Ashwin Bhaskar said:

Inconsistent RX Data: The SCI RX data I'm receiving is inconsistent; I often only receive the last 32 bytes or so of the transmitted data. This inconsistency appears to arise when I send data continuously. However, when I transmit just once, the data is accurate. I'm puzzled as to why this behavior occurs.

This sounds like your FIFO handling scheme has some issue.

Ashwin Bhaskar said:

Interrupt Nesting: Is interrupt nesting enabled in the board or in C2000ware? Is there anything specific I need to do to enable nested interrupts?

Please review the article below.

https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html

Coming back to the original question which I believe is: What is the best way to make use of UART FIFO interrupt level to generate the fewest possible interrupts without creating the possibility of leaving data in the FIFO? 

First, I would personally not set the RX FIFO level to max. SCI interrupts are pretty low in the priority list. Setting the RX FIFO to max trigger level leaves the possibility of an RX FIFO overrun when the CPU is not able to read data in time, e.g. when the CPU is in some higher priority ISR. Interrupt nesting sounds like a fix, but then again you may not want to interrupt some high priority ISR.

Second, you could use an RX FIFO trigger level of 1. This would generate the most interrupts, but given that SCI interrupts have lower priority, this may be acceptable. 

Third, is the frame length embedded in the SCI data? If so, is it possible to architect your code such that you use interrupts to to receive n x 16 characters in the frame, and then uses polling outside the ISR to read the remaining number of a characters? You could do the polling in some background task.

Hi Gus

Thank you for your prompt response

Gus Martinez said:

Can you explain what you mean when you say it fails? One thing to keep in mind is that CPU is running much faster than the SCI baud rate. It is possible that the FIFO is simply empty because no new RX character has been received when you read the FIFO status.

What i meant was I'm sure that data is left in the FIFO because i checked it outside the ISR. If u check the code you can see commented code in the while(1) loop that checks the same. This shows that there is data left in the FIFO, but when i use the same API to check inside the ISR it sometimes throws junk values or 0. Even if i try to access registers directly it still throws the same issues.

Gus Martinez said:

Second, you could use an RX FIFO trigger level of 1. This would generate the most interrupts, but given that SCI interrupts have lower priority, this may be acceptable. 

My concern with such kind of approach is that it will tank my system performance because i have to generate absurd amount of interrupts . As i said i data will be dynamic in size and could come at a periodicity of 200 ms . The data size could go high as 1024 bytes . That's 1024 interrupts inside 200 ms. Will this tank my systems ability to perform other tasks. I am new to TI boards so forgive me if I'm wrong in any of this.

Gus Martinez said:

Third, is the frame length embedded in the SCI data? If so, is it possible to architect your code such that you use interrupts to to receive n x 16 characters in the frame, and then uses polling outside the ISR to read the remaining number of a characters? You could do the polling in some background task.

Do you mean that i should get 16 bytes of data at a time and then poll to get the rest of the data?. That would mean i need to generate interrupt at every 16 bytes. 

Gus Martinez said:

First, I would personally not set the RX FIFO level to max. SCI interrupts are pretty low in the priority list. Setting the RX FIFO to max trigger level leaves the possibility of an RX FIFO overrun when the CPU is not able to read data in time, e.g. when the CPU is in some higher priority ISR. Interrupt nesting sounds like a fix, but then again you may not want to interrupt some high priority ISR.

But that would contradict to what you said above. Are you saying its a tradeoff ?

My main concern is to maintain data integrity without compromising my system performance. 

As i said i am new to TI so please correct me if i am wrong in any of this.

Thank you again for your inputs.

Hi Ashwin,

Note: while(scirxlvl){

Checking buffer level (main.c) high speed loop might lead to synchronization issues between CPU and SCI peripheral, besides it wastes precious CPU time. As Gus mentions set FIFO trigger level below what is expected in a single PIE interrupt for CPU to handle. TRM recommends checking for RX overflow status in the RXISR handler. We ignore overflow data, clear the overflow and exit RXISR. Serial data can cause FIFO framing errors depending on cable length and noise on RX/TX data paths. Be sure to use shielded twisted pairs to reduce errors even when testing between devices, especially testing without long distance receiver & transmit drivers.

      /* Check SCIFFRX register FIFO has overflowed */
        //if(SCI_getOverflowStatus(SCIB_BASE))
        if((HWREGH(SCIB_BASE + SCI_O_FFRX) & SCI_FFRX_RXFFOVF) == SCI_FFRX_RXFFOVF)
        {
            /* Clear Rx overflow status */
            //SCI_clearOverflowStatus(SCIB_BASE);

            /* clear SCIFFRX RXFFOVF SCIB */
            HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFOVRCLR;

            /* SCIA Prints event message */
            SCIprintf("\n*ClrOVF\n");

            /* Flush the RX buffer */
            for(i=0; i == 31; i++)
            {
                CcRxBuff[i] = 0;
            }

            #if DEBUG
                SCIprintf("\n>> RxBuffFlushed \n");

            #endif

            goto Exit;

        }

Ashwin,

I don't know the specifics of your GNSS module and how it generates UART frames so it's difficult to provide a suggestion. My proposal was that *if* the UART data from the GNSS module includes the number of bytes in the frame, then you could architect your code around that. For example, if the GNSS module minimum frame length is say 8 characters, and if one of those characters is the frame length, then you could write your code as:

- RX interrupt level = 8

- In RX ISR, always read 8 characters from RX FIFO. If first 8 characters, determine the frame length there, set some global variable to track the # characters received vs. total frame length

- In main.c background task, wait for # characters received = total frame length. If total frame length is not a multiple of 8 (UART RX INT trigger level), and the last N characters remain, poll UART RX FIFO level until last remaining characters have been received. Here N = frame length % 8. 

Hi Gus,

Thank you for your suggestions,

I think i understand what you are recommending. But ideally it would've been better for me to deal with the N characters inside the RX ISR. I had a logic that required me to check the RXFIL level and use that to get the data within the FIFO. But for some reason i was not able to get the register value even though i am using HWREGH . That was one of my primary questions. 

As Genatco mentioned polling for buffer level or polling the remaining characters might waste system resources, which was my main motive in going for FIFO interrupts in the RX side. 

I will try implementing your suggestions and evaluate my system to see what works. 

Thank you again for your suggestions Gus and Genatco. 

Warm Regards

Ashwin Bhaskar A