• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 33 subscribers
  • Views 2088 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.

TL28L92 timing problem

Martin Fletzer
Prodigy 150 points
Other Parts Discussed in Thread: TL28L92

Hi,

we use the TL28L92 as a replacement for the SC28L92. The output OP0 of the TL28L92 is used to control the direction of an RS-485 transceiver through the transmitter RTS signal.

But the timing is wrong and the stop bit will not be transmitted. The datasheet states the following: "This output is normally asserted by setting OPR[0] and negated by resetting OPR[0]. MR2A[5] = 1 caused OPR[0] to be reset automatically one bit time after the characters in the channel A transmit shift register and in the Tx FIFO, if
any, are completely transmitted including the programmed number of stop bits"

I have attached an image, showing the Tx signal (cyan) and the RTS signal (yellow).

Do you think it is a bug of the device, or could it be fixed by software?

Best Regards,

Martin Fletzer

  • 0
    TI__Expert 5230 points

    Hi Martin,

    I am looking in to this issue and should have an answer by the end of the day.

    Best Regards,

    Joe

  • 0 in reply to Joe Fockler
    TI__Expert 5230 points

    Hi Martin,

    The RTS should work as documented. I have asked the design team to look at the code and see if there is a problem in the state machine.

    Best Regards,

    Joe

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hi Joe,

    thank you for your response.

    I configured the device as described by the datasheet:

    1. Program auto-reset mode: MR2A[5] = 1
    2. Enable transmitter
    3. Assert RTSAN: OPR[0] = 1
    4. Send message
    5. Disable transmitter after the last character is loaded into the channel A Tx FIFO
    6. The last character will be transmitted and OPR[0] will be reset one bit time after the last stop bit, causing
    RTSAN to be negated

    I'm not sure what I did wrong, because the RTS pin is switching but with wrong timing. Maybe you can provide some code for using the auto-reset mode?

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    Prodigy 150 points

    Hi Joe

    I'm now switching the RTS pin manually. I use the TxEMTA bit in the status register SRA[3] to detect the end of transmission.

    But I have the same problem as with the auto-reset mode. The TxEMTA bit is set before the stop bit has been sent. Probably the hardware state machine depends on this bit and we have narrowed down the problem a litte?

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    TI__Expert 5230 points

    Hi Martin,

    I have not received any updates from the design team yet. In the message you posted on Friday it looks like the RTSAN is de-asserting correctly one bit time after the STOP bit. Is this correct? (part of your message is reposted below for convenience). We do not have any sample code for this device. I will follow up with the design team to see if they have had a chance to run a simulation.

    [Your text repeated below]

    I configured the device as described by the datasheet:

    1. Program auto-reset mode: MR2A[5] = 1
    2. Enable transmitter
    3. Assert RTSAN: OPR[0] = 1
    4. Send message
    5. Disable transmitter after the last character is loaded into the channel A Tx FIFO
    6. The last character will be transmitted and OPR[0] will be reset one bit time after the last stop bit, causing RTSAN to be negated

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hi Joe,

    no, the RTSAN is not de-asserting correctly. I copied the text for the 6 enumerations from the datasheet.

    I still have the same problem. Regardless of whether I use the auto-reset mode or switch the RTS pin manually.

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    TI__Expert 5230 points

    Hi Martin,

    what value are you writing to the MRA1 register? Is MRA1[7] = 1 or 0?

    Are you running in loop-back mode?

    The design team looked at the RTL code and stated that if MRA1[7] = 0 this will block the RX FIFO full indication from interrupting OPR[0]

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hi Joe,

    I wrote 0 to MR1A[7] and set MR2A[7:6] to normal mode.

  • 0 in reply to Martin Fletzer
    Prodigy 150 points

    Hi Joe,

    do you have any news regarding the timing problem?

  • 0 in reply to Martin Fletzer
    TI__Expert 5230 points

    Hello Martin,

    I have sent a follow up to our design team. Based on the configuration information you provided the device should work as documented and you should see RTS negated after the stop bit transmits. I have asked them to check the timing requirements. You are looking only at the Transmit side and not the Receive side, correct?

    Best Regards,

    Joe

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hi Joe,

    MR1A[7] is always set to zero. OP0 is only controlled by the transmitter.

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    Prodigy 150 points

    Hi Joe,

    the problem is still relevant to us. We use a workaround, implemented with busy wait.

    Because of performance requirements we have to remove this workaround. Do you have already a solution for this problem?

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    TI__Expert 5230 points

    Hello Martin,

    I have contacted the design team again to see if they have run a simulation. Some design resources were reassigned and I don't know if this task was completed. i do not have a bench set up to check this myself. I hope to have a response by tomorrow since the design team is not located here in Dallas.

    Best Regards,

    Joe

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hello Joe,

    do you have any news regarding this problem? We still need a solution for this bug.

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    TI__Expert 5230 points

    Martin,

    The UART product line has moved to another group and I have am contacting the new design team to have them run the simulations. The design team from my group was reassigned to other products so I lost the resources who were looking at the RTL code. Based on the information you provided the device should function as described in the datasheet. I am assuming this is a bug in the design but I need someone from the design team to run the simulations. We do not have a bench test setup for this device.

    Can you provide the register configuration for both UART channels in your setup? From your messages I know that you are using:

    Normal mode - Full Duplex
    Auto-Reset Mode (MR2A[5] = 1)
    No RTS control (manually asserting TRSAN

    Best Regards,

    Joe

  • 0 in reply to Joe Fockler
    Prodigy 150 points

    Hi Joe,

    I have reduced the configuration sequence to a minimum. After a power on reset I do the following initialization:

    Set CRA to 0xb0

    Set MR0A to 0x00

    Set MR1A to 0x13

    Set MR2A to 0x2f

    Set ACR to 0x80

    Set CSRA to 0xcc

    Set CRB to 0xb0

    Set MR0B to 0x00

    Set MR1B to 0x13

    Set MR2B to 0x2f

    Set ACR to 0x80

    Set CSRB to 0xcc

    The I do the following sequence to transmit one byte on channel A:

    Set CRA to 0x04

    Set SOPR to 0x01

    Write one byte to TxFIFOA

    Set CRA to 0x08

    And for completeness the sequence for using channel B:

    Set CRB to 0x04

    Set SOPR to 0x02

    Write one byte to TxFIFOB

    Set CRB to 0x08

    Always the same problem. OP[0] for channel A or OP[1] for channel B will be reseted after the last character bit. But the reset should be delayed for one bit time after the stop bit. I have configured 2 stop bits. So the reset of OP[0/1] comes 3 bit times to early.

    Hopefully we soon find a solution for this problem.

    Best Regards,

    Martin

  • 0 in reply to Martin Fletzer
    Prodigy 150 points

    Hi Joe,

    I don't know if TI is active working on this problem.

    Maybe you can provide den HDL design and testbench under NDA? Then we could try to reproduce the error with a modified testbench and help you top fix the hardware bug.

    Please help us to solve this problem.

    Best Regards,

    Martin