Propeller FLiP USB power requirements
Phil Pilgrim (PhiPi)
Posts: 23,514
in Propeller 1
I notice from the FLiP docs that its USB chip requests 1500 mA from a charger but only 500 mA from a computer's USB port. As a consequence, I've found that some charger modules will not power the FLiP, even though its actual requirements are much less, even, than 500 mA. FLiP-powered devices that work fine connected to a computer will not power up when connected to certain lower-than-1.5A chargers.
I've looked into reconfiguring the FLiP's FTDI chip to request less current, but I have not found a solution.
Has anyone dealt with this before? Have you found a work-around?
Thanks,
-Phil
Comments
Hi Phil,
I've not a got a FLiP with me to check so I hope this is right.... in the FTDI settings somewhere you will find "Force Power Enable". If you enable that option, and set CBUS3 to Tri-State, then the FLiP will run at approx. 500mA when connected to a computer or battery charger.
Thanks, but that didn't work. I got continuous power recycling from all sources, both charger and computer.
BTW, my device runs at 130 mA max.
-Phil
Dang! I could grab a module in the morning and give it a fresh pair of eyes if that's not too late.
The USB power source - is that just a "dumb" 5V charger, or is it a more advanced fast charger with multi-voltage negotiation ? Got a link to what you're using ?
The charger that works is an Intertek 5000566 (2.4A). The one that doesn't is a Mass Power NBS05B050100VUU (1.0A). The latter, of course, can't be expected to accept a request for 1.5A. (Both locally purchased; can't find a datasheet for either one.)
Not too late. Thanks for looking into it for me!
-Phil
Not sure I can answer the question about the specific charger bricks, but I maybe I can throw light on how the FLIP thinks.
The FLIP circuit is implemented by-the-book, as described in the FT231x data sheet, and is well elucidated in the (AN-175 Battery-Charger-Detection-over-USB-with-FT-X-Device). The FLIP is not a battery charger, but the detection works the same in order to determine how much power can be drawn from the USB Bus. It uses the current limit pin on its RT9728 USB power switch. A resistor on that pin to ground limits current to less than 100mA at startup. That same pin is also connected via resistors to open drain signals pwren# and bcdchg# pins on the FT231X. pwren# drives low when the PC gives permission to draw 500mA. And bcdchg# drives low if it detects that the USB signal lines are shorted together. Those two signals effectively add resistors in parallel that limit the FLIP current to 500mA or 1500mA respectively. The important thing here is that the FLIP's USB chip does not "request" 1500mA from the charger. It simply detects that the two USB signal wires are shorted. The value 500mA is programmed into the FLIP's eprom, and can be modified using the FT_Prog utility. But the programmed value is (should not be
!) the problem here.
If you connect the FLIP USB port to a 5V bench supply, using a USB cable, you will find that it won't work unless you short together the USB signal wires.
My problem with high power USB bricks usually comes from drawing too little current. It wants to deliver current at a high rate, and when the current drawn drops below a certain threshold, it shuts off to conserve its own power. The threshold might be 100 or 200mA, a PITA for micro-power projects.
Thanks, Tracy! That explanation makes sense.
Anyway, it's not a big deal to provide a charger that works. They just cost a little more is all. But now I'm curious if the cheap wall wart has its USB signal wires shorted. I'd lay odds that it doesn't.
The battery power brick thing is another conundrum that I'm trying to grok. I have one FLiP-powered unit that draws less than 100 mA. My small Anker PowerCore+ Mini 3350 unit powers it just fine without interruption. OTOH, the unit that draws 130mA cuts out periodically when powered by the Anker, even though the Anker can provide 1A. It's a mystery.
-Phil
Curious... If low-current were the issue on that charger, does adding a pull-down resistor at the FLiP "USB 5V" voltage output pin change the behaviour ?
I just came in and tried a FLiP, and found one workaround. What you could do is set the Force Enable back to "off" that I mentioned before, leave CBUS3 as "BCD_Charger#", and change CBUS2 to "Drive_0". That will allow the FLiP to operate with chargers/battery packs that don't short the data lines, whilst retaining compatibility for programming with many modern computers (those that don't barf when up to 500mA is drawn before negotiation).
Thinking ahead, that instant current draw depends on the user circuit and code of course, and might be obviated by adding a ~2 second pause at the start of the code, so that the FLiP doesn't start working (and pulling high current?) before the computer has had time to recognise the USB device. In your case of the circuit running <100mA, all that is irrelevant! Or if it's an issue, just change back the FT setting on CBUS3 before re-programming.
I checked three charger bricks that I have here, one a 6.7 Ah Anker, one an older 10.4Ah Radio Shack, and the third a 2.2Ah no-name swag from a trade show.
The Anker shut down for currents under 75mA, the Radio-Shack shut down under 65mA, and the no-name shut down for currents under 100mA. There was a delay for it to detect current below threshold and then shut down, from 3 to 10 seconds for the Anker and Radio Shack, and 45 seconds for the no-name.
The no-name did in fact have D+ shorted to D-, isolated from the supplies, thus conforming to the BCI1.2 spec for a dedicated charging port (DCP). However, the other two chargers did not have a simple short circuit there. Instead, when off, they had resistances in the range of 100kΩ to 5MΩ from D+ to D- and to the supplies, and probably active circuits as well. In fact, when the brick turned on, the resistance dropped (measured by a hand-held multimeter) to 50 to 70 ohms. The BCI1.2 spec allows up to 200Ω for a DCP, so that would signal to the connected device to go ahead and draw a whatever current it wants. The brick presumably has its own current limit protection in case the connected device gets greedy. That doesn't exactly conform to the BCI1.2 spec for downsteam ports (SDP or CDP), but a search on electronics.stackexchange reveals a complicated scene of manufacturer one-upmanship, both to support advanced features, and to hookwink the public with messages like "device not supported, please purchase matching accessory from ....".
One other potentially important difference was that the Anker and the Radio Shack bricks would both start up automatically when the load was connected at first or after an interruption. The no-name did not behave like that and a button had to be pressed to start it up.
I just rechecked the low-power wall wart on my unit with a different cable. It worked! All along the problem has been the cheap cable that accompanied the charger (thanks for nothing, O'Reilly Auto Parts!). Yes, there are two-conductor cables out there that do not support a programming connection — just charging. And, of course, those cannot communicate a short between the data lines to the downstream device, since there are no data lines.
So now I need to put a scope on the USB 5V line of the FLiP when connected to a battery-powered charging source to see exactly what's going on there.
-Phil
The bane of a charge-only USB cable imposter! If you want to keep it, emblazon it with a red flag or heat shrink, skulls and crossbones too.
I think you will find that there is a short circuit at the B end of the cable. The FLIP will identify it as a dedicated charger and happily turn on the green LED and set the current limit on the RT9728 to 1500mA (!). But no programming. Scratch head.
I checked for a short between D+ and D- at the micro-B end. The cheap cable doesn't even provide that much. So I guess the lesson is this: when buying electronic stuff, go somewhere that specializes in it, not to an auto parts store. (That said, however, the good stuff came from a QFC!)
I just threw it in the trash. Lesson learned.
-Phil
Here's a scope trace of the USB 5V line coming into my device from the Anker battery source:
That slight drop, which seems to happen at random times, is enough to raise havoc with the system.
-Phil
Thinking that maybe the battery needed more of a load, I put a 100R resistor between USB 5V and ground. That only made things worse. The drop-out became much longer, albeit no deeper.
So I removed the resistor and put a 10uF tantalum cap in its place. It made no difference.
I give up. There's something about the load that my device presents to the battery that it just doesn't like.
-Phil
Strange indeed - what is your load current doing ?
That's a quite long dip, and a strange shape too, but it looks like it is trying to cope with a load increase.
It probably has to do with the SCD30 CO2 sensor I'm using. Every two seconds, and for 400ms, the IR source comes on, sending the current consumption of the sensor from 5mA to 65mA. I've not been able to correlate that increase in demand with the drop-outs, however.
-Phil
Come to think of it, the IR source looks to be incandescent. And we all know what an incandescent load looks like before it incandesces (i.e. a dead short). Hmm.
Without the SCD30 plugged in, there are no glitches on USB 5V from the battery. So it turns out, this has nothing to do with the FLiP module after all.
Investigating further with the SCD30 plugged in, I put a separate scope probe on its RDY line, which goes high immediately after the IR goes off and low as soon as the Prop reads the data from the sensor. I observed glitches on USB 5V every 1.967 seconds. The RDY line pulsed high every 2.157 seconds. So the two signals stay mostly out of phase until the RDY signal "passes" the glitch. At that point, the glitch happens when the IR source is on, and then the FLiP does a power-fail reset.
Next I kept the SCD30 plugged in, but disabled the IR source. There were no glitches on USB 5V, and the FLiP never reset.
Finally, I enabled the IR again, but set its interval to five seconds, instead of two. Again the glitches occurred every 1.955 seconds, with the RDY pulses every 5.391 seconds. Whenever the two roughly coincided, I got a reset. So the period of the glitches has nothing to do with the period of the IR source. Yet the glitches occur only when the IR source is enabled, and reset occurs only when a glitch coincides with the IR source being "on".
Weird.
-Phil
Next step must be to scope the current drawn by that SCD30 module ?
What added load do you need to apply, to match the droop and ripple of that brownout ?
Weird indeed. Uncorrelated but causative. Go figure.
The way I read the 'scope trace, the glitch is a big one, 5V to 4V, and it lasts 3ms, and at the bottom there is evidence of a 10kHz oscillation of about 0.2V amplitude. Are you measuring that at the 5V output from the FLIP, or directly at the battery? The 5V output from the FLIP comes from the battery via the power limiting circuit, then to the 3.3V buck regulator. Is there a similar dip on the 3.3V FLIP output? I believe that is what is powering the CO2 sensor.
I was measuring it at the FLiP's 5V output. I finally got around to making a USB breakout cable so I could measure it at the battery 5V. The glitch does not appear there.
By scoping the instantaneous current, I was able to verify that when the glitch on the FLiP's 5V output is concurrent with a current peak (i.e. when the IR source is "on"), The FLiP does a brownout reset.
So both the wall wart and battery provide the same steady 5V, but the FLiP's output is somehow distinguishing between them. I'm beginning to think they're the PWREN# and BCDCHG# outputs from the FTDI chip that're causing the problem. For some reason, when connected to a battery, they glitch high. But probing those pins is well nigh impossible.
-Phil
This has nothing to do with the weird glitch, but speaks to the topic of FLIP power.
I was interested in the quiescent current drawn by the FLIP when the Propeller is operating at its minimum of about 10µA on RCslow. The module draws considerably more than that due to the power supply and the MEMs 5MHz oscillator.
Here is the test program:
{FLIP quiescent current draw test} PUB main dira[0..27]~~ outa[0..27]~ clkset(%0_00_00_001, 20_000) ' RCSLOW at ~20 KHz repeat outa[26]:=1 ' blink the led outa[26]:=0 waitcnt(100_000+cnt) ' ~5 secondsTotal current via USB port...10.8mA
.....divided approximately as follows
.....5.6mA to the green power led
.....1mA to the AOZ1281 current limiter
.....100µA to the RT2798 5V-3.3V buck regulator
.....3mA to the SiT8918 MEMs 5MHz oscillator
.....1.1mA to the FT231x USB bridge
There are some inferences from data sheet typical values in the determination.
When powered from the 5-9V input instead of USB, the current dropped to 9.5mA at 5V in, and 5.7mA at 9V in.
That's good info, Tracy. Thanks.
BTW, 5.6mA of that can be taken care of with a very tiny drill bit.
-Phil
Following up with the battery issue, I concluded that the PWREN# and BCDCHG# outputs from the FTDI chip were the culprits, pulsing high for reasons that elude me. To test that theory, I changed the FT231x's C2 output from PWREN# to Drive_0. This guarantees that 500 mA is always available to the FLiP and other circuitry, regardless of what the FT231x might otherwise be provisioned to provide. It's an inelegant, brute-force solution -- but it works! Under battery power, my device no longer suffers from power interruptions.
The mystery remains, however, why the FTDI chip behaves the way it does, or what exactly spurs it to do so.
-Phil
The above work-around also solved the problem with the cheap charger and cable. Still, though, it's not very nice.
-Phil
That workaround is what I explained in post #8 above, and attached the original and updated FT-Prog templates for.
It seems quite reasonable for PC connection, where your application doesn't draw more than 100mA at startup, and if you need higher current you could always run via a powered hub. Or hold the reset button until you are ready to re-program over a power hungry bit of code! (Yeah, that's got to be a wild edge case)
For direct to battery charger / battery pack connection, I can't see why it matters. ie. Why is it "not very nice" ? Curious if you spotted something, or if your conclusion is rather for aesthetic reasons.
Ah, right! I guess I didn't understand it until I re-studied the schematic that Tracy posted, then re-derived it on my own. Sorry.
Mainly because it circumvents answering the question about why PWREN# and BCDCHG# pulse high at a regular rate under battery power when the IR source is enabled -- but not in sync with it turning on. That's just . . . crazy. I don't know what to make of it.
Also, it might mess with the power-up sequencing, assuming that's important.
-Phil
More weirdness: I'd been having intermittent problems with one of my CO2 sensors when the FLiP's USB was powered by a plug-in charger. Sometimes the SCD30's IR source would activate; other times, it would not. Unplugging and replugging the power enough times would finally get it to work. In both instances, checking the power on the SCD30's Vdd input showed a steady 3.29V with no glitches. (This is with the FT231X's C2 output set to Drive_0.) This behavior did not happen with the unit plugged into my PC's USB port.
By plugging and unplugging FLiPs and sensors, I was able to isolate the problem to one of the FLiP modules. But it's a mystery why that one module behaves differently than all the others with the same exact program, which ran up to the point it needed data from the SCD30. The program wouldn't matter anyway, since the SCD30 was programmed to take readings every two seconds on its own as soon as it powered up. You can tell when it's doing that by the glow from the incandescent IR source. But sometimes it did; other times not, regardless of which SCD30 was plugged in, and only with that one FLiP.
It's a head-scratcher.
-Phil