P2-Eval (64000-ES) first impressions
Tubular
Posts: 4,622
I've spent my first full day with P2-Eval (part 64000-ES). Here are some quick notes before I wrap up
* Overall, a brilliant board
* Heat dissipation really good, the available area keeps things at most warm to touch
* Ground pillars great, really useful
Some rather minor issues relating to P2-Eval
* Measuring the 1v8 voltage isn't easy. Ended up making a kind of shunt jumper using a 2 pin stackthrough connector so could attach a probe
* Measuring 5v input current - it'd be nice to have jumpers like 1v8 and 3v3 rails have
* The micro USB connectors are 'upside down' compared with usual smartphone convention
* No reset transistor means operation is inverted compared to what we're used to with P1. ie it resets the P2 upon entry (rather than exit) from a terminal program. This is a pain for programs loaded in RAM (though not as much an issue for Taqoz, uSD/flash boot etc
* 1v8 adj pins not easy to use and could probably use a series resistor to limit adjustment range
* label the leds with their alternative function - RX, TX, MISO, MOSI etc
Some minor issues relating to P2 - will put in another thread after confirming them with others.
* PLL wobbles
* better VGA video out from 3v3 big switcher, compared to 3v3 low noise LDOs (why?[) its not; LDOs better
* HD vga timing
* PLL upper limits
* Overall, a brilliant board
* Heat dissipation really good, the available area keeps things at most warm to touch
* Ground pillars great, really useful
Some rather minor issues relating to P2-Eval
* Measuring the 1v8 voltage isn't easy. Ended up making a kind of shunt jumper using a 2 pin stackthrough connector so could attach a probe
* Measuring 5v input current - it'd be nice to have jumpers like 1v8 and 3v3 rails have
* The micro USB connectors are 'upside down' compared with usual smartphone convention
* No reset transistor means operation is inverted compared to what we're used to with P1. ie it resets the P2 upon entry (rather than exit) from a terminal program. This is a pain for programs loaded in RAM (though not as much an issue for Taqoz, uSD/flash boot etc
* 1v8 adj pins not easy to use and could probably use a series resistor to limit adjustment range
* label the leds with their alternative function - RX, TX, MISO, MOSI etc
Some minor issues relating to P2 - will put in another thread after confirming them with others.
* PLL wobbles
* better VGA video out from 3v3 big switcher, compared to 3v3 low noise LDOs (why?[) its not; LDOs better
* HD vga timing
* PLL upper limits
Comments
I tried a uSD card and then I found it was super awkward for my fingers to grab hold of again to remove it. I had to put some tape on the end of the card as a pull-tab so maybe this is something that can be adjust mechanically for the next time.
I will investigate further and get back about this.
I'm reading up about the LDOs
The CMD0 response seems to work at 120MHz though. (The lines with just a 1 or 0 are because I used a ^X to re-execute the last line entered).
EDIT: Further tests now seem to mount at 70MHz but not 80MHz.
I always put a 100nF and 10uF caps at the SD power pins as close to the SD socket as possible. I found they were needed years ago as the SD cards required a lot of current in spikes.
I used to use 22uF but admittedly not a lot of science behind it
It would be easy to parallel up the existing 0402 cap and see if it improves things. If you're feeling adventurous Peter, the cap is behind the molex uSD socket, between it and the flash chip, to the right. The left end of the cap is the VIO voltage. It should be possible to probe and see the voltage dip when mounting (since the other microsd socket pins are covered by the microsd card)
Interesting to note how the boot pins seem to have a lot of capacitance on them. I will also connect up a reference cap just so I can get an idea what this means.
TAQOZ# : U.R <# FOR # NEXT #> PRINT$ ; ok TAQOZ# : ?PIN ( pin -- ) ." P" DUP . 9 EMIT PIN L 100 us F CNT@ BEGIN R UNTIL CNT@ SWAP - ABS 10 U.R ; ok TAQOZ# : ?PINS 62 0 DO CRLF I ?PIN LOOP ; ok TAQOZ# ok TAQOZ# ok TAQOZ# ?PINS P0 0009212096 P1 0007412456 P2 0003025976 P3 0007411496 P4 0001332056 P5 0007367096 P6 0000486416 P7 0006839576 P8 0008339216 P9 0007840856 P10 0007900496 P11 0007490336 P12 0002984696 P13 0007790336 P14 0003848816 P15 0002530016 P16 0009377456 P17 0009101936 P18 0008730776 P19 0008374016 P20 0008725016 P21 0008310896 P22 0007427096 P23 0008241296 P24 0006275936 P25 0007353536 P26 0000646736 P27 0003584096 P28 0001111016 P29 0008386496 P30 0001767176 P31 0007808096 P32 0007926416 P33 0007786376 P34 0008354696 P35 0007804136 P36 0008359016 P37 0007992416 P38 0008161856 P39 0007449176 P40 0007458296 P41 0006984656 P42 0006080816 P43 0007120256 P44 0007244336 P45 0003085016 P46 0006141776 P47 0004675016 P48 0009187976 P49 0004548656 P50 0008700776 P51 0005089736 P52 0008358776 P53 0008215496 P54 0008423816 P55 0008633816 P56 0014658536 P57 0013100456 P58 0044194136 P59 0021615056 P60 0032916296 P61 0000000176 ok TAQOZ#Running the same test averaged over 8 samples confirms that P58 is abnormally loaded.
These kind of diagnostics that P2 can perform are going to come in very handy over the years ahead
As well as running up to V5663 connector, the track goes around far side of 3v3 regulator, over to V4047 connector and all the way down outside edge of board and right around the SD connector and back into SPI flash chip.
And also has 240R resister to MISO pin of SD card. So the SD card can't drive it as hard.
There is no convention regarding micro USB connectors. Some are to be mounted "upside down" and some aren't. As long as as the body pads are not SMT, it is good enough for me.
As for the lack of an inverting transistor to control the reset pin, that is good to know. Thus, it is possible to access the serial terminal with PuTTY or any conventional TTY com program. If you noticed, the serial output from the Activity board is not correctly visible (that is, the program is not seen starting up from the begining) via PuTTY or via HyperTerminal. That is due to the inverting transistor that exists on that board. Doing the same mistake here would be... well, a mistake.
To add, IMHO programs should be reset on entry rather than on exit. Doing otherwise would cause one to miss information that the program outputs after establishing a connection. Programs loaded on RAM are not much of an issue, since they will need to be loaded via some IDE anyways. The IDE could reset the interface after, as an option.
Kind regards, Samuel Lourenço
Just to be clear those minor observations I made were just that, minor, and no big deal, and there are workarounds. Overall this is a really useful board
I'm not sure of the problem you refer to with the activity board. Is there a link with further information? Using the reset transistor has been a long tradition (every prop plug has one, too).
Yes, a tightly integrated IDE that kept the port open between loading the program, and viewing results in a terminal, would solve the problem, but we don't have that. Even Prop tool had separate PST
Looks loaded alright. A 50% clock duty cycle can help and a well placed NOP can tolerate more slew on the paths.
That increases the sysclk, but at the expense of highest possible SD MHz.
Maybe the boot code need to be tuned as 'more tolerant', rather than 'fastest' ?
Can some of the long meander trace be isolated, to reduce the load ?
If you load my prime number program onto the Activity Board (or a simple "Hello World" program, for that matter), you will notice that the prompt (or the message) is not visible via PuTTY or HyperTerminal, because the Propeller is not reset once the com starts. SimpleIDE works OK, since it toggles !RTS or !DTR. On other terminal programs, these pins (on the FTDI chip) stay low during comunication, and stay high if no comunication is established.
Kind regards, Samuel Lourenço
2. If you are using a Microsoft OS, then Reset upon entry is most likely caused by the way the OS negotiates the port by default. It always toggles DTR in search of the old serial mouse. The behaviour can be disabled in device manager / properties. After that, you should be able to plug in P2 without experiencing any reset at all. (I'm being a bit vague here, as this is from memory. I'll be in the office tomorrow, and could share the OS setup doc if that would help anyone).
About SD...
About the Protoboards
A rough 'convention test' is to check Digikey stocks.
Cheapest, and highest volumes are what P2 Eval has, 240k, 20c/1200
'Reverse' tagged micro-usb are lower stocks and higher prices 43k, 48c/2k
If you need to keep your propeller board running without all this hassle requires to cut some traces and add a jumper or switch for programming/run. When Parallax was using a Propplug and not in build FTDI one could overcome this easy with a small adapter not connecting /RST, just put a three pin header in between and done.
Might not be such a big problem for a evaluation board but since the demise of the Protoboard w/o USB there is no Parallax board not resetting when plugging in a USB connection to a PC.
Witch is simply wrong if you need to check on a running system.
What I also miss is a simple power switch. Disconnecting the USB cable seems odd to me.
Enjoy!
Mike
This seems like the same settings issue for the com port. There are 2 things to un-tick in the com port properties, then you shouldn't get resets on most (if not all) the boards.
I'll share the step-by-step doc tomorrow. At least hopefully it will help improve some things.
If I recall correctly, there are no toggles on the !RTS and !DTR lines. I've confirmed that with PuTTY on Windows/Linux and with HyperTerminal on Windows. The FT230X !RST line goes down when the com starts, and stays there until it ends. The FTDI chip on the Activity Board behaves the same way.
Kind regards, Samuel Lourenço
Just confirming this, plus a power reboot, fixes the issue. Many thanks
The transistor to invert the DTR Reset is to overcome switching between programs on Windoze. This is due to separate programs rather than a complete IDE. When Windoze switches between a running program and starts a new program, DTR is cleared. If the outgoing program had DTR set, this causes a Prop Reset. Now, if DTR is inverted by the transistor, a Prop Reset does not occur, which is the desired outcome.
Tricks using capacitors etc work mostly, but they only hide the underlying problem. The transistor CCT solves a Windoze bug and a non-integrated IDE.
IMHO the transistor cct should be retained, but it should be on the Prop board, not on the PropPlug or other USB serial board. All my P1 pcbs for years have had a linkable transistor reset cct.
Plugging in a USB with an FTDI causing reset, and other similar reset problems, are due to the P1 powering up the FTDI chip thru the I/O pins. This is a totally different problem.
I'm pleased to say I had the sources mixed up, and the 8 small LDOs do indeed result in better video quality than the big 3v3 switcher.
I was mixed up due to the labeling. There is a current measuring jumper with "VIO" on one side and "3V3" on the other. Due to the orientation I believed 3v3 to be the rail going to the P2, but it is in fact the VIO side connected to the P2.
At the jumpers, "3V3" refers to local 3v3 LDO outputs, and "VIO" refers to main 3v3 big switcher.
The jumpers as shipped (at least on mine) were connected to the big switcher (jumpers closest to central axis)
I did some experiments with multiple local 47 ohm 1/4w load resistors from V0003 to ground. When running from the big switcher, 1 x 47 ohm resistor load made streaking slightly worse (than zero resistors), but keeping going and 4 x 47 ohm resistors made things good (similar to local LDO)
There is a glitch in the main voltage rails, both 1v8 and 3v4, 4 times per video scan line, synced to the scan line.
I need to revisit PLL supply and take some further measurements