SN65HVD07: There is an issue where the B line is being pulling down .603V instead of the typical decay on both A and B.

Hi Timothy,

I have a few questions to start our investigation of the issue. 

1. How many units have you seen exhibit this behavior - and do you have any units that are working normally? 

2. Can you share the top side marking of a suspect unit - a picture would be preferred so I can see all of the formatting as well. This will allow me to trace the part in our system and verify if its legitimate and if there are other issues similar to what you are reporting. 

3. Is it possible to share a schematic snippet of the direct IC and bus - I understand if you can't share this - but it will be very helpful for me to understand how your are connecting the device - I don't need a full system schematic - just this IC and its direct supporting circuitry would be ideal. 

Please let me know!

Best,

Parker Dodson

Hello Parker,

1. How many units have you seen exhibit this behavior - and do you have any units that are working normally? Almost all of them, but it is difficult to get an exact fallout rate.

Please see the attached document to answer the rest of your questions:

Modbus Issue_8-9-23.pdf

Regards,

Tim Harris

Hi Tim,

Thanks for providing the updated information. 

I was able to find the devices part markings in our system so at this time I don't really believe it to be a counterfeit device issue. 

That being said I have a few clarifying questions:

1. So the schematic at first pass - nothing seems super off - but I just want to verify a few things:

1a) For the filter on the SN65HVD07's A and B pins - what are the values of the capacitance and inductance -while these filters can be used in RS-485 applications (generally speaking I wouldn't use any inductors if at all possible - a common mode choke is okay - but differential inductors are generally not the most advisable - but not necessarily a major issue either)  I just want to ensure that it isn't overloading the bus. As from the data you shared it looks like both A and B are actually experiencing smaller swings that just so happens to line up where VOD is always positive. 

1b) How many total communication nodes are in the system - or is it just the 2? 

1c) Are two terminations used in the system - I'd assume yes but I just want to confirm. 

1d) what is the data-rate and length of the bus? 

1e) Do the A/B bias resistors (R107 and R69) only exist on the one node ? 

Essentially  - at this time it looks as if the most probable issue is as follows:

The effective impedance seen by the SN65HVD07 is too low and the device cannot output the correct signal strength. The issue seems to happen when A and B are held high and low respectively for it seems about 3ms  and then switch back to communicating. This is a big reason why I want to check the filter parameters as I do think that would be the most likely component to cause some kind of issue if the inductors are being charged with a decent amount of current for a relatively long time. Its not a guarantee - but I think it could be the source. 

I don't, at this time, think there is damage on the SN65HVD07 due to the fact that resetting the bus fixes the issue - as damage on the A/B pins is usually permanent and obvious - not saying its impossible otherwise - but please confirm the questions above and we can discuss next potential steps.

Best,

Parker Dodson

Hello Parker,

1a) CC42 & CC43 = 100pF, Inductor = TDK ACM2012-900-2P-T002 

1b & c) yes, 2 nodes

1d) baud rate = 19.2Kbps and the bus length is variable, but it does not exceed 30m.

1e) yes

Please let me know if there are any questions.

Regards,

Tim Harris

Hi Tim,

Thanks for the additional information.

So based on everything that you have shown me so far it does look like when the differential bus is held high something on the bus - most likely some inductance - is keeping the current flowing during the switch and its having a hard time bringing "B" back up. The issue only seems to appear after some period of a soak time (seems on the order of ms). Reason I think this is a bus response and not necessarily a device response is because you can reset the bus and the device works fine again. There could be some inductive issue on the pins - but I think that is less likely - and if that is the case we most likely would need to handle this as a return so we can do failure analysis in house - but before we get to that point there are a few tests that hopefully can be pretty quick that would more or less confirm if this is an apps issue or if there is a quality issue at play. 

A few quick tests that may help isolate the issue:

1. Hold the bus in its low state for like 20ms to 30ms  - if I am right - I'd think this would cause the "A" pin to exhibit similar behavior that the "B" pin has. 

2. If possible short out the filter and just do a test without the choke. The choke should generally be fine - and I really don't see a ton of problems with that + capacitors (the capacitors are very high impedance to data signal which is good) - but I just want to see if the choke is causing any issue with the device. Issue is the choke doesn't give a lot of its information - like nothing about impedance besides the differential mode should be fine for high speed signals - issue being there is essentially a low frequency / DC charging current that really isn't super well spec'd for this device - I am not 100% sure the device is causing issues - but its something that should be tested just in case there is something unexpected there. 

These are just some basic tests that will help isolate if we need to handle this as a return or if its something that can be remedied on your side. Essentially if it is a board issue I'd imagine that the results of test 1 will show "A" having a similar issue when it is held low - since it seems there is a specific condition that is met before the other issue you have seen on "B". Also I'd imagine test 2 could potentially show improvement in your systems.

Please let me know on the tests - if we don't find anything it may need to be handled as a return so we can do failure analysis on the device - essentially which would most likely be an Automated test to look into compliance with our datasheet as well as myself performing a bench test if there are no obvious failures from our automated testing. Hopefully one of the tests above can help us avoid this step, but if not please let me know so we can start moving forward in the next step of the process otherwise.

Best,

Parker Dodson