@VonSzarvas - thank you for your help. I will take the measurements again using the common ground this time as soon as I get back from church this morning. Thank you again.
Doc
...stick the black probe to a common ground somewhere (one of the 4 plated mounting holes or turrets would do), and the red probe to the each of the three 2 pin headers in turn, at the pins labelled 5V or 1V8.
Powered from PC USB
LDO VIN 5V header reads 2.027V with jumper in place.
VDD 1V8 header reads 1.842V with jumper in place.
ACC HDR 5V header reads 2.531V with jumper in place.
Powered from AUX USB
LDO VIN 5V header reads 4.687V with jumper in place.
VDD 1V8 header reads 1.845V with jumper in place.
ACC HDR 5V header reads 5.06V with jumper in place.
When powered by USB, does removing either the LDO or the ACC hdr jumper (try them individually, then both together) get the voltage at the 5V pin on those headers closer to 5V ?
And what evanh suggested is a good thing to try... running with both USB-PC and USB-AUX connected.
If that works, it seems likely the PC-USB power switch got damaged. Probably you could feel it getting rather warm when you have ONLY the PC-USB cable connected. (One of the black square IC's below the ACC-HDR pins).
The next test would be to connect USB-AUX and all the jumper headers, then go around the board edge headers, measuring each of the Vxxx pins with your red probe (and keep the black on common ground). If one or more of those Vxxx pins are less than 3.2V that would be a problem, and indicate which IO group of the P2 is having trouble.
You can operate with a cable in each USB socket. Then the AUX supplies power while PC just does the comms. This might work for you.
Thank you for this suggestion - I wasn't sure if I could power it with both connected. Unfortunately it didn't work. The red LED at PC USB goes out but when I try to upload a binary file I get dimly lit blue LED at P63 while it tries then "Could not find a P2" message (flexgui).
When powered by USB, does removing either the LDO or the ACC hdr jumper (try them individually, then both together) get the voltage at the 5V pin on those headers closer to 5V ?
Powered from PC USB
LDO VIN 5V header with jumper removed reads 1.039V on the left pin and 5.08V on the right pin.
ACC HDR 5V header with jumper removed reads 1.8V (and falling) on the left pin and 1.427V on the right pin.
It's always the oscillator VIO supply! ... LOL, I guess when it's another VIO we don't hear about it because the prop2 is still programmable. Having the 5V pin right next to the VIO pin at the accessory header I suspect is where this happened. A design fix would be to rearrange the accessories pinout. A bit late for that now though.
Recommendation is always remove the ACC_HDR jumper when not needed.
Recommendation is always remove the ACC_HDR jumper when not needed.
Yep! Duly noted.
I suppose I should ask before I risk one of my precious spare P2 chips: I assume from the measurements above that the power switches survived the short. I don’t want to fry another P2 chip.
Perhaps I should consider sending it back to be “refurbished”. Maybe @"Ken Gracey" can tell me if that is an option - if there wasn’t a ‘limit one per customer’ I’d just order another board. ;-)
Von,
Just thinking about reducing the failure rate: Not having the 5 Volt pin on the #4 accessory header would definitely limit the severity of such accidents. It'll mean accessory boards that need the 5 volts, eg: USB, can't be used in that position though. But so far, I think the USB accessory is the only one that does need 5 Volts.
Recommendation is always remove the ACC_HDR jumper when not needed.
Yep! Duly noted.
I suppose I should ask before I risk one of my precious spare P2 chips: I assume from the measurements above that the power switches survived the short. I don’t want to fry another P2 chip.
Perhaps I should consider sending it back to be “refurbished”. Maybe @"Ken Gracey" can tell me if that is an option - if there wasn’t a ‘limit one per customer’ I’d just order another board. ;-)
Doc
Damaged the board and need a replacement? Sure, it's no problem. Early adopters get special treatment from Parallax.
Send me an e-mail kgracey@parallax.com and I'll get you an RMA number and cross-ship a replacement.
We just made another batch, which might be the last one until we get more chips (P2 Rev C arrives March 10th (qty 10) with a few thousand arriving late April and early May).
I assume from the measurements above that the power switches survived the short. I don’t want to fry another P2 chip.
I think so. Presumption is that 5 Volts was spiked on to various accessory pins. 5 Volts is the highest voltage present so can't over-voltage the USB supplies and the USB power switches will shutdown on over-current. Likely you were seeing the 500 mA limit of PC-USB causing a pulsing of power up/down that just looked like a steady voltage on the multimeter. Whereas with AUX-USB, with 2 Amp limit, it was able to overpower the two LDO's that had busted VIO's and hold a steady supply. Those two LDO's hopefully are okay still, just would have run thermally limited for a while is all.
Actually, it wasn't even an over-voltage condition in my case. I'm already confident that spiking a VIO supply pin is just as likely to have this outcome as any I/O pin. What happened to me was very distinctly when I shifted a revA VIO jumper from the LDO to the switcher supply. There was nothing even touching the accessory header at the time.
There is a significant similarity with Doc's case - bare copper supply switch closing. In his case it was uncontrolled and accidental, but both still would have been a small spark.
I've forgotten what you'd hypothesised with my case. It probably applies here too, irrespective of the over-voltage.
I'd like to know if spiking an individual I/O pin is enough. I suppose it is. Presumably the I/O drive transistors are the only ones directly across the VIO/GIO power rails.
> @evanh said:
> Actually, it wasn't even an over-voltage condition in my case. I'm already confident that spiking a VIO supply pin is just as likely to have this outcome as any I/O pin. What happened to me was very distinctly when I shifted a revA VIO jumper from the LDO to the switcher supply. There was nothing even touching the accessory header at the time.
>
> There is a significant similarity with Doc's case - bare copper supply switch closing. In his case it was uncontrolled and accidental, but both still would have been a small spark.
>
> I've forgotten what you'd hypothesised with my case. It probably applies here too, irrespective of the over-voltage.
>
> I'd like to know if spiking an individual I/O pin is enough. I suppose it is. Presumably the I/O drive transistors are the only ones directly across the VIO/GIO power rails.
There must be a >4V spike to trigger a latch-up failure. Switching 0-3.3V levels can't cause any harm.
I can assure you my case was only the 3.3 V supplies involved. It was something about the interface to the core logic I vaguely rememberer you saying. ... or maybe that one was discounted when you decided on another explanation. I've forgotten too much.
It's always the oscillator VIO supply! ... LOL, I guess when it's another VIO we don't hear about it because the prop2 is still programmable. Having the 5V pin right next to the VIO pin at the accessory header I suspect is where this happened. A design fix would be to rearrange the accessories pinout. A bit late for that now though.
Recommendation is always remove the ACC_HDR jumper when not needed.
V2431 = 219.9mV
V4855 = 216.9mV
V2431 is the oscillator supply as evanh said.... V4855 is curious to have failed too.
> I had a wire pop loose and must have dragged across the board somewhere causing a power fault.
@doggiedoc Could you describe the moment of fault a bit more, to help us dial in on how things got zapped exactly?
I'm assuming the loose wire mush have brushed all the way across the top-left and bottom-left header pins (or top and bottom sides of the P2 pins) ?
Was the wire connected to anything? Or was it an unconnected wire causing a dead sort between any two pins it touched?
In general, the voltage readings you took suggest the power circuits are working as expected, and limiting current into the faulty P2 pins.
Hunch would be that VIO2831 is shorted to GND inside the P2. And either VIO4851 or VIO5255 also shorted to GND inside the P2.
Simply replacing the P2 should bring everything back to life.
That said... After removing the old P2, I'd strongly suggest re-measuring all the power points (all the Vxxx and also at the three 2-pin headers) to ensure voltages are correct before installing a new P2 chip. - Looks like Parallax already offered to do that for you.... Awesome bunch!
Von,
Just thinking about reducing the failure rate: Not having the 5 Volt pin on the #4 accessory header would definitely limit the severity of such accidents. It'll mean accessory boards that need the 5 volts, eg: USB, can't be used in that position though. But so far, I think the USB accessory is the only one that does need 5 Volts.
EDIT: Maybe header #8 too.
Added to internal feedback list. Thanks evan.
Instant options...
For those that want to remove 5V power from those "important" headers, then cutting the 5V header pins off with some solid snips would solve. (V5663 and V2431).
Although that won't help when a wire is accidentally flopping or brushing over the circuit; that could cause a short or failure anywhere.
On the production rev, we could re-arrange those IO headers- to have the two GND pads between the 5V/Vxxx pins and the I/O pins, so that any direct short would be to GND instead of the P2 IO. However, that breaks the accessory compatibility. Maybe not a huge deal moving from eval to production, but would be nice to avoid.
Or add a row of jumper headers or dip-switches that allow each IO header to have 5V (or some other injected voltage) switched on/off individually. I think on balance, that would be overkill though. Accidents will happen on any circuit, and adding more cost and complexity that impacts everyone probably won't change that.
Hence the idea behind the ACC HDR feature on the current boards (Rev B ), and the advice in the docs, and as you said, to keep the ACC HDR jumper OFF during wiring/re-wiring, and until all is connected, powered up, and you actually need it. That keeps 5V disabled at the edge headers whilst wires are being poked and moved about the board! AFAIK the RevB boards are supplied with that jumper in the OFF position, but always worth double checking before making changes to the board.
Fortunately @doggiedoc is still in an exclusive club! Out of a few hundred eval boards I think this was the 7th blown (including all reasons), and only the 2nd RevB I think. Statistically, very few accidents have happened and Parallax have supported them all! I think keeping the unfettered I/Os and 5V power options for full evaluation purposes is important (pretty much the point of eval!). And for everyone there's some good learning toward hardening approaches for an industrial/mainstream module here too; thanks for that.
For the next rev we could add one or two LDO's to provide 3.3V to the edge headers, instead of taking that voltage rail from the P2. That way, the 5V to Vxxx short scenario cannot break the P2 (and would be protected against by the new LDO circuit), and backward compatibility remains true for all other Eval boards and accessories.
Do we really need Vxxx at the headers, instead of just 3.3V in those places ?
To me it looks like HDMI/VGA/USB will need 5V on the headers, so discarding it completely is wrong. Changing the headers and breaking existing accessory boards is wrong also.
So my guess is that putting a jumper (or dip switch) on each header would be the best solution.
Do we really need Vxxx at the headers, instead of just 3.3V in those places ?
Good question. Separate 3.3 V seems a good idea to me.
Von,
I'm having second thoughts. It's useful for instrumentation designs to know the reference of an ADC. The only reference available with the prop2 is the VIO to GIO difference.
Much of this shorting out is probably from the lack of a power switch. It's annoying to have two USB supplies, having to unplug the PC USB connector as well as the aux power adapter. Laziness/tiredness steps in, and wiring gets changed with power on.
Do we really need Vxxx at the headers, instead of just 3.3V in those places ?
Good question. Separate 3.3 V seems a good idea to me.
Von,
I'm having second thoughts. It's useful for instrumentation designs to know the reference of an ADC. The only reference available with the prop2 is the VIO to GIO difference.
You got it! That's why they are how they are on the Eval. Keep everything open for experiments, keep voltage references common by IO group.
I've was pondering the same conundrum, as to how we might protect the P2 a bit more, and keep the voltage references the same.
Anything we add on the P2 rail will interfere with the reference level to some %.
High tolerance LDO's serving both the P2 and headers individually seem to beat that %, before we consider unknown loads on the breakout headers. Dang!
Having a row of headers near the P2, that provide "reference voltage" output, hooked direct to the P2 LDO's could be done, but that's adding more connections and code steps to offset readings. And just adds another place to zap the P2!
A @whicker switch could help, if people used it. That might be the simplest thing so far... all but the fan/aux 5V port by the aux-usb socket could be disabled by adding a switch that holds the existing USB power IC's off. (pull the enable pins low).
Might look a bit of a lump though, and still wouldn't protect the pins from being zapped by some other power source floating around. Really just another way to limit chances of an accident.
You know... I think the risk is almost 100% from the 5V header pin, and those ALREADY have a jumper to enable/disable. For customer's that prefer, why not add an external switch to plug in there; make it even easier to switch off before making changes ? Switches could similarly be added to the 1V8 and LDO headers to disable everything remotely by a switch.. Perhaps a little external PCB that has a single switch driving 3 fets or relays, that hook to those 3 headers.
Yep- pondering continues...!
So far though, all things considered, keeping the board as-is seems best for the majority. Maybe it's better to have replaced 2 or 3 blown boards, than to limit experiments?
Do we really need Vxxx at the headers, instead of just 3.3V in those places ?
Good question. Separate 3.3 V seems a good idea to me.
Von,
I'm having second thoughts. It's useful for instrumentation designs to know the reference of an ADC. The only reference available with the prop2 is the VIO to GIO difference.
You got it! That's why they are how they are on the Eval. Keep everything open for experiments, keep voltage references common by IO group.
I've was pondering the same conundrum, as to how we might protect the P2 a bit more, and keep the voltage references the same.
Anything we add on the P2 rail will interfere with the reference level to some %.
High tolerance LDO's serving both the P2 and headers individually seem to beat that %, before we consider unknown loads on the breakout headers. Dang!
Having a row of headers near the P2, that provide "reference voltage" output, hooked direct to the P2 LDO's could be done, but that's adding more connections and code steps to offset readings. And just adds another place to zap the P2!
A @whicker switch could help, if people used it. That might be the simplest thing so far... all but the fan/aux 5V port by the aux-usb socket could be disabled by adding a switch that holds the existing USB power IC's off. (pull the enable pins low).
Might look a bit of a lump though, and still wouldn't protect the pins from being zapped by some other power source floating around. Really just another way to limit chances of an accident.
You know... I think the risk is almost 100% from the 5V header pin, and those ALREADY have a jumper to enable/disable. For customer's that prefer, why not add an external switch to plug in there; make it even easier to switch off before making changes ? Switches could similarly be added to the 1V8 and LDO headers to disable everything remotely by a switch.. Perhaps a little external PCB that has a single switch driving 3 fets or relays, that hook to those 3 headers.
Yep- pondering continues...!
So far though, all things considered, keeping the board as-is seems best for the majority. Maybe it's better to have replaced 2 or 3 blown boards, than to limit experiments?
I haven't ordered the REVb eval yet but I'm very happy with my REVa board. One of the USB switches on it fried at some point (I think the P2-PWR) but a jumper wire solves all. I like all the incremental changes from A to B, and pondering a C rev I'm not sure what I'd recommend! Perhaps a solder jumper on back for 5V per pin group? Omit the XTAL and sys pin groups so you can't accidently destroy these pin groups since these will prevent a boot?
Without adding, which as you say is actually subtracting from versatility. A power switch would be nice, although I'm not sure how to do that to cover all use-cases.. I've pondered a power supply for the p2 several times and I think the LDO per-pin group is a great approach. Power management chips seem to be more aimed at microprocessors than microcontrollers
I'd say the Rev B board design seems pretty sound. I'll let you know once I've had a chance to break it. It's dare I say, IMPOSSIBLE, to make this bullet proof. Accidents happen and we are all human. Too many late night coding sessions and you KNEW you weren't supposed to but forgot..
Comments
Doc
Powered from PC USB
LDO VIN 5V header reads 2.027V with jumper in place.
VDD 1V8 header reads 1.842V with jumper in place.
ACC HDR 5V header reads 2.531V with jumper in place.
Powered from AUX USB
LDO VIN 5V header reads 4.687V with jumper in place.
VDD 1V8 header reads 1.845V with jumper in place.
ACC HDR 5V header reads 5.06V with jumper in place.
And what evanh suggested is a good thing to try... running with both USB-PC and USB-AUX connected.
If that works, it seems likely the PC-USB power switch got damaged. Probably you could feel it getting rather warm when you have ONLY the PC-USB cable connected. (One of the black square IC's below the ACC-HDR pins).
The next test would be to connect USB-AUX and all the jumper headers, then go around the board edge headers, measuring each of the Vxxx pins with your red probe (and keep the black on common ground). If one or more of those Vxxx pins are less than 3.2V that would be a problem, and indicate which IO group of the P2 is having trouble.
Powered from PC USB
LDO VIN 5V header with jumper removed reads 1.039V on the left pin and 5.08V on the right pin.
ACC HDR 5V header with jumper removed reads 1.8V (and falling) on the left pin and 1.427V on the right pin.
will try testing the AUX headers...
V0007 = 3.312V
V0815 = 3.312V
V1623 = 3.309V
V2431 = 219.9mV
V3239 = 3.319V
V4047 = 3.322V
V4855 = 216.9mV
V5663 = 3.318V
Yep! ya broke it well !
Sorry there's not an easy fix on this.
Doc
Recommendation is always remove the ACC_HDR jumper when not needed.
I suppose I should ask before I risk one of my precious spare P2 chips: I assume from the measurements above that the power switches survived the short. I don’t want to fry another P2 chip.
Perhaps I should consider sending it back to be “refurbished”. Maybe @"Ken Gracey" can tell me if that is an option - if there wasn’t a ‘limit one per customer’ I’d just order another board. ;-)
Doc
Just thinking about reducing the failure rate: Not having the 5 Volt pin on the #4 accessory header would definitely limit the severity of such accidents. It'll mean accessory boards that need the 5 volts, eg: USB, can't be used in that position though. But so far, I think the USB accessory is the only one that does need 5 Volts.
EDIT: Maybe header #8 too.
Damaged the board and need a replacement? Sure, it's no problem. Early adopters get special treatment from Parallax.
Send me an e-mail kgracey@parallax.com and I'll get you an RMA number and cross-ship a replacement.
We just made another batch, which might be the last one until we get more chips (P2 Rev C arrives March 10th (qty 10) with a few thousand arriving late April and early May).
Ken Gracey
There is a significant similarity with Doc's case - bare copper supply switch closing. In his case it was uncontrolled and accidental, but both still would have been a small spark.
I've forgotten what you'd hypothesised with my case. It probably applies here too, irrespective of the over-voltage.
I'd like to know if spiking an individual I/O pin is enough. I suppose it is. Presumably the I/O drive transistors are the only ones directly across the VIO/GIO power rails.
> Actually, it wasn't even an over-voltage condition in my case. I'm already confident that spiking a VIO supply pin is just as likely to have this outcome as any I/O pin. What happened to me was very distinctly when I shifted a revA VIO jumper from the LDO to the switcher supply. There was nothing even touching the accessory header at the time.
>
> There is a significant similarity with Doc's case - bare copper supply switch closing. In his case it was uncontrolled and accidental, but both still would have been a small spark.
>
> I've forgotten what you'd hypothesised with my case. It probably applies here too, irrespective of the over-voltage.
>
> I'd like to know if spiking an individual I/O pin is enough. I suppose it is. Presumably the I/O drive transistors are the only ones directly across the VIO/GIO power rails.
There must be a >4V spike to trigger a latch-up failure. Switching 0-3.3V levels can't cause any harm.
V2431 = 219.9mV
V4855 = 216.9mV
V2431 is the oscillator supply as evanh said.... V4855 is curious to have failed too.
> I had a wire pop loose and must have dragged across the board somewhere causing a power fault.
@doggiedoc Could you describe the moment of fault a bit more, to help us dial in on how things got zapped exactly?
Was the wire connected to anything? Or was it an unconnected wire causing a dead sort between any two pins it touched?
In general, the voltage readings you took suggest the power circuits are working as expected, and limiting current into the faulty P2 pins.
Hunch would be that VIO2831 is shorted to GND inside the P2. And either VIO4851 or VIO5255 also shorted to GND inside the P2.
Simply replacing the P2 should bring everything back to life.
That said... After removing the old P2, I'd strongly suggest re-measuring all the power points (all the Vxxx and also at the three 2-pin headers) to ensure voltages are correct before installing a new P2 chip. - Looks like Parallax already offered to do that for you.... Awesome bunch!
Added to internal feedback list. Thanks evan.
Instant options...
For those that want to remove 5V power from those "important" headers, then cutting the 5V header pins off with some solid snips would solve. (V5663 and V2431).
Although that won't help when a wire is accidentally flopping or brushing over the circuit; that could cause a short or failure anywhere.
On the production rev, we could re-arrange those IO headers- to have the two GND pads between the 5V/Vxxx pins and the I/O pins, so that any direct short would be to GND instead of the P2 IO. However, that breaks the accessory compatibility. Maybe not a huge deal moving from eval to production, but would be nice to avoid.
Or add a row of jumper headers or dip-switches that allow each IO header to have 5V (or some other injected voltage) switched on/off individually. I think on balance, that would be overkill though. Accidents will happen on any circuit, and adding more cost and complexity that impacts everyone probably won't change that.
Hence the idea behind the ACC HDR feature on the current boards (Rev B ), and the advice in the docs, and as you said, to keep the ACC HDR jumper OFF during wiring/re-wiring, and until all is connected, powered up, and you actually need it. That keeps 5V disabled at the edge headers whilst wires are being poked and moved about the board! AFAIK the RevB boards are supplied with that jumper in the OFF position, but always worth double checking before making changes to the board.
Fortunately @doggiedoc is still in an exclusive club! Out of a few hundred eval boards I think this was the 7th blown (including all reasons), and only the 2nd RevB I think. Statistically, very few accidents have happened and Parallax have supported them all! I think keeping the unfettered I/Os and 5V power options for full evaluation purposes is important (pretty much the point of eval!). And for everyone there's some good learning toward hardening approaches for an industrial/mainstream module here too; thanks for that.
For the next rev we could add one or two LDO's to provide 3.3V to the edge headers, instead of taking that voltage rail from the P2. That way, the 5V to Vxxx short scenario cannot break the P2 (and would be protected against by the new LDO circuit), and backward compatibility remains true for all other Eval boards and accessories.
Do we really need Vxxx at the headers, instead of just 3.3V in those places ?
So my guess is that putting a jumper (or dip switch) on each header would be the best solution.
Not one HDR jumper, but one per header.
Mike
@"Ken Gracey" - email sent (doc@tcah.com)
I'm having second thoughts. It's useful for instrumentation designs to know the reference of an ADC. The only reference available with the prop2 is the VIO to GIO difference.
You got it! That's why they are how they are on the Eval. Keep everything open for experiments, keep voltage references common by IO group.
I've was pondering the same conundrum, as to how we might protect the P2 a bit more, and keep the voltage references the same.
Anything we add on the P2 rail will interfere with the reference level to some %.
High tolerance LDO's serving both the P2 and headers individually seem to beat that %, before we consider unknown loads on the breakout headers. Dang!
Having a row of headers near the P2, that provide "reference voltage" output, hooked direct to the P2 LDO's could be done, but that's adding more connections and code steps to offset readings. And just adds another place to zap the P2!
A @whicker switch could help, if people used it. That might be the simplest thing so far... all but the fan/aux 5V port by the aux-usb socket could be disabled by adding a switch that holds the existing USB power IC's off. (pull the enable pins low).
Might look a bit of a lump though, and still wouldn't protect the pins from being zapped by some other power source floating around. Really just another way to limit chances of an accident.
You know... I think the risk is almost 100% from the 5V header pin, and those ALREADY have a jumper to enable/disable. For customer's that prefer, why not add an external switch to plug in there; make it even easier to switch off before making changes ? Switches could similarly be added to the 1V8 and LDO headers to disable everything remotely by a switch.. Perhaps a little external PCB that has a single switch driving 3 fets or relays, that hook to those 3 headers.
Yep- pondering continues...!
So far though, all things considered, keeping the board as-is seems best for the majority. Maybe it's better to have replaced 2 or 3 blown boards, than to limit experiments?
I haven't ordered the REVb eval yet but I'm very happy with my REVa board. One of the USB switches on it fried at some point (I think the P2-PWR) but a jumper wire solves all. I like all the incremental changes from A to B, and pondering a C rev I'm not sure what I'd recommend! Perhaps a solder jumper on back for 5V per pin group? Omit the XTAL and sys pin groups so you can't accidently destroy these pin groups since these will prevent a boot?
Without adding, which as you say is actually subtracting from versatility. A power switch would be nice, although I'm not sure how to do that to cover all use-cases.. I've pondered a power supply for the p2 several times and I think the LDO per-pin group is a great approach. Power management chips seem to be more aimed at microprocessors than microcontrollers
I'd say the Rev B board design seems pretty sound. I'll let you know once I've had a chance to break it. It's dare I say, IMPOSSIBLE, to make this bullet proof. Accidents happen and we are all human. Too many late night coding sessions and you KNEW you weren't supposed to but forgot..