Shop OBEX P1 Docs P2 Docs Learn Events
Testing new P2 EVAL RevB board with glob-top chip — Parallax Forums

Testing new P2 EVAL RevB board with glob-top chip

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.
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

«134

Comments

  • evanhevanh Posts: 15,126
    The 5 Volts at the headers is not powered by default on the revB boards. There is a jumper, ACC HDR 5V, for powering them all up.
  • evanhevanh Posts: 15,126
    You've reminded me to check the PLL limit for the revB chip. I'm getting 418 MHz at 22 °C with a /10 XDIVP and 412 MHz with /2 XDIVP, which is about 10 MHz faster than the revA chip I have. Sounds about right from what I expected.
  • ... 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!

    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.
  • evanhevanh Posts: 15,126
    And at /1 XDIVP, where the revA chip would crash on 390 MHz when the temperature is above 20 °C and the PLL didn't lose lock, it now works for both 390 and 400 MHz at 22 °C. Amazingly it runs this simple toggle at 410 MHz but quickly drops towards 400 MHz in a few seconds as it has obviously lost lock! So, the line between stable PLL and stable core is now very close.

    With the simplest code the PLL limit is reachable, but only just.

  • evanhevanh Posts: 15,126
    edited 2019-09-17 18:17
    Waahoo! /10 at -3.5 °C rakes in 445 MHz PLL limit!
    /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 too had a late night working with Rev B and hit a hurdle with the streamer.
    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.
  • 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.

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-09-17 22:22
    WTG guys!

    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 :smiley::smiley::smiley::smiley::smiley::smiley: (6 stars out of 5)
  • RaymanRayman Posts: 13,797
    ozpropdev wrote: »
    I too had a late night working with Rev B and hit a hurdle with the streamer.
    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.

    That doesn't sound good...
  • Tested VGA and for some reason it's not working. Tested wave audio and that plays fine but doesn't use streaming modes. I will have to investigate further.
  • rogloh wrote: »
    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.

    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.

    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.
  • Good work Eric, thanks.
    btw, I'm still using your old loadp2.
    loadp2 - a loader for the propeller 2 - version 0.005, 2018-04-04
    
  • Rayman wrote: »
    ozpropdev wrote: »
    I too had a late night working with Rev B and hit a hurdle with the streamer.
    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.

    That doesn't sound good...

    Don't Panic Rayman!
    Got things working Ok now. :)
    Getting some sleep and setting correct mode made all the difference. :blush:
  • Cluso99Cluso99 Posts: 18,066
    Good work Eric, thanks.
    btw, I'm still using your old loadp2.
    loadp2 - a loader for the propeller 2 - version 0.005, 2018-04-04
    

    I have
    loadp2 - a loader for the propeller 2 - version 0.016 2019-09-12
  • Just checked the VGA timing to see what was happening and only the software vsynch is working. I will check the streaming modes and make some updates.
  • evanhevanh Posts: 15,126
    Ha, I've been using -SINGLE with loadp2 so hadn't hit that bug.
  • ersmith wrote: »

    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.

    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!
  • Cluso99Cluso99 Posts: 18,066
    Peter etc
    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.
  • evanhevanh Posts: 15,126
    Tested VGA and for some reason it's not working. Tested wave audio and that plays fine but doesn't use streaming modes. I will have to investigate further.
    Expect every program that uses a streamer to fail due to new mode encodings. All streamer modes have new mode numbers now. There is additional modes and some old modes have new config bits or just remapped for consistency.

  • evanh wrote: »
    Tested VGA and for some reason it's not working. Tested wave audio and that plays fine but doesn't use streaming modes. I will have to investigate further.
    Expect every program that uses a streamer to fail due to new mode encodings. All streamer modes have new mode numbers now. There is additional modes and some old modes have new config bits or just remapped for consistency.

    Yes, I'm pleased that pretty much everything just works. Just sharing my unboxing experiences moment by moment :)
  • roglohrogloh Posts: 5,122
    edited 2019-09-18 01:47
    By the way, I noticed in MainLoader1.spin2 of loadp2 there is this line:
    waitx   ##20_000_000/100        'wait 10 ms
    
    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.

  • @ersmith , your updated version of loadp2 seems to let me download to the rev B EVAL board now with the two step download -CHIP option which is good. It doesn't contain the auto detect or the 2Mbaud features I created in my older variant of loadp2 for the Mac, but when I can I'll try to merge those features into this newer codebase and supply it.

  • evanhevanh Posts: 15,126
    Cluso99 wrote: »
    Peter etc
    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.

    Pin58 floating (Lead-in is press-release of reset button)
    pin_lat0162.PNG

    Pin58 with 10k pull-up to 5V (Lead-in is press-release of reset button)
    pin_lat0161.PNG

    Pin58 floating (When reset button released)
    pin_lat0164.PNG

    Pin58 with 10k pull-up to 5V (When reset button released)
    pin_lat0163.PNG
    640 x 480 - 7K
    640 x 480 - 7K
    640 x 480 - 7K
    640 x 480 - 7K
  • roglohrogloh Posts: 5,122
    edited 2019-09-18 03:59
    @ersmith , I have some changes to enable higher baud rates like 2000000 on Macs using your latest loadp2 codebase I grabbed today. I fixed your Makefile to enable it to also build Mac specific code and put in the higher baud rate changes to the osint_linux.c file. This Makefile.txt is just renamed from Makefile to let me post it here.

    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-09-18 05:22
    evanh wrote: »
    Cluso99 wrote: »
    Peter etc
    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.

    Thanks Evan. Looks good to go :)
  • cgraceycgracey Posts: 14,133
    Does anyone have any lingering streamer issues? I need to finish the streamer documentation, but the modes are all listed there.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-09-18 06:15
    The descriptions are different and I haven't familiarised myself with them .properly. The VGA code uses 7f00_0000 and çf00_0000 and I quickly changed them to 7f08 etc. But it's still not quite right. Mind you, I didn't have much time to read it through so a quick hint should help me on my way.
  • The descriptions are different and I haven't familiarised myself with them .properly. The VGA code uses 7f00_0000 and çf00_0000 and I quickly changed them to 7f08 etc. But it's still not quite right. Mind you, I didn't have much time to read it through so a quick hint should help me on my way.
    I found for VGA I had to change the CF00_0000) values to 7F01_0000.
    It all started behaving itself after that. :)
  • roglohrogloh Posts: 5,122
    edited 2019-09-18 08:28
    Was able to download and run my prior p2gcc based Micropython binary and run Chip's earlier HDMI demo on this rev B EVAL board. The colourful 16bpp bird image presented looks very nice (albeit upside down) on my old Dell 2405FPW which syncs fine to the 640x350 image it is being sent. Don't notice any shimmer or pixel sparkles etc with the magnifying glass. Sending over a 1.8m HDMI to DVI cable with the Digital Video Out breakout board. The rev B P2 chip is barely even warm at 250MHz.

    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?
  • VonSzarvasVonSzarvas Posts: 3,272
    edited 2019-09-18 08:14
    All these step-by-step updates are a joy to read. Thanks guys for sharing, so we can all follow along.
Sign In or Register to comment.