SN65HVD3082E: SN65HVD3082E

Hi Nihan,

To clarify I have a few questions:

1. What are the scope shots - as it what does the left side represent and is the right side a picture of. Is this measuring one device at the R, D, and enable pins or is there more than one device that is being shown.

2. Are the scope shots from only devices that are potentially damaged?

3. Are the HVD72 devices the ones in the test scope shots - I just want to clarify as it still states that part in the schematic.

4. What conditions is the device under when it power's on in steady state mode (voltages on devices pins at startup) - same question for normal operation mode. 

If you could just add scope shots of the bad device compared to a good one it will be a good indication of what could be happening in the device. Beyond that from the initial information that you have provided since this problem is seen in one condition and not the other that would make me first want to look at what differences does the transceiver see under the two modes of operation at startup. The dip in the R voltage when enable goes high could also indicate internal damage somewhere inside the part. If you could confirm the questions I can look a bit deeper into what could have caused damage and if that make sense for what is being seen. 

Please let me know so I can dig a bit deeper to see what could be happening!

Best,

Parker Dodson

Hello Parker,

1.The first picture is our signals when there is no communication. The second one is belong to when there is a communication.  (yellow-receive signal, blue-transmit signal, pink-enable signal)

2.Yes, they are from the potentially damaged devices. But not damaged products which are in our warehouse behave same as the second one. I know it is strange since there is a little voltage drop on the receive signal. But since it is still in the range of high voltage level there is no problem, MCU still understand it. 

3.There is HVD72DR on schematic but on the pcb SN65HVD3082ED is assembled, because our manufacturer thought they are equivalent and assembled without asking us. At the attachment of this post you can find the behaviour of HVD72DR  assembled product on normal operation mode and steady-state mode (actually it is standby mode) 

4. You can find the shots we took at the time of power up below for normal operation mode and standby mode of the product. For both situations power voltage of the communication IC is 3.3V and stable. 

When the damaged IC works (on normal operation mode) sometime after startup the signals are like below

You can see dip voltages of R signals on the images. 

I hope I answered all your questions. Waiting for your reply.

Thanks in advance. 

Hi Nihan,

Thanks for the detailed follow up I really do appreciate it!

That being said - it does seem that there is some electrical issue seen when the DE signal goes high - it seems to be dropping a voltage - probably over the pull-up resistor since the drop is similar in both cases (this makes me think that there is about a  100uA current being pulled on the R pin when DE goes high. Every pin is internally connected to VCC and ground - so there could be internal damage causing this current draw as when the RE pin is low the R output should be high-z when connected to VCC should put it ~3.3V. In the cases where communication fails - it seems that the R pin has a 1V signal on it - do you know where this coming from? Because it could also indicate that the device is shunting more current when starting in steady state mode. 

However I do suspect there is damage on the device - and while it does seem the damage has something to do with the R pin shunting current to ground - this could indicate issues with multiple pathways within the device. I do suggest the next steps in this problem are to look at our failure analysis page:
https://www.ti.com/support-quality/additional-information/failure-analysis.html

It has some steps on how to move forward with these issues and gives a chance for our quality team to look over it - they may want to test bad units or do an FA - it depends a few factors that they would be better to explain; however there help can be utilized here to see what next steps might need to be taken to help uncover the root of the problem. What I will say about the current schematic - I don't see a lot of "risk" of damage for normal operation - however that doesn't discount other more "transient events" that could cause damage. What that would be depends on the damage seen on the part and where the actual damage lies - but it does seem R is shunting current and the R voltage value when starting in steady state seems too low for a port that should be hi-z. 

Please let  me know if you have any other questions and I will see what I can do!

Best,

Parker Dodson 

Hello Parker,

After receiving your reply we tried to find the reason of the current beign pulled as you told.

I'm not sure if I mentioned this but we are communicating using bacnet. So we tried to if there is any communication problem if we use modbus protocol. We realized that there is no problem with communication either on normal operation mode or steady-state mode. But while checking signal voltage on modbus communication, we realized that voltage levels are normal and on ~3.3V level. There is no voltage drop to ~2.6V level on R pin like it happened on working communication status of HVD72DR or SN65HVD3082ED (You can see images belong to this situation in the post I last sent)

After realizing that we compared Uart Init function of modbus and bacnet firmwares. In the modbus communication firmware, receive signal was defined as a floating pin. But in bacnet communication firmware it was defined as alternative function push-pull pin. So using damaged ICs we changed bacnet firmware uart init function receive pin definition to floating pin and this worked. There is no voltage drop either on normal operation mode or steady-state mode. Do you have any knowledge about this? If you can please enlighten us about this.
We are also curious if this alternative function fush-pull definition is the cause of the damage on these ICs. We have been using this definitions for our Bacnet communication devices for years but after so long we received the complaint about communication. We are waiting for your comment about the reason.

Best Regards.

Parker Dodson said:

What I will say about the current schematic - I don't see a lot of "risk" of damage for normal operation - however that doesn't discount other more "transient events" that could cause damage. What that would be depends on the damage seen on the part and where the actual damage lies - but it does seem R is shunting current and the R voltage value when starting in steady state seems too low for a port that should be hi-z. 

I also would like to know more details of your thoughts about the protection of the circuit design. We placed TVS diodes to prevent transient voltages. Is this not enough? Would you suggest any other protection to prevent transient voltages and noise?

Hi Nihan,

For the protection circuits:

1. The issue seems to be at the R pin - so I doubt damage is from the A/B pins (as these pins are already the most robust pins on the device in terms of their ratings anyway) The TVS diodes added should keep any damaging signals at bay in most scenarios - so I don't think there is a major issue there. The logic pins are the most susceptible to damage as the pins only are rated from -0.3V to VCC + 0.3V so a transient spike could potentially cause issues. 

For the firmware issue:

From what I could find this could be the issue - and it may not be device damage. Could you clarify if the BACNET is programmed in an output push pull configuration when the failure occurs? if it is this could cause failure - not due to the transceiver but due to the GPIO pin state. This pin should be programmed to be either floating (which when you did this its fixes this problem - leading me to believe this could be a firmware error) or as an input push push configuration. Since it does seem there could also be that voltage drop on the HVD72 device that you tested - but it just doesn't cause the same issues as the device that is actually on the board. 

A few quick tests to try to see if it is independent of the transceiver is too: 

1.  Remove the transceiver (these inputs are high impedance so leaving them floating shouldn't be a huge issue for the test) and apply the same signals you normally would apply.  If the R voltage dips when configured in the push pull configuration then this voltage drop is from firmware.

2. Configure the Device in an input Push Pull Configuration (if the device allows for this configuration) - if communication works again this confirms that it is a firmware issue.

Please let me know if these tests result in results that possibly show the issue is independent of the transceiver. If it does it may just be as simple as changing the startup function to floating if possible to prevent this error with this device.

Best,

Parker Dodson