loadp2 loader for P2
ersmith
Posts: 6,053
in Propeller 2
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.
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.
Comments
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?
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
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.
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.
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?
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
Whenever the execution address is below $400, it gets instructions from cog/LUT RAM. It doesn't matter how you get there.
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.
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
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.
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:
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.
Thanks,
Eric
It exists in old and new code so isn't part of the changes.
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; #endifBased on the labelling I presume that call was reloading the parameters without prior changes being set.
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.
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); ...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.
... 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.
This auto-times to P2 clock speeds, and starts download sooner.
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
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 ;echoPS: With the P123 FPGA board I've had all three boards plugged in at times. I could have four with a prop1 board too.Thank you for your help in debugging this!
Eric