LAUNCHXL-F280049C: How CPU reads SCI peripheral registers & IER/IFR flags

Oddly enough the HWREGH seems to be parsing the RXFFST and ignoring the offset in the hot hover macro popup. Using similar syntax in the C file while test of HWREGH hangs in the while loop. No matter how the 32-bit HWREG or even 16-bit HWREGH is parsed does not work. Hex calculator ends up with 12h as the end product and the H file call is not returning the changing byte count of the FIFO as it shifts data out to the CPU in the my (for) loop using the blocking call. 

Only few bytes RX-FIFO get past the blocking macro then deadlocks the FIFO.  

static inline SCI_RxFIFOLevel
SCI_getRxFIFOStatus(uint32_t base)

return((SCI_RxFIFOLevel)((HWREGH(base + SCI_O_FFRX) & SCI_FFRX_RXFFST_M) >>
SCI_FFRX_RXFFST_S));

===========================================================================

Rending of the above blocking function does not when it should no matter how it's parsed.

while(((HWREGH(SCIB_BASE + SCI_O_FFRX) & SCI_FFRX_RXFFST_M) >>
SCI_FFRX_RXFFST_S) != SCI_FIFO_TX16){}

The IER and IFR flags in the motor control SDK 4.01 have named an extern with __cregister symbol. It would not resolve IER in relaxed ANSI/ISO compiler mode contrary to what the compiler text states works in strict too.

I had to change the name to (cregister) for relaxed ANSI and make f2800x49c_device.h the same as cpu.h in CCSv11.2 for a project copied from CCSv9.3. Oddly CCS9.3 had the same compiler v21.6.1.LTS and resolved the symbol __cresgister but CCSv11.2 refused

Suspected a PIE issue being ADCC1 has global group priority SCIB RXISR. Hence reason to attempt disabling IER/IFR DINT only for offline transfers via RXFFST too:

MyFunc(int agrc, char *argv[]) { }

Genatco said:

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.

The TRM is leaving out critical detail of when is the INT trigger (RXFFIL) cleared relative to word count (RXFFST).  Cleared As baud clock shifts match word <= (RXFFST) out of the FIFO for every single word when RXFFIL set to trigger level 1? Yet when the word count (RXFFST = 1) does the very next shifted word matching <= (RXFFIL) trigger another peripheral INT and clear the RXFFST bits?  

Seemingly RXFFST is not auto clearing after a match triggers RXFFIL INT event and blocking does not work by reading RXFFST if not R1S type register. Several TM4C peripheral registers are RW1C, simply reading the contents clears the bits after each CPU read cycle.

RXFFST It must be cleared by SW?

The TRM text below refers to TXFFST and TXFFIL and assumes the same behavior of RXFFST and RXFFIL interrupt triggers.

9. Programmable interrupt levels. Both transmit and receive FIFO can generate CPU interrupts. The interrupt trigger is generated whenever the transmit FIFO status bits TXFFST (bits 12−8) match (less than or equal to) the interrupt trigger level bits TXFFIL (bits 4−0). This provides a programmable interrupt trigger for transmit and receive sections of the SCI. Default value for these trigger level bits will be 0x11111 for receive FIFO and 0x00000 for transmit FIFO, respectively.

Another problem seems to be silicon related errata. The RXST status register error INT bit is an OR of all status flags including overrun condition.  The FIFO overflow is an overrun, they are the same error condition. The FIFO overflow often occurs from an input overrun on the FIFO. The WA being to check the SCIRXFIFO RXFFOVF status bit in the RXINT handler as the register text claims. Nobody is aware of that unless reviewing the Register since the TRM text is not elaborating the silicon has an errata condition/s.

* The RXWAKE flag setting seems coincident with RXFFOVF flag, seemingly the debug GEL file status bit name is crossed with RXERROR status bit. The FIFO is configured enhanced FIFO mode and often did set RXOE during RXISR interrupt Error status check of the RXFFOVF flag. I moved the check of overflow flag into RXISR main path but that's not typical in other TI UART's that actually raise an exception ISR for overflow or overrun conditions.  

New related post to this issue of RXFFOVF related to SCISXT RXRDY flag. 

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1187665/launchxl-f280049c-rxbuf-rxrdy-flag-not-being-set

Part Number: LAUNCHXL-F280049C

Hello,

TRM diagram Fig.23-2 shows the FIFO empties into the SCIRXBUF receive data buffer and the RXRDY flag is a SCISTX register bit. 

Why is the RXRDY flag not being set when the FIFO data is transferred to the RX buffer so the application can poll the RXRDY flag without crashing overflows of the FIFO?

The driverlib (sci.h) calls to check FIFO fill data count is not working for blocking SYSCLK application circular read of the RX buffer and keeping time with asynchronous input data.

Seemingly SCI needs to time SYSCLK reads of the RX buffer by blocking until the RXRDY flag sets/clears for each and every asynchronous character being sent to CPU by the application. 

Oddly don't see any logic shown in Fig.23-2 that would prohibit the RXRDY flag from being set. Yet RXRDY and RXERROR flag bits are never being set, only RXWAKE is being set. Noted as much in my last post about these flags being crossed in debug GEL file register layout.

Below suggested WA for SCI flag bits not being functional enhanced FIFO enabled.

Months ago I had to set the lower peripheral core priory orders of RX TX ISR handlers to embed group 1.3 to take priority over group 9.3 and 9.4 contrary to what the nesting rules state, that does not work at all as documented. Nesting HTML needs to be updated as it gives impression can NOT modify another groups IER in a non-group member ISR handler. However, the higher peripheral core order group INT1.3 is serviced first by the CPU-INT 1.3. So, this is not a nesting violation to assert Group1 IER1.3 inside group 9.3 ISR since it is serviced very late anyway.

Point is the RX ISR INT9.3 is reentrant right after Clear ACK Group 9 as the FIFO INT level is set to 8 and ISR buffers 32 words. The ISR is triggered once again with 32 words being buffered in a single ISR event and causes RXFFOVF error in the ISR handler. The FIFO level ISR event has to be set no >8 words for a single ISR event to load 32 buffered words. I did the same 32 words TM4C1294 since it's UART can monitor the FIFO empty flag at 15 count to continue buffering >16 words in any given ISR event.

How to stop wrapping of RX ISR interrupt well after it has already been cleared by SCI_clearInterruptStatus()?

And (sci.h) clear ISR function can't be tracked by CCS 11.2 to the source C file by CTRL+click on the function name. Stil need the RXRDY flag to be working in enhanced FIFO mode, not just RX buffer mode. Fixing the RX ISR to stop re-entrant after Clear ACK seemingly would help likely stop RXFFOVF flag too. 

There is trouble to clear the SCI RXD ISR  PIEIER flag in the CPU once it has been set even after clearing the PIEIFR after clear ACK group 9. And DINT/INTM does not clear IER9.3 Global mask bit in the CPU, contrary to same Fig.3-2 showing it can clear the IER9.3 global mask once the IER9.3 bit was cleared. The HWREG even cleared the wrong IFR bit watching it in debug register view, one time it did clear IFR9.3 the next time it cleared IFR9.4. 

  /* clear IER/IFR register flags arrest second FIFO INT trigger */
HWREGH(PIECTRL_BASE + PIE_O_IFR9) &= PIE_IFR9_INTX3;
HWREGH(PIECTRL_BASE + PIE_O_IER9) &= PIE_IER9_INTX3; 

Hi Gl,

[Merged threads, please do not create multiple threads for similar topics, thank you]

Genatco said:

Why is the RXRDY flag not being set when the FIFO data is transferred to the RX buffer so the application can poll the RXRDY flag without crashing overflows of the FIFO?

RXRDY flag is defined as shown in the registers section of the TRM. The functionality was determined to be the best course of action for most applications.

Regards,

Vince

Hi Vince,

There was more going on as I didn't have in CPU IER-9 enabled but the TX/RX FIFO were triggering the CPU IER 3,4,9. Had believed SCIB mux to IER INT 3.4 group 9. That was seemingly a mistake enabling in CPU INT IER-3/4? 

Yet TRM vector table 3.5.6 group 9 vectors header state use CPU IER-9.  The RX FIFO goes into OVF anytime >8 words enter RX buffer as FIFO INT trigger point set to 8 words. The only way to stop clear ACK group 9 second ISR event and RXOVF is to disable PIEIER1.3 ADCC1 inside RX ISR and disable PIEIER 9.3 then enable it after 100ns delay.

The odd part was IER3 is EPWMx and IER4 is for eCAPx as shown 3.5.6 vector table TRM 3.5.4.

How was SCI FIFO interrupt levels even working without in CPU-INT (IER flag) 9 and being enabled automatically CPU registers?

Even 16 bytes the RX FIFO re-enters the RX-ISR right after clear ACK group 9 near the exit, how to stop tha?. Group-1 ADCC1 has priority in both TX/RX-FIFO ISR's though each DINT on exit. Seems that should disable the ADCC1 ISR only when RX/TX FFIFO interrupts are asserting, correct?  The compiler is sets via f280049device.h has extern cregister for the IER events in relaxed ANSI/ISO mode. The IER don't resolve in either ISR but compile without warnings or errors. Oddly enough __cregister would not compile in latter versions of CCS even with code analysis disabled in workplace or project.

Vince said:

[Merged threads, please do not create multiple threads for similar topics, thank you]

That was a ligament post how the C2000 CPU reads the peripheral registers LSB-MSB or MSB-LSB? It matters which way the register shift in the mask occurs << or >> and seemed oddly placed in the sci.h blocking calls. It was not so obvious RX ISR was being reentered after clear ACK group 9 when the HID only sent 28 words. The RXBUFF squelched them out after the first 16 words, locks RXFIFO and SW reset does not clear RXFFOVF status.

The RXFFOVRCLR clear should NOT be included in clear interrupt call (sci.h). Who even expected that was being done when TRM states to do check in user code. It was clearing the exception before my ISR code could read the RXFFOVF register. We don't typically clear an ISR at the bottom as that allow re-entrant ISR events to occur. Tthough I have seen that done is some c2000 examples without advisory text to justify why. Perhaps the reason to clear RXFFOVRCLR flag should have been added to call below? I don't have time to investigate obvious C2000 driverlib calls, most calls are typical syntax other TI driverlib MCU classes and expected some consistency would exist in clear ISR events.

    SCI_clearInterruptStatus(SCIB_BASE, ui32IntStatus);

Some calls to sci.h seem to Not work such as the SICFFRX word count RXFFST <= RXFFIL interrupt trigger point, never returns the value to HWREG. Using HWREG to read the word count in while blocking loop hangs the RXFIFO. That may have been re-entrance into RX ISR after clear ACK group 9. And loop buffer misses every word >16 as no blocking at all seems to cause RXOVF flag events. The second ISR causes the buffer to be written 0x0 during the RXFFOVF set flag and ignores any HID data >16 words. That was mind blowing, still is as 8 words have no issues but this is 16 word RX with 1 word buffer.

The RXOVF does not occur in TM4C UARTS and find it strange behavior since a for loop is emptying the RxBuffer into myBuff[i] at very high speed. CPU and PIE should continue to preempt any new IER flag pending until it receives clear ACK group 9. Seems PIE is stacking IER pend events and asserts the FIFO trigger INT when it should drop (preempt) any new pends until after clear ACK are asserted, Hence my madness to preempt further CPU IER flags, stacked pends seemingly come from EPIE flood the FIFO after clear ACK group 9.

Vince said:

IER's get automatically restored on exit of an ISR.

The CPU IER bit was not configured or even enabled by SW, ever. It seems SCI TX/RX FIFO require 3 CPU IER's or they do not work correctly. The group INT mux 9 for CPU IER flag 9 is not being illustrated TRM Interrupts 3.5.3 Fig.3-2. That would help to explain groups require CPU IER flag bit be configured too.

The other point being (cregister) key word for IER/IFR flags are not being resolved in the source file. CCS code analysis believes keyword __cregister is a syntax error. Below WA to resolve IER/IFR in my SCI source code (globals) even with [ #include "F28004x_device.h" ] Latest LTS compilers don't warn _cregister is not resolved in the SCI module, only questions the syntax. Point being it begs the question if compiler actually registered these flags.

cregister volatile unsigned int IFR;
cregister volatile unsigned int IER;

Vince said:

This requires that the IER and INTM are not enabled within the ISR, if they are, then the interrupt can nest.

I believe part of that issue has to do with sci.h INT defines combined RX_RXRDY_BRKDT interrupts as 1 bit. They are separate INT sources SCIRXST even for enhanced FIFO mode, even when SCICTRL2.1 BRKDT bit is not set. Below they are now separate INT bits. Otherwise, the next SW reset hangs the FIFO among other odd behaviors. Perhaps since clearing RXFFOVF in the RXISR by HWREG. So RXRDY flag is separated from BRKDT since RXRDY is not a specific error condition of RXERROR flag bit and signifies the RXBUFF has data.

#define SCI_INT_RXERR 0x01U //!< RXERR interrupt
#define SCI_INT_RXRDY 0x02U //!< RXRDY interrupt
#define SCI_INT_BRKDT 0x03U //!< BRKDT interrupt

Gl,

Good suggestion, separating the BRKDT and RXRDY is a good solution.

Regards,

Vince

Hi Vince,

Vince said:

Good suggestion, separating the BRKDT and RXRDY is a good solution.

Oddly sometimes the SCIRXST ERROR flag is not being triggered for BRKDT INT condition though RXRDY had the same INT source. Not so difficult to separate the flags in sci.h.. Perhaps SDK 's should use C:\ti\c2000ware_4.01 library to reduce redundancy and make easier upgrades via newer versions driverlib into the SDK project builds. If we reference C2000ware_4.01 the compiler warns of shadowing and the SDK's have included similar or modified files.

Removing the SDK project includes c2000ware files, clean rebuilding index to reference C2000ware_4.01 driverlib breaks the project. Even if C2000ware_4.01 driverlib is imported into the IDE the include paths to library Symbols can Not be resolved in the added reference, such as gpio.h, hw_gpio.h. This presented big problems after modifying sci.h to separate the above interrupt sources. For good measure also dropped modified sci.h files in c2000ware_4.01.

Reason why IER would not resolve in my module by (#include f28004x_device.h) and conflicted with (cpu.h __cregister) had to exactly match. Commented below symbol f28004x_device.h also resolve IER in cpu.h. Why so many different MCU class driverlibs in C2000 SDK projects? Are the c2000 CPU instruction sets so different? 
//#ifndef __TMS320C28XX__
#define __cregister
//#endif //__TMS320C28xx__

Above post I was confused by TRM 3.5.5 thinking Rows of group flags, in this case INT9.3 and INT9.4 the 9 signified only the PIE group flag and Columns for INT-3, INT4 were CPU IER flags shown 3.5.2.3. Reason I had enabled CPU IER flags 3, 4 and did not enable CPU IER-9. Though it was triggering CPU register flag 9 and also re-entering the ISR after Clear ACK. That seemed to stop after adding 200ms delay in the HID data stream after TXD every 16 bytes and enabling CPU IER-9 for both FIFO level interrupts.

The SCITX FIFO INT (INT level 8) tended to hog CPU time if the ISR did not ;1. Check IFR flag prior to transport, e.g. (SYSCLK) to Async GPIO, 2. Throttle FIFO (fill level) prior to sending data out the Async GPIO port. Oddly the RXFFIL level bits do not seem to have any effect to control the FIFO ISR events, only the INT trigger level. That IFR polling was imperative to keep ADC CPU INT1 from odd triggering in CCS debug or runtime ADC interrupts skipping over parts of code not being initialized.

I realize 16 bit peripheral registers are read into the CPU accumulator via parallel bus. Yet the HWREG right data shifts (>>) with masking seem to indicate ROM embedded clang interpreter reads are being serialized in reverse order (MSB-LSB), is that correct? I have not studied the CPU to that level just accepted nanobots must exist down there (lol) until HWREG macro does not seem to work as defined.

Is there a TI weblink that explains and illustrates how HWREG macro's are quantified?  

Hi Gl,

Genatco said:

Why so many different MCU class driverlibs in C2000 SDK projects? Are the c2000 CPU instruction sets so different? 

I believe this is for backwards compatibility.

Genatco said:

Yet the HWREG right data shifts (>>) with masking seem to indicate ROM embedded clang interpreter reads are being serialized in reverse order (MSB-LSB), is that correct?

I will contact the compiler expert to answer these two questions

Regards,

Vince

Hi,

C28 data bus is 32 bits wide. HWREG is a 32 bit data read and happens in one shot.

Regards.

Veena

That much I already was aware of so why the right shift versus doing left shift in the register mask? Could you have a look at the RX blocking calls in sci.h they lock up the FIFO or the SCIFFRX register RXFFST bits are not changing. That is why I had suspected the mask shift was being read backwards by the macro RW feature, wherever that exist in c.lib or embedded ROM. The desktop math calculator comes up with 0x12 but that is not the offset for RXFFST bits.

Do you mean this piece of code?

Hi Veena,

Yes, the RX FIFO locks in a while loop via HWREG or just calling the existing HWREG in sci.h. It didn't care how the mask was shifted << or >> had same lock issue.

Genatco said:

while(((HWREGH(SCIB_BASE + SCI_O_FFRX) & SCI_FFRX_RXFFST_M) >>
SCI_FFRX_RXFFST_S) != SCI_FIFO_TX16){}

Do you mean in this code snippet, you could see the Register bit RXFFT set to RX16 (I believe you meant RX16) in Registers view window, still it is not coming out of the loop?

Regards,

Veena

The TX FIFO level check is functioning correctly, even TX ISR while blocking loops work. The RXFFST offset seems odd mask shft 0x8U or for RXFFST bits don't change if the CPU refuses the IER. The C code only reads the FIFO to C buffer after the level is not nearly full or <= some value. Using SCIFFST word bits inside if() test seems to have an effect but unclear to what extent. I assumed the CPU was processing the FIFO but it may be the chicken and the egg scenario using while loop in RX FIFO mode.

My logic was the first 17 words were being processed by the CPU, so the word count should reduce in SCIFFST while loop checking allowing more words to be received. In that case the FIFO would be empty not full so the C code can again buffer 16 more words though I was trying to buffer 32 words at the time.

/* Blocking checks FIFO space filled 0-15=16 words */
while(SCI_getRxFIFOStatus(SCIB_BASE) != SCI_FIFO_RX15)

Hi Gl,

Genatco said:

/* Blocking checks FIFO space filled 0-15=16 words */
while(SCI_getRxFIFOStatus(SCIB_BASE) != SCI_FIFO_RX15)

That should theoretically work to receive any number of bytes, as long as the space between packets of 16 words is sufficient.

Regards,

Vince

Hi Vince,

It only halts the RX FIFO with the C code used to read the FIFO in 16-word 4 loop buffering called from the ISR. The chicken came before the egg or after seemingly has some relevance during buffering of 26-28 words. The OE flag is being tripped when the CPU can't read the RX buffer, correct? 

Hi Gl,

Genatco said:

The OE flag is being tripped when the CPU can't read the RX buffer, correct? 

OE is specifically tripped when "a character is transferred into registers SCIRXEMU and SCIRXBUF before the previous character is fully read by the CPU or DMAC." So in this case, the SCI sounds like there may not be sufficient time between the data packets (the interrupt takes 7/8 of a bit time after stop bit before it triggers). If the data is 1-stop-bit and the interrupt does not complete within 1/8 of a bit time, then OE (and potentially other errors) would occur.

Regards,

Vince

Hi Vince,

I had to side burner SCI and debug another UART issue as the vendor made huge modifications to the OS that affects similar serial code. I will try to get back here next week with any SCI updates. 

One thought to stop OE is to put while{} blocking after the char buffer[i] so it can clear the RX buffer of the 16th word.

Hi Vince,

Vince said:

That should theoretically work to receive any number of bytes, as long as the space between packets of 16 words is sufficient.

Any RXFF blocking at all causes even more issues with RX buffer being locked in rolling SW resets. I added extra clear RXISR above clear ACK group 9 stopped IFR flag being stuck after clear ACK. Removing ADCC1 priority from RXISR did not stop re-entry after the first 15 words had been processed by C code 4 loop. So this second ISR clear may be a WA for ghost tripping OE and OVF flags.

Oddly enough syntax (i < 16) in the 4 loop is not counting 0 as being real number, should stop the loop on 15, not 14. There are other odd issues that seem to be affecting basic c.lib clang functions as other code that works on ARM CPU is not working on x49c via similar debug stepping.  

Hi Gl,

Genatco said:

There are other odd issues that seem to be affecting basic c.lib clang functions as other code that works on ARM CPU is not working on x49c via similar debug stepping

One debug path on this is to ensure the library functions (if not from TI's C2000 libraries) are properly ported for C2000 devices. The C2000 devices are 16-bit addressed memory while ARM is 8-bit addressed. Can definitely see issues with ports between 8-bit and 16-bit code.

Regards,

Vince

Hi Vince,

The ARM Cortex M4 I'm also working with has 32-bit registers, hence it can shift 32 words in a gulp into 16 word FIFO. Though the XDS110 debug probe step simulator is not behaving very well seems to account for the count value being 1 less in RXFFIO 4 loop so 15 count is 16 words. I opened a case to report some C lib basic functions are not working correctly with x49c CPU debug simulator or runtime. I discovered (uint16_t char) word length has two leading zeros not being shown in debug simulator passing into called function headers. So 0xC8 is actually 0x00C8 and breaks C lib functions that work correctly on ARM cortex M4. 

The RX FIFO cannot be SW reset or it gets in a SW reset loop. That has me puzzled though it seems to be a peripheral core priority timing issue with TX FIFO. When the RX FIFO word count exceeds 16 even with 20ms-200ms delay between groups of 16 words, it randomly gets stuck in SW reset looping. 

Have to wonder if above mention causes SW reset loops reading RX FIFO uint16_t (char). Since it also passes16 word gulps into a command interpreter function header via char*. The RX FIFO debug words are 0x00 length from the RX buffer and after char* debug sees 0x0000 in the functions with (int argc, *argv[]) headers and storing the RX FIFO data that randomly causes OE, OVF while storing RX words into several C lib array[n] cells.