SN65HVD72: Rogue pulse on receive pin when RE# is enabled

Hi Andrew,

This glitch seems to have quite the impact on your system. This behavior is not expected. I'd like to know more to see what may be causing this issue.

The R pin output should only output a LOW value when Vid < Vit- and RE/ is LOW (valid bus low). This may also occur when the bus is in an indeterminate state (Vit- < Vid < Vit+).

What voltages are present on the bus when RE/ is toggled? Is Vdiff < Vit?
What value is the D pin driving before DE is disabled?

What other devices are present on the bus? Other potential drivers? You mentioned there is no biasing network. Would it be possible to add one to the design?
Is the delay between toggling RE/ and the pulse on the R pin consistent with the receiver enable time (3-8us)?

Regards,

Eric

Hi Eric

Thanks for your rapid response.

The bus currently only has a 130R termination resistor and an SM712 TVS, with 10R in series in each line, so no external bias resistors and no cable attached (so no other drivers).  Vdiff is approximately 0.0V so is outside the indeterminate range Vit- < Vid < Vit+, and this is a typical "open bus" state so I understand will represent a valid failsafe condition.  The D pin is high (3.3V) and DE low (driven from the bridge RTS#).  I have a 74LVC1G126 non-inverting buffer driving RE# from DE, so normally DE and RE# are effectively the same signal - both driven by bridge RTS#.  However when idle/asleep the LVC1G126 buffer is tristated and RE# is then pulled high by a 10k resistor, so both driver and receiver of the SN65HVD72 are disabled for minimal power consumption.  It is enabling and disabling this buffer (i.e. toggling RE# high and low) that reveals the 2us pulse on the R receive output as RE# goes low.  The pulse happens about 2.5us after RE# falling edge (mostly within the 3-8us receive enable window you mention).  Receiver output has a 100k pullup and the pulse has clean fast edges so is definitely being driven by the receiver.

I want to avoid external bias resistors if at all possible as these increase current consumption dramatically.  Originally I was switching the entire supply to the transceiver off when idle but had issues with bleed current from the bridge partially powering the transceiver.  There is always the option for additional circuitry to isolate bridge from transceiver, but thought I'd exhaust the simpler fixes first and see if we can prevent this pulse occurring in some way.  I'll try adding external bias resistors just to see if that removes the pulse.

Regards

Andrew

Hi Andrew,

Your setup seems sound from what you've described. I will do some lab testing later this week using this part to see if an explanation can be found. 

If you're looking for a quicker solution, the THVD1410 may be an alternative. It is a newer part that has gone through more recent testing and exhibits a robust internal failsafe biasing. It does have higher power requirements than the SN65HVD72, but will likely be preferable to an external biasing network.

I will be in touch with my findings.

Regards,

Eric

Hi Eric

Adding bias resistors (680R pullup and pulldown) shortens the pulse down to around 100ns but doesn't eliminate it entirely.  The bridge still reacts to it. These resistors aren't really an option for me due to power consumption, but interesting to see it has an effect.  I have meanwhile tried adding an extra tri-state buffer before the receive pin of the bridge and I enable this 10us after enabling the SN65HVD72 receiver.  This seems to work OK at removing the pulse from the bridge input and it now sleeps correctly.  I'll change the PCB decal so I have provision for either SN65HVD72 or THVD1410 parts.

Regards

Andrew