TL16C750E: Receive data exception

Darren Chang said:

2. There is an abnormality in receiving data. The main problem is that it may be messed after receiving 0xFF.

• For example, after receiving 01 02 03 FF 04 05, only 01 02 03 FF 05 is left when reading it out, and the 04 after FF will disappear.
• If the received data ends in FF, even stranger phenomena may occur.

Are you testing this device by connecting the 750E's TX and RX pins to another uart device? 

Does the same error occur if you do a loopback test by shorting 750E's TX to its RX pins? 

Darren Chang said:

For example, after disabling the FIFO (the default value of FIFO is disable after power-on), send a FF to it, and the FF can be read. After that, no other data will be sent, and then it will be judged whether there is data. LSR will always get the flag with data, and then when reading data, it will keep sending the data in the FIFO repeatedly in a loop.

You're saying that the RX will only show 0xFF when you perform reads to RHR? Or are you saying that the device connected to 750E on the parallel side will always keep trying to send data through THR?

Darren Chang said:

Inaddition, it can be found in the EVM board manual that all data buses will have a 33 ohm resistor in series. Is this for current limiting or EMI suppression? Is this a must?

The 33 ohm resistors are there to limit some current in the case of a short, but they are mainly there if we needed to do debugging. They are not required, for an EVM having series resistors that can be depopulated is useful. 

-Bobby

Hi Bobby,

BOBBY said:

Are you testing this device by connecting the 750E's TX and RX pins to another uart device? 

Does the same error occur if you do a loopback test by shorting 750E's TX to its RX pins? 

Customer have tested loop mode and external RX connected to TX, and the results are the same.

BOBBY said:

You're saying that the RX will only show 0xFF when you perform reads to RHR? Or are you saying that the device connected to 750E on the parallel side will always keep trying to send data through THR?

The main problem is that it get messed after receiving 0xFF.

What is strange now is that the same testing method will not cause problems on platform 1, but will on platform 2. (Both are 80186 architecture)

After power on, it can only be set to 115200,8,N,1

outp(ComBase+Lcr,0x83);
outpw(ComBase,8);
outp(ComBase+Lcr,0x03);

Use outp(ComBase+Fcr,1); to enable FIFO, or outp(ComBase+Fcr,0); to disable FIFO.
To send data, use outp(ComBase,data);

Read data use
if(inp(ComBase+Lsr) & 1){
data=inp(ComBase);
}
No other registers are read or written.

Thank you.

Darren

Hi Darren,

Do you have the customer schematic you can post?

Darren Chang said:

What is strange now is that the same testing method will not cause problems on platform 1, but will on platform 2. (Both are 80186 architecture)

Is there any difference between platform1 and platform2?

Darren Chang said:

After power on, it can only be set to 115200,8,N,1

outp(ComBase+Lcr,0x83);
outpw(ComBase,8);
outp(ComBase+Lcr,0x03);

Use outp(ComBase+Fcr,1); to enable FIFO, or outp(ComBase+Fcr,0); to disable FIFO.
To send data, use outp(ComBase,data);

Read data use
if(inp(ComBase+Lsr) & 1){
data=inp(ComBase);
}

I'm not sure I 100% follow this section of code.

Is it possible for the customer to walk through each write after power up?

Example

Step 1: write to FCR 0x06

Step 2: Write to LCR 0x80

Step 3: write to DLL 0x4F

Step 4: ect.....

Darren Chang said:

The main problem is that it get messed after receiving 0xFF.

I wrote code for this device when it was released about 4 years ago, I never saw any issue related to receiving data 0xFF. The only time I ever saw an issue was when I accidently set the device to use the wrong mode (pin 10).

-Bobby

Hi Bobby,

Could you share the email to me?

I'll mail the Sch to you.

Thank you.

Darren

Hi Darren,

You can reach me at duynguyen@ti.com.

Thanks,

-Bobby