[SOLVED] [moved] RS422 communication failure at elevated temperature

[jeevaaraam]

Re: RS422 communication failure at elevated temperature

The circuit (Single line diagram is attached)

The transceiver IC: AM26LS32AMDREP

The UART: XR16C864IQ

Both are operated at +5V DC.

- - - Updated - - -



The circuit (Single line diagram is attached)

The transceiver IC: AM26LS32AMDREP

The UART: XR16C864IQ

Both are operated at +5V DC.

 

[betwixt]

Re: RS422 communication failure at elevated temperature

:-|

Please show the SCHEMATIC, I think we had already guessed the two ends were connected together.

Brian.

 

[jeevaaraam]

Re: RS422 communication failure at elevated temperature



The Schematics are attached.

There are 3 more UART with same scheme are available in the processor board and all 4 UART sharing the 'ADDRESS LINES' and 'DATA LINES'.

In all four UARTs (Quad channel), only the channels B and C are failed (Channel A & D are always passed).

- - - Updated - - -

Further to analysis,

1) If I'm ignoring the status of LSR and reading the FIFO (Although it is not the proper method to read FIFO, for debugging I have done it), I got the expected data.

For example:
Tx data AA01 0E55. Rx is as follows,

LSR Status Read Data
~~~~~~~~~~ ~~~~~~~~~
61 (Data available) AA
61 (Data available) 01
61 (Data available) 0E
60 (Data not available) 55 (But physically data is available in the FIFO)

Then, there is malfunction happened between FIFO to RHR(Receive Holding Register), after sending the mentioned patterns (x2 / x6 / xA / xE).

2) The failure is occurred for the following condition,
1. If the processor board is in Higher temperature (> ~48 Deg C).
2. Only with one particular communication board, irrespective of this board temperature.

 

[jeevaaraam]

Re: RS422 communication failure at elevated temperature




The RS232 interface (available in Communication board) is attached.

As mentioned earlier, Four UART's Channel B and C are failed (Totally 8 Rx channels, 6 Nos of RS422_Rx and 2 Nos of RS232_Rx)

 

[betwixt]

Re: RS422 communication failure at elevated temperature

Electrically it looks OK. From your description I would say the fault lies in the UART. It looks like at high temperature it's status register fails. There is no external electrical access to the status register and it seems the data is arriving correctly so that eliminates the RS422 side of things. The only other possibility is the status register isn't being read properly but that points the finger even further away from where you have localized the fault.

Brian.

 

[jeevaaraam]

Re: RS422 communication failure at elevated temperature

To localize the issue, I have tested the circuit with UART self loop back mode (Tx and Rx has been looped back internally to the chip, the chip has this provision) and the same observation found (Rx is not received for Tx data mentioned patterns <x2 / x6 / xA / xE> ). From this, It is clear that the issue is in output side of UART IC.


There is a PCN (Product Change Notice, EXAR PCN Number: 13-0501-02) from the UART IC manufacturer says that change in TRDA (TIME - Read Data Access) from 15ns to 50ns (For 5V VCC).

My program timing were finalized with TRDA = 15ns timing based on the earlier data. The existing CPU wait State is 4 for the UART communication.

If I the changed the WAIT STATE = 5, the failure is random (~90% passed, ~10% failed).

If I the changed the WAIT STATE = 6, all were passed always.


Shall I know the reason, Why It was passed with 6 WAIT STATE?

If 128 byte of data is passed (without data patterns <x2/ x6 / xA / xE>) With existing wait state=4, what is the relation with WAIT STATE and data patterns?

 

[betwixt]

Wait states are generated by peripherals to 'hold' the CPU while they have time to complete internal operations. It is a mechanism to make sure data isn't missed if read or written too quickly. The CPU typically executes 'no operation' instructions to kill time until the wait signal is removed.

However, the 16C864 does not have any 'wait' signal output so I'm not sure where the wait states you refer to are comng from. It would seem the solution to your problem is to fix the software or FPGA design so there is a delay before reading the UART. I would guess that by changing "WAIT STATE" to a higher values (by whatever means) is slowing UART access down enough that it becomes reliable.

Brian.

 

[FvM]

I guess, if you already have a FPGA, you'll get away better by implementing the UART function there.

I see that the recent XR16C864IQ data sheet already specifies 50 ns TRDA, sounds moderate for µP peripherals.

 

[jeevaaraam]

I guess, if you already have a FPGA, you'll get away better by implementing the UART function there.

FPGA logic blocks had been used for other circuit implementations. Also the current UART requirement is 16 Channels.

I see that the recent XR16C864IQ data sheet already specifies 50 ns TRDA, sounds moderate for µP peripherals.

The prototype board design was freezed with old UART chip (with 15 ns).

 

[betwixt]

I doubt the chip design has been slowed down, it is more ikely to be the same silicon but re-specified with longer access time because of the very problems you are noticing.

Brian.

 

[jeevaaraam]

The issue was solved.

I had re-soldered the connector of 'Communication board' (300 pin high dense connector) and the mentioned issue was not appeared. The system undergone full ESS - Thermal cycling (10 cycles) and passed.

Although it was solved, the exact ROOT CAUSE(localized), which creates the issue was not identified. The issue was solved and I don't have time to analyze the ROOT CAUSE.

I have learnt that 'Even with the small soldering issue leads to patterned/structured error in the digital communication'.