Propeller Proto Board - Fails to Boot Without USB Cable Connected
Greg P
Posts: 58
OK, This is an odd one. I'm hoping someone on the forum has encountered this problem before and can offer some sage advice. I know I'm providing a lot of detail up front, but from my experience, the more information about a particular problem a reader has the better able he is to craft a good answer. Bare with me please ...
I'm using the Propeller Proto Board (with USB, part#32812), to control an old XYZ stepper controller. The stepper controller has a well regulated 5v supply that I'm using to power-up the Proto Board (I'm attaching the +5v source between the 5v and 3.3v regulators (I've tested up to a 7v input at this point and the 5v regulator (with no input voltage attached) did not interfere by unexpectedly drawing current through its output pin.)
As long as I have the USB cable from the PC attached to the Proto Board my firmware on the Propeller boots normally following application of +5v power from the controller. The USB cable can be detached at this point, and the Propeller will continue executing normally, driving the stepper motors as expected.
If I remove the USB cable prior to power-up, the Propeller will not boot at all when the +5v supply is activated ! Even more oddly, I can press the small reset button on the board, and it will fail to reboot the Propeller ! I can monitor the RESET pin at the Propeller itself and see the active-low voltage drop on my oscilloscope. When I examine a clock line output signal (which should be commanding the steppers), it is not active (as it would be normally) clearly suggesting my firmware is not executing.
I observed that with the USB cable attached and no +5v power being supplied to the Propeller, the Propeller's Vdd input pin is driven to about 0.6 volts. At the same time, the RESET line to the Propeller is at about 0.3 volts.
My attention turned to the Propeller RX (p31) and Propeller TX (p30) line to see if there was any activity on them during the time the Propeller was apparently inactive. To my surprise, the Propeller TX line was active in a very odd way:
Every 2 seconds, it would go high (to 3.3v) for about 750mS. The rising edge of this pulse appeared to have a few bits of data at just a few volts amplitude (close to the 115K baud rate I'm using), followed by a gradual rise to 3.3v over about 0.25 mS. The pulse stays high for the next 750mS, then drops quickly to 2v, before exponentially decaying to 0v over about 20mS. I should note that my firmware is programmed to move back and forth a few inches with a 2 second pause between reversals in direction. The duration of each movement in a single direction is about 8 seconds or so.
Before using the Proto Board, I had constructed a very similar circuit on a garden-variety protoboard using a 40-pin DIP Propeller. That circuit behaved as expected. The differences between the two circuits:
1) The Proto Board attached its BOEn pin to ground, enabling brown-out detection. My 40pin DIP circuit had BOEn attached to +5v, disabling it, and eliminating the internal 5K pullup.
2) I used a 2K resistor between the TX(propeller) and RX(USB2Ser adapter), and another 2K resistor between the RX(propeller) and TX(USB2Ser adapter). On the Proto Board With USB, the schematic shows that there is a direct connection between the FT232RQ and the Propeller on its RX and TX lines.
3) The Proto Board, with its BOEn pin grounded, activates the Propeller's internal 5K resistor to Vdd at its reset pin input. I had used a DS1233-10 reset IC (5v version in stock) to guarantee a 350mS active-low pulse at the Propeller's reset pin input at power-up in my original 40pin DIP circuit. It has an internal 5K pullup transistor to the +5v supply, which limits current from the +5v supply through the reset pin of the propeller. That worked because BOEn was attached to the +5v supply, and the brown-out circuit's 5K pullup to the +3.3v supply was disabled, and the reset pin interface behaved as an ordinary CMOS input. Unfortunately, with BOEn grounded, you have a path from the DS1233-10 (via its 5K pull up to +5v) to the Propeller (via its 5K pull up to its +3.3v), that draws current, and drops voltage across the DS1233-10's internal 5K pullup, potentially triggering the DS1233-10 "trip voltage" sensor of 4.375v. I ended up having to add a non-inverting buffer with an open-drain output between the DS1233-10 output and the Propeller reset pin. On an oscilloscope all looks great ! The DS1233-10 is NOT generating unexpected RESET pulses. This modification to the design seems unrelated to my particular problem. In fact, the addition of the buffer was an attempt to remove any possible effects the DS1233 may have been causing. That eliminated ... the problem persists.
HERE'S MY BEST IDEA (SO FAR) :
The FT232RQ chip when disconnected from its USB cable, has its Vcc line at ground potential, and any voltages applied externally to the FT232RQ's RXD or TXD lines would likely be clamped to within a diode drop of ground. The Propeller tries to boot (or run my firmware which uses the Propeller TX line also), but the powered-off FT232RQ clamps this output voltage, and perhaps triggers the Propeller's brown-out detection circuit which initiates a full reboot operation, and the cycle repeats.
Is this why I see on the forum recommendations to include the 2K resistors in series with the TX and RX lines ?
Some might say that no activity by the Propeller until after its properly connected to its controlling PC is a "design feature", but its behavior is marginal at best and I would like to determine a clear explanation for this "odd" behavior.
Any help anyone may be able to offer would be greatly appreciated !
I'm using the Propeller Proto Board (with USB, part#32812), to control an old XYZ stepper controller. The stepper controller has a well regulated 5v supply that I'm using to power-up the Proto Board (I'm attaching the +5v source between the 5v and 3.3v regulators (I've tested up to a 7v input at this point and the 5v regulator (with no input voltage attached) did not interfere by unexpectedly drawing current through its output pin.)
As long as I have the USB cable from the PC attached to the Proto Board my firmware on the Propeller boots normally following application of +5v power from the controller. The USB cable can be detached at this point, and the Propeller will continue executing normally, driving the stepper motors as expected.
If I remove the USB cable prior to power-up, the Propeller will not boot at all when the +5v supply is activated ! Even more oddly, I can press the small reset button on the board, and it will fail to reboot the Propeller ! I can monitor the RESET pin at the Propeller itself and see the active-low voltage drop on my oscilloscope. When I examine a clock line output signal (which should be commanding the steppers), it is not active (as it would be normally) clearly suggesting my firmware is not executing.
I observed that with the USB cable attached and no +5v power being supplied to the Propeller, the Propeller's Vdd input pin is driven to about 0.6 volts. At the same time, the RESET line to the Propeller is at about 0.3 volts.
My attention turned to the Propeller RX (p31) and Propeller TX (p30) line to see if there was any activity on them during the time the Propeller was apparently inactive. To my surprise, the Propeller TX line was active in a very odd way:
Every 2 seconds, it would go high (to 3.3v) for about 750mS. The rising edge of this pulse appeared to have a few bits of data at just a few volts amplitude (close to the 115K baud rate I'm using), followed by a gradual rise to 3.3v over about 0.25 mS. The pulse stays high for the next 750mS, then drops quickly to 2v, before exponentially decaying to 0v over about 20mS. I should note that my firmware is programmed to move back and forth a few inches with a 2 second pause between reversals in direction. The duration of each movement in a single direction is about 8 seconds or so.
Before using the Proto Board, I had constructed a very similar circuit on a garden-variety protoboard using a 40-pin DIP Propeller. That circuit behaved as expected. The differences between the two circuits:
1) The Proto Board attached its BOEn pin to ground, enabling brown-out detection. My 40pin DIP circuit had BOEn attached to +5v, disabling it, and eliminating the internal 5K pullup.
2) I used a 2K resistor between the TX(propeller) and RX(USB2Ser adapter), and another 2K resistor between the RX(propeller) and TX(USB2Ser adapter). On the Proto Board With USB, the schematic shows that there is a direct connection between the FT232RQ and the Propeller on its RX and TX lines.
3) The Proto Board, with its BOEn pin grounded, activates the Propeller's internal 5K resistor to Vdd at its reset pin input. I had used a DS1233-10 reset IC (5v version in stock) to guarantee a 350mS active-low pulse at the Propeller's reset pin input at power-up in my original 40pin DIP circuit. It has an internal 5K pullup transistor to the +5v supply, which limits current from the +5v supply through the reset pin of the propeller. That worked because BOEn was attached to the +5v supply, and the brown-out circuit's 5K pullup to the +3.3v supply was disabled, and the reset pin interface behaved as an ordinary CMOS input. Unfortunately, with BOEn grounded, you have a path from the DS1233-10 (via its 5K pull up to +5v) to the Propeller (via its 5K pull up to its +3.3v), that draws current, and drops voltage across the DS1233-10's internal 5K pullup, potentially triggering the DS1233-10 "trip voltage" sensor of 4.375v. I ended up having to add a non-inverting buffer with an open-drain output between the DS1233-10 output and the Propeller reset pin. On an oscilloscope all looks great ! The DS1233-10 is NOT generating unexpected RESET pulses. This modification to the design seems unrelated to my particular problem. In fact, the addition of the buffer was an attempt to remove any possible effects the DS1233 may have been causing. That eliminated ... the problem persists.
HERE'S MY BEST IDEA (SO FAR) :
The FT232RQ chip when disconnected from its USB cable, has its Vcc line at ground potential, and any voltages applied externally to the FT232RQ's RXD or TXD lines would likely be clamped to within a diode drop of ground. The Propeller tries to boot (or run my firmware which uses the Propeller TX line also), but the powered-off FT232RQ clamps this output voltage, and perhaps triggers the Propeller's brown-out detection circuit which initiates a full reboot operation, and the cycle repeats.
Is this why I see on the forum recommendations to include the 2K resistors in series with the TX and RX lines ?
Some might say that no activity by the Propeller until after its properly connected to its controlling PC is a "design feature", but its behavior is marginal at best and I would like to determine a clear explanation for this "odd" behavior.
Any help anyone may be able to offer would be greatly appreciated !
Comments
The easy solution is not to start the serial/debug drivers so as not to output on the TX/RX lines.
You may be able to check for a high on RX to decide whether to start the serial drivers or not.
Otherwise, you can add a pullup resistor.
I have series resistors in my design and it seems to have prevented that problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I disabled Propeller serial transmits to the PC and the Propeller now boots successfully when the USB cable is disconnected. To test further, I added the following line at the start of the serially-disabled code :
outa[noparse][[/noparse]pinSerTx] := HIGH
dira[noparse][[/noparse]pinSerTx] := OUTPUT
Just as expected, problems reappeared. This time my Propeller firmware would send pulses to the X-axis of the stepper for about 2 seconds, a brief pause of movement would occur (internal BOE reboot ?), then movement would resume. If I changed the code above so that the pinSerTx (P30) was set to LOW instead, no problems occurred...the propeller would start up without the USB cable connected, just as desired.
I did a quick search for the discussion thread you had referred to in your previous post but was unable to locate it. Could you assist in helping me locate this thread ?
Adding series resistors to the existing Proto Board With USB product would be a rather painful process. Sensing the state of the Propeller RX pin (P31) prior to enabling/disabling each transmission is also a bit cumbersome. RX and TX processes should remain independent of each other. The order an operator will take (USB connect, then Power-on VS. Power-on, then USB connect) should not alter the expected behavior of the system.
Since my application, in its current form, is merely a demo driving the X-axis back and forth without PC commands, and in the final form the system will only respond to specific PC commands, the best approach would be to have the SERIAL object BY DEFAULT continue to float the Propeller TX line (P30) (blocking data flow to the PC) until after the first <CR> terminated PC command (or <CR> character) has been received via the Propeller's RX pin (P31). No power to the FT232 chip, means no PC commands received, and thus no unwanted Propeller TX pin interactions with the FT232 chip.
A few questions remain ... why does the Propeller NOT REBOOT if the USB cable is disconnected AFTER POWER-UP ? What is different in regards to the Propeller-TX/FT322-RXD interaction AFTER power up ? Why does the REBOOT event occur once every 2 seconds or so ? What is the sensitivity of the Brown-Out detection circuit ? Will even a few nanoseconds during which the +3.3v VDD supply falls below its internal threshold cause the Propeller to reboot ? How much of a safety margin do the 2k series resistors provide ? Will 1K or 500 ohms work also ?
http://forums.parallax.com/showthread.php?p=807799
I'd be tempted to call this a design flaw (but I don't want Parallax mad at me [noparse]:)[/noparse]...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
This is a much better way to search. Go to :
http://search.parallax.com
In the search box type:
prop reset site:forums.parallax.com
The "site:" statement narrows the seach to just the forums. You will see quite a few posts.
Hope that helps,
Jim
edit: Darn! Ray beat me to it!
My ultimate solution was the addition of 3 lines of spin code at firmware startup.
I appreciate you assistance in helping to resolve this matter, particularly the
suggestion to monitor the RX line ! Elegantly simple.
'By default, at startup pinSerRX is an input. As long as power is not applied to the
'FT232 chip the Propeller's pinSerRX pin will remain LOW, and code execution
'will remain in this repeat loop. Once pinSerRX goes HIGH, the start method for
'the serial object is executed, and pinSerTX is allowed to become an output.
repeat
if ina[noparse][[/noparse]pinSerRX] == HIGH
quit
The fix, as I've stated before, entails an open drain buffer (i.e. 74LVC2G07) powered from the FTDI chip's VCCIO. This would be easy to implement on boards that include both the Prop and the USB port. It's a little more complicated for the Prop Plug, however, since it may have to plug into legacy Demo boards that don't include a pullup on A31. The solution may be to include a two-pin header on the revised Prop Plug with a shunt that connects a pullup to VCCIO for Prop boards that don't include the pullup to Vdd. In any event, this issue comes up frequently enough that Parallax really should address it with a design mod.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
The pullup method prevents the problem, but it's a rather ugly way to do it. The reason the problem goes away is that the pullups partially power the FTDI chip through their I/O pins and, thence, through their protection diodes. This keeps the DTR pin in a constant "on" state rather than toggling on when A30 goes high and causing another reset. Powering the FTDI chip in this fashion is a really poor workaround. The advantage of the 74LVC2G07 is that it prevents power flow in either direction to an unpowered chip connected to it. And it only costs a few cents to add, along with pullups on its outputs. So why not include it?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
It's what I used in the design for the MoboStamp-pe. It will work across different VCCIO and Vdd levels; but it should be powered from the lower of the two. The reason is that the high input threshold could be as much as 0.7 * Vdd, which for 5V is 3.5V. In conjunction with a Propeller, the FTDI's VCCIO should therefore be 3.3V if you power the buffer from VCCIO. (Its inputs are still 5V-tolerant.) The 74LVC logic prevents input and output pullup voltages from leaking to the supply line. The open-collector outputs prevent a powered chip from outputting levels on their own that might power a system downstream. Together, these features prevent a powered Propeller from powering an unpowered FTDI chip, and vice-versa.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
Here's a schematic:
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
However, my new design does not have the space to remove the connections. I see 2 or 3 choices...
1. Use an external PropPlug
2. Use Phil's circuit.
3.·Use 2·diodes to power the FTDI from either the USB or PCB's +5V. The FTDI would always be powered in this case.
Any other thoughts ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
So, as long as I keep something like this audio amp in the circuit and use 1k series resistors, there's no problem.
Also, I bet I could get away with 10k series resistors, but haven't tried that.
Still, Phil's idea has a lot of merit, so I'm on the fence about implementing it on PSM2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm