LAUNCHXL-F280049C: TRM SCIFFRX register INT bits 6-7

Hi Jason,

The identified issue SCIB RXFIFO level check does not return level status once the RXFFINT flag has been set high. That level check always occurs after the RXISR function calls handler incoming data. The code snip below (FIFO level status) when placed in the RX data handler debug halts inside level check snip always with RXFIFO overflow flag set and the RXFFINT flag being set, No RX error flags being set, e.g. OE, FE, PE.

To make things more complicated ADCC has highest group interrupt priority (1.3) granted inside SCIB TX/RX FIFO ISR handlers. That was in MCSDK 21µs ISR thus suspect UMCSDK is roughly the same ISR timing.

And SCIB TXFIFO keeps interrupting even as RXFIFO overflowed last RXFFINT flag pend to ePIE. Suspect FIFO level check (HWREG) even when locally placed inside the RX handler (code snip) without stacking (push/pop address) is using a volatile CPU instruction decode. So it often freezes PIE SCIB RXFFINT interrupt to the CPU. Being the RXFIFO RXFFINT flag is perpetually locked high state, requires debug CPU reset to clear locked ePIE flag. 

/* Timeout MAX count for getting RXD FIFO bytes */
for(Timeout = 0; Timeout < timeout; Timeout++)
{
	/* Load RX data elements */
	for(i = 0; i <= 31; i++)//<= 15-31
	{
		/* Blocking checks FIFO space filled 0-15=16 words */
		//while(SCI_getRxFIFOStatus(SCIB_BASE) == SCI_FIFO_RX16)

        /* Check RXFIFO OVF flag */
        if(i >= 32)
        {
            /* Check SCIFFRX register FIFO has overflowed */
            if(SCI_getOverflowStatus(SCIB_BASE) == SCI_FFRX_RXFFOVF)
            {
               if(((HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF) &&
                       (HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINT)))
               {
                   /* Clear Rx overflow status */
                   while(HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFOVF)
                   {
                       /* clear SCIFFRX RXFFOVF SCIB */
                       HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFOVRCLR;
                   }
                   while(HWREGH(SCIB_BASE + SCI_O_FFRX) &= SCI_FFRX_RXFFINTCLR)
                   {
                       /* clear SCIFFRX RXFINT SCIB */
                       HWREGH(SCIB_BASE + SCI_O_FFRX) |= SCI_FFRX_RXFFINTCLR;
                   }
                }
             }

            /* Stop OVF FIFO loading */
            return(0);
        }

        CcRxBuff[i] = (HWREG(SCIB_BASE + SCI_O_RXBUF) & SCI_RXBUF_SAR_M); 
        
                /* If the RX FIFO FULL status wait until it empties */
         while(((HWREG(SCIB_BASE + SCI_O_FFRX) &SCI_FFRX_RXFFST_M) >>
                                  SCI_FFRX_RXFFST_S) >= SCI_FIFO_RX8{}
        
        }
        
    }
}    

Long story short if RXFFOVF & RXFFINT flags cannot be cleared in the ISR handlers or the application. More likely the TXFFINT ISR or called function is causing the fault condition in RXFFOVF. Strategic placement of TXFIFO level check after data input via (for / while) loops can arrest the RXFFOVF random flag set.

Oddly doing FIFO blocking level test before data output caused random RXFFOVF flag set. High speed circular data handling between RX/TX FIFO interrupt level requires specific application handling to avoid RXFFOVF. Since the RXERROR flag is not being set for the RXFFOVF RXFFINT flag sets that occur After the RX/TX-FFINT clear ACK. Not sure placing clear ACK near the top of either ISR would stop the issue since ADCC ISR granted priority both TX/RX FIFO interrupts. 

Seemingly issue describes a race condition and modification of silicon could help to stop random RXFFOVF flag conditions.