Arbitration section (SRC_ADDR 0x55) Differential output anomaly?

[HunterLiu0517]

As shown in the figure above, the 485 transceiver TX input is normal (TTL level), but the differential output is abnormal (arbitration segment 0x55), and the other segments are normal.

[HunterLiu0517]

Pink is the differential output signal. And register "SETTING=0x11", CDBUS-A mode (default).

[dukelec]

I suggest capturing TX, OE (TX_EN), and A signals simultaneously to check if TX_EN lags too much behind TX, as this may relate to FPGA timing constraints.

Also, which interface chip are you using? Some chips may have a significant difference between driver propagation delay and driver disable/enable time (receiver enabled).

[dukelec]

The next* branch adds a configuration: setting bit7 of the SETTING register avoids this issue and lowers interface chip requirements by keeping TX low during arbitration.

[HunterLiu0517]

I suggest capturing TX, OE (TX_EN), and A signals simultaneously to check if TX_EN lags too much behind TX, as this may relate to FPGA timing constraints.

Also, which interface chip are you using? Some chips may have a significant difference between driver propagation delay and driver disable/enable time (receiver enabled).

During transmitting arbitration section (SRC_ADDR), TX_EN is disabled when TX=1. And if TX_EN disabled, output signals (A or B) is "Z", no matter what level TX is（as follow figure）. I think that's where the problem comes in.

[dukelec]

When TX_EN is off, it is normal for AB outputs to be in a "Z" state. At this time, the bus pull-up and pull-down resistors pull AB to a weak 1 state.

It is recommended to use 330Ω pull-up and pull-down resistors, which will improve the waveform significantly. The 120Ω termination resistor is optional.

If the interface chip takes too long to disable AB outputs after TX_EN goes low, it may generate a strong 1 glitch. Small glitches don’t affect communication, but the one you observed is too wide.

[HunterLiu0517]

The next* branch adds a configuration: setting bit7 of the SETTING register avoids this issue and lowers interface chip requirements by keeping TX low during arbitration.

Hi dukelec, i want to know when you'ii release the new branch. And will this change affect the arbitration mechanism, When TX conflicts?
And the transceiver interface chip type we are using is SN65176BDR.

[dukelec]

The commit was submitted just last night.
It only eliminates the strong 1 glitch and will not affect the arbitration mechanism.

The tPHZ (Output disable time from high level) of the chip you're using is relatively large.
The latest commit is suitable for the chip you selected.
For reference, you can compare the parameters with those of the SN65HVD75 and THVD1450DR.

[HunterLiu0517]

When TX_EN is off, it is normal for AB outputs to be in a "Z" state. At this time, the bus pull-up and pull-down resistors pull AB to a weak 1 state.

It is recommended to use 330Ω pull-up and pull-down resistors, which will improve the waveform significantly. The 120Ω termination resistor is optional.

If the interface chip takes too long to disable AB outputs after TX_EN goes low, it may generate a strong 1 glitch. Small glitches don’t affect communication, but the one you observed is too wide.

Based on your suggestion, I have optimized the RC parameters of the circuit, and now the waveforms of TX, TX_EN and signal A are shown in the figure above. Now the waveform has been improved significantly, and most of the glitches have been eliminated.
However, in the arbitration stage, the differential signal output is high resistance, and the difference between A-B is small. If the signal in this stage is subjected to external interference, is it possible that the AB output will change from weak 1 state to weak 0 state, resulting in communication failure?
I'd like to know your opinions and suggestions. Thanks!

[dukelec]

What RC parameter modifications have you made?

I noticed that you haven't enabled the latest feature I submitted. Simply adjusting the pull-up and pull-down resistors will not eliminate the strong "1" glitch.

It is possible that the TX_EN and TX signals from the FPGA are not synchronized, which could be causing this issue. This desynchronization can vary with each synthesis, especially in the absence of SDC constraints.

5V ÷ (330+330+120/2) × (120/2) = 0.416666667 V (The termination resistor including both ends.)
This voltage difference is significantly higher than the 200mV specified by RS485, ensuring reliable communication.

Traditional RS485 also maintains this voltage difference when idle, so there is no need to worry about interference data being received due to a low differential voltage.

If you want to further increase the voltage difference, you can decrease the resistance value of the pull-up and pull-down resistors, increase the resistance value of the termination resistor, or use AC Termination. For example, setting cTERM to 100pF could work. For short-distance transmission, the termination resistor is often not needed.
(When no termination resistor is added, the pull-up and pull-down resistors themselves can also be AC-equivalent to a termination resistor.)

[HunterLiu0517]

Yes, totally agree. This issue was caused for TX_EN and TX signals are not synchronized. (On my board, TX and TX_EN are synchronized which are output by FPGA. However, when they pass through the intermediate circuit (such as the driver buffer, etc.), the circuit parameters (RC) are different, resulting in the output to the 485 transceiver chip end (SN65176BDR) is not synchronized.
Now TX_EN and TX signals are synchronized, and the strong "1" glitch can be eliminated as above.

And my RC parameter for 485 transceiver chip (SN65176BDR) are as follow:

In addition, I did not adopt your latest branch submission. Because I found that your latest branch has changed a lot from the previous one, may I ask if these changes are necessary? Are there any other problems if I still use the earlier branch?

[dukelec]

If there are no longer any strong "1" glitches, you don't need to merge the latest commit (8ccf609). Even if you do merge it and enable the feature, there will be no noticeable difference in usage.

Your pull-up/down resistor is a bit large; it's recommended to use 330Ω:
(The 330Ω pull-up/pull-down should be used only at a single node.)

[HunterLiu0517]

Got it. Thank you.
And the reason why I choose 1kΩ pull-up/pull-down is that my system contains up to 10 nodes, and they are networked via 485. If the pull-up/pull-down resistance is too small (Rs), the final resistance value after 10 nodes are connected will be smaller(Rtotal=1/10 Rs), which will make the drive current flowing through the interface chip relatively large.
In addition for single node, the differential output voltage ΔU(A-B):
ΔU=5120/(120+1000+1000) =0.2830V > 0.2V, This voltage difference is higher than the 200mV specified by RS485, ensuring reliable communication.