Shop OBEX P1 Docs P2 Docs Learn Events
loadp2 loader for P2 — Parallax Forums

loadp2 loader for P2

Starting a thread for discussing issues related to the loadp2 command line loader for P2 (there was lots of discussion in the fastspin thread, but that's probably not the best place).

The current loadp2 as of this writing is 0.026, 2019-10-21, available on github. It'll be released as part of the 4.0.0 flexgui release.
«13

Comments

  • Cluso99Cluso99 Posts: 18,066
    Eric,
    I've downloaded spingui 4.00 :)

    fastspin seems to be working fine so far :)

    loadp2 is causing me some grief.
    To work, I MUST use the -SINGLE option otherwise it doesn't work properly.
    Caveat: I don't like command lines any more.
    I use this to run loadp2
    loadp2 myfile.binary -b115200 -t -SINGLE
    This is way too much typing. I cannot use a bat file as I regularly update my spin file name with a version number.

    Is there any way to tell (preset) loadp2 that I want SINGLE and set the baud to 115200?
  • Cluso use a parameter in your batch file.

    eg create a batch file "lp2.bat" with the single line
    loadp2 %1.binary -b115200 -t -SINGLE

    then you can just type 'lp2 myfile' and it'll insert the first parameter into the filename and do it

    I do this to process gerber files (rename, zip etc) for different pcb houses
  • Cluso99 wrote: »
    Eric,
    I've downloaded spingui 4.00 :)

    fastspin seems to be working fine so far :)

    loadp2 is causing me some grief.
    To work, I MUST use the -SINGLE option otherwise it doesn't work properly.
    Are you still having that problem with the loadp2 in 4.00? I thought I had fixed 115200 baud (which was the thing that wasn't working).
    Caveat: I don't like command lines any more.
    I use this to run loadp2
    loadp2 myfile.binary -b115200 -t -SINGLE
    This is way too much typing. I cannot use a bat file as I regularly update my spin file name with a version number.

    Is there any way to tell (preset) loadp2 that I want SINGLE and set the baud to 115200?

    In flexgui under the Commands menu there's a "Configure Commands..." dialog box that has the compiler command and the run command. There are buttons to switch to various defaults, but you can also edit the command lines to be whatever you like (so for example in the Run Command that runs loadp2 you could replace "-l230400" with "-SINGLE" and "-b230400" with "-b115200"). Those changes are saved in the .flexgui.config file so they're persistent across FlexGUI invocations.
  • Cluso99Cluso99 Posts: 18,066
    Thanks tubular. It's been so long since I've used the command line.

    Eric,
    loadp2 (flexgui v4.0.0 identifies as v0.019) still requires the -SINGLE command. Otherwise it does not work.
    I suspect it is a download problem as IIRC it appeared was no serial action after the download.

    What does loadp2 do to the reserved hub positions for the clock?
    Perhaps there's a missmatch from what I am trying to do to use a previously loaded value.
  • ersmith wrote: »
    Cluso99 wrote: »
    loadp2 is causing me some grief.
    To work, I MUST use the -SINGLE option otherwise it doesn't work properly.
    Are you still having that problem with the loadp2 in 4.00? I thought I had fixed 115200 baud (which was the thing that wasn't working).
    Ah, I think I remember -- even after fixing the 115200 baud bug your test program didn't work with the fast loader. But it does work with the loadp2 fast loader if I give the -ZERO option to it to force memory to be cleared (the fast loader doesn't clear HUB ram by default).
  • Cluso99 wrote: »
    loadp2 (flexgui v4.0.0 identifies as v0.019) still requires the -SINGLE command. Otherwise it does not work.
    I suspect it is a download problem as IIRC it appeared was no serial action after the download.

    What does loadp2 do to the reserved hub positions for the clock?
    Perhaps there's a missmatch from what I am trying to do to use a previously loaded value.

    Our messages crossed :).

    loadp2 does not do anything to the reserved hub positions for the clock, unless you give the -PATCH option (in which case it writes the loader's frequency and mode into those). With no -PATCH the fast loader goes back to rcfast mode before starting the user program.

    The other difference between -SINGLE and the fast loader is that memory is not zeroed by the fast loader, unless you pass the -ZERO option to it.

    Were you able to change the command line with the "Commands > Configure Commands..." dialog?
  • Cluso99Cluso99 Posts: 18,066
    I shouldn't be relying on hub being cleared - notice I did say shouldn't.
    I have had a number of bugs that also coincided with problems between fastspin and pnut, and a few weirdos too. And I suspect I also have a stack problem too.
    So just wait until I get some of the bugs out and the code is working properly. Then I'll trap why loadp2 isn't working for me. Time is real tight atm :(
  • cgraceycgracey Posts: 14,133
    ersmith wrote: »
    ... The hardware will always treat absolute jumps to below $400 as being into COG or LUT memory. So it's probably a very bad idea to try to hubexec code below $400. Maybe, possibly, a relative jump could be made to hub code in that space (@cgracey, please correct me if I'm wrong). ...

    Whenever the execution address is below $400, it gets instructions from cog/LUT RAM. It doesn't matter how you get there.
  • msrobotsmsrobots Posts: 3,701
    edited 2019-10-14 02:25
    wasn't there something with using odd addresses below $400 for HUBEXEC?

    Mike
  • cgraceycgracey Posts: 14,133
    msrobots wrote: »
    wasn't there something with using odd addresses below $400 for HUBEXEC?

    Mike

    That was a few years ago on the FPGA. We went through a couple iterations on how to discriminate between hub exec and cog exec. At one point, which you are referring to, the PC stepped by 4 while in cog/LUT memory.
  • Cluso99Cluso99 Posts: 18,066
    As Chip said, no hubexec below hub $400.

    If you think about it, the PC (which is 20 bits) cannot tell the difference between cog/lut $000-3FF and hub within that range. Hence, no way hubexec will work below hub $400. There is no extra bit in the PC to say cog/lut or hub!

    We are grateful we got hubexec, and those caveats were readily accepted at the time :)
  • evanhevanh Posts: 15,126
    Code space is quite different to data space. With data there is three separate maps with three separate groups of instructions.

    With code, everything is a single unified map; and excludes the first 1 kByte of hubRAM.

    This 1 kByte boundary creates an amusing overlap with instructions like COGINIT where, when provided with a hub load address of $0, it will load, as data, almost the first 2 kByte of hubRAM into cogRAM, which includes the block $400 to $7df, ie: Dragging in a copy of what is often the first hubexec code.
  • evanhevanh Posts: 15,126
    edited 2019-10-18 12:47
    Eric,
    Something is broken in recent loadp2 on Linux. It messes up a freshly added comport in some manner. A port opened correctly by an older loadp2 it is fine with.

    I note it no longer reports forcing of baud to 115200 any longer ...

    EDIT: Console output:
    Setting load mode to SINGLE
    Loading ad7400.es2.binary - 3008 bytes
    ad7400.es2.binary failed to load
    Error response was ""
    

    EDIT2: There is DTR reset and there is data from PC on pin63 and also responses on pin62. The data sequence on the scope looks basically the same as a good one. I haven't tried to analyse the data but I'd think if the PC was seeing the response then it'd be reporting other than null ...

    EDIT3: There is a visual difference on the scope, about 14.35 ms after end of download the PC sends one dot character (0x2e). This doesn't occur normally from either revision of loadp2 ... EDIT4: Oh, it's an echo of the prop2's response code! Albeit 14.35 ms after the fact.

    PS: I just realised the prop2 is even running the code too. What I thought was another download response from the prop2 is actually the downloaded program running and reporting in.
  • Hmmm, maybe echo is being left on by mistake? I'm not sure. I made a lot of changes to the linux driver recently to allow changing baud and also for MacOS support. Could you try the very latest one from github? It's at v022 now. I think the offending change was one where I used cfmakeraw (as in the Mac) rather than zeroing the termios structure. I've reverted that change so the serial port should be in a more predictable state now under Linux.

    Thanks,
    Eric
  • evanhevanh Posts: 15,126
    edited 2019-10-18 12:14
    Done. About two hours ago I deleted it all and git cloned fresh. Previous pull was maybe two weeks back and it was working. My recovery copy is now from July.
  • evanhevanh Posts: 15,126
    I'm new and unskilled with git. Just before I deleted the loadp2 source directory I was editing the sources and decided to just refresh the whole thing from the master again. What I discovered then was git pull told me it was all up to date. I had a read of the git help but it used so many specific terms that I didn't understand I just gave up, deleted my sources and git cloned again.
  • evanhevanh Posts: 15,126
    High confidence in it being something in or under serial_init(). I'm not seeing anything else changed enough.
  • evanhevanh Posts: 15,126
    edited 2019-10-18 13:43
    Huh, how does this work? "sparm = old_sparm;" Both are a defined same structure type, not pointers. My understanding is C doesn't generate a mem copy for that. EDIT: Double huh, learn something new every day! Apparently a memory copy is exactly what it will do.

    It exists in old and new code so isn't part of the changes.
  • Are you sure you have v022? I made some changes this morning, so you may not have those. If you run just "loadp2" it should print:
    loadp2 - a loader for the propeller 2 - version 0.022 2019-10-18
    

    The code in serial_init() has been changed and should read:
        /* get the current options */
        chk("tcgetattr", tcgetattr(hSerial, &old_sparm));
        sparm = old_sparm;
        
        /* set raw input */
    #ifdef MACOSX    
        cfmakeraw(&sparm);
        sparm.c_cc[VTIME] = 0;
        sparm.c_cc[VMIN] = 1;
    #else
        memset(&sparm, 0, sizeof(sparm));
        sparm.c_cflag = CS8 | CLOCAL | CREAD;
        sparm.c_iflag = IGNPAR | IGNBRK;
        sparm.c_cc[VTIME] = 0;
        sparm.c_cc[VMIN] = 1;
    #endif
    
  • evanhevanh Posts: 15,126
    Ah, it was v21. However, with another git pull just now, the error hasn't changed ... and using the old loadp2 once still fixes it.
  • evanhevanh Posts: 15,126
    I think I got it. I've removed chk("tcgetattr", tcgetattr(hSerial, sparm)); from set_baud().

    Based on the labelling I presume that call was reloading the parameters without prior changes being set.

  • evanhevanh Posts: 15,126
    edited 2019-10-18 15:02
    Multiple tests now done on both revA and revB without issue. Even though the download is small I can still feel the quicker response from the faster default baud now.

    PS: Having now watched it on the scope, at 2 Mbaud, there is notable rounding of the waveform of the data from the USB comport on the Eval boards. Single bit times don't flatten at all. That alone is is setting a real limit for max download speed. The prop2 responses are a lot crisper.
  • evanhevanh Posts: 15,126
    edited 2019-10-18 16:39
    I've done this too
    void hwreset(void)
    {
        int cmd = use_rts_for_reset ? TIOCM_RTS : TIOCM_DTR;
        ioctl(hSerial, TIOCMBIS, &cmd); /* assert bit */
        msleep(2);
        ioctl(hSerial, TIOCMBIC, &cmd); /* clear bit */
        msleep(2);
        ioctl(hSerial, TIOCMBIS, &cmd); /* assert bit */
    }
    
    EDIT: Updated to 2 ms per step. 1 ms still worked but was a tad short for the charge curve on the reset cap.

    It's the reason I did the git pull today. This allows me to reprogram the Flash memory on the Eval boards. Without this faster timing, and with FLASH dip switch on, the boot sequence times-out at 100 ms and stops looking for serial comms before the PC has started trying to send anything.

    And along with that I've adjusted three, I think, associated msleep() timings down to 50 ms. Had to shift the position of one to bring the pair three functions together. Eg:
                ...
                hwreset();
                msleep(50);
                tx((uint8_t *)"> Prop_Chk 0 0 0 0  ", 20);
                ...
    

  • jmgjmg Posts: 15,140
    evanh wrote: »
    PS: Having now watched it on the scope, at 2 Mbaud, there is notable rounding of the waveform of the data from the USB comport on the Eval boards. Single bit times don't flatten at all. That alone is is setting a real limit for max download speed. The prop2 responses are a lot crisper.

    The Eval rev1 Schematic shows quite large 10k isolation resistors in both USB_TX and USB_RX lines, those would really need to be much lower, for 2MBd usage.
    Does the new Eval use the same value ?

    Even 1k has ~3mA contention limit, and 470R will be ~6mA contention.

  • evanhevanh Posts: 15,126
    jmg wrote: »
    The Eval rev1 Schematic shows quite large 10k isolation resistors in both USB_TX and USB_RX lines, those would really need to be much lower, for 2MBd usage.
    Does the new Eval use the same value ?

    Even 1k has ~3mA contention limit, and 470R will be ~6mA contention.
    I didn't think to check the schematic, nor compare revB. RevB is perfect looking square waves. Turns out some 1 nF caps have been added to square things up.

  • evanhevanh Posts: 15,126
    edited 2019-10-19 06:17
                ...
                hwreset();
                msleep(50);
                tx((uint8_t *)"> Prop_Chk 0 0 0 0  ", 20);
                ...
    
    Eric, I've just measured the boot time for the Flash. The first stage completes in around 9 ms after the DTR low going impulse at room temperature. That's when the 100 ms timeout starts. There will be variation on both numbers due to it operating from RCFAST.

    The 50 ms msleep() above feels the right amount of compensating delay. I recommend that be the common delay used after every DTR reset. I guess it could be included in the hwreset() function itself.

  • jmgjmg Posts: 15,140
    evanh wrote: »
                ...
                hwreset();
                msleep(50);
                tx((uint8_t *)"> Prop_Chk 0 0 0 0  ", 20);
                ...
    
    Eric, I've just measured the boot time for the Flash. The first stage completes in around 9 ms after the DTR low going impulse at room temperature. That's when the 100 ms timeout starts. There will be variation on both numbers due to it operating from RCFAST.

    The 50 ms msleep() above feels the right amount of compensating delay. I recommend that be the common delay used after every DTR reset. I guess it could be included in the hwreset() function itself.
    An alternative approach is to send a series of "> Prop_Chk 0 0 0 0 ", and listen for any reply. On reply, the Rx buffer is flushed, and checked. Then Loading can start.
    This auto-times to P2 clock speeds, and starts download sooner.

  • @evanh: I've reduced the delays in line with what you suggested, and also removed some unnecessary hwreset() calls (since we were already resetting the chip when we discovered it). I also added a second set of retries with a longer delay if no chip is detected. This is because when an SD card is present it takes longer for the serial to come up, and that was confounding some of my tests.

    Could you try the latest github please and let me know if it works for you? The version is up to 0.023 now.

    Thanks!
    Eric
  • evanhevanh Posts: 15,126
    edited 2019-10-19 11:13
    ersmith wrote: »
    Could you try the latest github please and let me know if it works for you? The version is up to 0.023 now.
    Fails immediately. There's no reset because, with two Eval boards on the USB hub, I always provide a port name to select the right board, eg:
    filename=Flash_loader_ebh3;   echo; fastspin -q -l -2b ${filename}.spin2; echo; loadp2 -p /dev/serial/by-id/usb-Parallax_Inc_Propeller_P2-ES_EVAL_P23YOO42-if00-port0 ${filename}.binary -v -t ;echo
    
    PS: With the P123 FPGA board I've had all three boards plugged in at times. I could have four with a prop1 board too. :)
  • evanh wrote: »
    ersmith wrote: »
    Could you try the latest github please and let me know if it works for you? The version is up to 0.023 now.
    Fails immediately. There's no reset because, with two Eval boards on the USB hub, I always provide a port name to select the right board,
    D'oh! Yes, of course we need to do a reset in that case. Actually we should probably check to make sure there really is a P2 board on the port as well. I've factored out the code for that and added the reset + check for the case where the port is explicitly given. It seems to work for me, but if you have time could you give this new version (v024) a whirl?

    Thank you for your help in debugging this!
    Eric
Sign In or Register to comment.