Testing new P2 EVAL RevB board with glob-top chip
Peter Jakacki
Posts: 10,193
in Propeller 2
Parallax have kindly sent me one of their precious few new P2 EVAL boards that arrived earlier today. I forgot that Chip mentioned something a few weeks ago about mounting the few chips he had knowing that some might not work due to poor wire bonds on the leadframe side. When I got the board it came with a HyperRAM+HyperFlash module which I automatically plugged in and then I powered it up. Something wasn't right because the ROM wasn't responding on the serial terminal so I unplugged the module and powered up again and it worked. I was a little bit concerned but I have only just double checked it now and found that I had plugged the module in upside down and the two grounds of the module were shorting +5V and VIO, while the modules VIO was connected to ground. Ooops!. But plugging it back in now it seems fine. Close call!
After that initial close call I tried loading my latest TAQOZ onto the board but nothing seemed to happen. After a few hours of debugging by driving the P56 LED at various points in my code it dawned on me that the P2 was being reset by the loader after loading since I use loadp2 on Linux. So I cut the DTR-RST track that is meant to be cut and installed a 2-pin header and jumper in the off position and rely on manual reset which suits me very well indeed because this is the exact same thing I did to the original EVAL board although in its case I had to flick a 0402 cap off the pcb.
Then P2 EVAL Revb came to life and after playing with it for a while checking it out I even clocked it up to 399MHz and I have had it running for several hours now, not even warm and only using my serial coms USB for power.
It's a bit late here now but I will run through my audio/video tests tomorrow and see if I can make up a HDMI cable (really needs a module). But what I really want to do is some audio processing work which I will get onto shortly. I'm not sure what I need to do yet to get the memory module running though.
The P2 seems to die as soon as I select 400MHz but I will try some other more optimal PLL settings.
After that initial close call I tried loading my latest TAQOZ onto the board but nothing seemed to happen. After a few hours of debugging by driving the P56 LED at various points in my code it dawned on me that the P2 was being reset by the loader after loading since I use loadp2 on Linux. So I cut the DTR-RST track that is meant to be cut and installed a 2-pin header and jumper in the off position and rely on manual reset which suits me very well indeed because this is the exact same thing I did to the original EVAL board although in its case I had to flick a 0402 cap off the pcb.
Then P2 EVAL Revb came to life and after playing with it for a while checking it out I even clocked it up to 399MHz and I have had it running for several hours now, not even warm and only using my serial coms USB for power.
It's a bit late here now but I will run through my audio/video tests tomorrow and see if I can make up a HDMI cable (really needs a module). But what I really want to do is some audio processing work which I will get onto shortly. I'm not sure what I need to do yet to get the memory module running though.
The P2 seems to die as soon as I select 400MHz but I will try some other more optimal PLL settings.
TAQOZ# fibos --- fibo(1) = 457 cycles= 1,145ns @399MHz result = 1 fibo(6) = 777 cycles= 1,947ns @399MHz result = 8 fibo(11) = 1,097 cycles= 2,749ns @399MHz result = 89 fibo(16) = 1,417 cycles= 3,551ns @399MHz result = 987 fibo(21) = 1,737 cycles= 4,353ns @399MHz result = 10,946 fibo(26) = 2,057 cycles= 5,155ns @399MHz result = 121,393 fibo(31) = 2,377 cycles= 5,957ns @399MHz result = 1,346,269 fibo(36) = 2,697 cycles= 6,759ns @399MHz result = 14,930,352 fibo(41) = 3,017 cycles= 7,561ns @399MHz result = 165,580,141 fibo(46) = 3,337 cycles= 8,363ns @399MHz result = 1,836,311,903 ok TAQOZ# MOUNT --- CARD: SANDISK SD SL08G REV$80 #168665696 DATE:2016/2
*** SPEEDS ***
SECTOR.......................... 331us,1169us,24us,25us,285us,285us,286us,285us,
BLOCKS.......................... 3,999kB/s @399MHz
Comments
The new EVAL board will survive that condition in most cases. The supply rail will be disconnected within a couple uSecs, and the fault LED should light up for most fault events.
Glad you tested this for us
Oh, and what evanh said about the 5V jumper- it may not be installed by default. BTW... Those Hyper modules are running on 3V3, so no need for the headers 5V to be active on their account.
With the simplest code the PLL limit is reachable, but only just.
/2 at -7.5 °C gives 445 MHz PLL limit.
/1 at -9.0 °C gives 440 MHz PLL limit.
/20 at -9.0 °C gives 451 MHz PLL limit.
EDIT: /1 at +30.0 °C gives 400 MHz PLL limit.
I changed my video code to the new streamer mode values and P2 is generating a sync'd 640x480/60Hz frame ok but the streamer seems to be inserting 0 DAC values every third pixel.
The effect is only 2/3 of image displayed woth vertical black lines through the image.
Hsync and vsync timings match the Rev A results exactly.
I will take another closer look tonight.
This might be related to my problem too. I have spent half a day yesterday looking into something similar on my new P2 eval board as well and now have a logic analyzer on LED pins to find where it dies etc. Weirdly the downloaded code seems to complete one byte prior to the end of the code sent. I toggle a pin for each byte received and it stops toggling one byte before the end. It might be explained by getting a reset at the end of the download in loadp2 (on a Mac) trashing the IO pin states etc.
Using loadp2's -SINGLE option lets me download some sample programs (but without a proper baud rate in C as it doesn't setup the PLL and continues to run at RCfast :frown: ). These do actually execute ok but when I used the -CHIP option with the two stage downloader it doesn't complete properly and the P2 just appears to hang at the end (or possibly reset, I'll have to check that). Same test code sent to the old and new EVAL boards with the same loadp2 appears to not be giving the same result for me. So this could be a board difference.
WOW, seems like 400MHz is the limit, so to be conservative ~360MHz should be a nice overclocking limit with room to spare. Never expected to get this, as we were just hoping to get 200MHz originally
That doesn't sound good...
I had to update the loadp2 fast loader for the new chip -- it needed a "nop" between the setse1 and pollse1, without it it just hangs.
The updated source code is at https://www.github.com/totalspectrum/loadp2. I also added a -ZERO option to the loadp2 command line to force the fast loader to clear memory; that was helpful when I needed to track down a different bug.
btw, I'm still using your old loadp2.
Don't Panic Rayman!
Got things working Ok now.
Getting some sleep and setting correct mode made all the difference.
I have
loadp2 - a loader for the propeller 2 - version 0.016 2019-09-12
Thanks Eric. Looks like you've already done what I started doing. I like how you've patched the Mainloader spin binary stuff into the Makefile. I got tired of manually pasting bytes into loadp2.c during testing too.
I had been using my own loadp2.c file with some of my Mac specific fixes on serial timeouts, enabling 2Mbaud, and auto detecting ports etc. I really should just bite the bullet and get your latest revision of this tool from your repo, and try to create a pull request for any of my remaining patches so they can go in if they are not already covered. I know Dave Hein took some of the earlier changes I made so some of these are probably in there. I just didn't really want to have to revisit/retest/merge all this stuff on my Mac again after I spent some time a while ago debugging it and working it all out the first time. Much prefer to spend the time on the P2 itself!
Can you check the SD loader is working and releasing DO please?
Just load a program from SD (_BOOT_P2.BIX) and then check the DO (pin58) floats and not driven to low.
Yes, I'm pleased that pretty much everything just works. Just sharing my unboxing experiences moment by moment
I believe the value 20000000 should be increased to the upper limit of the RCFAST frequency. My P2 eval rev B board is running closer to 25MHz than 20MHz. This will ensure that at least a 10ms PLL delay is used, not the 8ms in this case.
Pin58 floating (Lead-in is press-release of reset button)
Pin58 with 10k pull-up to 5V (Lead-in is press-release of reset button)
Pin58 floating (When reset button released)
Pin58 with 10k pull-up to 5V (When reset button released)
If you or others want to take a look at this with a merge in mind here they are...(small changes in two files). If you want it via proper github pull request that could take longer and I'd possibly need to resurrect some things there first like my account/passwords/email/certificates etc, as I've not used it in some time and may have lost access to it, not sure yet.
I have separate changes to do USB serial port auto-detect on Macs though that was a real hack in the code last time and I'd probably want to revisit the approach so it makes sense for that to be done later.
Roger
Thanks Evan. Looks good to go
It all started behaving itself after that.
This type of Dell LCD monitor is really great as it seems to sync to all sorts of things you throw at it. In the past I recall it even working down to displaying just a handful of active scanlines which it scales up to the full screen.
I do hope that the USB code works out fine operating at 250MHz because having HDMI and USB together is going to be really compelling now and I don't think overclocking it to 250MHz is going to be a drama for many people given the headroom being reported. There's no USB 12 MHz oscillator frequency multiple requirement is there?