Receive Issue

Hi,

During receive when I print LSR register it shows a value of 0xE1 some times and 0xE9 some times.

When we send 63 Bytes using a Send Text File option from Hyper Terminal first 28/29 bytes looks fine after that we see corrupted data. The data that we are sending is 1ABCDEFGHIJKLMNOPQRSTUVWXYZ2ABCDEFGHIJKLMNOPQRSTUVWXYZ3ABCDEFGH.

LSR - 0xE9 means a framing error and a proper stop bit is not detected. What could be the reason for this?

We consistently see this problem when we tranmit data using Send Text File option from Hyper Terminal and for the following baud rates (9600, 19200, 38400 and 57600).

Configuration is 8-Data Bits, No Parity and One Stop Bit. Where as when we operate at 115200 baud rate this problem was not observed.

Please help us in understanding the issue.

Regards,

GSR

Hi,

Looks the issue which we are seeing is similar to the one which is already discussed in the following thread (http://e2e.ti.com/support/interface/industrial_interface/f/142/p/109013/385322.aspx#385322).

Why the stop bit can be 98uS (Short STOP) only. How much Short Length Stop bit can a device send when we set baud rate to 9600?

We are also using 1.8432MHz crystal. By decreasing the divider value to 11 for 9600 baud rate, I have observed that the TL16C754C has failed in receiving and all the data that I see is corrupted.

As suggested in the errata we have decreased divider value by 1. Then for 1200, 2400 and 4800 baud rates the 16C754C able to write on Hyper Terminal. For 9600, 19200, 38400, 57600 and 115200 it fails or no data has been seen on Hyper Terminal.

But when I used 2-Stop Bits the problem got solved. Looks we see some baud rate error even when we use higher crystals of value 14MHz.

Is this problem observed only on some of the chips or all TL16C754C chips has this issue.

Also can some one suggest if we can use 16MHz crystal if the device is operating at 1.8V

Is there any equivalent part in TI with out these issues.

Regards,

GSR

Hi All,

Any help or suggstions please...

Is it clear what issue am I seeing?

Is it okay to use 16MHz Clock instead of a 14.74M value which is suggested in errata of TL16C754C data sheet.

Thanks and Have a Nice Weekend.

Regards,

GSR

GSR,

The errata exists with the TL16C752C, TL16C2752, and the TL16C754C devices.

What are the baud rates are you using?

What Vcc voltage are supplying?

If you can select a crystal that provides an exact baud rate (integer divisor) that should provide the best possibility of avoiding the errata. In the table below the divisor required to generate the given baud rate is an integer (e.g., 115200 is achieved with a divisor of 8.00 - no decimal). There is also a dependency on matching the exact baud rate of the other device you are communicating with.

Best Regards,

Joe

The question:

"Why the stop bit can be 98uS (Short STOP) only. How much Short Length Stop bit can a device send when we set baud rate to 9600?"

Originally after receiving the programmed number of data bits (e.g., 8-bits in an 8N1 configuration) the TL16C754B device immediately started looking for the next high-to-low transition indicating a start bit. However, the logic changed to wait some number of clocks before starting to look for the next start bit. In cases where the stop bit is actually shorter than one bit width the TL16C754C logic can miss the start bit.

Hi Joe Fockler,

Thank You for the reply and for the errata.

The chip is operating at 1.8V right not the clock we are supplying is 16MHz.

I am attaching the excel sheet which contains the results when the clocks are 1.8432Mhz and 16MHz.

Can we supply 16MHz clock when the chip is operating with 1.8V?

Regards,

GSR1447.EUART.xls

Hi Joe Fockler,

Thank You for the reply and for the errata.

The chip is operating at 1.8V right not the clock we are supplying is 16MHz.

I am attaching the excel sheet which contains the results when the clocks are 1.8432Mhz and 16MHz.

Can we supply 16MHz clock when the chip is operating with 1.8V?

Regards,

GSR1447.EUART.xls

Hi GSR,

Yes, 16 MHz is the maximum input clock frequency at 1.8V.  I am surprised you are seeing receive (read) errors at 1200 baud.

Can you send a scope capture of the RX line with the bits from the failing character? At 1200 baud a bit period is 833 us.

Can you try a 14.7456 MHz input clock?

Joe Fockler,

I am not sure whether I would be able to capture for failing cases or not.

We see failing when we send a text file from the Hyper Teminal Application (Windows XP Host PC). When we send say for example 1KB in that the erroe occurs here and there. I will try to capture it if it possible.

What I do not understand is the errata says we have to use divisor-1 value to avoid the Receive Problem. But for 16MHz clock when we use divisor value we haven't seen any receive errors.

We don't have a 14.7456 crystal as of now. May be we will get it next week. I will share the results with you after testing with that clock.

Regards,

GSR

Hi Joe,

I am attaching the scope capture while sending a 38-Byte data from HyperTerminal using Send Test File Option.

I am also attaching the text file that is being used to send data from Hyper Terminal and the name of text file is 32Bytes.txt

The last character that is in text file is 'J', however I see a hex value of 0xA5.

1abcdefghijklmnopqrstuvwxyz2ABCDEFGHIJ

The RS-232 pin is probed for two times. So, I have attached two JPEGS 

Please note that these captures are probed at RS-232 Level.

Regards,

GSR

Hello All,

Any suggestions or inputs?

Regards,
GSR

Hi Joe,

As per your suggestion we have replaced 16MHz crystal with 14.7456MHz crystal.

Below table shows the results.

For all the baudrates we have conencted the Target with a Host PC. Can you suggest any thing to have 1200 to 115200 baudrate working?

Thank You & Regards,

GSR

Hi GSR,

What is the failure mode of the read data? Framing error?

Can you provide a scope capture of the failing data on the RX line?

We do not have a final schedule yet but we are respinning the TL16C754C device to fix the errata.

Best Regards,

Joe

Hi Joe,

Thank You for your reply and Time.

When we read LSR it shows 0xE9, 0xEB and rarely 0x6B. So, based on these values RX FIFO has a Framing Error or Parity Error and Framing Error.

Do you wish to have a look at RS-232 level or TTL level of RX Line?

Regards,

GSR

Hello GSR,

Last time I looked at this thread I did not see the scope captures you posted. I apologize. If you are getting the framing error it indicates the stop bit errata. We have been working on the resources to fix this errata and I am waiting on the schedule.

In the meantime, if the 16MHz oscillator is working for transmit and receive it would be best to stick with that value. The errata contains potential workarounds and suggests trying the divisor - 1 to see if that resolves the stop bit framing error problem. As you have seen, this does not work for every case. I will let you know as soon as I have a schedule for the release of the new device.

Best Regards,

Joe