• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1898 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Enabling RTS/CTS on UART2 has no effect.

Snehal Parmar
Intellectual 485 points

Hi,

 

I need to have RTS/CTS enabled on UART2 of DM6446 based custom board.

I already had UART2 send/receive working ok.

 

Did following in kernel to enable flow control :

1. Enabled "U2FLO" bit in pinmux1 to enable flow control.

2. In MCR for register for UART2 enabled bits 1 and 5(UART2_MCR |= 0x22;). Did this in 8250.c autoconfig().

3. In serial_platform_data[] for serial devices added flag UPF_CONS_FLOW for UART2.

 

After enabling UART2 flow control through above steps. I made CTS line of UART2 as high through external pull-up register.

And then tried to send data though UART2. Since CTS line is high I was hoping that send data will be blocked.

But DaVinci just sends data despite of CTS line being high.

 

In the uart test application I open uart device with "O_RDWR"  flag(iUartDevFd =  open(UART2_DEV, O_RDWR);).

 

I see the same issue on Dm6446 EVM board as well.

 

Has any one got RTS/CTS to work ok with UART2 on DaVinci ?

Appreciate any help on this.

 

Thanks,

Snehal

 

  • 0
    TI__Intellectual 1265 points

    Snehal,

    Are you sure that nothing else later is overwriting your MCR register settings?

    Can you check while sending the data that the AFE/RTS bits are still set in the register?  This goes for PINMUX setting as well.

    One other quick check would be to add some diagnostic to serial_outp to see all writes to the UART(2) MCR register.  It looks like some other configuration of the MCR register can happen in 8250.c???

    -Ian

     

  • 0 in reply to IanB
    Intellectual 485 points

    Thanks for the reply Ian.

     

    Actually on our custom board we have another device connected to UART2. So I can do a loop-back test.

    I tried UART test application in CCS where I could check if the registers are getting changed runtime while uart operations are being performed. AFE/RTS bits are still set in the register MCR.

    I still see the same issue with CCS test application also.

     

    Is is possible to some how read CTS status through UART controller ?  Or it remains internal to the controller ?

     

    Thanks,

    Snehal

  • 0 in reply to Snehal Parmar
    TI__Intellectual 1265 points

    Snehal,

    I tried your CCS test application (sent via off line email), and a different one that also turns on CTS flow control, on the dm6446 evm.

    Both are working as expected in a rudimentary environment:

        With CTS pulled up, transmission will not occur.

        When CTS is grounded, the test will continue and ultimately pass.

    This seems to confirm the autoflow device function on uart 2.  Is this a different result than you are getting?

    -Ian

  • 0 in reply to IanB
    Intellectual 485 points

    Hi Ian,

     

    Yes the results seem look different than what I see.

    For me data transmission does not stop despite of CTS being high. I will retest.

     

    Did you short Rx/Tx lines on EVM for testing ?

    Do you see same behaviour after booting up the kernel ?

     

    Thanks,

    Snehal

  • 0 in reply to IanB
    Intellectual 485 points

    Hi Ian,

     

    Yes the results look different than what I see.

    For me data transmission does not stop despite of CTS being high. I will retest.

     

    Did you short Rx/Tx lines on EVM for testing ?

    Do you see same behaviour after booting up the kernel ?

     

    Thanks,

    Snehal

  • 0 in reply to Snehal Parmar
    TI__Intellectual 1265 points

    Snehal,

    Yes, Rx/Tx were shorted on the evm.

    CTS is pulled high with a 1k resistor for my test case.  There is an internal pull down on this pin.  What are you using for a pull-up?  Perhaps it is not strong enough?

    I have only tried the CCS test so far.

    -Ian

  • 0 in reply to IanB
    Intellectual 485 points

    Hi Ian,

     

    I tried with different pull registers on the custom board such that the voltage level is closer to 1.8V.

    I tested CCS test application again after this. Now I can see that if CTS is high then the data is not being transmitted.

    Application keeps looping for "THRE" bit to get set to 1.

    If I pull the line to low then data gets transferred.

     

    Is this expected behaviour ?

    Is is required to poll for "THRE" bit after enabling CTS/RTS ?

     

    I tried to do similar kind of implementation in 8250.c in the function "wait_for_xmitr()". But that did not work.

     

    Thanks,

    Snehal

     

  • 0 in reply to Snehal Parmar
    TI__Intellectual 1265 points

    Snehal,

    Yes, this is the expected behavior for your CCS app.

    Something like polling for THRE is required in a polling based system/application.  This is just software waiting for one transmit to occur before writing another one.  However, you might use this regardless of autoflow mode vs. non-autoflow mode.

    The CTS function is something built into hardware.  It will block a transmission until the CTS line is active low.  Your application should be blocked waiting on the 'second' consecutive transmission if the CTS line is held high.

    Again, in a Linux environment, I would recommend double checking the pin voltage level (i.e. pull-up value), and MCR and PINMUX1 register settings at application run-time if you are seeing unexpected behavior.  This is a hardware function, so the transmit block should behave the same as the CCS app as long as the register settings are the same.

    -Ian

     

     

     

  • 0 in reply to IanB
    Intellectual 485 points

    Hi Ian,

     

    In Linux environment I found that MCR is getting overwritten ever now and then. This is causing the issue.

    I added a patch such that every time data needs to be sent , AFE and RTS bits get set in MCR. After this change the linux application does halt on receive when CTS is pulled up and reads data when CTS is pulled low.

    Will check why MCR gets cleared and add better fix.

     

    Thanks for you help Ian.

     

    Regards,

    Snehal