RS485 chip glitches - what do you think?
Peter Jakacki
Posts: 10,193
I have asked the TI forum about this glitch with their 65HVD75 RS485 chip and it keeps going backwards and forwards with them asking for more information and more scope captures etc. Sounds like MS support, you know, it must be something YOU are doing!
So I thought I'd throw this up here on this forum to see if anyone would think any different from what I think, that is, it is a design fault with the chip, these are full-failsafe glitchless chips you see, and it looks like they don't quite work.
In this test I remove any possibility that it is the Prop glitching by floating the chip's R (receive) line and simply pulsing the combined TE and /RE line. The R line is actually combined with the D transmit of the chip but that is an input anyway.
Have a look and see what you think and btw the supply is decoupled right next to the chip and extremely clean. This unit had a 330R resistor grafted into the R line to check solutions so that accounts for the slower fall and rise time that you may see in the top trace.
Traces: 1=R+D, 2=TE+/RE, 3+4=Bus
So I thought I'd throw this up here on this forum to see if anyone would think any different from what I think, that is, it is a design fault with the chip, these are full-failsafe glitchless chips you see, and it looks like they don't quite work.
In this test I remove any possibility that it is the Prop glitching by floating the chip's R (receive) line and simply pulsing the combined TE and /RE line. The R line is actually combined with the D transmit of the chip but that is an input anyway.
Have a look and see what you think and btw the supply is decoupled right next to the chip and extremely clean. This unit had a 330R resistor grafted into the R line to check solutions so that accounts for the slower fall and rise time that you may see in the top trace.
Traces: 1=R+D, 2=TE+/RE, 3+4=Bus
800 x 480 - 47K
Comments
How does the glitch length relate to the data ?
Traces 3 & 4 have been merged in the same position to clearly show their relationship to one another without losing this information if I used differential mode on these channels. Either way there is nothing there on the bus, shorted, biased, capacitor loaded etc that causes or affects the glitch.
Low Standby Supply Current: < 2 µA
and the data hints this mode has time-domain effects
tPHZ, tPLZ Driver disable time 12 50 ns
tPZH, tPZL Driver enable time
Receiver enabled 10 20 ns
Receiver disabled 3 7 µs
See Figure 13 and Figure 14
tPLZ, tPHZ Receiver disable time 15 30 ns
Driver enabled 10 50 ns tpZL(1), tPZH(1),
Receiver enable time tPZL(2), tPZH(2)
Driver disabled 3 8 µs
See Figure 16 See Figure 17
Notice that change in TX & RX times, based on if Standby is Enabled, or not.
Seems that deep power down, (both disabled) has a finite exit time, and maybe while it is waking up, is is somewhat befuddled...
If you keep /RE low, does the problem go away ?
Yes, as awkward as it was this is the first thing I did along with the 330R resistor in the R line of course. But just to be on the safe side I will repeat that test again, as I have done so with everything I can think of. The combined TE and /RE is very common and TI also show that configuration in their datasheet APP section.
I haven't seen this problem before with other chips and I have used the 65HVD308x chips as well. However this design uses msop package and 3.3V operation so I don't have another I can drop in nor will change anything with this. I have plenty of other boards with regular chips that don't do this but IF they did then you would think someone would have noticed by now!!!
Hmm, I see they also do something moderately sneaky in the data
Figure 17. Measurement of Receiver Enable Times With Driver Disabled
they quietly FLIP the load-idle condition via their S1 for the two line cases, and do not show the converse waveforms.
The standby sense circuits look to be slower than the Data paths, and looks to me like they have stuffed this up a little with some overlap/confusion resulting. They omit to mention the time to go into standby.
Digikey shows Intersil 83078 and 3179 devices in MSOP8 , as well as the other speed choices in TI parts ?
Could be worth a try.
Yeah, I'm keeping all that in mind for production as I can work around it now but I will have to check whatever chips I intend to use before I commit volume. So I might get some of those ISL3178EIUZ chips as they seem to be quite reasonably priced too. They don't enter shutdown unless both TE and /RE are disabled which is never the case with my setup. The TI part is actually a VSSOP which seems identical with msop footprint.
Well since I'm following along here and want to explore 485 on a couple bread boarded IOT5500 modules what other chips should I investigate?
Here are some 3.3v DIP8 choices
Also can I just follow the 485 electrical spec with 220ohm termination and 680ohm bias (pull up/down) resistors? What about ground as the spec suggests but doesn't require?
Your 'scope capture seems to have a lot of high frequency ringing. The 3+4 traces that should be rock solid, instead cross back and forth a couple of times in the first 50+ ns at a level up to 1/2 volt. I hear what you say about the cable attachment making no difference, but then, what is going on? Is the ground solid at the chip?
With regard to manufacturers and products, I too have had gripes and have been put off by haphazard responses for technical help. On the other hand, some FAEs are very helpful, trying to second guess what I'm doing, emphasizing that this or that factor is crucial and may be found only as fine print between the lines in the app notes. It usually comes down to me eating crow on a basic issue. A couple of weeks ago I had a TI boost converter that wouldn't start up into load. I thought my layout was pretty tight, but as it turned out, it had to be a lot tighter. All a matter of tiny inductance at MHz+ with nanosecond edges.
My guess is in trying to be clever and add Power Down, TI messed up the overlaps of tplh.tphl in the power down side of things, which will be in a slower process. (hence the us region specs)
Get those us delays wrong by 121ns, and voila, you have a Power-down-oops-no-wakeup pulse.
It could be worth trying the slower 65HVD72, as the pulse is possibly hidden in that by the slower drivers.
Do TI have the same part, with no Power Down ?
Just heard back from TI and they say sorry about that part, try these other ones, they've been fixed for the glitch. Some comfort but I wonder why these parts aren't pulled from the shelves and replaced. The engineer said he had bench tested a HVD1782 and that works fine but the only suitable replacement parts I seem to be able to order off the shelf are Intersil.
WIth regards to the ringing bear in mind that I am zoomed up at 50ns/div and I do have cable attached in this instance and the stubs are around 10mm. Being a MSOP/VSSOP pack the layout is tight with the 0.1uF snuggling up but even if the decoupling wasn't perfect it wouldn't account for this type of glitch.
The truth is I'm not even using twisted pair, shhhh, it's actually 10-way IDC with the inner 485 pair surrounded by pairs of ground and one outer pair for power but the cable is only a meters long anyway. There are four independent buses with one running longer distances over TP cable. When I placed a rough and ready 100pf on the line it cleared up a lot of the ringing.
I can workaround this problem simply by delaying transmitting after receiving so that the receiving end doesn't lose the signal due to the glitch. But the glitch is long enough even at 1Mbaud that the DigiView 10% glitch filter won't filter it out and as for the Chinese Rigol, well, we won't go there, where would you stop?
BTW, thanks for looking into this for me, I appreciate the feedback and critique!
BTW, here is the pcb layout for that area.
These are prototypes so there could be a little improvement with decoupling but sometimes we are just trying to get it functional and on the bench first as there is always something that needs to be changed, even if it works perfectly. Noise, termination, and protection components are on a separate board since the the cable length is so short etc. The 0R resistors are placeholders for either ferrite beads, 10R resistors, or just 0R. The board has two bus connectors but only one long cable is used with headers crimped at intervals. EDIT: These are full fail-safe parts so no biasing is required.
Here's another analog capture of the bus and slave showing a character ($81) on trace 1 from the master with a response from the slave. Notice the glitch right after TE (trace 2) goes from high to low. That's also the problem on the other end which isn't visible here but I have attached the LA captures. This glitch is longer than the simple TE pulse test and can affect the receive line for up to 600ns after TE goes low.
EDIT: don't be worried about the "silk screen" component IDs over the pads, they are on a mechanical layer as they are only used as an assembly guide, I don't place designators etc on PCBs normally as there just isn't enough room for them to do it properly and besides, who is going to look at it???? The PnP machine doesn't need it and I wouldn't let a "technician" try and fix it. I print up the zoomed overlays to fill a page which I follow for prototype assembly, either in print or dropboxed on a tablet.
I response to the unexpected (expect it) I too read the online posts to see if there is advice to take to heart, and I don't usually post anything myself until I've tried the advice. That is where I stand with the problem with the TI booster I talked about earlier, waiting for a revised pcb from OSHPark. I had changed over from a Linear Tech part (which was working fine) to the TI part in order to lower the BoM cost and to get a lower Iq. I'll dig deeper if there is still a problem. In the "old days" with National Semi or Linear, a phone call asking for technical help was as likely as not to find you talking to Bob Pease or Jim Williams respectively, or someone involved in the design of the part, a real education. Not so much these days, maybe a consequence of all the corporate acquisitions.
The '65HVD75 data sheet advice on layout does show it on a 4-layer pcb with large pads for power and with multiple vias directly to the power planes. Also pullup/down resistors on the enable lines close to the chip, "to limit noise currents in these lines during transient events." That is in the context of industrial surge transients, but it has to do with the fast edges. I do still wonder where the oscillation in your A/B output is coming from, just before the glitch. The hysteresis band for that chip is 80mV and the oscillation is a full volt. Could the 'scope probes be acting as stubs?
The layout they show is always the "dry clean only" version so anything less might be fine but they ain't saying. It is rather amusing though that you can do all that but still you are lumped with a glitchy chip that they haven't bothered to issue an errata for nor have they pulled the parts and replaced it with a new version.
The devices do have weak pulldown on the TE and pullup on R but that's not the problem here either. However on every other design I have always had pulldown on the TE but the TE is always driven except during reset although with the weak pulldown I haven't seen any power-up glitching.
In the original capture the A/B probes were placed along the cable at a convenient point to attach the probes so that might be another reason for the ringing. Considering though the purpose of the capture was really to show that the extremes of the system could not be contributing to the glitch, especially when the TE line is simply pulsed without any drive whatsoever onto the data line from the Prop.
I used a little bit of bias to double check the system and it reduces the width of the glitch but doesn't remove it. Anyway these parts are full failsafe which is the whole reason for using them as to avoid bias resistors etc.
If it changed at all, that's a sign it may not be internal.
If you use 'a little bit more bias', does the width reduce further ?
Fail safe really only means they have the no-cable static case covered, by skewing the hysteresis band slightly one side of 0v.
How long is the attached cable in this test ?
CAN drivers have a better fail-safe/slicing scheme, but I think they cannot wire in this 1 pin mode.
I like TI parts in general but I'm shaking my head at how they are handling this problem with such a simple low end part such as this. If I was TI I'd rather recall the stock and replace it with the fixed version as it is much cheaper than trying to shore up your reputation as a trustworthy reliable and professional company. A "fail-safe" chip that glitches all by itself in normal operation is not something you want anybody discovering.
The cable is only a few meters long but as mentioned maybe in other threads it isn't TP, just the center pair of a 10-way IDC with ground pairs on either side. I can easily setup the probes to show that this ringing you see in the original capture is really only an artifact of the less than precise measurement method. Even so, that main ringing spike is only about 20ns wide.
Which ones are supposedly OK ?
Can you use those ?
My other thought is decouple the TE and /RE, to see if that pulse is associated with the collapse of current associated with the transmitter part of the circuit
@Tubular - the supply is flat and clean, no problems with droop or noise. One of the first things I did was remove the chip and replace it with one with the R and RE pins bent up so I could pull RE low and insert a 330R resistor in the R line because of this. This accounts for the slow fall and rise time you see in the glitch but the glitch was still there as it happens when TE is released. It's when the TE is turned on and also as data changes that you would expect to see problems from decoupling etc.
I don't think there is much point to look at it further, it is a chip design defect and in spite of it my network is flying along. I may however put up some more detailed waveforms as it currently is.
As always take into context the voltage and time scales as the waveforms will always look good "zoomed out" and bandwidth limited.
1=Receive line via 330R
2=TE line reference
3=bus line - single
4=Vdd across HVD75 - maybe 150mv with less than 40ns of ~100Mhz ringing.
1=Receive line via 330R
2=TE line reference
3&4=bus
MATH bus differential at 100mV
(or, maybe they have 250,000+ of the main ones to clear, and the bean counters decided..)