Is there a list of boards that have this "feature"?
The ones that I know of (or can infer from the schematic) are:
Propeller Demo Board
Propeller USB Proto Board
Propeller Professional Development Board
Propeller C3
Gadget Gangster Propeller Platform USB
Propeller Servo Controller USB
PropStick USB
Also any board that requires a Prop Plug or Prop Clip which does not have P30 and/or P31 pulled up will exhibit this behavior.
Boards without an FTDI chip on them have an obvious solution... Remove the PropPlug when done programming.
I think that's what everybody did before we know for sure what the problem was.
BTW: You can also solve the problem on the software side by just checking the RX line for high to make sure PC is connected before starting your serial driver...
This thread is from quite a while ago, and there are some newer ones that go in more depth about what the problem is and how to solve it, but in a nutshell, the I/O pins on the FT232R are rated for input voltages up to Vdd + 0.5 V. If the device is unplugged Vdd will essentially be 0 V, which means that any outputs from the Propeller's transmit pin are outside of the FT232R's specifications, which can cause undesired behavior. In this case, it is partially powering the FT232R which causes it to go through its start-up sequence, which toggles the DTR pin and resets the Propeller.
Our newer boards, such as the QuickStart development board, have buffers between the Propeller and the FT232R that prevent this from occurring. We may switch to the new FT231X, which is tolerant of up to 5.8 V on its input pins when unpowered, which would also eliminate the problem.
We may switch to the new FT231X, which is tolerant of up to 5.8 V on its input pins when unpowered, which would also eliminate the problem.
So the inputs to the FT213X must look like LVC logic then, without the protection diodes to VCCIO? Unless its outputs are open-drain, you will still need an output buffer to keep a powered FT213X chip from powering an unpowered Prop through its protection diodes.
I just found this (I think this is how it works):
For a self-powered configuration it is necessary to prevent current from flowing back to the USB data lines when the connected USB host or hub has powered down. To carry out this function the UMFT231XA uses an on-board voltage divider network connected to the USB power bus and RESET# pin. This operates on the principle that when no power is supplied to the VBUS line, the FT231X will automatically be held in reset by a weak pull-down, when power is applied the voltage divider will apply a weak 3.3V pull-up. Driving a level to the RESET# pin of the UMFT231XA will override the effect of this voltage divider. When the FT231X is in reset the USB DP signal pull-up resistor connected to the data lines is disconnected and no current can flow down the USB lines.
Actually, I don't see why this wouldn't work on FT232RL too... They actually show this in the FT232RL datasheet too...
If that's all they've done, it might not solve the problem at hand. Their only objective appears to be protecting the USB bus. That may not prevent voltage migration from the data I/O lines through VCCIO to DTR.
DTR has to go through a capacitor and then drive a transistor to force a restart. I don't think a slowly bleeding up signal would do that...
I thought the FTDI was actually powering up and toggling DTR...
I guess it would be easy enough to figure out which mechanism is at play: cut the connection between 3V3OUT and VCCIO and see if it still happens.
-Phil
My experience is that it works much better if VDDIO is provided from a separate regulator that has USB 5V as the input. I don't even connect 3V3OUT - works great.
I ran VDDIO at 5V and used resistors on RX and TX and had no problems too.
But, Phil's way is on the Quickstart and I haven't heard of this problem there, so that is a sound solution too.
Still, if two resistors on the reset line do this too and also protect the USB lines, maybe that's better...
On second though, maybe we don't know for sure about Quickstart, because everybody is using it in "USB Bus Powered" mode...
It's only the "Self-Powered" mode that has issues. And actually, the datasheet says that these resistors on the reset signal are required in "Self-Powered" mode.
The FT231X datasheet says the same thing, except the resistors feed a "VBus Sense" input instead of "reset".
On second though, maybe we don't know for sure about Quickstart, because everybody is using it in "USB Bus Powered" mode...
It's only the "Self-Powered" mode that has issues. And actually, the datasheet says that these resistors on the reset signal are required in "Self-Powered" mode.
The FT231X datasheet says the same thing, except the resistors feed a "VBus Sense" input instead of "reset".
I use the resistors ... I've been tempted though
My next design will get rid of it altogether, lower the cost, allow better flexibility, and provide other advantages.
Based on the Quickstart schematic, I can state categorically that it will not exhibit the reset bug when self-powered. The reason is that the LVC buffer is powered from VCCIO, not the Prop's 3.3V supply. And LVC logic does not power up or pass spurious inputs to its outputs unless powered through its supply pin.
Based on the Quickstart schematic, I can state categorically that it will not exhibit the reset bug when self-powered. The reason is that the LVC buffer is powered from VCCIO, not the Prop's 3.3V supply. And LVC logic does not power up or pass spurious inputs to its outputs unless powered through its supply pin.
-Phil
Too bad the Quickstart buffer sets up an oscillator when Propeller P30 is kept as an un-driven input.
I've always advocated for 4.7K pull-ups on P28..P31. Just one two-cent quad-pack resistor is all it takes. Even without the buffer, it will cure the reset problem, too, but not in a very nice way.
Ok then the LVC buffer should also prevent any power getting to the USB pins and therefore achieve the same goal as the resistors on the reset line.
(unless there's some other path for power to get to the FT232RL chip).
I still don't see anything in the FT231X datasheet about the pins being more tolerant to voltage when in self-powered mode.
David Carrier, can you tell us more about this? Is this from the datasheet or from talking to FTDI?
I've always advocated for 4.7K pull-ups on P28..P31. Just one two-cent quad-pack resistor is all it takes. Even without the buffer, it will cure the reset problem, too, but not in a very nice way.
-Phil
I remember you mentioned that once, and i agree with it entirely. I was also told that the resistors were intentionally left out as a feature - that is, you can have more pins available without interference from on board pull ups. To me abusing the natural definition of the pins is just a recipe for more RMA where there is margin for none. This is just my opinion.
P30 and P31 would be connected to COM1 and COM2, The FT232 and <your circuit> would use NOx and NCx. IN1 and IN2 could be connected to the FT232 #PWREN output (CBUS3 I think). The idea is when the USB cable is connected for programming, P30 and P31 would be only connected to the FT232. When running self powered, or powered from a 'dumb' USB wal-wart, P30 and P31 would be only connected to <your circuit>. The drawback is you could not have <your circuit> connected to the FT232 at any point.
One of the problems with the FTDI USB converter is actually a problem with the way the PC handles the RTS\ line.
Sometimes in older PC's with noisy power there are random RTS\ signals that will reset the Propeller chip. You
can go into the advanced settings on the converter and "disable modem controls at start up" but this does not
always solve the problem.
We had to put a dip switch in our PoS terminal's to disable the RTS signal. In an old lab that we had, every
time you would turn on the room lights the PC would send out a couple of pulses and reset our product's.
Yes, this "bug" caused a lot of grief... If you leave your USB board connected to a computer, it will reset the Prop whenever the PC feels like resetting the USB bus..
If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes.
Like BigFoot said, putting in a physical switch on the reset line is the only 100% solution when you have a FTDI chip on the board.
If you have a Prop Plug, you just need to remove the Prop Plug...
Another fix is to put a pulse width discriminator in the reset circuit. This can be done by putting a resistor
in series with the capacitor that drives the base of the transistor.
I have a thread on this too a few months back, its very annoying adding some pull ups to the i2c buss for the eeprom fixed it for me. Now it only resets when i plug or unplug my usb cable to the prop plug...
let me guess constantly restarts every 10 seconds......
One of the problems with the FTDI USB converter is actually a problem with the way the PC handles the RTS\ line.
Sometimes in older PC's with noisy power there are random RTS\ signals that will reset the Propeller chip. You
can go into the advanced settings on the converter and "disable modem controls at start up" but this does not
always solve the problem.
We had to put a dip switch in our PoS terminal's to disable the RTS signal. In an old lab that we had, every
time you would turn on the room lights the PC would send out a couple of pulses and reset our product's.
mine does it on a brand new alienware laptop.... ;x
I've always advocated for 4.7K pull-ups on P28..P31. Just one two-cent quad-pack resistor is all it takes. Even without the buffer, it will cure the reset problem, too, but not in a very nice way.
-Phil
^ THis, his same suggestion in my thread a few months ago fixed me..
Yes, this "bug" caused a lot of grief... If you leave your USB board connected to a computer, it will reset the Prop whenever the PC feels like resetting the USB bus..
If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes.
Like BigFoot said, putting in a physical switch on the reset line is the only 100% solution when you have a FTDI chip on the board.
If you have a Prop Plug, you just need to remove the Prop Plug...
I see this is from a little while ago, but I cannot find explicit mention of If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes.
If the PC-USB is disconnected, is that some timer buried in FTDI, that can fire after a couple of minutes ?
How long do I need to wait, to check for this, and which FTDI pins/parts are affected ?
The new 230X have this option, should bleed out any slow power build-ups.
Though maybe different outcome if self powered or bus powered.
Internal MTP Memory Configuration:
Pull down I/O Pins in USB Suspend (defualt state: Disabled)
Enabling this option will make the device pull down (75k) on the UART interface lines when in USB suspend mode (PWREN# is high).
Comments
Propeller USB Proto Board
Propeller Professional Development Board
Propeller C3
Gadget Gangster Propeller Platform USB
Propeller Servo Controller USB
PropStick USB
Also any board that requires a Prop Plug or Prop Clip which does not have P30 and/or P31 pulled up will exhibit this behavior.
-Phil
I think that's what everybody did before we know for sure what the problem was.
BTW: You can also solve the problem on the software side by just checking the RX line for high to make sure PC is connected before starting your serial driver...
Our newer boards, such as the QuickStart development board, have buffers between the Propeller and the FT232R that prevent this from occurring. We may switch to the new FT231X, which is tolerant of up to 5.8 V on its input pins when unpowered, which would also eliminate the problem.
— David Carrier
Parallax Inc.
-Phil
For a self-powered configuration it is necessary to prevent current from flowing back to the USB data lines when the connected USB host or hub has powered down. To carry out this function the UMFT231XA uses an on-board voltage divider network connected to the USB power bus and RESET# pin. This operates on the principle that when no power is supplied to the VBUS line, the FT231X will automatically be held in reset by a weak pull-down, when power is applied the voltage divider will apply a weak 3.3V pull-up. Driving a level to the RESET# pin of the UMFT231XA will override the effect of this voltage divider. When the FT231X is in reset the USB DP signal pull-up resistor connected to the data lines is disconnected and no current can flow down the USB lines.
Actually, I don't see why this wouldn't work on FT232RL too... They actually show this in the FT232RL datasheet too...
If that's all they've done, it might not solve the problem at hand. Their only objective appears to be protecting the USB bus. That may not prevent voltage migration from the data I/O lines through VCCIO to DTR.
-Phil
I thought the FTDI was actually powering up and toggling DTR...
For my money, though, the external buffers are so cheap and so small, it's almost silly to omit them.
-Phil
My experience is that it works much better if VDDIO is provided from a separate regulator that has USB 5V as the input. I don't even connect 3V3OUT - works great.
But, Phil's way is on the Quickstart and I haven't heard of this problem there, so that is a sound solution too.
Still, if two resistors on the reset line do this too and also protect the USB lines, maybe that's better...
It's only the "Self-Powered" mode that has issues. And actually, the datasheet says that these resistors on the reset signal are required in "Self-Powered" mode.
The FT231X datasheet says the same thing, except the resistors feed a "VBus Sense" input instead of "reset".
I use the resistors ... I've been tempted though
My next design will get rid of it altogether, lower the cost, allow better flexibility, and provide other advantages.
-Phil
Too bad the Quickstart buffer sets up an oscillator when Propeller P30 is kept as an un-driven input.
-Phil
(unless there's some other path for power to get to the FT232RL chip).
I still don't see anything in the FT231X datasheet about the pins being more tolerant to voltage when in self-powered mode.
David Carrier, can you tell us more about this? Is this from the datasheet or from talking to FTDI?
I remember you mentioned that once, and i agree with it entirely. I was also told that the resistors were intentionally left out as a feature - that is, you can have more pins available without interference from on board pull ups. To me abusing the natural definition of the pins is just a recipe for more RMA where there is margin for none. This is just my opinion.
P30 and P31 would be connected to COM1 and COM2, The FT232 and <your circuit> would use NOx and NCx. IN1 and IN2 could be connected to the FT232 #PWREN output (CBUS3 I think). The idea is when the USB cable is connected for programming, P30 and P31 would be only connected to the FT232. When running self powered, or powered from a 'dumb' USB wal-wart, P30 and P31 would be only connected to <your circuit>. The drawback is you could not have <your circuit> connected to the FT232 at any point.
Sometimes in older PC's with noisy power there are random RTS\ signals that will reset the Propeller chip. You
can go into the advanced settings on the converter and "disable modem controls at start up" but this does not
always solve the problem.
We had to put a dip switch in our PoS terminal's to disable the RTS signal. In an old lab that we had, every
time you would turn on the room lights the PC would send out a couple of pulses and reset our product's.
If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes.
Like BigFoot said, putting in a physical switch on the reset line is the only 100% solution when you have a FTDI chip on the board.
If you have a Prop Plug, you just need to remove the Prop Plug...
in series with the capacitor that drives the base of the transistor.
let me guess constantly restarts every 10 seconds......
mine does it on a brand new alienware laptop.... ;x
^ THis, his same suggestion in my thread a few months ago fixed me..
I see this is from a little while ago, but I cannot find explicit mention of If you disconnected your USB board from the computer, this slow powerup bug could reset your prop after a couple minutes.
If the PC-USB is disconnected, is that some timer buried in FTDI, that can fire after a couple of minutes ?
How long do I need to wait, to check for this, and which FTDI pins/parts are affected ?
Though maybe different outcome if self powered or bus powered.
Internal MTP Memory Configuration:
Pull down I/O Pins in USB Suspend (defualt state: Disabled)
Enabling this option will make the device pull down (75k) on the UART interface lines when in USB suspend mode (PWREN# is high).