Other Parts Discussed in Thread: C2000WARE
Hello,
I have been having odd lockup issues of the SCI RX FIFO level filled by sci.h calls to driverlib SCI_getRxFIFOStatus(). The RXFIFO works for one fill of 16 bits then randomly locks up when more than 16 words are received every time. Only on the rear occasion will it ever allow more than 16 words even with array buffering and return status blocking method. RX FIFO full level seemed to work for several cycles only one time after disable ADCC1 interrupt RX function passing RX buffer data into several numbered buffers. All other times in RX FIFO ADCC1 has priority over group 9 and must be that way.
Oddly ADCC1 ISR handler remains a blinking LED also ignored disabling the CPU interrupt. Hence my reason to question if the FIFO was locking up and not posting any RX exception messages. The ADCC1 INT has global group priority in SCI RX/TX interrupt handlers and attempts to clear IER/IFR flags worked only one time in the sub function.
Edit 1/14/23: The RX-FIFO seems to be locking up not triggering RX overflow INT and RXFFST is not clearing bits after a match of RXFFIL register event.
To my surprise the call does >> 8u in the SCIFFRX register. Seemingly the HW macro IP would be at the lower 8-bit Word of RXFFIL bit-0, >> 8u to NULL address space.
Perhaps (SCI_FFTX_TXFFST_M 8u) in (hw_sci.h) should (<< 8) to be at RXFFST to read bits 8-12 in the return FIFO fill level.
Does the x49c CPU read registers from MSB 15 to LSB 0? The HW macro calls read backwards from right to left?
Sorry for the confusion as ARM Cortex CPU reads registers from bit 0 to 31 and that would seem the proper way all CPU should read registers.