Fixed the Hydra USB connect / download hang hardware bug.
epmoyer
Posts: 314
I have identified the cause of the problem which occasionally causes the Hydra to hang when USB is connected. I believe this is the same issue RedNifre described in his “Problems connecting the Hydra to the PC” post (http://forums.parallax.com/showthread.php?p=648112) and is very likely the issue Brian Beckius recently described in his “hydra can’t be programmed” post (http://forums.parallax.com/showthread.php?p=657119).
The Problem:
If you look at the following schematic you will see that the EEPROM serial data line (SDA) is pulled up to the reset net (RESn) with a 10k resistor.
I’m not sure what the original intent of this connection was. Possibly it was intended to allow a reset to force an I2C START (SDA falling edge while SCK high) followed by and I2C STOP (SDA rising edge while SCK high) in order to “reset” the EEPROM device. What ends up happening though is that SDA ends up pulling the reset net (RESn) down.
Since BOen on the Propeller is tied to ground the Prop has an internal 5k pullup (to 3.3.V) on RESn. That means that whenever SDA is low, RESn sits in the middle of a 5K/10K voltage divider and gets pulled down to nominally 3.3 * 10K/(5K + 10K) = 2.2V. Due to the tolerances of the resistor values (I’m guessing the 5K in the prop is not very accurate) I see an actual voltage during the contention of 1.83V.
Here is a picture of the Hydra resetting when the USB cable is inserted into my PC:
Blue is the base of Q5 (the transistor which pulls RESn low to create the reset)
Green is P29 (the Propeller pin which drives the EEPROM’s SDA line)
Pink is RESn (the Propeller reset line)
SDA goes high on reset, so it is not fighting against RESn and the initial reset pulse happens pretty normally. I don’t particularly care for the use of C15 to couple the DTR pulse into Q5. It barely makes 1.1V and barely manages to turn on the transistor, but it seems to work pretty repeatably. Parallax uses this same coupling method on their demo board. [noparse][[/noparse]I changed my mind about this. See later posting]
Now, here is a picture of the Hydra beginning its first EEPROM access
Yikes!. As you can see, the SDA transitions cause weird behavior on RESn, often dragging it down roughly 1/3 to about 1.8V. In some cases the Hydra will bang around a bunch, resetting a few times and eventually coming out of its “funk”, but sometimes it will get hung in a steady state condition which looks like this:
RESn is stuck at 1.8 and nothing is happening. The Hydra appears hung, and attempts to download code from the prop IDE will result in the “No propeller chip found on any COM port. Scanned COM3” error.
This also explains why I have had very good success clearing the “hung” state by hot-inserting a cartridge into the cartridge slot; undoubtedly the insertion glitch on SDA knocks RESn out of its hung state.
The Fix:
The solution is to pull SDA up to 3.3V. This can be accomplished very easily by anyone skilled in surface mount rework. Rotate the 10K pullup resistor R21 so that it is no longer connected to the right hand pad, and then solder a rework wire from the far side of R21 to the right side of R41 (3.3V).
After the fix the USB-insertion reset looks like this:
And the initial EEPROM access looks like this:
And USB insertion/download no longer hangs the device.
Post Edited (epmoyer) : 7/7/2007 3:22:43 PM GMT
The Problem:
If you look at the following schematic you will see that the EEPROM serial data line (SDA) is pulled up to the reset net (RESn) with a 10k resistor.
I’m not sure what the original intent of this connection was. Possibly it was intended to allow a reset to force an I2C START (SDA falling edge while SCK high) followed by and I2C STOP (SDA rising edge while SCK high) in order to “reset” the EEPROM device. What ends up happening though is that SDA ends up pulling the reset net (RESn) down.
Since BOen on the Propeller is tied to ground the Prop has an internal 5k pullup (to 3.3.V) on RESn. That means that whenever SDA is low, RESn sits in the middle of a 5K/10K voltage divider and gets pulled down to nominally 3.3 * 10K/(5K + 10K) = 2.2V. Due to the tolerances of the resistor values (I’m guessing the 5K in the prop is not very accurate) I see an actual voltage during the contention of 1.83V.
Here is a picture of the Hydra resetting when the USB cable is inserted into my PC:
Blue is the base of Q5 (the transistor which pulls RESn low to create the reset)
Green is P29 (the Propeller pin which drives the EEPROM’s SDA line)
Pink is RESn (the Propeller reset line)
SDA goes high on reset, so it is not fighting against RESn and the initial reset pulse happens pretty normally. I don’t particularly care for the use of C15 to couple the DTR pulse into Q5. It barely makes 1.1V and barely manages to turn on the transistor, but it seems to work pretty repeatably. Parallax uses this same coupling method on their demo board. [noparse][[/noparse]I changed my mind about this. See later posting]
Now, here is a picture of the Hydra beginning its first EEPROM access
Yikes!. As you can see, the SDA transitions cause weird behavior on RESn, often dragging it down roughly 1/3 to about 1.8V. In some cases the Hydra will bang around a bunch, resetting a few times and eventually coming out of its “funk”, but sometimes it will get hung in a steady state condition which looks like this:
RESn is stuck at 1.8 and nothing is happening. The Hydra appears hung, and attempts to download code from the prop IDE will result in the “No propeller chip found on any COM port. Scanned COM3” error.
This also explains why I have had very good success clearing the “hung” state by hot-inserting a cartridge into the cartridge slot; undoubtedly the insertion glitch on SDA knocks RESn out of its hung state.
The Fix:
The solution is to pull SDA up to 3.3V. This can be accomplished very easily by anyone skilled in surface mount rework. Rotate the 10K pullup resistor R21 so that it is no longer connected to the right hand pad, and then solder a rework wire from the far side of R21 to the right side of R41 (3.3V).
After the fix the USB-insertion reset looks like this:
And the initial EEPROM access looks like this:
And USB insertion/download no longer hangs the device.
Post Edited (epmoyer) : 7/7/2007 3:22:43 PM GMT
Comments
I wonder if those of us who haven't had problems yet should do this mod as a preventative measure?
Works on the second try always.
I'm gonna try the mod as I've never seen the same thing happen on the demo board.
Since I have have my Hydra set up on my workbench with a soldering iron literally less than a foot away its a no-brainer; I'd cut the fix in preventatively even if I wasn't seeing the hang. If I didn't own an iron, or if I wasn't comfortable reworking surface mount, and I wasn't seeing the hang then I probably wouldn't worry about it.
If you're like me and saw the hang only rarely, then inserting a cart is a very effective way to clear the hung state (in my experience), so you might be able to work around it.
I have to rescind that comment! I thought about it last night and realized that the reason the voltage at the base of Q5 just barely gets high enough to turn it on is because as soon as the voltage does reach the turn-on threshold then current starts flowing into the base, which depletes the charge on C15. I tried removing Q5 just to test it, and with Q5 removed the voltage on the Q5 side of C15 reaches a full 3.3V. There's probably a lot more design margin in that circuit than it originally appeared.
With my Hydra I have to plug and unplug the USB cable several times before the IDE will recognize the Propeller and let me program it. I haven't had this experience with the demo boards so it seems unique to the Hydra. Do you think this change might help with that?
As as aside, what software are you using for your scope? I have an old tektronics scope that I got keep because it was out of spec and the lab didn't want to bother paying to re-calibrate it so they gave it to me. I've been thinking about replacing it with a PC based scope.
--Chris
Yes, It sounds you have the same problem as well, and the fix should eliminate it.
I'm running a Tektronix TDS 3014B. I've used older variants of that scope before and love it so we bought one when we started our own company. This model has an Ethernet port on it and runs a little HTML server, so you can just point your browser at it and get screen captures very easily. You can also control it via HTML and grab trace data in excel format but I never actually use any of that capability; I use the screen capture all the time though and miss it terribly when I'm working on older models. I'm doing a little consulting on the side right now and I often bring my scope in just for the screen grab capability even though they have an Ethernetless version of the exact same scope there.
I find that when all I have a slow floppy then I only tend to grab traces of stuff I really know I'll need. But when screen capture is easy I grab pictures of everything, and often that turns out to be very useful because I can fish back through old traces and find stuff I didn't know I was looking for when I first took them.
Thanks Eric for taking the time to really drill down into it. But, this problem is very rare for most people. Most of the time when there is a programming problem I have found that driver problems with the FTDI setup has been the culprit. But, if we find that changing this fixes this bug that occurs with some customers then we will definitely modify the board in the future, easy fix.
Andre'
Post Edited (AndreL) : 7/7/2007 9:51:16 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
This is a problem we discovered sometime last year (I believe too late for the Hydra production to change).· I'm uncertain about how often or how many Propeller-to-Propeller-Tool interactions this causes problems with.
The original design (SDA to RESn) was intended to allow the Propeller/EEPROM circuit to achieve minimum current draw during sleep states, but, as you know from this thread, it has an unforseen side effect.
We now wire SDA through a 10 KOhm resistor to 3.3v, which eliminates the problem you are mentioning.
Sorry for the inconvenience.·
NOTE: This doesn't seem to effect every system, nor does it seem to affect some systems all the time; our recommendation is to make the board modification only if you are experiencing problems with the current circuit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.