I have never seen this slow power up problem. Our PAD's (Personal Access Device's) are powered off the USB bus so
the FTDI cable is always connected. There is a shunt in the PAD that disconnects the RTS\ line from the FTDI cable
to the reset circuit. About 10-15% of the units we sell have to have this shunt removed because the customers PC's
keep reseting our PAD's.
I have never really understood why this happens, it seems to have something to do with how the PC's bios controls this
signal. We see it more with older PC's but sometimes the newest ones are also effected. Laptops seem to have more
trouble with this problem than desktops.
If the PC-USB is disconnected, is that some timer buried in FTDI, that can fire after a couple of minutes ?
It's got nothing to do with "slow power-up" or any kind of "timer." It's a consequence of a rising edge from the Prop's TX pin powering the FTDI chip parasitically, which produces an edge on DTR which, in turn, resets the Prop -- lather, rinse, repeat ad infinitum. Pull-ups "solve" the problem by keeping the FTDI chip powered all the time, not just when the Prop sets TX to an output and drives it high.
It's got nothing to do with "slow power-up" or any kind of "timer." It's a consequence of a rising edge from the Prop's TX pin powering the FTDI chip parasitically, which produces an edge on DTR which, in turn, resets the Prop -- lather, rinse, repeat ad infinitum. Pull-ups "solve" the problem by keeping the FTDI chip powered all the time, not just when the Prop sets TX to an output and drives it high.
-Phil
Does that only happen if vccio is not connected to the supply that feeds the prop?
...About 10-15% of the units we sell have to have this shunt removed because the customers PC's
keep reseting our PAD's.
I have never really understood why this happens, it seems to have something to do with how the PC's bios controls this
signal. We see it more with older PC's but sometimes the newest ones are also effected. Laptops seem to have more
trouble with this problem than desktops.
Does it happen when the user plugs something else into another USB port, or does it happen on a PC that appears in all respects to be simply idling windows ?
Does this happen on Serial a port you have open ? - if so, how does that PC intusion affect the Baud-settings ?
It's got nothing to do with "slow power-up" or any kind of "timer." It's a consequence of a rising edge from the Prop's TX pin powering the FTDI chip parasitically, which produces an edge on DTR which, in turn, resets the Prop -- lather, rinse, repeat ad infinitum. Pull-ups "solve" the problem by keeping the FTDI chip powered all the time, not just when the Prop sets TX to an output and drives it high.
-Phil
I can see parasitic power could be another issue, but that is not quite what #55 suggested to me with the words "If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes."
So if a system powers from 5V USB, or 5V system power, and also powers FTDI, parasitic power should not be an issue ?
Phil is correct, as usual... What I meant to say back then is that with the USB cable connected to a PC the FTDI chip is powered and so there is no problem.
But, if you disconnect the USB cable and you are running code that puts P30 or P31 as output and high, the FTDI chip will power up after a minute or two and initiate a reset...
Another solution, that I use, is to configure the FTDI chip for 5V I/O and use 10k series resistors on the TX and RX lines.
This combination seems to also prevent resets.
For finished projects I tend to use the Propeller Proto Board Serial or some other (custom) board that doesn't have the FTDI chip installed. I use the Prop Plug to program these boards. In this manner there is no issue and I don't have an extra IC drawing power from my project power supply (especially when using batteries).
Phil is correct, as usual... What I meant to say back then is that with the USB cable connected to a PC the FTDI chip is powered and so there is no problem.
But, if you disconnect the USB cable and you are running code that puts P30 or P31 as output and high, the FTDI chip will power up after a minute or two and initiate a reset...
So this minute or two means 'possibly, whenever the user code changes P30 or P31 to partially power the FTDI part', it is not meant to indicate some timer running ?
- or does the parasitic power have a delay in the FTDI part, so some time can elapse from P31 to RST ?
Another solution, that I use, is to configure the FTDI chip for 5V I/O and use 10k series resistors on the TX and RX lines.
This combination seems to also prevent resets.
I can see 10k is ok for FTDI to Prop CMOS in, but 10k could be marginal to drive against the FTDI pullup of 40k+ ?
It is just under Vil, so spends nearly all your logic margin...
I still have a question, is this using split supplies, where you've got a 3.3v regulator on the board, feeding the prop, and the FTDI running from USB with internal regulation?
If you tie 3v3/VCCIO on the FTDI to VDD on the prop, the FTDI should be half powered and not have a parasitic draw on the prop. The upside is that you can power the prop and program it without an external power supply.
That might be an option. I think Parallax makes there circuits under the idea that P31 and P30 can still be general purpose after boot. I think doing it that way would break that though... Not a big deal really though.
If you tie 3v3/VCCIO on the FTDI to VDD on the prop, the FTDI should be half powered and not have a parasitic draw on the prop. The upside is that you can power the prop and program it without an external power supply.
BTW, guys, this is pretty old stuff. Parallax has been aware of the issue for awhile now, and their newest designs include proper buffering to eliminate the problem without relying upon parasitic power via pull-ups.
Does it happen when the user plugs something else into another USB port, or does it happen on a PC that appears in all respects to be simply idling windows ?
Does this happen on Serial a port you have open ? - if so, how does that PC intusion affect the Baud-settings ?
Yes it does happen sometimes when someone plugs in another USB device, but not on all computers. It doesn't affect any of the serial
ports settings, it just causes the PC to send out an RTS\ pulse. Another thing we have seen is worn out USB connectors on the PC's,
any movement of the cable will cause an RTS\ signal to be generated.
Rayman,
Look at the "DC Input Voltage High Impedance Bi-directionals (powered from VCCIO)" under the "Absolute Maximum Ratings" on page 16 of version 1.1 of the FT231X datasheet. It is "-0.3 to +5.8" volts. Contrast that with the "DC Input Voltage High Impedance Bidirectionals" on page 17 of version 2.10 of the FT232R datasheet, which is "-0.5 to +(VCC +0.5)" volts.
If the voltage on the I/O pins of the FT231X is between -0.3 and 5.8 volts, it wont alter the behavior of the FT231X, regardless of the voltage on VCC. With the FT232R, the voltage on the I/O pins needs to be between -0.5 volts and VCC + 0.5 volts. When VCC is zero, any voltage on the I/O pin above 0.5 volts is outside of the absolute maximum ratings and can cause undesired operation, in this case powering up and toggling DTR.
Good, so that means the newer FT23nX have removed a clamp diode, present on the FT232R.
I cannot see a number for Iin when Vcc = 0 (or ~0?) , - ie for those battery application users, with the clamp diode gone, what load does an unpowered FT23nX present to a Prop pin driving HI ?
David, Thanks for the explaination. I'm pretty happy with my FT232RL solution now, but the new chip does sound a lot better...
BTW: I don't really know for sure why the way I'm doing it (FT232RL with 5V I/O and 10k resistors) works... Maybe it's the 5V I/O, maybe it's the 10k resistors... maybe both... I have tested it until my patience wore out and didn't see a reset though...
BTW2: If someone has actually tested the new chip and found it to be immune to this bug, I'd really like to hear that...
Just an FYI....
When I was playing with Tachyon Forth and PropForth, I set up an ANSI Terminal with a second Propeller and seemed to run into this bug in the context of one of the terminal applications I used.
PockeTerm has a two serial port scheme that seemed to become unstable. I had to use Jeff Ledger's (aka Oddbitcollector) scheme with one RS232 port in order to avoid problems.
But that version requires recompile to change baud rate and such. I'd rather have all the flex of the PockeTerm without the two ports, but haven't gotten into hacking that code.
There also seems to be PropTerm that I have yet to investigate. At the time, I only found two options avalable. There may be a lot more.
With so much varied product out there. I suspect that if you want a ANSI Terminal, it is best to stay away from trying to communicate on Pin 30 and Pin 31 if a USB interface is intended.
Comments
the FTDI cable is always connected. There is a shunt in the PAD that disconnects the RTS\ line from the FTDI cable
to the reset circuit. About 10-15% of the units we sell have to have this shunt removed because the customers PC's
keep reseting our PAD's.
I have never really understood why this happens, it seems to have something to do with how the PC's bios controls this
signal. We see it more with older PC's but sometimes the newest ones are also effected. Laptops seem to have more
trouble with this problem than desktops.
-Phil
Does that only happen if vccio is not connected to the supply that feeds the prop?
Does it happen when the user plugs something else into another USB port, or does it happen on a PC that appears in all respects to be simply idling windows ?
Does this happen on Serial a port you have open ? - if so, how does that PC intusion affect the Baud-settings ?
"If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes."
So if a system powers from 5V USB, or 5V system power, and also powers FTDI, parasitic power should not be an issue ?
But, if you disconnect the USB cable and you are running code that puts P30 or P31 as output and high, the FTDI chip will power up after a minute or two and initiate a reset...
Another solution, that I use, is to configure the FTDI chip for 5V I/O and use 10k series resistors on the TX and RX lines.
This combination seems to also prevent resets.
So this minute or two means 'possibly, whenever the user code changes P30 or P31 to partially power the FTDI part', it is not meant to indicate some timer running ?
- or does the parasitic power have a delay in the FTDI part, so some time can elapse from P31 to RST ?
I can see 10k is ok for FTDI to Prop CMOS in, but 10k could be marginal to drive against the FTDI pullup of 40k+ ?
It is just under Vil, so spends nearly all your logic margin...
This winds up taking a minute or two.
If you tie 3v3/VCCIO on the FTDI to VDD on the prop, the FTDI should be half powered and not have a parasitic draw on the prop. The upside is that you can power the prop and program it without an external power supply.
That works perfectly for me.
-Phil
Did you mean FTDI data ?
The sheet I have open here (FT230X) says this
Rpu Input pull-up resistance 40k Min 75k Typ 190k Max @ Vin = 0
The FT230X is a newer, lower cost and smaller version. I was about to try them when they got recalled, but maybe they're all fixed now.
I've heard that the FT230X may be immune to this parasitic start-up bug. If so, this whole topic may not apply.
Like Phil said, this is an old topic that Parallax has addressed in their newer boards.
Yes it does happen sometimes when someone plugs in another USB device, but not on all computers. It doesn't affect any of the serial
ports settings, it just causes the PC to send out an RTS\ pulse. Another thing we have seen is worn out USB connectors on the PC's,
any movement of the cable will cause an RTS\ signal to be generated.
Look at the "DC Input Voltage High Impedance Bi-directionals (powered from VCCIO)" under the "Absolute Maximum Ratings" on page 16 of version 1.1 of the FT231X datasheet. It is "-0.3 to +5.8" volts. Contrast that with the "DC Input Voltage High Impedance Bidirectionals" on page 17 of version 2.10 of the FT232R datasheet, which is "-0.5 to +(VCC +0.5)" volts.
If the voltage on the I/O pins of the FT231X is between -0.3 and 5.8 volts, it wont alter the behavior of the FT231X, regardless of the voltage on VCC. With the FT232R, the voltage on the I/O pins needs to be between -0.5 volts and VCC + 0.5 volts. When VCC is zero, any voltage on the I/O pin above 0.5 volts is outside of the absolute maximum ratings and can cause undesired operation, in this case powering up and toggling DTR.
David Carrier
Parallax Inc.
I cannot see a number for Iin when Vcc = 0 (or ~0?) , - ie for those battery application users, with the clamp diode gone, what load does an unpowered FT23nX present to a Prop pin driving HI ?
BTW: I don't really know for sure why the way I'm doing it (FT232RL with 5V I/O and 10k resistors) works... Maybe it's the 5V I/O, maybe it's the 10k resistors... maybe both... I have tested it until my patience wore out and didn't see a reset though...
BTW2: If someone has actually tested the new chip and found it to be immune to this bug, I'd really like to hear that...
When I was playing with Tachyon Forth and PropForth, I set up an ANSI Terminal with a second Propeller and seemed to run into this bug in the context of one of the terminal applications I used.
PockeTerm has a two serial port scheme that seemed to become unstable. I had to use Jeff Ledger's (aka Oddbitcollector) scheme with one RS232 port in order to avoid problems.
But that version requires recompile to change baud rate and such. I'd rather have all the flex of the PockeTerm without the two ports, but haven't gotten into hacking that code.
There also seems to be PropTerm that I have yet to investigate. At the time, I only found two options avalable. There may be a lot more.
ANSI Terminal apps known by me.
PockeTerm for Briel http://www.brielcomputers.com/wordpress/?cat=25
PropTerm http://www.shaels.net/index.php/propterm
Jeff Ledger's code http://n8vem-sbc.pbworks.com/w/page/4200926/Propeller-VT100-Compatible-Terminal
With so much varied product out there. I suspect that if you want a ANSI Terminal, it is best to stay away from trying to communicate on Pin 30 and Pin 31 if a USB interface is intended.