TMS570LS20216 SCI RX does not work

Elena,

Will get back to you on this in a short while.

Elena,

Since you have mentioned about SCI2, I'm assuming you are using Pins 10,11 of CON11 ?

In that case, are you sure you are using SCI2 base registers for configuring the module as well as the right interrupt service routine in VIM RAM if you are using interrupts ? 

Hi,

Yes I am using pins 10 and 11 of CON11 and the SCI2 base registers. I am using interrupt and I have mapped the SCI high level interrupt service routine to channel in the VIM table, but I am not sure of the right channel to select.

In the attachment you will find my project.

Thanks,

Elena B

I just got hold of one of our experts on this, can you pls help clarifying on how you are connecting the transmitting  UART on to SCI2 ?  

I have connected pins 10 and 11 of CON 11 to a UIART/RS-232 transceiver and I am using HyperTerminal to TX/RX from my PC.

Elena,

Do you have a connection to GND as well?  You need this and there isn't a GND pin unfortunately on these connectors.  The USB stick isn't really designed to add on boards to those connectors they are mainly for probing.

I am suppling the UART/RS-232 transceiver via a wire from C26 and I am using one of the two GND pins as ground reference. The UART/RS-232 transceiver average current consumption is very low, about 1uA.

Elena,

Ok sorry to keep asking you obvious questions.  Did you check that TX and RX are correct?   What I mean is that sometimes they need to be crossed over, either in the cable connection to your PC or between the transceiver and the micro.    Not sure which transceiver you are using.   On the PC side are you using a DB9 cable?

The TX and RX connection is correct, in fact I can successfully send a byte from the microcontroller to the PC. I am using a MAX3232 transceiver and a DB9 connector to the PC.

My problem is on RX to the microcontroller side. At the moment I am using interrupt and I am not sure if it is mapped correctly. I have tried also the polling mode but RX does not work in any case.

Elena,

The last thing I'd ask you to check would be to see if you can probe / view the data coming out of the MAX3232 chip and going into the MCU's pin. 

There could still be some where the PC wouldn't send depending on how the cable is setup for flow control.
 I don't believe this would block the PC from receiving but it could block it from transmitting.  The flow control signals I'm thinking of are the RTS/CTS and the DTR/DSR/DCD pins.  Used to have a book with the diagram on which signals to loop back to avoid problems but probably you can find this on the internet ... if you don't already have it.

If you've already got it though and you can verify that the UART signal is appearing on the SCI RX pin then I think you are correct and the problem is inside the chip with something like a SCI interrupt setting.

We'll take a quick look at your proj. to see if anything's obvious.   Otherwise the next step would be to check various flags as your application is running to get status information.

EDIT:  Elena, Sorry, probably should have looked at your code earlier ---  I think you are in polling mode.

Take a look at the code in the file sci.c for the function sciReceive and the explanation in the comments:

*   Receive a block of 'length' bytes long and place it into the 
*   data buffer pointed to by 'data'.  If interrupts have been 
*   enabled the data is received using interrupt mode, otherwise
*   polling mode is used.  In interrupt mode receive is setup and
*   the routine returns immediately, sciReceive must not be called 
*   again until the transfer is complete, when the sciNotification 
*   callback will be called.  In polling mode, sciReceive will not
*   return until the transfer is complete.

It looks like you don't have the RX interrupt enabled for the SCI2 module:

Since you only have one call to the sciReceive function you'd only receive 1 byte in polling mode.

You should probably change both of the interrupt enables in the screen above to be on, and
 then use sciReceive() and sciSend() which will then run in the interrupt driven mode.

You can see in the code for these functions that the behavior is changed when interrupts v.s. polling is chosen.

For example in sci.c / sciReceive() the you will take the first condition of the

    if ((sci->SETINT & SCI_RX_INT) == SCI_RX_INT) {} else {};

statement (comment is /* we are in interrupt mode */)  when you are in interrupt mode.  Before changing anything you can confirm by stepping through this function that you are taking the other branch which would be the problem.

You can also let HalCoGen manage turning on and off the SCI TX interrupt flag for you.  It actually defers turning this flag on in hardware until you call the send function but the data structure g_sciTransfer_t  has a member called 'mode' that keeps track of interrupt v.s. polling.  If you pick interrupt driven when it is  time to transmit some number of bytes it'll turn on the hardware interrupt enable at the beginning of the block and turn it off after the last byte in the block is transferred.  I see in your main program you were changing the interrupt enable:

            UART->SETINT = SCI_TX_INT;    // Setting this bit enables the SCI/LIN to generate a

And you should not need to do this.

When you are in polling mode the sciNotification() function is what you will use for your receive interrupt, it is called with the 2nd parameter set to "SCI_RX_INT" when the # of bytes that you requested have been received.  I don't think there's any notification on the transmit side though.  But you can tell by examining the code generated for the sci2(Low|High)LevelInterrupt() functions.

Anyway this isn't as good as a working example but maybe it'll get things moving along a bit.

Hi Anthony,

you were right when you said that I was working in the polling mode. I solved a HW problem with my transceiver and now in fact everything works correctly in the polling mode.

But the problem now is that I want to setup the interrupt on RX.

I have mapped vimRAM->ISR[13] to the sci2HighLevelInterrupt function (is this the right interrupt channel for SCI2?) and I have enabled vimREG->REQMASKSET0 bit 13. Then I have set bit 9 in the sciREG2->SETINT register (RX interrupt).

When I send a byte to the microcontroller from PC, I can see with oscilloscope that the datum arrives on the RX pin. Also, RXRDY flag is correctly set in the FLR register. But I don't know why the function sci2HighLevelInterrupt is never entered.

What am I missing to enable/map this interrupt? At the moment I am not using the HalCoGen, but if you suggest to use it, I can try. in this case, can I link HalCoGen to my existing project?

Thanks,

Regards,

Elena.