• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 1321 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.

Original question:

TL16C752D: /CDA,/CDB interrupt

Compiler/TL16C752D: TL16C752D linux driver do not work

Yafei Wang
Intellectual 280 points
Part Number: TL16C752D

Tool/software: TI C/C++ Compiler

Hello team,

I am using the TL16C752D on linux platform , and linux version is : 4.9.69 

when I bootup , the log shows :

[ 5.520485] Serial: 8250/16550 driver, 16 ports, IRQ sharing disabled
[ 5.545997] serial8250.0: ttyS0 at MMIO 0x2000000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.567223] serial8250.0: ttyS1 at MMIO 0x2000200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.588253] serial8250.0: ttyS2 at MMIO 0x2001000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.609272] serial8250.0: ttyS3 at MMIO 0x2001200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.630233] serial8250.0: ttyS4 at MMIO 0x2008000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.651215] serial8250.0: ttyS5 at MMIO 0x2008200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.672172] serial8250.0: ttyS6 at MMIO 0x2009000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.693139] serial8250.0: ttyS7 at MMIO 0x2009200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.714107] serial8250.0: ttyS8 at MMIO 0x2010000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.735072] serial8250.0: ttyS9 at MMIO 0x2010200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.756019] serial8250.0: ttyS10 at MMIO 0x2011000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.776980] serial8250.0: ttyS11 at MMIO 0x2011200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.798003] serial8250.0: ttyS12 at MMIO 0x2018000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.818956] serial8250.0: ttyS13 at MMIO 0x2018200 (irq = 29, base_baud = 921600) is a ST16654
[ 5.839918] serial8250.0: ttyS14 at MMIO 0x2019000 (irq = 29, base_baud = 921600) is a ST16654
[ 5.860868] serial8250.0: ttyS15 at MMIO 0x2019200 (irq = 29, base_baud = 921600) is a ST16654

I find the driver match the wrong chip : ST16654 , and  it does not work,

and  I can not find the type TL16C752D  at   linux-4.9.69\include\uapi\linux\serial_core.h 

How can I add the support of  TL16C752D   to work ?

  • 0
    TI__Guru 53575 points

    Hi Yafei,

    Unfortunately, we don't offer sample code or develop drivers for most of our UART devices. This forum is primarily for supporting the transceiver physical layer. For this device, I believe standard 16550 Linux drivers should work. I would recommend searching for compatible drivers for similar (pin-to-pin) devices.

    Let me know if I can help in another way.

    Regards,

    Eric

  • 0 in reply to Eric Schott1
    Intellectual 280 points

    Hi  Eric , 

    Thanks for your replication, I have successfully added the support for TL16C752D,

    And I tested with RS232 mode, It works well, But when I change to RS485 mode , I can only send messages( receive side can receive successfully),

    but can not receive anything , is any other setting up about TL16C752D for RS485 mode ?

    Best Resards,

    Yafei

  • 0 in reply to Yafei Wang
    TI__Guru 53575 points

    Hi Yafei,

    Have you set Alternate Function Register (AFR) bit 4 for Receiver Enable (RCVEN)? Setting this bit allows the serial receiver to listen in on RS-485 traffic. You can test this by also enabling 485EN (AFR bit 2) and writing a message on RS-485. With both bits set, the receiver will store any data presented on RX.

    Regards,
    Eric

  • 0 in reply to Eric Schott1
    Intellectual 280 points

    Hi  Eric , 

    I use as RS485 mode,

    1、enable  (AFR) bit 4 , AFR bit 2.

    2、Set TCR 

    3、enable Auto-RTS flow control : EFR[6]

    When I open the UART device , I read the register as followimng value:

    IIR == 01
    LCR == 03
    MCR == 08
    LSR == 60
    MSR == 00
    SPR == 00
    AFR == 14
    EFR == 51
    TCR == 4d
    TLR == c0

    I use the RTS to control RS485 TX/RX direction, but I find that RTS always low. So I can only send messages, can not receive. Here is the connection between TL16C752D and RS485 Transceiver.

    Can you help me to find why?

    Regards,

    Yafei

  • 0 in reply to Yafei Wang
    TI__Guru 53575 points

    Hi Yafei,

    Thanks for sharing the register values. It helps a lot with the debugging.

    When you say "RTS always low" do you mean it is inactive and the DE/RE# line for RS-485 is logic HIGH? Knowing which level the pin seems stuck at will help diagnose what state Auto-RTS is in.

    If you would like to manually control this pin, you can disable Auto-RTS (EFR[6]=0) and toggle RTS# directly using MCR[1] (0=inactive HIGH, 1=active LOW). This could help debug the setup to ensure you can send and receive data before using the Auto-RTS feature.

    Regards,

    Eric

  • 0 in reply to Eric Schott1
    Intellectual 280 points

    Hi  Eric 

        Here is my schematic ,  the RTS is always low(from TL16C742D) , according to my schematic , the RS485 transceiver will enable TX , so I can not receive data from another side.

    （1）When I disable Auto-RTS , and set MCR[1]=0 , now I can only receive data, but can not send data.

    （2）When I disable Auto-RTS , and set MCR[1]=0, now I can only send data, but can not receive data.

    （3）When I enable Auto-RTS,  the RTS from TL16C752D  is always low  after  opening the uart port when I send or receive data

    I want to know why the RTS can not work normally?

    another question : If I change RTS to DTR , to  control the direction of RS485 TX/RX, as following:

    I can successfully control the direction of RX/TX.  Do you office recommend this way ?

    Regards,

    Yafei 

  • 0 in reply to Yafei Wang
    TI__Guru 53575 points

    Hi Yafei,

    Unfortunately, the first image you posted is not appearing. Please try reposting it if you have questions or concerns regarding the schematic. 

    It is good to hear that the system is able to both transmit and receive data. Using RTS as the direction control would serve as a more manual way to select which mode the RS-485 transceiver would be in. It is good that this method proved useful for testing the hardware of the system. However, because this is not the intended use of the pin and it is being used as a GPO, the internal FIFO-based flow control does not operate as it would during typical UART transactions.

    Changing to use DTR as the EN input for the RS-485 would streamline this operation. In RS-485 alternate mode (AFR[2]) the DTR pin is intended to be used as the RS-485 driver EN input. This will cause the pin to be set HIGH when there is data available in THR or TSR so it can be transmitted over RS-485. Once the delay set by DLY[2:0] expires, the pin will go LOW allowing the half-duplex RS-485 driver to act in receiver mode to receive messages from the bus.

    Regards,

    Eric