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.

RTOS/TMS320F280049C: Sysbios SCI RX Interrupt not triggering

Part Number: TMS320F280049C
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hi,

We have a non-bios project based on the F280049 example code. I am trying to move this into a sysbios project. I have made memory adjustments and am able to get sysbios to run with a task that toggles an LED. The next step is to get the SCI-A RX interrupt to trigger. Note, the non-bios code for this works with the F280049C eval board, but now I don't get a Rx interrupt to trigger. I can put a break point on the ISR handler for the SCI-A RX and it doesn't occur (when adjusting for HWI usage). 

I have made the following adjustments to utilize the HWI module within SYSBIOS:

1) Enabled HWIs in the .cfg and added the HWI for SCI-A RX.

var Hwi = xdc.useModule('ti.sysbios.family.c28.Hwi');
var ti_sysbios_hal_Hwi = xdc.useModule('ti.sysbios.hal.Hwi');

var hwi0Params = new Hwi.Params();
hwi0Params.instance.name = "SCI_A_RX_ISR";
hwi0Params.enableInt = true;
hwi0Params.enableAck = true;
Program.global.SCI_A_RX_ISR = Hwi.create(96, "&sciARxISR", hwi0Params);

2) Adjusted the SCI initialization code. Note, this is an 'unrolled' version of our abstracted code:

// Disable global interrupts.
DINT;

// Plug the interrupt vector 96 with the ISR function
Hwi_plug(96, (Hwi_PlugFuncPtr)rxHandler);

// Disable Group 9 , interrupt 1 in PIE
Hwi_disablePIEIER(9, 0x0001);

SCI_disableFIFO(SCIA_BASE);

SCI_performSoftwareReset(SCIA_BASE);

// Set initial configuration of the SCI
SCI_setConfig(SCIA_BASE, LSPCLK_FREQUENCY, 38400,(SCI_CONFIG_WLEN_8 | SCI_CONFIG_STOP_ONE | SCI_CONFIG_PAR_NONE));
SCI_resetChannels(SCIA_BASE);
SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);
SCI_enableFIFO(SCIA_BASE);
SCI_enableModule(SCIA_BASE);

SCI_performSoftwareReset(SCIA_BASE);

// Set the transmit FIFO level to 0 such that characters will be sent immediately
// Set the receive FIFO level to 1 such that a single character in the FIFO will flag the interrupt
SCI_setFIFOInterruptLevel(SCIA_BASE, SCI_FIFO_TX0, SCI_FIFO_RX1);

// Enable the TXRDY and RXRDY interrupts.
SCI_enableInterrupt(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);

// Clear the SCI interrupts before enabling them in the PIE.
SCI_clearInterruptStatus(SCIA_BASE, SCI_INT_TXFF | SCI_INT_RXFF);

// Enable Group 9 , interrupt 1 in PIE
Hwi_enablePIEIER(9, 0x0001);

Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);

// Enable global interrupts.
EINT;

3) The main.c looks very minimal at the moment. 

uint32_t main()
{
    InitPeripheralClocks();

    // Initialize GPIO
    initializeAllGPIO();

    // Initialize SCI A
    initializeSci();

    // Start the BIOS
    BIOS_start(); /* does not return */
    return(0);
}
  • Wesley,

    I have assigned this threads to one of SYSBIOS experts. Hopefully they should be able to get back to you within next 2 - 3 business days.

    Regards,
    Manoj
  • Thank you, Manoj,

    I'll provide some more information for when the SYSBIOS expert is able to look into this.

    For reference, I am using Code Composer Studio Version: 8.1.0.00011 

    The project is set to use the TI compiler v18.1.2.LTS and includes SYS/BIOS v6.73.0.12 using XDCtools version 3.59.7.20_core

    Regards,

    -Wes

  • What's the difference between "sciARxISR" and "rxHandler"? Which one were you putting the breakpoint in? If you're doing your Hwi creation in the cfg file, you don't need to call Hwi_plug().

    Whitney
  • Hi Whitney,

    The rxHandler is a pointer to the sciARxISR. I just forgot to update the 'unrolled' code here, but I was able to get an interrupt today due to this same code when I removed the Hwi_plug line. Apparently, in my test code I had a logical issue. Unfortunately, I am only able to get the single interrupt which occurs without triggering it via my external connection. After that, I can't trigger it again. Once I am able to analyze the information from the system and SCI registers on the current interrupt, I'll update this post.

    Thanks!

    -Wes

  • Yes, if you could give us more information about the SCI status registers, that could be helpful. Like what is the Rx FIFO status before the interrupt? What is it after? Even though you aren't getting any more interrupts, do you still see the RXFFINT bit getting set? Any error bits set in SCIRXST?

    Whitney
  • Hi Whitney,

    Here are some SCI register memory rendings:

    When interrupt occurs:
    --------------------------------------------
    0x00007200 SciaRegs, SciaRegs_SCICCR
    0x00007200 0007
    0x00007201 SciaRegs_SCICTL1
    0x00007201 0023
    0x00007202 SciaRegs_SCIHBAUD
    0x00007202 0000
    0x00007203 SciaRegs_SCILBAUD
    0x00007203 0050
    0x00007204 SciaRegs_SCICTL2
    0x00007204 00C0
    0x00007205 SciaRegs_SCIRXST
    0x00007205 0090
    0x00007206 SciaRegs_SCIRXEMU
    0x00007206 0000
    0x00007207 SciaRegs_SCIRXBUF
    0x00007207 8000 0000
    0x00007209 SciaRegs_SCITXBUF
    0x00007209 00D0
    0x0000720A SciaRegs_SCIFFTX
    0x0000720A E0A0
    0x0000720B SciaRegs_SCIFFRX
    0x0000720B 21A1
    0x0000720C SciaRegs_SCIFFCT
    0x0000720C 0000 0000 0000
    0x0000720F SciaRegs_SCIPRI
    0x0000720F 0000
    --------------------------------------------

    After interrupt logic:
    --------------------------------------------
    0x00007200 SciaRegs, SciaRegs_SCICCR
    0x00007200 0007
    0x00007201 SciaRegs_SCICTL1
    0x00007201 0023
    0x00007202 SciaRegs_SCIHBAUD
    0x00007202 0000
    0x00007203 SciaRegs_SCILBAUD
    0x00007203 0050
    0x00007204 SciaRegs_SCICTL2
    0x00007204 00C0
    0x00007205 SciaRegs_SCIRXST (changed!!)
    0x00007205 0000
    0x00007206 SciaRegs_SCIRXEMU
    0x00007206 0000
    0x00007207 SciaRegs_SCIRXBUF
    0x00007207 8000 0000
    0x00007209 SciaRegs_SCITXBUF
    0x00007209 00D0
    0x0000720A SciaRegs_SCIFFTX
    0x0000720A E0A0
    0x0000720B SciaRegs_SCIFFRX (changed!!)
    0x0000720B 2021
    0x0000720C SciaRegs_SCIFFCT
    0x0000720C 0000 0000 0000
    0x0000720F SciaRegs_SCIPRI
    0x0000720F 0000
    --------------------------------------------

    So the change during this first interrupt appears to be:
    SCIRXST 0090->0000 [framing error, which then gets cleared]
    SCIFFRX 21A1->2021 [Rx Fifo emptied, interrupt cleared]

    Pause during operation:
    --------------------------------------------
    0x00007200 SciaRegs, SciaRegs_SCICCR
    0x00007200 0007
    0x00007201 SciaRegs_SCICTL1
    0x00007201 0023
    0x00007202 SciaRegs_SCIHBAUD
    0x00007202 0000
    0x00007203 SciaRegs_SCILBAUD
    0x00007203 0050
    0x00007204 SciaRegs_SCICTL2
    0x00007204 00C0
    0x00007205 SciaRegs_SCIRXST (changed!!)
    0x00007205 00B0
    0x00007206 SciaRegs_SCIRXEMU
    0x00007206 0000
    0x00007207 SciaRegs_SCIRXBUF
    0x00007207 8000 0000
    0x00007209 SciaRegs_SCITXBUF
    0x00007209 00D0
    0x0000720A SciaRegs_SCIFFTX
    0x0000720A E0A0
    0x0000720B SciaRegs_SCIFFRX (changed!!)
    0x0000720B 22A1
    0x0000720C SciaRegs_SCIFFCT
    0x0000720C 0000 0000 0000
    -------------------------------------------

    So the change between the SCI-A Rx interrupt end and the pause appears to be:
    SCIRXST 0000->00B0 [framing error, break detect]
    SCIFFRX 2021->22A1 [4 bytes detected]

    So it appears that breaks are being detected and the FIFO is getting filled up, but I'm not getting the interrupt that I'm expecting. Note, I set the Rx FIFO to set an interrupt on 1 character/word being received on SCI-A so the FIFO should not be filled up.

    Thanks,
    -Wes
  • Actually, after looking at that again, it does appear to have generated an interrupt, but my break point did not get hit a second time which seems odd.
  • So I apparently removed the PIE group acknowledge at the end of my ISR. After restoring this, I am getting interrupts... but I'm continuously getting interrupts. I'm guessing that this is related to the framing error which for some reason I've been glossing over. I'll check into this.
  • Ok. So, I removed the connectors to the SCI-A Rx and Tx pins on my device. Note, I'm using a F280049 control card and had an eval board hooked up for the RS232/RS485,etc connection. After removing these pins and ground the Rx pin, I am still continuously getting interrupts.

    For reference, here is my ISR. Perhaps I am doing something to cause this from within the ISR, or perhaps not doing something that I should?

    interrupt void sciRxISR(SciSettings* settings)
    {
    Uint16 currentRxBytes = 0;
    bool readyToReceive = true;
    bool bufferError = false;

    while((0 < settings->registers->SCIFFRX.bit.RXFFST) && (true == readyToReceive))
    {
    // Pop from HW FIFO
    Uint16 rxData = settings->registers->SCIRXBUF.all;

    // If data is not within byte range, there is a buffer receive error.
    if (rxData > BYTE_MASK)
    {
    // Flag it
    bufferError = true;
    }

    // Only put data into buffer if it is good.
    if (false == bufferError)
    {
    // Put into SW FIFO if there is room
    readyToReceive = (*settings->receiveFunction)(rxData);
    ++currentRxBytes;
    }
    }

    if ((settings->registers->SCIRXST.bit.RXERROR != 0) || (currentRxBytes >= MAXIMUM_INTERRUPT_INCOMING_BYTE))
    {
    SCI_performSoftwareReset(settings->hardwareAddress);
    }

    // FIFO reset - Write 0 to reset the FIFO pointer to zero, and hold in reset
    settings->registers->SCIFFRX.bit.RXFIFORESET = 0;

    // FIFO reset - Re-enable receive FIFO operation
    settings->registers->SCIFFRX.bit.RXFIFORESET = 1;

    // Clear the SCI RXFF interrupt
    SCI_clearInterruptStatus(settings->hardwareAddress, SCI_INT_RXFF);

    // Acknowledge the PIE interrupt.
    Interrupt_clearACKGroup(INTERRUPT_ACK_GROUP9);
    }
  • Note, I updated the interrupt keyword to __interrupt but I still see the same continuous ISR breaks on the SCI-A RX.
  • Based on reading the silicon errata, after the PIE group acknowledge I also tried adding an asm(" NOP"); line but this doesn't appear to change anything. Still seeing the continuous interrupts with a grounded SCI-A Rx pin.

    Note, the value that I'm seeing in the SCIRXBUF is always 0x8000 so it appears to be having continuous framing errors but I'm a bit lost as this code worked fine when I didn't use SYSBIOS. I'll perform some more tests on my non-SYSBIOS project to ensure that I didn't introduce anything.
  • Thanks for the updates. You can use a software reset of the SCI to clear the errors. If you do that, does it recover and stop with the constant interrupts? Also, aren't the signals typically held high when they're idle? I'm wondering if your grounding them is confusing the device.

    You don't need to use the __interrupt keyword with your Hwi function--the dispatcher will take care of the context switch so it's not necessary.

    For future reference, when posting code onto the forum, please use the code formatting tool marked by the </> button. This tool can be located by clicking the "Insert Code, Attach Files, and more" link on the bottom right hand side of the Reply menu. It makes everything much easier to read.

    Whitney
  • Hi Whitney,

    I'll have a task check the SCI and do a software reset it in case of errors. Regarding the signals, I tried leaving them float, grounding, and putting a 3.3v on it to see if it would change the behavior but no luck there.

    Ok, I'll remove the keyword when using the SYSBIOS. I added it due to 28004x technical reference manual (sprui33a) section 3.5.4.2 indicating the need for this. I had used it in my non-SYSBIOS project.

    Regarding inserting code to the forum, I didn't notice that until now. Thanks. I had expected the formatting menu to appear similar to when I post. I'll make sure to use that in future replies.

    -Wes
  • Hi Whitney,

    Within the ISR, I added/modified the error check since my logic was a little off, but I'm still seeing continuous interrupts with the SCIRXBUF = 0x8000 indicating the  framing error.

    I changed the ISR to utilize the following code which checks for the framing error (via the bufferError which is set when the SCIRXBUF is greater than 0xFF which includes the framing and parity error flags)

        if ((settings->registers->SCIRXST.bit.RXERROR != 0) || (currentRxBytes >= MAXIMUM_INTERRUPT_INCOMING_BYTE) || (bufferError == true))
        {
            SCI_resetRxFIFO(settings->hardwareAddress);
            SCI_performSoftwareReset(settings->hardwareAddress);
        }

    I haven't been able to find one, but do you know if there is an example project that uses SYSBIOS with the F280049 processor and the SCI module?

    -Wes

  • I did some searching of past forum posts with similar issues, and it sounds like incorrect baud rates can cause these errors:
    e2e.ti.com/.../437956

    Can you tell me how you're configuring the SYSCLK and LSPCLK? Are you letting the SYS/BIOS Boot module do it or are you calling Device_init() like our examples do? This is one thing that could be different between your non-BIOS code and BIOS code that could be to blame.

    Unfortunately we don't have an example project that demonstrates this.

    Whitney
  • Hi Whitney,

    Thanks! That was it. I apparently misconfigured the clock settings. The timing appeared to be okay on my board (i.e. correct SYS clock setting) but I didn't have the LSPCLK set correctly.

    -Wes

  • Hi Whitney, I'm opening another issue as the clock settings do appear to be the resolution to this one. My problem now is that those settings don't appear to be persisting. Note, the LSPCLK was not what I configured differently. It was the PLL clock.
  • This thread, right? I'll respond over there.

    Whitney