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, ifany, 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
Hi Martin,
I am looking in to this issue and should have an answer by the end of the day.
Joe
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.
Hi Joe,
thank you for your response.
I configured the device as described by the datasheet:
1. Program auto-reset mode: MR2A[5] = 12. Enable transmitter3. Assert RTSAN: OPR[0] = 14. Send message5. Disable transmitter after the last character is loaded into the channel A Tx FIFO6. The last character will be transmitted and OPR[0] will be reset one bit time after the last stop bit, causingRTSAN 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?
Martin
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?
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]
1. Program auto-reset mode: MR2A[5] = 12. Enable transmitter3. Assert RTSAN: OPR[0] = 14. Send message5. Disable transmitter after the last character is loaded into the channel A Tx FIFO6. 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
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.
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]
I wrote 0 to MR1A[7] and set MR2A[7:6] to normal mode.
do you have any news regarding the timing problem?
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?
MR1A[7] is always set to zero. OP0 is only controlled by the transmitter.
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?
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.
Hello Joe,
do you have any news regarding this problem? We still need a solution for this bug.
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 DuplexAuto-Reset Mode (MR2A[5] = 1)No RTS control (manually asserting TRSAN