This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F280049C: SCI SW reset loops, nesting rules

Guru 56218 points

Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: C2000WARE

Hello,

SCIB randomly gets stuck in repeating SW resets inside the RX ISR. That seems to follow repeating 16 byte data bursts with 200ms blanking between 2 such data bursts. Oddly the OE register flag is never set or rapidly cleared by the SW reset but SCIprtinf() reports 0x4004, assuming OE flag. When RX FIFO data bursts are short (8 bytes) everything works as expected. The CPU seems to lag behind reading RX buffer, OE trips SW reset, not always the case.  

TRM states SCIB TX FIFO is supposed to give RX FIFO priority, that seems to be part of the problem as it keeps transmitting data during RX burst events.

Q1: Why SW reset never exists the RX ISR via (return, clear ACK, DINT) statements being above the ISR__attribute__((interrupt)) C2000 compiler adds IRET inside eabi projects?

Also tried using _asm("  IRET") rather than (return) after SW reset and RX FIFO just dead locks. The only way to clear the SW reset loop requires MCU cold reset. I located file (DSP28_SWPrioritizedIsrLevels.h) deep dive C2000ware_4.01 driverlib, below link nesting rules page mentions. Links text is unclear if that file is part of an example project or mandated for correct peripheral core priority order regardless of tandem groups nesting.

It seems wrong to assume individual groups require nesting as the core priority order is supposed to control inner group core flags. The word Nesting in CPU instruction sets infers one routine exists inside the other, not working in tandem as depicted by TRM 3.3.5 table 3-3 and 3.5.6. A drill down tree illustration might better explain what TRM means by adding words (tandem Group nesting) not just saying one word (nesting) as peripheral core priority controls each inner group pending ISR's and PIE priority so no tandem group nesting should even be required. Yet that does not seem to work as the TRM has depicted the PIE IER group interrupt priority model. Suggesting the groups peripheral core priority silicon has some kind of errata and requires the file (DSP28_SWPrioritizedIsrLevels.h) to work correctly.   

Q2: Does that file have to be part of the project for peripheral core priory PIEIER flags to correctly work? 

https://processors.wiki.ti.com/index.php/Interrupt_Nesting_on_C28x

  • Hi Gl,

    Q1: Why SW reset never exists the RX ISR via (return, clear ACK, DINT) statements being above the ISR__attribute__((interrupt)) C2000 compiler adds IRET inside eabi projects?

    If doing a blocking read, the code is likely in an infinite loop, waiting to receive data before returning from the ISR. A non-blocking read can help to get past that.

    Q2: Does that file have to be part of the project for peripheral core priory PIEIER flags to correctly work? 

    No, the PIEIER flags do not require that code to work properly, it just helps to configure it properly without much potential for error. There is no silicon errata/bug in the PIE other than the ones mentioned in the current errata, and this PIE has been used over several generations of devices and decades.

    Regards,

    Vince

  • Hi Vince,

    A non-blocking read can help to get past that.

    It is a non-blocking read already. I added below to both FIFO ISR's but it still might roll in SW resets. Oddly doing two 8 bit writes to TX FIFO, then 16 byte write burst to RX FIFO more often succeeds without OE occurring.  #pragma FUNCTION_OPTIONS (SCIbRxISR, "--opt_level=1 --opt_for_speed=1").

    There is no silicon errata/bug in the PIE other than the ones mentioned in the current errata

    It seems the link text mentions hardware periodization (peripheral core priority) too. Though it leaves out any details of adjacent groups IER nesting inside others that might cause issues I mention. The Advisory to place _asm(" NOP") in B2B reads of an ISR is mentioned in the c2000 compiler guide as to avoid placing  __asm() around IER flags. Suspect It might be that causing random SW reset error mostly right after a TX ISR locks RX ISR into SW resets.

  • Hi Gl,

    Oddly doing two 8 bit writes to TX FIFO, then 16 byte write burst to RX FIFO more often succeeds without OE occurring.

    Depending on how the other device is transferring data, it could be that the SCI requires a full 2 (or more) stop bits between FIFO bursts. The 2x 8-bit writes and 1x 16-bit write imply that maybe the SCI module needs more time between packets. Splitting it into 2 smaller 8-bit bursts may be allowing the SCI interrupt more time.

    Regards,

    Vince

  • Hi Vince,

    Splitting it into 2 smaller 8-bit bursts may be allowing the SCI interrupt more time.

    From the SCI perspective settings 1152KBPS 1Stop bit, NoParity.

    Exchange: Rx8 bytes, Tx18-20 bytes, Rx8 Tx18-20 bytes then Rx8, Tx18-20 bytes back to HID.

    That double RW action seems to take CPU priority away from ADCC1 IER global priority mask. In only that case does ADC1 not require any priority level could be disabled though it is given global priortiy in each FIFO ISR. Sw rest OE loop an interrupt issue more than likely. I will disable ADCC1 globals in each FIFO ISR to test that hypothesis.

  • Hi Gl,

    I will disable ADCC1 globals in each FIFO ISR to test that hypothesis.

    Thanks, that should theoretically work to stop ADCC1 interrupts from interrupting the ISR.

    Regards,

    Vince