TMS320F28055: Issue with RX and TX interrupt

Part Number: TMS320F28055
Other Parts Discussed in Thread: C2000WARE

Hi,

 

I'm working on setting up a UART interrupt for the F28055 chip, but the interrupt for the RX line is not getting triggered even though I am sending data to it via UART. I have intialized the interrupts for the RX and TX pins and enabled the clock for SCI C. Could you advise me on what I can do to resolve this issue?

 

These are a few of the functions I have in my code so far:

#

void UART_PIN_init(void)
{
    test_code = 2;
    // GPIO27 for SCITXDC_Z and GPIO26 for SCIRXDC_Z
    EALLOW;
    GpioCtrlRegs.GPAMUX2.bit.GPIO27 = 2; // set GPIO27 pin as SCITXDC_Z
    GpioCtrlRegs.GPAMUX2.bit.GPIO26 = 2 ; // set GPIO26 pin as SCIRXDC_Z

    GpioCtrlRegs.GPADIR.bit.GPIO27 = 1; // set SCITXDC_Z (GPIO27) as output pin
    GpioCtrlRegs.GPADIR.bit.GPIO26 = 0; // set SCIRXDC_Z (GPIO26) as input pin

    GpioCtrlRegs.GPAPUD.bit.GPIO27 = 1; // disable pull up
    GpioCtrlRegs.GPAPUD.bit.GPIO26 = 1; // disable pull up
    EDIS;
}

void SCI_C_init(void)
{
    test_code = 3;
    ScicRegs.SCICTL1.bit.SWRESET = 0;

    // set the clock rate supplied to SCI module
    EALLOW;
    SysCtrlRegs.PCLKCR0.bit.SCICENCLK = 1; // enable the low speed clock
    EDIS;

    // set desired baud rate - 9600, BRR = 1301
    ScicRegs.SCIHBAUD = 5;
    ScicRegs.SCILBAUD = 21;

    // set data format for port
    ScicRegs.SCICCR.bit.SCICHAR = 7; // Data length is 8 bits
    ScicRegs.SCICCR.bit.PARITYENA = 0; //disable parity
    ScicRegs.SCICCR.bit.PARITY = 0;
    ScicRegs.SCICCR.bit.STOPBITS = 0;  // 1 stop bit

    /* RX and TX Enable Registers */
    ScicRegs.SCICTL1.bit.RXENA = 1;
    ScicRegs.SCICTL1.bit.TXENA = 1;

    /*RX and TX Interrupt Enable */
    ScicRegs.SCICTL2.bit.RXBKINTENA = 1;    // receiver-buffer/break interrupt enable
    ScicRegs.SCICTL2.bit.TXINTENA = 1;      // SCITXBUF-register interrupt enable
    ScicRegs.SCICTL1.bit.RXERRINTENA = 1;   // SCI receive error interrupt enable

    ScicRegs.SCICTL1.bit.SWRESET = 1;
    test_code = 4;
}



//TODO: Review implementation to make sure it's done correctly
__interrupt void SCI_RX_ISR(void)
{
    test_code = 5;
    // store the data from the receive character bits in a variable
    receivedChar = ScicRegs.SCIRXBUF.bit.RXDT;

    if(receivedChar != 0x0A)
    {
        RecDataC[index] = receivedChar;
        ReceiveBuf_CPU[index] = RecDataC[index];
        index++;
    }
    else
    {

        //initialize the ReceiveBuf_CPU array
        memset(ReceiveBuf_CPU, '\0', 256);
        memset(ReceiveBuf_CPU + index, '\0', BUFFER_SIZE - index);
        RecDataC[index] = receivedChar;

        for(loop = 0; loop < index; loop++)
        {
           // ASCII values for lowercase letters 'a' to 'z'
          if(RecDataC[loop] >= 97 && RecDataC[loop] <= 122)
          {
              // convert the lowercase letters to uppercase letters
              ReceiveBuf_CPU[loop] = RecDataC[loop] - 32;
          }
          else
          {
              // copy the character as is if it is already uppercase
             ReceiveBuf_CPU[loop] = RecDataC[loop];
          }

        }
//        sprintf(Reply_String, "SCI/UART is Okay! \r\n%s\r\n", ReceiveBuf_CPU);
//        printMSG(Reply_String);
        RecDataC[index] = '\0';
        index = 0;
    }

    PieCtrlRegs.PIEACK.bit.ACK8 = 1;
    test_code = 6;

}



__interrupt void SCI_TX_ISR(void)
{
    test_code = 7;
    PieCtrlRegs.PIEACK.bit.ACK8 = 1;
}
  • Hello, the subject matter expert assigned was out of office but should be able to provide a response within a day or two

  • Hello,

    A few questions and suggestions to try methodically:

    1. To clarify, this is for F2805x, correct?
    2. Have you already referred to the C2000Ware SDK examples to cross check your initializations and setup?
    3. Can you confirm/share your PIE init?
    4. Can you also confirm your GPIO init? 
      1. Are you using async mode? I believe it is GpioCtrlRegs.GPAQSEL2.bit.GPIO26 = 3;
      2. Can you try enabling pullups on GPIO26/27? e.g. GpioCtrlRegs.GPAPUD.bit.GPIO26 = 0;  
    5. What is your target baud rate? Please double check the BRR is set correctly. CPU frequency is 60MHz, and LSPCLK is div4 so 15MHz. For a 9600 baud rate: BRR = (15,000,000 / (9600 × 8)) - 1 = 194 = 0x00C2
      1. ScicRegs.SCIHBAUD = 0x0000;
        ScicRegs.SCILBAUD = 0x00C2;

    Best Regards,

    Allison

  • Hi, thanks for the reply. These are my answers to the aforementioned questions:

    1. Yes, this is for F2805x.

    2. Yes, I have referred to the C2000Ware SDK examples to cross check my initialization and setup.

    3.  Please find attached my PIE init.

    4. a. I see. Thank you. That's a good question because I don't think I had the async configuration code for that included in my project so I will try that out.

         b. I will try doing that; thank you.

    5. My target baud rate is 9600. I'll double check my BRR and make sure I use the same setup you have.

     

    //Disable all interrupts and clear all flags
        IER = 0x0000;
        IFR = 0x0000;
    
    
        //Initialize PIE module
        InitPieCtrl();
    
        //Initialize PIE Vector Table
        InitPieVectTable();
    
        EALLOW;
        PieVectTable.TINT0 = &timer0_ISR;
        PieVectTable.SCIRXINTC = &SCI_RX_ISR;
        PieVectTable.SCITXINTC = &SCI_TX_ISR;
        EDIS;
        
        //setup the interrupts in
        PieCtrlRegs.PIEIER1.bit.INTx7; // timer interrupt
        PieCtrlRegs.PIEIER8.bit.INTx6; // SCITXINTC interrupt
        PieCtrlRegs.PIEIER8.bit.INTx5; // SCIRXINTC interrupt
    
        // enable the interrupts in the IER module
        IER |= M_INT1;
        IER |= M_INT8;
    
        //enable global interrupts
        EINT;
        ERTM;

  • I tried the aforementioned changes and I can see that there is data on the RXDT bits in the SCIRXBUF register but there is still an issue as the data being received is not the same as the data being sent (I wrote some code to continuously send some bytes to the F2805 chip as a way of verifying if the interrupts were set correctly). I'm just wondering whether this issue could still be caused by the initialization and setup code that I have. 

  • Hello,

    Thanks for the follow up responses. I'll take a look at the SW. Can you elaborate on what data you are sending and what data you are receiving back as well as what you are scoping on both lines?

    Best Regards,

    Allison

  • Hi,

    No worries. Yes, I am sending 0x41 (65 when converted to decimal) to the microcontroller but I am only receiving 254 in the SCIRXBUF.bit.RXDT variable when I go into debug mode. In debug mode, I am monitoring the data on the SCIRXBUF and SCIRXBUF registers.

  • Hi Gb,

    Apologies for the extended delay. I will respond in the next 1-2 days. Thank you for your patience. 

    Best Regards,

    Allison

  • Hi Gb,

    A few notes:

    1. Baud Rate Mismatch

    Will start with reiterating my suggestions earlier just to cover bases, can you again double check your BRR? The BRR value of 1301 (SCIHBAUD=5, SCILBAUD=21) is not correct for your target baud rate. The formula is: BRR = (LSPCLK / (BaudRate × 8)) - 1

    • So if your SYSCLK = 60 MHz and LOSPCP.LSPCLKDIV = 2 (default divider = 4), then LSPCLK = 15 MHz:
    • BRR = (15,000,000 / (9600 × 8)) - 1 = 194 → 0x00C2
    • So the correct values would be:
    • ScicRegs.SCIHBAUD = 0x00;
    • ScicRegs.SCILBAUD = 0xC2;

    You can also check your actual LSPCLK by checking SysCtrlRegs.LOSPCP.bit.LSPCLKDIV and calculating accordingly.

    I would also again suggest you implement async mode on GPIO26 if you haven’t already.

    2. PIE Enable Bits Not Being Set

    Other issue within your PIE- looks like in your PIE init, the bits are being read but not written, was this a typo?

    // Wrong — these are just reads, no assignment:
    PieCtrlRegs.PIEIER1.bit.INTx7;
    PieCtrlRegs.PIEIER8.bit.INTx6;
    PieCtrlRegs.PIEIER8.bit.INTx5;
    
    // Correct version for setting the bits:
    PieCtrlRegs.PIEIER1.bit.INTx7 = 1;
    PieCtrlRegs.PIEIER8.bit.INTx6 = 1;
    PieCtrlRegs.PIEIER8.bit.INTx5 = 1;

    3. Clock Enable Before SWRESET

      After you implement the above and try again, can you also please try asserting SWRESET after enabling the SCI clock? i.e.

    void SCI_C_init(void)
    
    {
    
    // Enable clock FIRST, then reset the peripheral
    EALLOW;
    SysCtrlRegs.PCLKCR0.bit.SCICENCLK = 1;
    
    EDIS;
    ScicRegs.SCICTL1.bit.SWRESET = 0; // Then reset
    
    // ... rest of config ...
    ScicRegs.SCICTL1.bit.SWRESET = 1;
    
    }

     

    Let me know any change in behavior after each of the above changes.

     

    Best Regards,

    Allison

  • Hi, thanks for that. Yes, I think there was a typo in my PIE init; thanks for pointing that out. I will make the necessary changes and reach out if there are still issues. Thanks

  • Hi, I tried making the changes and I can see that the RX ISR is being fired now (I have a counter in the ISR that increments each time the ISR is called) but the value being stored in the ScicRegs.SCIRXBUF.bit.RXDT variable is incorrect (I am continuously sending 65 to the F28055 microcontroller but the value 254 is stored in this variable instead of 65). Could you advise me on some other steps to take to correct this issue? Thanks

  • Hello,

    Can you please share your latest clock settings for the SCI and LSPCLK?

    To confirm, are you able to run our SDK examples without changes ok?

    Best Regards,

    Allison

  • Hi,

    Yes, I can do that. I have attached my clock settings for the SCI. The LSPCLK is set as 15MHz and I confirmed this by explicitly setting it to 15MHz in the code to confirm that the default on the F28055 chip is indeed 15MHz. I am able to run the sci_echoback ,scia_loopback and the scia_loopback_interrupts examples

    void SCI_C_init(void)
    {
        test_code = 3;
    
        // set the clock rate supplied to SCI module
        EALLOW;
        SysCtrlRegs.PCLKCR0.bit.SCICENCLK = 1; // enable the low speed clock
        EDIS;
    
        ScicRegs.SCICTL1.bit.SWRESET = 0; //reset the clock
    
    /*    // disable FIFO completely
        ScicRegs.SCIFFTX.all = 0;
        ScicRegs.SCIFFRX.all = 0;
        ScicRegs.SCIFFCT.all = 0;*/
    
        // set data format for port
        ScicRegs.SCICCR.bit.SCICHAR = 7; // Data length is 8 bits
        ScicRegs.SCICCR.bit.PARITYENA = 0; //disable parity
        ScicRegs.SCICCR.bit.PARITY = 0;
        ScicRegs.SCICCR.bit.STOPBITS = 0;  // 1 stop bit
        ScicRegs.SCICCR.bit.ADDRIDLE_MODE = 0;
    
        //disable internal loopback
        ScicRegs.SCICCR.bit.LOOPBKENA = 0;
    
        // RX and TX Interrupt Enable
        ScicRegs.SCICTL2.bit.RXBKINTENA = 1;    // receiver-buffer/break interrupt enable
        ScicRegs.SCICTL2.bit.TXINTENA = 1;      // SCITXBUF-register interrupt enable
        ScicRegs.SCICTL1.bit.RXERRINTENA = 1;   // SCI receive error interrupt enable
    
    
        // set desired baud rate - 9600,
        ScicRegs.SCIHBAUD = 0x00;
        ScicRegs.SCILBAUD = 0xC2;
    
        //RX and TX Enable Registers
        ScicRegs.SCICTL1.bit.RXENA = 1;
        ScicRegs.SCICTL1.bit.TXENA = 1;
        ScicRegs.SCICTL1.bit.SWRESET = 1;
    
        test_code = 4;
    
    }

    Thanks,
    Gb

  • Hi Gb,

    Allison is currently out of office. Please expect a delayed response.

    Best Regards,

    Delaney

  • Okay, no worries. Thanks.

    GB

  • Hi GB,

    Thanks for the patience- let me take a look and try to test over the next 1-2 days.

    Best Regards,

    Allison

  • No worries. Thanks as well.

    Gb

  • Hi GB,

    A few suggestions

    1. Remove ScicRegs.SCICTL1.bit.RXERRINTENA = 1 from SCI_C_init() or add error handling
    2. Change GpioCtrlRegs.GPAPUD.bit.GPIO26 = 0 (enable pull-up)
    3. Confirm GpioCtrlRegs.GPAQSEL2.bit.GPIO26 = 3 is set
    4. Test again and let me know your observations

    Best Regards,

    Allison

  • Hi Allison, 

    I tried the suggested changes but I am still getting 254 instead of 65.

    Thanks,

    Gb

  • Hi GB,

    Can you check SCIRXST register when 254 is received? Do you see any error flags?

    Best Regards,

    Allison

  • Hi Allison,

    I just checked the SCIRXST register and there are no error flags when 254 is received.

    Thanks,

    Gb

  • Are you able to scope the sender's baud rate independently to confirm the actual bit timing is 9600?

    Can you run F2805x in internal loopback so it is echoing its own TX to RX to confirm correct hardware and init?

    Please also export and send me allSCI register values after 254 is received.

  • I see. Unfortunately, I am unable to scope the sender's baud rate independently as the only pin available for the F28055 microcontroller on the PCBA I am working with is the debug probe pin but I will check the SCILBAUD and SCIHBAUD registers for the sender in debug mode. I tried running the internal loopback example before with the TX connected to RX and I could see that the right data was being displayed on the RX line.

    These are all SCI register values after 254 is received:

    ScicRegs	struct SCI_REGS	{SCICCR={all=7,bit={SCICHAR=7,ADDRIDLE_MODE=0,LOOPBKENA=0,PARITYENA=0,PARITY=0...}},SCICTL1=...	0x00007770@Data	
    SCICCR	union SCICCR_REG	{all=7,bit={SCICHAR=7,ADDRIDLE_MODE=0,LOOPBKENA=0,PARITYENA=0,PARITY=0...}}	0x00007770@Data	
    SCICTL1	union SCICTL1_REG	{all=35,bit={RXENA=1,TXENA=1,SLEEP=0,TXWAKE=0,rsvd1=0...}}	0x00007771@Data	
    SCIHBAUD	unsigned int	0	0x00007772@Data	
    SCILBAUD	unsigned int	194	0x00007773@Data	
    SCICTL2	union SCICTL2_REG	{all=194,bit={TXINTENA=0,RXBKINTENA=1,rsvd1=0,TXEMPTY=1,TXRDY=1...}}	0x00007774@Data	
    SCIRXST	union SCIRXST_REG	{all=0,bit={rsvd1=0,RXWAKE=0,PE=0,OE=0,FE=0...}}	0x00007775@Data	
    SCIRXEMU	unsigned int	254	0x00007776@Data	
    SCIRXBUF	union SCIRXBUF_REG	{all=254,bit={RXDT=254,rsvd1=0,SCIFFPE=0,SCIFFFE=0}}	0x00007777@Data	
    rsvd1	unsigned int	0	0x00007778@Data	
    SCITXBUF	unsigned int	0	0x00007779@Data	
    SCIFFTX	union SCIFFTX_REG	{all=40960,bit={TXFFIL=0,TXFFIENA=0,TXFFINTCLR=0,TXFFINT=0,TXFFST=0...}}	0x0000777A@Data	
    SCIFFRX	union SCIFFRX_REG	{all=8223,bit={RXFFIL=31,RXFFIENA=0,RXFFINTCLR=0,RXFFINT=0,RXFFST=0...}}	0x0000777B@Data	
    SCIFFCT	union SCIFFCT_REG	{all=0,bit={FFTXDLY=0,rsvd1=0,CDC=0,ABDCLR=0,ABD=0}}	0x0000777C@Data	
    rsvd2	unsigned int	0	0x0000777D@Data	
    rsvd3	unsigned int	0	0x0000777E@Data	
    SCIPRI	union SCIPRI_REG	{all=0,bit={rsvd1=0,FREE=0,SOFT=0,rsvd2=0,rsvd3=0}}	0x0000777F@Data	

    Thanks,

    Gb

  • Hi Gb,

    Thank you for sending the information. Please allow another day for me to review it.

    Thanks & Regards,

    Allison

  • Hi Allison,

    Okay, no worries.

    Thanks,

    Gb

  • Hi GB,

    Since you are not getting errors, and believe the clock configurations and baud rate settings are correct, it is difficult to determine the cause. The registers look ok to me from a functional perspective.

    Which device are you using to send the message to the C2000 MCU? What are the configurations of the sender?

    Can you also test other send pattern bytes to characterize the error since it appears to be systematic (not random such as due to noise etc.)? If you send the below, what values do you RX on the C2000 SCI?

    • 0x00
    • 0xFF
    • 0x55

    Best Regards,

    Allison

  • Hi Allison,

    I see. I am using the Texas Instruments F28054m to send the message to the F28055 chip. The sender has a baud rate of 9600.

    For the values 0x00, and 0x55, I received on the RX line 0x00. However, for the value 0xFF, I receive 0XFE.

    Thanks,

    Gb

  • Hi Gb,

    Thank you for the info. The 0x55 → 0x00 result is particularly notable. 0x55 (0101 0101) should be a perfectly alternating bit sequence on the line. Receiving 0x00 instead suggests the bit transitions are not being sampled at the right positions, which typically points to a clock or baud rate discrepancy between the sender and receiver, or a signal integrity issue at the physical layer. 

    A few targeted follow-ups:

    1. Can you also double check the F28054M SCI transmitter init code? Specifically: SCICHAR, SCIHBAUD/SCILBAUD values, parity setting, and loopback state. We want to confirm both sides match exactly - the F28054M's BRR calculation needs to match the same LSPCLK and target baud rate.
    2. Confirm a common GND between the two boards - is there a ground wire connecting the F28054M and the F28055?
    3. Sender-side loopback isolation - can you wire the F28054M's own SCITX back to its SCIRX (or enable software loopback on the F28054M) and confirm it correctly receives 0x55 and 0xFF back? Same for F28055 if sending data to itself?

    Best Regards,

    Allison Nguyen

  • Hi Allison,

    Thank you,  I will try the suggested changes and reach out if that doesn't resolve the issues.

    Thanks,

    Gb