EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: TomS_ on October 03, 2017, 09:00:32 am
-
Hi everyone, just thinking out loud a bit here, and maybe someone has some ideas about what is going on.
Im using a 74HC166 (specifically a SN74HC166N from TI) in a project, and Im seeing some odd behaviour where it appears as though it is not shifting out one of the bits that has been loaded in from its inputs.
Ive got the inputs wired up such that it would represent a binary value of 11000001 (0xC1), but when reading the value in I see 11000010 (0xC2). I see this if the serial input pin is low. If the serial input pin is high I will see 11000011 (0xC3).
Ive used my scope to confirm that I am sending 8 and only 8 clock pulses, and on the MCU side (PIC24EP128MC202) Ive used debug mode and stepped through the entire loop in MPLAB X to ensure that it flows correctly. You'll have to take my word for it for the time being, but it certainly looks to be doing exactly what it needs to be doing.
But it would appear that one of those middle 5 zero bits is just being skipped entirely, leading to the first bit of the trailing serial input appearing at the end of the shifted data.
I can post code (written in C) and screen caps from my scope later, but I feel reasonably confident that Im not doing something silly, as I do have two other 166's which I have cascaded, and reading those with the same code I see the correct 16 bit sequence. Ive also quadruple checked my wiring, over a two day period to make sure I wasnt stuck in some erroneous cycle, to make sure that I do have them wired as I expect. But the fact that the first bit of the serial input seems to be making it on to the end of the shifted data is raising an eyebrow.
Other than a busted chip, can anyone else explain what might be going on here? :-//
I still need to do some additional testing to pull each of those other bits high and see if I can find the one that is being skipped, and perhaps swap them around and see if the problem moves with this suspect 166, I thought I might just throw this out there in the mean time and see if anything comes out.
Cheers!
-
This might seem obvious, but have you got adequate local decoupling on the chip? Also avoid excessively long wiring and make sure your grounds are sound.
-
Swap chips, and if that doesn't move the fault, you probably have a glitch on a CP rising edge and its double-clocking. Try an 01010101 test pattern to find which edge has the glitch. Then if you've got good ground integrity and sufficient decoupling, you could go glitch hunting with an active probe and a 500MHz scope. A 100MHz scope and a x10 probe may not be good enough - the datasheet says the max frequency for CP is 63MHz @5V, and the 15pF typical x10 probe input capacitance has an impedance of 168 ohms @ 63MHz so will probably load the signal enough to hide the glitch.
-
This might seem obvious, but have you got adequate local decoupling on the chip? Also avoid excessively long wiring and make sure your grounds are sound.
Thanks for your response.
Each chip on the board as a 0.1uF ceramic on each VDD/VCC pin.
The wiring shouldnt be too long as it on a 100x160 prototype board. As I was putting it together I measured the ohms of each connection and didnt see anything beyond contact resistance of my multimeter probes. May not be s strictly scientific method, but the results seemed to be pretty good. :-)
-
Swap chips, and if that doesn't move the fault, you probably have a glitch on a CP rising edge and its double-clocking. Try an 01010101 test pattern to find which edge has the glitch. Then if you've got good ground integrity and sufficient decoupling, you could go glitch hunting with an active probe and a 500MHz scope. A 100MHz scope and a x10 probe may not be good enough - the datasheet says the max frequency for CP is 63MHz @5V, and the 15pF typical x10 probe input capacitance has an impedance of 168 ohms @ 63MHz so will probably load the signal enough to hide the glitch.
Thanks for your input.
Ive got a Keysight MSOX2024A, not quite 500MHz but a little more than 100MHz. :-)
Youre probably right, I should just go for the obvious and most simple solution first and swap the chip before toying around with more "complicated" tests which could all be in vain...
My clock rate is quite a lot less than 63MHz. Ive got my MCU running at 70 MIPS, but Im looking at more like 2MHz between peaks of the clock signal. It looks a lot like a sharp triangle wave, but it does reach 5V at the peak.
I was originally running the clock input at 3.3V as supplied by the MCU pin, but in the process of troubleshooting that I fed it through a spare OR gate to bring it up to 5V thinking it may have been voltage threshold related, but I think that should have still been just in spec.
-
This might seem obvious, but have you got adequate local decoupling on the chip? Also avoid excessively long wiring and make sure your grounds are sound.
Thanks for your response.
Each chip on the board as a 0.1uF ceramic on each VDD/VCC pin.
The wiring shouldnt be too long as it on a 100x160 prototype board. As I was putting it together I measured the ohms of each connection and didnt see anything beyond contact resistance of my multimeter probes. May not be s strictly scientific method, but the results seemed to be pretty good. :-)
That's a completely inadequate test. You need to do back-of-the-envelope calculations of the voltage drop due to changing currents in inductors - the voltages will surprise you.
Key equations: I = CdV/dt, V = LdI/dt, assume 1nH/mm of wire, lookup the transition time and load capacitances in data sheets.
And after you've done that, you'll know why you'll never use solderless breadboards again!
(And don't fall into the trap of thinking clock rate has any relevance whatsoever - all that matters is the transition time)
-
why you'll never use solderless breadboards again!
This is on a soldered proto board. :-+
The reason I mentioned measuring the resistance was because of a new construction method I tried this time around. I decided to give Verowire a shot, but I found that you need really high temperatures to burn the coating off and I was worried about joints between the wire and pins/pads not forming correctly. So I measured the resistance of each link from end to end to see what the resistance was like and make sure there wasnt anything obviously wrong with the physical construction.
So in relation to making sure I had good ground connections, making sure there were no high resistance joints between ground the the chips I suppose was important to mention.
And I suppose the reason I mentioned clock rate was because, I guess, in poor conditions a high rate of clock pulses might end up running together and be poorly defined, but a lower clock rate probably isnt going to suffer so badly. In my case my edges are 10ns or thereabouts IIRC.
-
My clock rate is quite a lot less than 63MHz. Ive got my MCU running at 70 MIPS, but Im looking at more like 2MHz between peaks of the clock signal. It looks a lot like a sharp triangle wave, but it does reach 5V at the peak.
I was originally running the clock input at 3.3V as supplied by the MCU pin, but in the process of troubleshooting that I fed it through a spare OR gate to bring it up to 5V thinking it may have been voltage threshold related, but I think that should have still been just in spec.
Sounds like you have severe signal integrity problems. Signals should be reasonably square (ignoring up to 10% ripple and hash on the tops and bottoms) and not hang about in the 20% to 80% transition region. Exception: if driven by an open drain (or collector) driver, with resistor or current source pullups a rising ramp is normal - but then all inputs driven by that signal should have a Schmitt trigger characteristic, with enough hysteresis to prevent noise causing glitches.
Also 74HC logic at 5V Vcc is *NOT* 3.3V compatible. Logic '1' out of a 3.3V device will barely reach 66% of 5V Vcc, and that's below the guaranteed logic '1' threshold for 74HC. (which if you plot the specs for the minimum, for most HC devices, works out to 70% of Vcc for Vcc near 5V). Any loading on the 3.3V logic '1' compounds the issue. It *may* appear to work on the bench in a shirt-sleeve environment as the actual switching point is near 50%, but you have virtually no margin for noise, ground bounce etc, so its not surprising you are getting unwanted clock edges.
You can however use 74HCT powered from 5V for upwards level translation from 3.3V logic as their TTL compatible thresholds are acceptable for 3.3V levels. A proper level translator would probably have better noise margins.
Time to sit down with a 74HC family overview and reference manual + your favourite beverage. (e.g. T.I.'s HCMOS Design Considerations - SCLA007A (http://www.ti.com/lit/an/scla007a/scla007a.pdf))
A sharp well lit photo of each side of your board would be nice, + captures or screenshots of the offending scope traces, with description and details of scope and probe settings - then we can see if you have *any* hope of it working if you substitute 74HCT for any gates that are driven by the MCU, or whether your grounding, and signal and power distribution is so bad that the only option is to Widlarize it.
-
Thanks Ian,
Youve given me a lot to think about!
But I think some screen caps would do better justice here as I may be confusing things and making it sound worse than it potentially is...
I think youve raised a very good point about using HCT, especially in this case since I am using a 3.3V MCU. Historically Ive been a 5V guy, so my stock of chips is naturally geared towards that voltage. Just working with what Ive got I guess.
Mixing 3.3V and 5V logic on one board is a new experience to me, so Im bound to make some cock ups. ^-^
Perhaps I should grab some HCT for this project for anything interfacing directly with the MCU. Or I could use some MOSFETs to form level converters - Ive got plenty of 2N7000's to work with. We'll see if its just a dud chip, and if swapping it out doesnt yield any results, it will be time to dig deeper.
FWIW the proto board I am using is very similar to this one http://www.verotl.com/en/product/double-sided-100x160 (http://www.verotl.com/en/product/double-sided-100x160) with the ground plane top and bottom, except that I had my own knock offs produced because these were way too expensive on an individual basis. ^-^
Widlarize it.
I hope not!
-
So you have a full ground plane on one side of the board? That would eliminate grounding issues, and assuming sufficient decoupling, most power issues as well, so no need to ritually prepare the Widlariser.
I suspect there's an induced glitch synchronous to the SPI access that's causing an extra edge on CP. If you are using an external crystal, what's its frequency and what clock multiplier and divider settings is the PIC24EP128MC202 MCU using? Are you bit-banging or using hardware SPI? What other I/Os toggle during the SPI frame?
2N7000 would leave you with the open drain + pullup slow risetime problem. Better to use proper level translators - 74LVC1T45 (http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf) and 74LVC2T45 (http://www.ti.com/lit/ds/symlink/sn74lvc2t45.pdf) are nice, with separate power pins for the two sides, and don't load the signal when the other side is powered down. You'll need breakout boards as this is a DIP project. There are alternatives, but few can handle upto 5.5V on one side with full push-pull drive, *AND* do down-translation.
-
Its not a pour, but there are traces of copper running the length of the top and bottom sides of the board which are the ground plane. The bottom side of the board has an additional trace which is for the positive supply.
Attached is a very crude cross section of what the traces look like.
Blue is ground, with plated holes top to bottom, red is positive, and green are isolated pads where IC pins would be soldered such that they straddle the two rails. Wiring is done using Verowire with combs to keep everything in line.
As for the level shifter, Ive used a circuit like this one in the past which has seemingly worked quite well: http://www.hobbytronics.co.uk/mosfet-voltage-level-converter (http://www.hobbytronics.co.uk/mosfet-voltage-level-converter)
I am bit banging this particular serial interface. Ive got one UART tied up with RS-232 and the other for I2C, although neither of them are operating at the moment.
No external crystal, Im using the internal osciallator PLL'ed up to 140MHz to give 70 MIPS. Im not presenting that clock signal on any IO pins, i.e. the osciallator output pin is configured as GPIO.
The only other IOs that might toggle around the same time are some outputs which are controlled by a timer interrupt which blink some LEDs.
-
Should have done a full copper ground plane on the top side, with a clearance ring round all holes except those over the ground tracks. Oh well, you'll have to make the best of it. Tie the ground tracks together with reasonably heavy extra wires cross-ways to form a grid and call it good!
That MOSFET level converter is only really suitable for lines that don't mind slowly rising signals, though for those, including I2C its a well proven circuit. The 10K pullup gives a time constant of 0.5us with only 50pF of capacitance. As a 2N7000 will have about 30pF of gate-drain capacitance in that circuit, you cant do any better than that. If you drop the pullup to 1K, as the 2N7000 is marginal on gate theshold voltage for logic applications*, you'll compromise you logic '0' levels. If you use a push-pull drive on the 3.3V side at least it drives to 2.7V quickly but from there on up its a classic RC charging exponential, so if you don't use a Schmitt trigger input gate on the 5V side you risk noise induced glitches.
* The 2N7000 has a wide gate threshold voltage range - At a test current of 1mA, 0.8V to 3V with 2.1V listed as typical. When pulled low to lets say 0.3V, you've only got 3V gate drive, which, worst case, limits your minimum pullup and also compromises your falling edge rate. Use a better MOSFET or build a jig to select on test for 2N7000 with a lower threshold! Rule of thumb: the gate threshold should be no more than half the available gate drive.
-
Well, interesting developments.
I decided to go straight ahead and swap the 166 out, but not before I took a fresh scope capture (scope_64.png). In this image, between the X cursors is the bit we're interested in.
I was actually out by a factor of 10, the rise time of the clock pulse from bottom to top was more like 100ns, and there was clearly something going on as there were several hundred mV hanging around after each clock pulse which gradually died off.
But what you see is 8 clock pulses, with D4 being the data shifted out of the 166. The signal represented by D4 is sampled in the dead spot between each clock pulse, so for the first two clock pulses the signal is high, then 4 lows, then a high and finally a low.
scope_66.png is after I had swapped the 166 out. A lot of ringing, maybe I didnt get a good connection on the springy ground connector at the end of my probe, but you can see that 2 highs are followed by 5 lows and a final high which is what I was expecting to read, and indeed that is what my PIC read too. The edges of the clock pulse were looking much better defined, even with the ringing.
For shits and giggles I decided to put the original 166 back in to see if the fault would reoccur, and what do you know, it too is also working just fine, and this time I got a much better capture as in scope_69.png. The rise time of the clock pulse is more like 15ns now, closer to what I originally thought it was, and the PIC is reading the correct value, too.
So, dicky connection in the IC socket I suppose?
-
You have mentioned Verowire - I have that wire too. Be careful that you don't have a cold joint somewhere that moved when you have swapped the chips. It is fairly easy to get them when the enamel doesn't burn completely off (it needs about 400C on the soldering iron to take it off, ouch!)
-
What's the frequency of the ringing? What is your probing technique?
A bog-standard *10 "high" impedance probe with a 6" ground lead will self-resonate at ~100MHz - and its impedance will actually be low (~100ohms!). The input impedance is dominated by the capacitance, i.e. 1/2*pi*f*C. Plug in the values, using 15pF and f = 0.35/tr
-
You have mentioned Verowire - I have that wire too. Be careful that you don't have a cold joint somewhere that moved when you have swapped the chips. It is fairly easy to get them when the enamel doesn't burn completely off (it needs about 400C on the soldering iron to take it off, ouch!)
Yeah, it needs really high temperatures. Ive never run my iron so high (usually sit at 330)! Im running at 390 degrees C and that seems to be working. Im kind of afraid to go much higher. I guess its a trade off between dont go too hot, or dont apply it for too long - just need to find the balance. :-\
Ive been worried about damaging the components that Ive been soldering, especially things like DIP switches which I havent bothered to socket - Im worried about melting them internally and buggering them up - fixing issues when everything is wired in with Verowire has not been a fun experience!
But based on this suggestion I went over the solder joints for this chip with a little extra fresh solder and at 400 degrees, so hopefully if there was a dry joint there it will be resolved now.
Thanks!
-
What's the frequency of the ringing? What is your probing technique?
I didnt take a measurement of that, sorry. But guesstimating based on the screen cap I posted above, maybe somewhere around 10MHz.
Usually I have a flying ground wire coming off the probe, but for the most recent set of waveforms that I captured, or if I suspect the long ground attachment is messing with the waveform, I used a little springy attachment that goes on the end of the probe, and then put that in contact with the ground pin of the IC that I am probing, or whatever other ground is within easy reach.
-
What's the frequency of the ringing? What is your probing technique?
I didnt take a measurement of that, sorry. But guesstimating based on the screen cap I posted above, maybe somewhere around 10MHz.
Usually I have a flying ground wire coming off the probe, but for the most recent set of waveforms that I captured, or if I suspect the long ground attachment is messing with the waveform, I used a little springy attachment that goes on the end of the probe, and then put that in contact with the ground pin of the IC that I am probing, or whatever other ground is within easy reach.
OK. Now is the time to understand that the probe is part of the circuit, and that it affects the circuit. Bad technique => meaningless results or chasing phantasms.
FFI, see https://entertaininghacks.wordpress.com/library-2/scope-probe-reference-material/
-
My clock rate is quite a lot less than 63MHz. Ive got my MCU running at 70 MIPS, but Im looking at more like 2MHz between peaks of the clock signal. It looks a lot like a sharp triangle wave, but it does reach 5V at the peak.
The rise and fall time are more important than the clock rate for signal integrity. In my experience HC logic is slow enough that it is really difficult to have problems with this but the input threshold problem below is a completely different matter.
HC logic with a minimum high input between 3.15 and 4.2 volts driven by 3.3 volt CMOS is unlikely to work and will not be reliable if it does but HCT logic with a minimum high input of 2.0 volts will be fine. What you might try temporarily is putting one or two diodes in series with the HC166's Vcc to drop the voltage a little shifting the input threshold voltage lower while degrading the output high voltage slightly.
A real level shifter in one form or another or an HCT logic part should be used. I prefer common base level shifters because of ideal noise margin and better speed but a common emitter or source level shifter should be sufficient and takes fewer resistors.
-
The rise and fall time are more important than the clock rate for signal integrity.
Yeah. The more I think about this, the more I wonder why I didnt suspect something was really wrong. Live and learn!
-
Yeah, it needs really high temperatures. Ive never run my iron so high (usually sit at 330)! Im running at 390 degrees C and that seems to be working. Im kind of afraid to go much higher. I guess its a trade off between dont go too hot, or dont apply it for too long - just need to find the balance. :-\
Ive been worried about damaging the components that Ive been soldering, especially things like DIP switches which I havent bothered to socket - Im worried about melting them internally and buggering them up - fixing issues when everything is wired in with Verowire has not been a fun experience!
But based on this suggestion I went over the solder joints for this chip with a little extra fresh solder and at 400 degrees, so hopefully if there was a dry joint there it will be resolved now.
Thanks!
I had the same problem - when using this wire, I am usually using a small piece of scrap of tinned FR4 where I burn the enamel off and tin the end of the wire. In that way I don't have to "cook" the components on the board waiting for the enamel to burn off. That makes it a pain to use, though - I am thus mostly using it only for circuit modding where I need thin wire.
Furthermore, the enamel gives off nasty toxic fumes. Pain in the backside and I certainly will not buy more of this wire. Normal tinned uninsulated wire and Kynar insulated wirewrap wire are much better alternatives.
-
try putting 100k pulldown resistors on the pins between the mpu and ttl
-
I had the same problem - when using this wire, I am usually using a small piece of scrap of tinned FR4 where I burn the enamel off and tin the end of the wire. In that way I don't have to "cook" the components on the board waiting for the enamel to burn off.
Ive also resorted to doing this to a degree. Though it doesnt help when you have daisy chained a few pins together and you cant really pre-tin the wire off the board.
I finished a project recently (a clock built entirely out of transistors) where I used Kynar insulated wire, it worked, but it wasnt the neatest way to wire things together. e.g. https://ornotblog.blogspot.co.uk/2017/08/clock-design-and-build-log-6-calendar.html
It had its own challenges associated with it. I decided to try Verowire this time around to see how it compares. So far Im 50/50 about which one I will use going forward as they are both a PITA. :-DD
-
I had the same problem - when using this wire, I am usually using a small piece of scrap of tinned FR4 where I burn the enamel off and tin the end of the wire. In that way I don't have to "cook" the components on the board waiting for the enamel to burn off.
Ive also resorted to doing this to a degree. Though it doesnt help when you have daisy chained a few pins together and you cant really pre-tin the wire off the board.
I finished a project recently (a clock built entirely out of transistors) where I used Kynar insulated wire, it worked, but it wasnt the neatest way to wire things together. e.g. https://ornotblog.blogspot.co.uk/2017/08/clock-design-and-build-log-6-calendar.html (https://ornotblog.blogspot.co.uk/2017/08/clock-design-and-build-log-6-calendar.html)
It had its own challenges associated with it. I decided to try Verowire this time around to see how it compares. So far Im 50/50 about which one I will use going forward as they are both a PITA. :-DD
Oh whoa, that's some rat's nest! I do feel your pain - I have tried to build a MC68k computer using that technique. Yikes. That's actually why I have bought the Verowire pen and the wire, thinking it will be easier to route and neater. The pen is a cheap piece of crappy plastic and the wire we have discussed already.
Actually, I stand corrected - what I have is not the Verowire but the Roadrunner system. But it is very much the same thing, using the same type of wire.
http://www.roadrunnerelectronics.com/epages/BT3782.sf/en_GB/?ObjectPath=/Shops/BT3782/Products/RRS-K-110 (http://www.roadrunnerelectronics.com/epages/BT3782.sf/en_GB/?ObjectPath=/Shops/BT3782/Products/RRS-K-110)
Their site lists the wire as:
"Suitable soldering temperature 400-430°C"
-
try putting 100k pulldown resistors on the pins between the mpu and ttl
Hi,
Thanks for your suggestion. Have to excuse my ignorance, but would you mind elaborating on why you would do this?
I understand with CMOS it would be particularly important if the MCU pin is going to tri-state for example, such that the net may be left floating - "unconnected" inputs should be pulled either high or low. But I didnt think that was as much of an issue with TTL?
-
just something i'v had to do sometimes when mixing ttl & cmos signals.
-
Just skimmed over the replies, so don't hit me if I'm repeating:
From my experience, these chips are quite sensitive to noise on their clock inputs, that may result in mis-shifting the register (like you appear to see on the first post).
Sometimes there's a simple cure for this: a small capacitor (some 1pf to some 10 pF) wired from the clock input pin to GND near the chip. If you've got more than one of these on the same clock line, use trial and error to find the best place. Also observe setup and hold times if you cascade these shift registers.
-
Just skimmed over the replies, so don't hit me if I'm repeating:
From my experience, these chips are quite sensitive to noise on their clock inputs, that may result in mis-shifting the register (like you appear to see on the first post).
Sometimes there's a simple cure for this: a small capacitor (some 1pf to some 10 pF) wired from the clock input pin to GND near the chip. If you've got more than one of these on the same clock line, use trial and error to find the best place. Also observe setup and hold times if you cascade these shift registers.
If it is noise causing such a problem, you have bigger problems. (In this context noise = AGWN or EMI)
If it is signal integrity, then you should be able to solve the problem with proper construction techniques, principally ground planes plus impedance control and terminations.
Adding a capacitor on a signal line is always a bodge, suitable for short-term debugging only.
-
Clock inputs are often schmitt inputs to prevent clocking problems but it varies between parts and manufacturers and the documentation is not always explicit.
-
Clock inputs are often schmitt inputs to prevent clocking problems but it varies between parts and manufacturers and the documentation is not always explicit.
Yee, but in pernicious signal integrity situations, that can shift the clock by a significant amount; hold time can become a problem.