SCI RX Interrupt

Nick,

Please check CPSR and confirm that the interrupts are enabled there.

Also please let me know how you exactly have configured SCI and VIM.

Which SCI are you using and are you using the "SCI" or "LIN" tabs in HalCoGen to configure it.

Also which version of HalCoGen are you using?

_enable_IRQ() and sciInit are called.  Do we have to do anything more for the CPSR?

We are using the SCI tabs in HalCoGen

HalCoGen 4.00

Nick,

Regarding CPSR, it wouldn't hurt to check that the I bit reads 0 just to make sure nothing went wrong w. your intrinsic.

There is one more screen to check in HalCoGen:

Also, when you say you aren't getting to the interrupt handler, are you distinguishing between the callback (Notification) function and the interrupt handler?

The interrupt handler woudl be sci1HighLevelInterupt as it appears in the vector table.  If there isn't a hardware issue you should be reaching this handler (try setting a breakpoint there).   But if you haven't enabled notification then the notification routine where you normally put your own handler code won't be called.

VIMRAM looks the same.

I put break points here and sent some text to the hercules 

The interrupt function is called.  I stepped through after the break point and discovered that the first if statement below (case 11 of sci2HighLevelInterrupt) is never true so sciNotification is not called.

Does this mean it thinks there is no data to receive?

Do you mean that

if (g_sciTransfer_t[1U].length > 0U) never evaluates to true?

What did you pass to sciSend()?

Yes.  It never evaluates to true and sciNotification is never called.

I sent a series of random ascii characters to the hercules from a USB to TTL serial converter.  I verified that the characters were being sent correctly by connecting a logic analyzer to the RX line of the hercules.  I can also receive the correct characters using sciReceiveByte in a loop in the main function.

Ok, sorry so you are receiving only.

Did you call void sciReceive(sciBASE_t *sci, uint32 length, uint8 * data)?   Did you give it a non-zero length?

sciReceiveByte and sciReceive do work in a loop in main when RX INT is not enabled.  

Ideally, I would like to call sciReceive in sciNotification.  sciReceive called in sciNotification works on a launchpad with a TMS570LS0432 but now with the TMS570LS20216.

Where is g_sciTransfer_t[1U].length set?  I cannot find any assignments for it in sci.c.

Nick,

That's why I was asking what you were passing to sciReceive() - the length argument sets it:

void sciReceive(sciBASE_t *sci, uint32 length, uint8 * data)
{
/* USER CODE BEGIN (16) */
/* USER CODE END */

    if ((sci->SETINT & SCI_RX_INT) == SCI_RX_INT)
    {
        /* we are in interrupt mode */
        uint32 index = sci == sciREG1 ? 0U : 1U;
        
        /* clear error flags */
        sci->FLR = SCI_FE_INT | SCI_OE_INT | SCI_PE_INT;

        g_sciTransfer_t[index].length = length;
        g_sciTransfer_t[index].data   = data;
    }
    else
    {   
        while (length-- > 0U)
        {
            while ((sci->FLR & SCI_RX_INT) == 0U) 
		    { 
	        } /* Wait */
            *data++ = (uint8)(sci->RD & 0x000000FFU);
        }
    }
}

sci1HighLevelInterrupt is triggered by the RX line

sci1HighLevelInterrupt calls sciNotification if length is greater than 0

sciNotification calls sciReceive

sciReceive sets length

If sciReceive has not set length first, sciNotification will never be called.

Something needs to set length before sci1HighLevelInterrupt right?

I didn't realize that sciReceive was non blocking.  My mistake was not calling sciReceive before the while loop in the main function.  This caused the sciReceives in the sciNotification function to never be called thus never calling sciNotification.  Thank you.

Super - thanks Nick.

We could probably use a good example of interrupt mode receive.  It took me a while to understand it too.

Best Regards,

Anthony