Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 146 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1143144146148149160

Comments

  • cgraceycgracey Posts: 14,131
    edited 2018-05-30 18:20
    I could certainly compile special versions for the DE0-Nano and BeMicro-A2. I just need the new ROM source.
  • jmgjmg Posts: 15,140
    edited 2018-05-30 19:45
    ersmith wrote: »
    The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.

    A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
    I requested an autobaud echo some time ago, but that never made the cut. Such an echo is useful for fastest reset exit from a host-boot MCU.

    The shortest query to get a response response string from the booter is the "> Prop_Chk 0 0 0 0 " which echoes 13,10,"Prop_Ver ","A",13,10
    A waiting host MCU can send "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 "..


    There may be shorter ones that can hop to other parts of ROM, and hop back to booter ?

    Not clear if those shorter ones could work as packed strings at the full baud rate ? ie some delays might be required.
  • I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).

    SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".

    However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.


  • cgraceycgracey Posts: 14,131
    garryj wrote: »
    I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).

    SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".

    However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.


    The SD card has the pull-up built-in.

    I will modify PNut soon to allow for longer
    response times, so that it will work with SD cards.

    Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
  • I will have a look at that SD fail timing shortly....
  • Cluso99Cluso99 Posts: 18,066
    ersmith wrote: »
    v32i seems to be working on my DE2-115; at least, I'm able to get into TAQOZ and the P2-MONITOR.

    The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.

    A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
    Yes. It was removed due to space. :(
  • Cluso99 wrote: »
    Yes. It was removed due to space. :(

    At the end of it we still had a whopping 58 bytes "wasted" :) It might be an idea to allow for it in the next ROM source as an option (just in case). I will be testing better versions of the ROM (just in case).

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 01:39
    BAD SD CARD BOOT - 100ms
    I've popped an old 256M card in and booted the P2 which of course fails SD boot. I've then been able to go into TAQOZ and confirm boot failure. The time from first boot activity to fail is about 100ms. ( I will do another post for a good card but no boot files as it will take longer to boot) (Also another one for pull-up only)
    SD%20FAIL.png

    Confirming SD detection and failure:
    Cold start
    ----------------------------------------------------------------
      Parallax P2  .:.:--TAQOZ--:.:.  V1.0--142          180530-0135
    ----------------------------------------------------------------
    TAQOZ# SD? . -1 ok
    TAQOZ# !SD .L $0000_0000 ok
    TAQOZ# 0 0 cmd . 1 ok
    
    It responds to a CMD0 which says it is a real SD card.
    Next I force a crc just for this command since it is still in SD mode and check CMD8.
    TAQOZ# $87 $34 C!  ok
    TAQOZ# $1AA 8 CMD .W $0005 ok
    
    I repeatedly test but we need a response of 1 and this old card is not able to accommodate a $1AA capabilities.

    SD%20INIT.pngSD%20INIT%20STATES.png
    800 x 480 - 55K
  • Cluso99Cluso99 Posts: 18,066
    Is it fat32 ?
  • Cluso99 wrote: »
    Is it fat32 ?
    No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.

    My next few posts will be testing:
    1) Pull-up only
    2) Good card - non-FAT32
    3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 01:39
    PULL-UP on SD CS but no SD - 2ms
    The case of a pull-up on SD CS but no SD isn't too bad. Most of the time seems to be taken up with the slow clocking before checking which I am fairly sure is not required of SDHC cards. However, it is only 2ms.
    SD%20PULLUP%20ONLY.png

    Confirming the pullup where SD? tests for a pullup and returns true/false where -1 is true. Then CMD0 with data of 0 (0 0 CMD) returns with 0 which could even be $FF if it were pulled up on the DO line but we are looking for a $01.
    TAQOZ# SD? . -1 ok
    TAQOZ# 0 0 CMD . 0 ok
    

    Confirming that slow clocking is NOT required I insert a card, check it for pull-up, and issue a raw CMD0 without anything else.
    TAQOZ# SD? . -1 ok
    TAQOZ# 0 0 CMD . 63 ok
    TAQOZ# 0 0 CMD . 193 ok
    TAQOZ# 0 0 CMD . 1 ok
    
    The card responded after the 3rd try which is well within what we expect and allow for. Timing this without clocking:
    TAQOZ# BEGIN SD? UNTIL 5 ms LAP BEGIN 0 0 CMD 1 = UNTIL LAP .LAP 8475 cycles = 105.937us  ok
    

    Type a ^X to repeat the last line executed returns the exact same result:
    TAQOZ# 8475 cycles = 105.937us  ok
    

    So we could know within around 100us or so that it is a real SD card.
    800 x 480 - 49K
  • jmgjmg Posts: 15,140
    cgracey wrote: »

    I will modify PNut soon to allow for longer response times, so that it will work with SD cards.

    Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.

    is there any down side to having a longer timeout ?
    Or you could simply continually repeat send of the Autobaud + query, checking for a reply - that auto-adjusts to any variable path delays.
    You could allow the user to stop after some seconds, or just have some umbrella timeout


  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 01:38
    SD BOOT - NEW BLANK FAT32 - 193ms
    Now here's another boot fail case I added, one where we insert a brand new FAT32 card that is blank. The SD booter still goes through the motions looking for a raw file before checking the root directory which is blank. Total time spent here is 193ms.
    SD%20FAT32%20BLANK.png

    Confirming it is blank and nothing, not even deleted entries in the root directory:
    TAQOZ# SD?  ok
    TAQOZ# DIR .SDSL08G 3230_3631 NO NAME    32k 7,576M
    .SDSL08G 3230_3631 NO NAME    32k 7,576M
     ok
    TAQOZ# @ROOT FOPEN 0 $80 SD DUMP 
    00000: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00010: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00020: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00030: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00040: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00050: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00060: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00070: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................' ok
    
    800 x 480 - 47K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 01:38
    NON-FAT32 SD BOOT FAIL - 320ms
    I tried formatting an SD card to NTFS just to give the SD booter something tough to chew on. It seems NTFS is just unpleasant with a timeout of 320ms.
    SD%20NTFS%20BOOT%20FAIL.png
    TAQOZ# SD? . -1 ok
    TAQOZ# !sd .L $C0FF_8000 ok
    TAQOZ# MOUNT ...NCard 0000_0100  Y    u q  4k 0M ok
    TAQOZ# DIR 
    ...NCard 0000_0100  Y    u q  4k 0M
     ok
    TAQOZ#
    
    800 x 480 - 51K
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 01:38
    FAT32 - MANY FILES BUT NO BOOT - 244ms
    I noticed that this old 4G card had been formatted in a PC incorrectly. Always use a proper SD Formatter utility.
    Nonetheless, after searching the root directory it timed out after 244ms.
    SD%20FAT32K%20POOR%204K%20SECT%20-%20FILES%20BUT%20NO%20BOOT.png
    TAQOZ# SD? . -1 ok
    TAQOZ# !SD .L $C0FF_8000 ok
    TAQOZ# MOUNT .SM00000 F184_E94B WIDGET     4k 3,758M ok
    TAQOZ# DIR 
    .SM00000 F184_E94B WIDGET     4k 3,758M
    WIDGET       $0000_42AC   2015.02.21.14.52   0
    HOME    .HTM $0000_42C4   2015.02.17.15.19   68,037
    P8CPU   .JPG $0000_434C   2015.02.17.15.18   67,271
    IOTPINS .JPG $0000_43D4   2015.02.17.15.15   40,010
    LOVE    .WAV $0000_4424   2015.02.16.18.06   14,630,692
    MENU    .TXT $0007_3E8C   2014.01.20.22.59   1,556
    EXTEND  .FTH $0000_B3EC   2015.02.16.15.31   99,338
    P8      .H   $0000_B4B4   2015.02.13.23.44   1,401
    EASYNET .FTH $0000_B4BC   2015.02.13.15.19   37,673
    W5500   .FTH $0000_B50C   2015.02.13.01.50   14,872
    EASYFILE.FTH $0000_B52C   2015.02.12.18.48   45,794
    SDCARD  .FTH $0000_B58C   2015.02.12.18.22   16,343
    IOT5500H.JPG $0000_B5AC   2014.11.20.14.07   28,237
    DRAGON  .JPG $0000_B5E4   2014.11.20.10.31   376,830
    AI o T 5. 5  $0250_42AC   1980.02.07.00.02   4,294,901,760
    IOT5500 .JPG $0000_B8C4   2014.11.18.21.25   83,571
    128K    .BIN $0000_B96C   2014.11.06.16.49   131,072
    256K    .BIN $0000_BA6C   2014.10.28.07.59   262,144
    W5200   .FTH $0000_BC6C   2014.09.28.23.19   19,889
    SYSTEM  .ROM $0000_BC94   2015.02.25.15.05   65,536
    WELCOME .TEL $0000_BD14   2014.06.19.18.36   212
    WELCOME .FTP $0000_BD1C   2014.06.19.18.34   140
    DEBUG   .ROM $0000_BD24   2014.06.19.18.31   65,536
    POPCORN .WAV $0000_BDA4   2014.06.17.16.15   117,804
    P8X32A  .PDF $0000_BE8C   2014.06.17.15.07   1,442,886
    IMAGE3       $0000_C994   2014.06.15.23.54   80,286
    FRED    .PNG $0000_CA34   2014.06.15.15.44   7,935
    FSRSCH  .PNG $0000_CA44   2014.06.15.15.44   99,235
    FSRPCB  .PNG $0000_CB0C   2014.06.15.15.44   64,764
    IMAGE        $0000_CB8C   2014.06.15.15.44   16,204
    HTTP404 .HTM $0000_CBAC   2014.06.15.15.44   564
    IMAGE2       $0000_CBB4   2014.06.15.15.44   51,347
    IMAGE1       $0000_CC1C   2014.06.15.15.44   12,500
    LOGON   .HTM $0000_CC3C   2014.06.15.15.44   388
    TACHYON .HTM $0000_CC44   2014.06.15.15.43   159,937
    SITE0004.LOG $0000_CD84   2014.02.24.14.31   1,048,576
    SITE0003.LOG $0000_D584   2014.02.24.14.31   1,048,576
    SITE0002.LOG $0000_DD84   2014.02.24.14.31   1,048,576
    SITE0001.LOG $0000_E584   2014.02.24.14.31   1,048,576
    FAVICON .ICO $0000_ED84   2013.12.17.09.57   8,069
    SYSLOG  .TXT $0000_ED94   2013.12.03.01.56   1,048,576
    HCB4208 .JPG $0000_F594   2013.06.20.20.45   340,668
    CHARLCD .JPG $0000_F834   2013.03.25.11.30   45,446
    ECOLCD  .PDF $0000_F894   2012.05.24.21.20   342,919
    LOVE    .MP3 $0000_FB34   2012.02.13.00.26   3,981,374
    FIRMWARE.ROM $0001_199C   2015.02.25.16.32   65,536
    EASYNET .AVI $0001_1A1C   2015.02.25.17.04   8,651,838
    EASYNET2.OGV $0005_29C4   2015.02.23.12.48   69,830,407
    Bm - 2 R. P  $0000_42AC   2107.15.31.31.63   4,294,967,295
     . g o u. t  $0398_42AC   1980.03.18.00.03   6,357,093
    GOUTPU~1     $0000_42AC   2015.02.26.14.59   0
    EASYNET3.AVI $0004_666C   2015.02.25.15.10   25,601,912
     ENU2   .TXT $0007_3E8C   2015.02.26.15.17   1,556
    MENU1   .TXT $0000_B3C4   2015.02.26.10.57   19,948
    TAQOZ# @BOOT FOPEN 0 $100 SD DUMP 
    00000: EB 58 90 6D  6B 66 73 2E  66 61 74 00  02 08 20 00     '.X.mkfs.fat... .'
    00010: 02 00 00 00  00 F8 00 00  10 00 04 00  00 08 00 00     '................'
    00020: 00 70 75 00  4E 1D 00 00  00 00 00 00  02 00 00 00     '.pu.N...........'
    00030: 01 00 06 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    00040: 80 01 29 4B  E9 84 F1 57  49 44 47 45  54 20 20 20     '..)K...WIDGET   '
    00050: 20 20 46 41  54 33 32 20  20 20 0E 1F  BE 77 7C AC     '  FAT32   ...w|.'
    00060: 22 C0 74 0B  56 B4 0E BB  07 00 CD 10  5E EB F0 32     '".t.V.......^..2'
    00070: E4 CD 16 CD  19 EB FE 54  68 69 73 20  69 73 20 6E     '.......This is n'
    00080: 6F 74 20 61  20 62 6F 6F  74 61 62 6C  65 20 64 69     'ot a bootable di'
    00090: 73 6B 2E 20  20 50 6C 65  61 73 65 20  69 6E 73 65     'sk.  Please inse'
    000A0: 72 74 20 61  20 62 6F 6F  74 61 62 6C  65 20 66 6C     'rt a bootable fl'
    000B0: 6F 70 70 79  20 61 6E 64  0D 0A 70 72  65 73 73 20     'oppy and..press '
    000C0: 61 6E 79 20  6B 65 79 20  74 6F 20 74  72 79 20 61     'any key to try a'
    000D0: 67 61 69 6E  20 2E 2E 2E  20 0D 0A 00  00 00 00 00     'gain ... .......'
    000E0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................'
    000F0: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00     '................' ok
    
    800 x 480 - 51K
  • cgraceycgracey Posts: 14,131
    Thanks for the timing data, Peter.

    I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one. When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one.
    Faster sounds better ...
    cgracey wrote: »
    When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
    A blind scan is useful for easily setting things up initially, but it's not going to be the default development loop, surely ?
    Few would want all serial ports being messed with.

    Options are to save the port the P2 was found on, in a file, and start there next time, and to support command line param saying which explicit port to use ?
    You could alternatively do 2 scan passes, one more rapid one that expects serial-default, and then a slower one for the fall-back choices ?
  • cgraceycgracey Posts: 14,131
    Jmg, yes, the last-working port is remembered during the run-life of PNut.exe. The first download takes a bit longer than the rest. We could bother to save the port number to disk, as well.
  • I've compiled all this SD boot information here in this pub doc from which you can jump to the original doc.
  • cgraceycgracey Posts: 14,131
    I've compiled all this SD boot information here in this pub doc from which you can jump to the original doc.

    Looks good. Thanks, Peter.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 02:35
    Hey Chip, do you think you could update the front page of the docs with an image of the P2 chip artwork including a status box outlining that the chip and P2 ROM have been submitted and a rider about the hazards of internal "alpha" sampling but with a confident note about the expected positive outcome and maybe when chips are available etc? The image will make it seem more real to many. A block diagram up here would also be super.

    I'd like to use this document as a reference but if you also publish this Google doc it will be more readily accessible to those who are just casually perusing the document and if you include a link in your document to this pub doc and vice versa then anyone can click to see the original etc.
  • cgraceycgracey Posts: 14,131
    Peter, I sort of did it. No talk about "alpha sampling", though.
  • cgracey wrote: »
    Peter, I sort of did it. No talk about "alpha sampling", though.
    Thanks, I was thinking of a "fine print" rider, maybe down in a footer just so they've been told and you are covered since everyone will ask
    "Great! but when?".

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 04:35
    As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
    P2DIAGRAM.png
    Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
    742 x 741 - 86K
  • cgraceycgracey Posts: 14,131
    As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
    P2DIAGRAM.png
    Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.

    Looks good, Peter. Jazz it up if you want and we can put it in there.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-31 06:06
    Keep an eye on the drawing file in the P2/docs dropbox folder. There's also a pdf version that I will keep updating. Just for now, these are the bits I'm playing with but I'm a long way off yet (complete with errors - for the moment)
    Updated!
    p2art-3.png
    632 x 834 - 109K
  • cgraceycgracey Posts: 14,131
    edited 2018-05-31 05:10
    Super, Peter!

    It is looking kind of like a sunflower.
  • evanhevanh Posts: 15,091
    Yes, good work Peter. The Cogs look much fuller.

    Along with the CORDIC and PRGN, there is also CT counter and the LOCK flags. That would round it off. There is plenty more but it would just get messy I'd say.

  • Cluso99Cluso99 Posts: 18,066
    Maybe that should have been printed on the chip packaging ;0
  • Cluso99Cluso99 Posts: 18,066
    Cluso99 wrote: »
    Is it fat32 ?
    No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.

    My next few posts will be testing:
    1) Pull-up only
    2) Good card - non-FAT32
    3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
    What response are you seeing to the CMD8 Peter?
Sign In or Register to comment.