Another resource- page 7 of the Propeller 2 datasheet has the minimal connections diagram, and crucially a list of bullet points below the diagram explaining the essential connections.
Where it mentions the bypass caps, ideally select a 0402 package 100nF to 4.7uF range, or else 0603 package 100nF to 1uF range. And the note about "closely-located" is a critical part of the value choice (as always for digital IC decoupling - follow standard selection, placement and layout rules). Placement & layout is 95% of the battle! If considering 0805 then should be 100nF, but ideally reconsider and target a smaller package capacitor!
That's a good point- the amount of capacitors on the Parallax designs are partially due to the layout "constraints" and wide band performance requirements. For a simpler layout with a less contortioned IO feedout (as you have), then you might consider bypass caps on alternate VDD and VIO pins, and perhaps some bulk capacitance feeding each side of the IC.
These things really are layout dependant, and ultimately use-case dependant (including max speed, processor load and I/O function, ie. Analog, Digital or mixed). In simple terms, how much juice the microcontroller needs to run at the level your project needs will determine the power supply requirements, layout, and component choices. And the I/O functions will determine the maximum noise and ripple specs that you might also want to consider for a certain design.
Looking at your board briefly, it looks like a reasonable starting point would be to keep things simple as others have suggested.
All ceramic caps- perhaps 0603 sized 100nF caps on alternate VDD & VIO pins to ground.
10uF-22uF on each VDD rail close to the P2, (could be 0805, 1210's or a little larger, but for the smaller package aim for the larger capacitance)
10uF-22uF on each side of the P2 on the VIO rails, (could be 0805, 1210's or a little larger)
And sufficient capacitance for (and close to) each power-supply, according to whatever the manufacturer datasheets suggest.
That will certainly get you a working solution to start from, assuming the layout is intact of course, and that the power and ground traces are appropriately formed.
I added (4) 1uF Caps on the underside of the 1st tested board, under the chip on the Cap pads to the Vdd.
I got a few Detects at the begining and a few start of Uploading but unfinished, then nothing after that.
Maybe the breadboard is acting as a capacitor ... ?
-- Plastic things like breadboards are known to be EMF absorber emitters - common problems for radio & metal detector circuits.
Guess I'd try seeing if can use a loadp2 setting to have it try to load at a lower baud...
This looks old, but it what I have in FlexProp folder, loadp2.md.
Perhaps try lowering the loader baud with "-l 115200" and maybe also do "-SINGLE" for single stage loading...
Usage
usage: loadp2
[ -p port ] serial port
[ -b baud ] user baud rate (default is 115200)
[ -l baud ] loader baud rate (default is 2000000)
[ -f clkfreq ] clock frequency (default is 80000000)
[ -m clkmode ] clock mode in hex (default is ffffffff)
[ -s address ] starting address in hex (default is 0)
[ -9 dir ] serve 9P file system with root dir
[ -t ] enter terminal mode after running the program
[ -v ] enable verbose mode
[ -k ] wait for user input before exit
[ -q ] quiet mode: also checks for exit sequence
[ -n ] no reset; skip any hardware reset
[ -? ] display a usage message and exit
[ -xDEBUG ] enter ROM debug monitor
[ -xTAQOZ ] enter ROM version of TAQOZ
[ -CHIP ] set load mode for CHIP
[ -FPGA ] set load mode for FPGA
[ -PATCH ] patch in clock frequency and serial parms
[ -ZERO ] clear memory before download
[ -NOZERO ] do not clear memory before download (default)
[ -SINGLE ] set load mode for single stage
filespec file(s) to load
[ -e script ] execute script after loading
@jlsilicon said:
I added (4) 1uF Caps on the underside of the 1st tested board, under the chip on the Cap pads to the Vdd.
I got a few Detects at the begining and a few start of Uploading but unfinished, then nothing after that.
Maybe the breadboard is acting as a capacitor ... ?
-- Plastic things like breadboards are known to be EMF absorber emitters - common problems for radio & metal detector circuits.
Using breadboards can cause problems unless connections are really good, I've been burnt there before. Check that the leads and component legs are making very good full contact in the breadboard holes, and that your leads themselves are all good. Also powering from a proper power supply rather than the FT232 board's output with those breadboard wires could be a better option to try.
Your board seemed to have a path designed for serial to the P2 although without an actual board schematic and all the silkscreen overlap it was hard to tell what you had exactly. Can you solder some components there on your board to avoid the extra breadboard circuitry to be in the path?
I'm a bit worried if the system works intermittently for a while before stopping completely you may be somehow damaging something. Do you have dropper resistors between the FTDI and the P2 serial pins? What sizes are they? If you apply a 5V signal to the P2 RX pin, you could fry it if the internal protection diode is overwhelmed.
If you are going to invest in the P2, it may be worth getting a proper PropPlug. It just makes serial a lot simpler.
@Rayman said:
Guess I'd try seeing if can use a loadp2 setting to have it try to load at a lower baud...
This looks old, but it what I have in FlexProp folder, loadp2.md.
Perhaps try lowering the loader baud with "-l 115200" and maybe also do "-SINGLE" for single stage loading...
I tried your commands menu:ConfigCommands in Flexprop -all it returns is "can not find P2 on Com15
I'm a bit worried if the system works intermittently for a while, before stopping completely you may be somehow damaging something. Do you have dropper resistors between the FTDI and the P2 serial pins? What sizes are they? If you apply a 5V signal to the P2 RX pin, you could fry it if the internal protection diode is overwhelmed.
I'm a bit worried if the system works intermittently for a while, before stopping completely you may be somehow damaging something. Do you have dropper resistors between the FTDI and the P2 serial pins? What sizes are they? If you apply a 5V signal to the P2 RX pin, you could fry it if the internal protection diode is overwhelmed.
-- Used a Resistor Ladder , should bring Tx 5V down to 3.3V ~
Bit of a worry if you had a 5V signal before, the damage may have already been done with 220 ohm dropper resistor to the P2 if the signal was at 5V and driven out by CMOS. Current into the P2 protection diode could have been in the vicinity of 5mA while you had it attached. For a prolonged period this could well damage the protection diode from the pin to the 3.3V rail. I think it's safer to keep the current below a mA for the serial ports if fed by a 5V signal.
Did you have your FTDI board configured for 3.3V IO signals or 5V IO?
I got a Detect 1 out of 10 times,
sometimes it starts to as : Upload 'Loading' , or "Loading" then "Verifying",
but quickly aborts with popup window just disappearing.
3rd Board has :
100uF cap across VRegs VIn from VIn +5V to Gnd.
10u + 1u + 0.1uF caps across VReg3.3V from VOut to Gnd.
10u + 1u + 0.1uF caps across VReg 1.8V from VOut to Gnd.
(4) 1uF caps from chip Vdd to Gnd.
(4) 1uF caps from chip Vio to Gnd.
Pullup Resistor 10K to Reset.
Pullup Resistors 10K to PD61 & PD59 .
But, the resistor wires are misleading.
Look closely at the image again.
That is the Resistor 1K from FTDI32 DTR to Transistor Base to Reset.
The 1K res goes under the 220R resistor.
I removed the pulldown resistor 470R - DTR is 2V so not needed.
VoltMeter says that the 470R pulls DTR down to 0V, and I get NO Detects at all.
-- May be the 220R on Tx is causing the problem ?
Did you measure the current drawn, which goes to almost zero after the 60~70sec timeout, to verify reset is getting through to the P2 and doing its job?
@Rayman said:
I'm looking at the resistors where the yellow and orange wires connect to your board... Are the resistors there supposed to go to ground?
No.
And they do not go to Gnd.
Gnd is the Brown and Black wires.
Yellow and orange wires are Ftdi32:Tx & Ftdi32:Rx going to 220R resistors to P2:Rx & P2:Tx
Resitor 1K BrownBlackRed links from ftdi:DTR to Cap 0.1uF to Transistor Base.
@Tubular said:
Did you measure the current drawn, which goes to almost zero after the 60~70sec timeout, to verify reset is getting through to the P2 and doing its job?
@Tubular said:
Did you measure the current drawn, which goes to almost zero after the 60~70sec timeout, to verify reset is getting through to the P2 and doing its job?
I have not hooked up the datascope yet.
Ok, but this is something you can check with a multimeter fairly easily, and would eliminate 1 or 2 of the 4 domains where the remaining problem hides
1:
If I run Spin Tool IDE,
then reconnect PC USB to FTDI32 to Board 3.
I can successfully Detect again and again many times.
2:
But, on first Upload , it pops up 'Uploading' then 'Verifying' for a few seconds , then closes up the window (unfininshed ?)
Any Uploads after that just say P2 is not present.
Voltage 3.3V does not vary after the plugin to PC USB , through all of these detects and Uplads / Fails.
Voltage 1.8V does not vary after the plugin to PC USB , through all of these detects and Uplads / Fails.
3:
If I replugin FTDI32 , sometimes it comes back to Detects repeatedly again.
Maybe the TFDI32 currecnt is not enough Power/current to support the Uploading ?
Comments
Another resource- page 7 of the Propeller 2 datasheet has the minimal connections diagram, and crucially a list of bullet points below the diagram explaining the essential connections.
https://www.parallax.com/package/propeller-2-p2x8c4m64p-datasheet/
Where it mentions the bypass caps, ideally select a 0402 package 100nF to 4.7uF range, or else 0603 package 100nF to 1uF range. And the note about "closely-located" is a critical part of the value choice (as always for digital IC decoupling - follow standard selection, placement and layout rules). Placement & layout is 95% of the battle! If considering 0805 then should be 100nF, but ideally reconsider and target a smaller package capacitor!
That's a good point- the amount of capacitors on the Parallax designs are partially due to the layout "constraints" and wide band performance requirements. For a simpler layout with a less contortioned IO feedout (as you have), then you might consider bypass caps on alternate VDD and VIO pins, and perhaps some bulk capacitance feeding each side of the IC.
These things really are layout dependant, and ultimately use-case dependant (including max speed, processor load and I/O function, ie. Analog, Digital or mixed). In simple terms, how much juice the microcontroller needs to run at the level your project needs will determine the power supply requirements, layout, and component choices. And the I/O functions will determine the maximum noise and ripple specs that you might also want to consider for a certain design.
Yeah, I was looking at that for a general simple reference for my design.
Looking at your board briefly, it looks like a reasonable starting point would be to keep things simple as others have suggested.
That will certainly get you a working solution to start from, assuming the layout is intact of course, and that the power and ground traces are appropriately formed.
I added (4) 1uF Caps on the underside of the 1st tested board, under the chip on the Cap pads to the Vdd.
I got a few Detects at the begining and a few start of Uploading but unfinished, then nothing after that.
Maybe the breadboard is acting as a capacitor ... ?
-- Plastic things like breadboards are known to be EMF absorber emitters - common problems for radio & metal detector circuits.
I'd try with FlexProp... Some things under "Special" don't require the crystal circuit to be working I think...
I have been testing with FlexProp also
Guess I'd try seeing if can use a loadp2 setting to have it try to load at a lower baud...
This looks old, but it what I have in FlexProp folder, loadp2.md.
Perhaps try lowering the loader baud with "-l 115200" and maybe also do "-SINGLE" for single stage loading...
Usage
usage: loadp2 [ -p port ] serial port [ -b baud ] user baud rate (default is 115200) [ -l baud ] loader baud rate (default is 2000000) [ -f clkfreq ] clock frequency (default is 80000000) [ -m clkmode ] clock mode in hex (default is ffffffff) [ -s address ] starting address in hex (default is 0) [ -9 dir ] serve 9P file system with root dir [ -t ] enter terminal mode after running the program [ -v ] enable verbose mode [ -k ] wait for user input before exit [ -q ] quiet mode: also checks for exit sequence [ -n ] no reset; skip any hardware reset [ -? ] display a usage message and exit [ -xDEBUG ] enter ROM debug monitor [ -xTAQOZ ] enter ROM version of TAQOZ [ -CHIP ] set load mode for CHIP [ -FPGA ] set load mode for FPGA [ -PATCH ] patch in clock frequency and serial parms [ -ZERO ] clear memory before download [ -NOZERO ] do not clear memory before download (default) [ -SINGLE ] set load mode for single stage filespec file(s) to load [ -e script ] execute script after loadingThink you can type this into the "Configure Commands" window in FlexProp...
Using breadboards can cause problems unless connections are really good, I've been burnt there before. Check that the leads and component legs are making very good full contact in the breadboard holes, and that your leads themselves are all good. Also powering from a proper power supply rather than the FT232 board's output with those breadboard wires could be a better option to try.
Your board seemed to have a path designed for serial to the P2 although without an actual board schematic and all the silkscreen overlap it was hard to tell what you had exactly. Can you solder some components there on your board to avoid the extra breadboard circuitry to be in the path?
I'm a bit worried if the system works intermittently for a while before stopping completely you may be somehow damaging something. Do you have dropper resistors between the FTDI and the P2 serial pins? What sizes are they? If you apply a 5V signal to the P2 RX pin, you could fry it if the internal protection diode is overwhelmed.
If you are going to invest in the P2, it may be worth getting a proper PropPlug. It just makes serial a lot simpler.
As below :
I changed :
FTDI32 Tx -> R220 -> P2:Rx
To:
FTDI32 Tx ---> R220 --+---> P2:Rx
Gnd <<--------- R470 --+
-- Used a Resistor Ladder , should bring Tx 5V down to 3.3V ~
Bit of a worry if you had a 5V signal before, the damage may have already been done with 220 ohm dropper resistor to the P2 if the signal was at 5V and driven out by CMOS. Current into the P2 protection diode could have been in the vicinity of 5mA while you had it attached. For a prolonged period this could well damage the protection diode from the pin to the 3.3V rail. I think it's safer to keep the current below a mA for the serial ports if fed by a 5V signal.
Did you have your FTDI board configured for 3.3V IO signals or 5V IO?
The other question I have is what drive strength the FT232 is set to drive at - could it be set to 4mA rather than 8/12/16mA?
Similarly are any of the signals being inverted by the FT232? Particularly DTR or RTS?
You'll need FT_Prog to look at these if you don't have it already
No luck with 3rd board.
I got a Detect 1 out of 10 times,
sometimes it starts to as : Upload 'Loading' , or "Loading" then "Verifying",
but quickly aborts with popup window just disappearing.
3rd Board has :
100uF cap across VRegs VIn from VIn +5V to Gnd.
10u + 1u + 0.1uF caps across VReg3.3V from VOut to Gnd.
10u + 1u + 0.1uF caps across VReg 1.8V from VOut to Gnd.
(4) 1uF caps from chip Vdd to Gnd.
(4) 1uF caps from chip Vio to Gnd.
Pullup Resistor 10K to Reset.
Pullup Resistors 10K to PD61 & PD59 .
Am I missing anything ?
3rd Board Below :
FTDI32 Tx ---> R220 --+---> P2:Rx
Gnd <<--------- R470 --+
Looks to me like R470 is going to VIO and not GND...
Thanks.
But, the resistor wires are misleading.
Look closely at the image again.
That is the Resistor 1K from FTDI32 DTR to Transistor Base to Reset.
The 1K res goes under the 220R resistor.
I removed the pulldown resistor 470R - DTR is 2V so not needed.
VoltMeter says that the 470R pulls DTR down to 0V, and I get NO Detects at all.
-- May be the 220R on Tx is causing the problem ?
I'm looking at the resistors where the yellow and orange wires connect to your board... Are the resistors there supposed to go to ground?
Did you measure the current drawn, which goes to almost zero after the 60~70sec timeout, to verify reset is getting through to the P2 and doing its job?
I went back to switch FTDI32's .
Found that the Propeller1 Board is not recognized either - for either FTDI32.
Maybe its the cable ...
No, its cable is ok.
-
PropellerTool :
sees Propeller1 great ,
but does Not see Propeller2.
SpinToolsIDE :
does Not see Propeller1 ,
and does Not see Propeller2 (except once in a while) ...
???
No.
And they do not go to Gnd.
Gnd is the Brown and Black wires.
Yellow and orange wires are Ftdi32:Tx & Ftdi32:Rx going to 220R resistors to P2:Rx & P2:Tx
Resitor 1K BrownBlackRed links from ftdi:DTR to Cap 0.1uF to Transistor Base.
I have not hooked up the datascope yet.
Ok, but this is something you can check with a multimeter fairly easily, and would eliminate 1 or 2 of the 4 domains where the remaining problem hides
I'm seeing what looks like 10k pullups on FTDI:TX&RX is that what you have?
that sounds ominously like damage.
Start with very simple pings, from any ASCII terminal (with simple manual Rst, then DTR resets)
Read this
https://forums.parallax.com/discussion/comment/1552173#Comment_1552173
You should get 100% echoes confirming the P2 is there. ( RST/send/echo)
And also measure ICC as suggested above.
1:
If I run Spin Tool IDE,
then reconnect PC USB to FTDI32 to Board 3.
I can successfully Detect again and again many times.
2:
But, on first Upload , it pops up 'Uploading' then 'Verifying' for a few seconds , then closes up the window (unfininshed ?)
Any Uploads after that just say P2 is not present.
Voltage 3.3V does not vary after the plugin to PC USB , through all of these detects and Uplads / Fails.
Voltage 1.8V does not vary after the plugin to PC USB , through all of these detects and Uplads / Fails.
3:
If I replugin FTDI32 , sometimes it comes back to Detects repeatedly again.
Maybe the TFDI32 currecnt is not enough Power/current to support the Uploading ?
That sounds good…
Make sure prop tool debug is turned off
Where ?
100K pullups to P2:Tx & P2:Rx
10K pullups to P61 & P59
220R limiter between FTDI:Tx -> 220R -> P2:Rx
220R limiter between FTDI:Rx <- 220R <- P2:Tx