Call for comments for a USB-Plug with 3.3V source

Joerg

Hi
since i have noticed, that (maybe) there is a certain request for a USB-device with a voltage regulator on board,
i have done the schematics and layout for it (EAGLE! see the red and green lines). The next step is to create a little
PCB to put to plugs on it having so the possibility to run the prop tool on one USB interface and a other USB interface
for communicating after downloading.

Any comments are welcome

Saluti Joerg

Phil Pilgrim (PhiPi)

I'm glad to see somebody is finally paying attention to the soft-start requirements for USB-powered devices! Unfortunately, the circuit recommended by FTDI is nearly worthless for this purpose — especially with the FT232R, which has a power-on glitch on its /PWREN pin. I wrestled with these issues through sixteen iterations of the MoBoStamp-pe before I found a circuit that works reliably. The resulting schematic can be seen at the end of the MoBo docs. The soft-start circuit used is derived from one that I found in a Texas Instruments app note. I added the Microchip voltage detector both to delay past the FT232R's startup glitch and to cut off power to the downstream circuit in case of an overload, which would otherwise drag down the USB supply voltage and reset the the FT232R.

Whatever you do, I recommend that you don't go right to a production PCB, but spend some time with either a breadboard or proto PCB and a scope to fine-tune this important part of your circuit.

-Phil

deSilva

With some boards, I am using the 4D Plug which is (much) more affordable than the Parallax Plug, and has the 5V on a pin. As it has some disadvantages we will not use it for the next class however...

The 5V are nice as well for the breadboard as for some veroboard buid-ups. As most things should run stand -alone eventually they will be powered by 4.8 to 6 Volts, be it from the 4D plug or from an external battery, but thus ned a regulator anyhow..

On the other hand I also build a small "all-in-one-bridge" fitting on top of a breadboard inserted Propeller to minimize wiring... There is a small DPAK regulator on it.

Well, what I wanted to say: Yes and no... It could be nice, depending on the circumstances..

N.B.: Header Pins.. After a lot of experiences with fitting and unfitting things onto solderless breadboards, I should recomend you use double row headers. It will become much more robust.

Post Edited (deSilva) : 1/6/2008 8:25:02 PM GMT

Joerg

Thaks for the comments.

@Phil:
- I have attached three pdf files with a simulation of the Power On sequence. If the PWREN# pin of the device is set as
input there is the possibility of a spike (ON.pdf) adding a resistor (R4=4.7k) makes it almost disappearing (ON1.pdf).
Is it this effect you meant?

- Since i have a LPKF milling machine i can mill my prototypes by myself! This saves a lot of costs, time and nerves!


@deSilva:
- i will change the socket to a 2x5row type.

Saluti Joerg

Phil Pilgrim (PhiPi)

Joerg,

I think I tried the pullup, but didn't get as satisfactory results as your simulation indicates. But there's a bigger problem, as I hinted at in my prior post: Upon powerup, PWREN# does not stay high until the FT232R is enumerated, but pulses low multiple times during the chip's reset sequence, rendering its intended function nearly useless. The reason this occurs in the 'RL but not the 'BM version is that in the 'RL PWREN# is assigned to a general-purpose I/O pin, which has to be configured as part of the reset sequence. This is one reason I resorted to the voltage detector circuit: to delay past the low pulses.

Below, I've attached some GIFs of the PWREN# line during powerup and enumeration for you to look at, with detailed views of the pulses I referred to...

-Phil

Addendum: Here's a transcript of my exchange with FTDI tech support:

Q (from me): Have you experienced this multiple-pulse behaviour on PWREN#?

A (from FTDI): Yes the behaviour you recorded is what we expect to happen.

Q: Do you have an explanation for it?

A: The low pulses are due to the device resetting due to its initialisation
sequence. When the device resets the CBUS pins go low. 

Q: Is there a way to get rid of it?

A: Unfortunately there is no work around for this issue.

Then later, from FTDI:

I have spoken to the Hardware engineer responsible for the FT232R. The
reason PWREN# behaves differently to the FT232BM device is because the pin
is programmable. In the BM device the PWREN pin is hard wired. The engineer
tells me it is not was not intentional that the PWREN# pulses low in reset
but is a side effect from resetting the chip. 

A possible work around is to use the SLEEP# signal in conjunction with the
PWREN#. This could done using a P-type FET controlled by SLEEP# connected
between the base and source (BUS power) of the FET used in the soft start
circuit. SLPEEP# is low in USB suspend so when the device is reset the CBUS
pin will remain low. 

The engineer is looking further into the issue and purposed work around.

And finally,

Our Engineering department have tested and proposed the circuit attached as
a work around to the PWREN# signal issue. The SLEEP# signal always leads
PWREN# so will turn of USB power quicker. A USB device can draw up to 100mA
at power, after enumeration it can then draw up to its power descriptor.

Here is the circuit they proposed:



I tried it, and responded thus:

I tried your workaround, and it appears to do the job, even though about 
1.9V is able to sneak through the softstart switch ahead of time 
somehow. There are also errant positive pulses on SLEEP#, by the way, 
but I'm unable to detect any cases where PWREN# is low and SLEEP# is 
high simultaneously before enumeration is complete. Nonetheless, there 
are some VERY close calls!

Those close calls concern me somewhat, in that process variations or 
future silicon revs may cause them to overlap at some point down the 
road. (They're not spec'd after all.) Some commentary from engineering 
on this possibility would be helpful.

Also, if one is using FTDI's softstart circuit, there's the concern 
about PWREN# pulling against that 1K resistor, while the other end is 
clamped to Vcc by the additional PMOS. This may result in 5mA current 
spikes when the USB bus can't provide that much. (I'm using a slightly 
different circuit with a 47K resistor, so that wasn't a factor here.)

I have no record of an answer to this last email. Anyway, that's when I decided the voltage detector route was the safest one.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 1/7/2008 6:35:51 PM GMT

Joerg

Dear Phil

During my monthly sensor collecting trip in the woods of southern Switzerland i was thinking of the problems with the PWREN# line.

Conclusion: One problem is, that the PWREN# line goes at maximum of 3.3V as the VCCIO is set to this level and second if the d.. chip is doing "flippering", why not eliminate these pulses by blanking them out like you do it with the supervisory chip?

A result of my brain burning action you can see in the pdf's.

The vantage of my solution is that i use standard parts only and i am blanking short pulses (where ever they may come from!).




Saluti Joerg

Phil Pilgrim (PhiPi)

What you propose looks like it could work, and I can well understand your desire to use plain vanilla parts. However, one additional advantage that the supervisor chip confers is a limited amount of hot-plugging capability. This occurs after the FT232RL is enumerated and power has been turned on, when a step load (such as a board with a large filter cap) is plugged in. In such a situation, V_cc(USB) will dip in response to the transient overload. The supervisor will catch the dip and disconnect power temporarily from the downstream load before the USB supply voltage dips far enough to reset the FT232RL. I'm not claiming it's an adequate replacement for a fuse, but I've been able to dead-short the downstream V_dd on the MoBoStamp without harm to the USB circuitry and, in most such cases, the supervisor responds fast enough to avoid resetting the chip. In a dead short situation, the supervisor continues trying to connect power, at its built-in delay interval, but shuts off immediately when the USB supply drops below 4V.

One caveat, of course, is that if a heavy enough load were hot-connected that it's filter capacitor completely drained during the "off" time, it would not be possible to charge the cap sufficiently to stay "on". I've never seen an instance of this in my testing, however.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 1/8/2008 7:54:17 PM GMT

Joerg

Thanks Phil

I will make the layout with my solution and since i have my on "PCB factory" in house i do not spend a lot (time only; i hope).
As soon as i have built up i will report the case.

Saluti Joerg

Javalin

Although to chip in here, I was reading a maxim app note recently on USB battery Lipo charging - challenges etc.

To quote the article (link below) - the bottom section - the interestingly titled "What Your Mom Didn't Tell You About USB":

·-> USB ports do NOT limit current.

·->USB Ports rarely (never) turn off power: The USB spec is not specific about this

So argumentatively you can draw (almost) what you want going by that....?· Hummm....

http://www.maxim-ic.com/appnotes.cfm/appnote_number/3241

I thought it was an interesting article anyway - and my Mum has never told me anything about USB anyway..!

Good forum post/topic though.

James

Joerg

Here the newest version of USB-SCI-P interface.

to James: have you ever tried to put you PC into standby mode with a USB powered device (i.e. simple charger for phones) running?
-> my acer does not go to sleep when i have UMDL with the propeller MCU running. So the new design will resolve these problems.

Saluti Joerg

Javalin

Joerg,

Nope - cannot say I have.

Good stuff.

James

Joerg

OK it did take some time but here the results:

- After some fine tuning (or even some coarse t..) the circuit seems to work!


The updated schematics is attached and here the measurements of /PWREN (red) and the output of the PFET (blue)
(the timescale is 250ms/unit, y is 2V/unit).




Saluti Joerg

Post Edited (Joerg) : 1/28/2008 9:07:21 PM GMT

Rayman

Just want to comment here that I found the FTDI circuit to work even with the glitch mentioned here. I've added enough load to draw 430 mA, and tested it with several computers and it works fine. Works fine with a full size laptop.· Also, it shuts of power as it should when a computer is put to "sleep".

There was one interesting thing with new netbook... Netbook would not recognize the FTDI chip until I dropped the load to under 200 mA. But, once it recognized the FTDI chip for the first time, it was fine with the full load upon later connections.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm