Is there a Recommendation for Binary Distribution of P2 code?

Larry Martin · 2024-05-02 12:54

I need a way to distribute P2 executables without exposing my source code. In P1, I use propeller.exe to compile a .eeprom file, then bundle that in a ZIP with propeller.exe and a batch file:
propellent /eeprom filename.eeprom

Onsite maintainers then ran that batch file on their Windows computer and the new code loads.

I'm not finding equivalent P2 functionality in pnut (v42s) or loadp2 (version 0.054 Apr 24 2022). Pnut can Flash but does not seem to understand its own BIN or OBJ output files. loadp2 will load the pnut BIN file but I don't see a command line switch for Flash. Plus, it looks like the target isn't really running, so the BIN format probably isn't really compatible.

What's the right way to do this? Thanks!

Wuerfel_21 · 2024-05-02 14:04

loadp2 can flash, but the command to do it is non-obvious. The P2 has no built-in flashing program, so it has to be loaded in manually. Something like loadp2 "@0=P2ES_flashloader.bin,@8000+program.bin" (If you have a flexprop installation, the flashloader stub is in the board directory, not sure where it originally comes from)

Another option is to just create a source file consisting only of

DAT
file "program.bin"

and have PNut compile and load that.

Or just give them the actual source code, it's just the right thing to do, really.

Rayman · 2024-05-02 15:17

FlexProp can flash binary files onto P2. I'd suggest distributing that:

https://github.com/totalspectrum/flexprop/releases/tag/v6.9.4

Larry Martin · 2024-05-02 20:35

Thank you for your suggestions. None work out of the box.

In all cases, my BIN file is made by PNut_v42s.exe with the -c switch. Is that a problem?

I should have said, I am loading via PropPlug. My board is a Prop1 design with a Prop2 wedged in there for obvious reasons, but without neat new P2 attachments like an SD card that can be used for firmware update. I generally use Pnut in a batch file with the -r or -f flag as needed, and a line to show error.txt at the end.

@Wuerfel_21 #1:
loadp2 "@0=P2ES_flashloader.bin,@8000+TCUv4P2_EIM_U_HF_AllFeig.bin"
gives me a blue light on my PropPlug, indicating something happened, but afterwards the board is dead on RS232 and telltale LEDs are not lit. So I think the code is not running, or running "wrong." Placing a '$' before the $8000 made it worse. P2ES_flashloader.bin is also compiled by Pnut (edit).

@Wuerfel_21 #2:
Claims to work but board is dead:
cat zzz.spin2 DAT file "TCUv4P2_EIM_U_HF_AllFeig.bin" PNut_v42s.exe zzz.spin2 -f cat Error.txt okay
Same symptoms as #1

@Rayman :
Starting flexprop in the distribution folder so it can find the TCL stuff, the menu Commands, Flash Binary File, gives me a dialog about switches, then lights up the PropPlug for a second and finally brings up an ANSI terminal which I just killed. After that, the board is RS232 dead and LEDs off, as above. Thinking the BIN format might be a problem, I went to compile with Flexprop, but it does not like my SPIN2 either - it chokes on some inline assembly that compiles in Pnut and works in real life.

I can't believe I am the first P2 user to need this capability, but I guess we're all learning. Could you use a hand with one of the software projects?

Rayman · 2024-05-02 20:46

Interesting... In my experience, Flexprop can compile anything that PropTool can. But, PNut can sometimes be ahead of PropTool and FlexProp.
There is a new versioning thing, but I don't remember anything new having to do with inline assembly...

But, you are saying this is a custom board. Are you sure it is designed to boot from flash?

Flashing from PNut should work. You might be missing a pullup on the board to let it boot from flash...

Larry Martin · 2024-05-02 20:58

@Rayman said:
Interesting... In my experience, Flexprop can compile anything that PropTool can. But, PNut can sometimes be ahead of PropTool and FlexProp.
There is a new versioning thing, but I don't remember anything new having to do with inline assembly...

But, you are saying this is a custom board. Are you sure it is designed to boot from flash?

Flashing from PNut should work. You might be missing a pullup on the board to let it boot from flash...

Flashing from PNut does work, and the board boots afterward whether the PropPlug is in place or not. When I build in the lab, or when I am at the customer site, that's all I need. It's now time to send a firmware update. This is how we've done it in P1 since 2011 or so:
https://gluelogix.com/Downloads/TCU3xFirmwareUpdate_RevC_31Dec2015.pdf

This is the project:

ersmith · 2024-05-02 21:01

@Wuerfel_21 said:
loadp2 can flash, but the command to do it is non-obvious. The P2 has no built-in flashing program, so it has to be loaded in manually.

Actually new-ish versions of loadp2 have a -SPI flag to copy applications to flash, and that's what flexprop uses now to flash. This uses the same loader as PNut does, so it should be compatible.

@"Larry Martin" said:
I'm not finding equivalent P2 functionality in pnut (v42s) or loadp2 (version 0.054 Apr 24 2022). Pnut can Flash but does not seem to understand its own BIN or OBJ output files. loadp2 will load the pnut BIN file but I don't see a command line switch for Flash. Plus, it looks like the target isn't really running, so the BIN format probably isn't really compatible.

This is probably the first thing to try to fix -- before trying to flash the program, make sure you have something that can run on the board stand-alone. If you compiled with debug enabled PNut may be doing something funny behind the scenes. I also have a vague memory that PNut emits a .BIN2 file that's the actual binary that should be loaded, but it's been a while since I looked. In most cases you should be able to compile your application with flexspin to get a .binary file that loadp2 will run, and that's the way I usually do it.

ersmith · 2024-05-02 21:06

@"Larry Martin" said:
Thinking the BIN format might be a problem, I went to compile with Flexprop, but it does not like my SPIN2 either - it chokes on some inline assembly that compiles in Pnut and works in real life.

Can you share the error message (and ideally the inline assembly code) with us? Also, you could try using FlexProp's P2 bytecode mode -- its inline assembly takes a different path which is more likely to be compatible (because it doesn't need to mesh with the assembly generated by the compiler).

I can't believe I am the first P2 user to need this capability, but I guess we're all learning.

You're definitely not the first P2 user to need this, and others have managed it successfully, so it is possible. There's just something you're doing differently that tools writers haven't expected yet.

Larry Martin · 2024-05-02 21:22

In Weurfel_21 #1, I changed the loader to flash LEDs that exist on my board, and recompiled to BIN in Pnut. The LEDs do not flash at the end of programming.

orgh $8000 size long @code_end - @code 'located at Flash address $8000 code 'example code indicating programming suceeded drvh #4 drvh #5 rep @.floop, #0 'loop forever toggling the LEDs outnot #4 outnot #5 waitx ##(25_000_000/4) .floop

After programming and after board reset, the board is still "dead" as described before. The only thing that gets function back is
PNut_v42s.exe TCUv4P2_EIM_U_HF_AllFeig.spin2 -f

Is this what's supposed to be happening:
1. Loadp2 reads in both BIN files
2. LoadP2 loads the loader at address 0 in on-chip RAM
3. LoadP2 loads my BIN file at address $8000 in on-chip RAM
4. LoadP2 runs the loader, which copies code from $8000 of internal memory to - what - address 0 of external Flash?
5. LoadP2 hangs out blinking lights until I reset the board, and my code is read from external serial Flash.

#58,spi_do,spi_di,spi_clk,spi_cs
My PIO58 connects to SDO of the external chip, PIO59 to SDI, PIO60 to CLK and PIO61 to CSn. And the whole thing works with PNut and source. So I think my I/O is right.

Larry Martin · 2024-05-02 21:34

Weurfel_21 #1 WORKS with JonnyMac's FDS Demo Bin. So it's something about my BIN file. But I just recompiled the loader in Pnut42, so that rules out format issues.
loadp2 "@0=P2ES_flashloader.bin,@8000+jm_FDS_DEMO.bin" WORKS
loadp2 "@0=P2ES_flashloader.bin,@8000+TCUv4P2_EIM_U_HF_AllFeig.bin" FAILS

ls -l (Cygwin on Win11):
-rwxrwx---+ 1 Larry Larry 30460 May 2 17:07 TCUv4P2_EIM_U_HF_AllFeig.bin
-rwxrwx---+ 1 Larry Larry 5668 Sep 29 2023 jm_FDS_DEMO.bin

I don't see a magic number at the start of any of the three BIN files. Is it size?

Wuerfel_21 · 2024-05-02 21:47

P2 binaries don't have any sort of header. They're just RAM images that load in and start executing (effectively coginit(0,0,0)).

If none of the binaries you build with PNut work, maybe you're doing it wrong. I haven't used it in a while, so I don't remember what the correct way is.

Rayman · 2024-05-02 21:57

Suppose it could be some kind of serial error on large file.
loadp2 might have some switches to specify a lower baud?
Are you using the same flash chip as Parallax?

Rayman · 2024-05-02 22:10

@"Larry Martin" Maybe try using the "file" directive to include a larger and larger files to make the binary bigger and see where it goes off the rails?

Also, I seem to remember the loader having a 2 stage feature that one can turn off, if having issues with high speed loading...

Larry Martin · 2024-05-02 22:24

@Wuerfel_21 said:
P2 binaries don't have any sort of header. They're just RAM images that load in and start executing (effectively coginit(0,0,0)).

If none of the binaries you build with PNut work, maybe you're doing it wrong. I haven't used it in a while, so I don't remember what the correct way is.

The boot loader P2ES_flashloader.bin that I built with pnut worked with loadp2 and JonnyMac's application BIN.

Larry Martin · 2024-05-02 22:28

@Rayman said:
Suppose it could be some kind of serial error on large file.
loadp2 might have some switches to specify a lower baud?

Good thinking, I'll try that on Saturday.

Are you using the same flash chip as Parallax?

Winbond W25Q128JVSIM TR, works with PNut -f

Rayman · 2024-05-03 01:18

Might want to see if serial port has a timeout setting issue

evanh · 2024-05-03 05:16

What is the compile error that Eric is asking about? https://forums.parallax.com/discussion/comment/1559174/#Comment_1559174

Rayman · 2024-05-04 12:06

I might be seeing the same issue with this micropython binary just made... it's 230kB or so. Flashes and runs on P2 Eval, but not on my board. No errors when flashing, but doesn't run... Can't believe haven't seen this before...

Uh Oh, even 28kB binary won't run when flashed... I may have a bigger issue here... Very strange because I know this used to work...

Hmm... Loading flash from code works, but not from binary... Maybe this is the same problem?

Rayman · 2024-05-04 12:23

Truly strange, but using PropTool like @Wuerfel_21 suggested works:

DAT
file "firmware.bin"

Works also with PNut, but not FlexProp? This also works with Spin Tools IDE
I think @Wuerfel_21 knows what's going on here, need to include some flash loader stub to make it work...

Rayman · 2024-05-04 12:42

This works with Eval board but not my board.... Strange:
c:\FlexProp\bin\loadp2 "@0=C:\FlexProp\board\P2ES_flashloader.bin,@8000+firmware.bin"

Rayman · 2024-05-04 12:46

Ok, the above does work on one of my boards with better overclocking.
Must be that P2ES_flashloader.bin is using some insane clock speed for some reason...

Rayman · 2024-05-04 12:58

Actually, looks like P2ES_flashloader is set for 160 MHz, so not exactly sure why doesn't work...
But, here I've dropped it to 80 MHz and now seems to work with my board like so:

c:\FlexProp\bin\loadp2 "@0=C:\FlexProp\board\SimpleP2_flashloader.binary,@8000+firmware.bin"

ersmith · 2024-05-04 13:00

@Rayman said:
This works with Eval board but not my board.... Strange:
c:\FlexProp\bin\loadp2 "@0=C:\FlexProp\board\P2ES_flashloader.bin,@8000+firmware.bin"

How about c:\FlexProp\bin\loadp2 -SPI firmware.bin ? That uses the same flash programming method as Chip's SPI flash loader.

Rayman · 2024-05-04 13:07

-SPI doesn't work?

Invalid option -SPI
loadp2 - a loader for the propeller 2 - version 0.060 Sep 23 2023
usage: loadp2

ersmith · 2024-05-04 13:59

@Rayman said:
-SPI doesn't work?

Invalid option -SPI
loadp2 - a loader for the propeller 2 - version 0.060 Sep 23 2023
usage: loadp2

You need a new loadp2. The one that comes with recent-ish FlexProps (e.g. 6.8.x or 6.9.x) has that option.

Rayman · 2024-05-04 14:26

@ersmith Yes, that seems to work.

Larry Martin · 2024-05-04 16:28

@ersmith, thanks for jumping in. loadp2 -p com19 -SPI TCUv4P2_EIM_U_HF_AllFeig.bin works for me with the loadp2.exe from flexprop 6.9.4. I do have to reset my board after I load my BIN file (30460 bytes) but not JonnyMac's FDS_DEMO.bin (5668 bytes). I think I can add manage to add a reset to my batch file. My OP problem is solved! Here is some more info:

@rayman slowed down loader in comment #22:
loadp2 -p com19 "@0=SimpleP2_flashloader.binary,@8000+jm_FDS_DEMO.bin" loadp2 -p com19 "@0=SimpleP2_flashloader.binary,@8000+TCUv4P2_EIM_U_HF_AllFeig.bin"
Works with JonnyMac's FDS_DEMO.bin (no reset required) but not with my big BIN file (not even after a reset, not even with the new loadp2). I slowed XMUL further, from 8 down to 4, and got the same results.

@rayman comment #19, FlashBinary.spin2:
This works for me now. I thought it was not working on Thursday, but there is an extra step. I have to reset the target board after flashing my big BIN this way. The explicit reset is not needed for the small FDS_DEMO.bin, or when I flash from source using PNut. I was doing the reset check on Thursday just to be thorough, but I may not have tried it at just the right time to prove this technique. In any case it works, and so does my zzz.spin2 from comment #4:
PNut_v42s.exe zzz.spin2 -f

Larry Martin · 2024-05-04 16:53

@ersmith said:

@"Larry Martin" said:
Thinking the BIN format might be a problem, I went to compile with Flexprop, but it does not like my SPIN2 either - it chokes on some inline assembly that compiles in Pnut and works in real life.

Can you share the error message (and ideally the inline assembly code) with us? Also, you could try using FlexProp's P2 bytecode mode -- its inline assembly takes a different path which is more likely to be compatible (because it doesn't need to mesh with the assembly generated by the compiler).

Here is my code compiling OK on PNut:
PNut_v42s.exe TCUv4P2_EIM_U_HF_AllFeig.spin2 -c >cat Error.txt okay

FlexSpin chokes on MultiPortSerial210216c.spin2, straight out of OBEX:
>flexspin TCUv4P2_EIM_U_HF_AllFeig.spin2 Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc. Version 5.9.10 Compiled on: Apr 24 2022 TCUv4P2_EIM_U_HF_AllFeig.spin2 |-MultiPortSerial210216c.spin2 C:/GlueLogix/Development/Products/LineLogix/EncodeInMotion/TcuV4Spin/P2/MultiPortSerial210216c.spin2:173: error: syntax error, unexpected '[', expecting end of line or ',' C:/GlueLogix/Development/Products/LineLogix/EncodeInMotion/TcuV4Spin/P2/MultiPortSerial210216c.spin2:596: error: syntax error, unexpected identifier setq' C:/GlueLogix/Development/Products/LineLogix/EncodeInMotion/TcuV4Spin/P2/MultiPortSerial210216c.spin2:614: error: syntax error, unexpected identifiertestb' \<10 more\>

FlexProp chokes when my inline assembly (in a PUB method) accesses stack variables for that method. The exact error message is "Variable ??? must be placed in memory" Screenshot:

Wuerfel_21 · 2024-05-04 17:12

When you use flexspin on the command line you need to add -2 to enable P2 mode.

Larry Martin · 2024-05-04 17:17

@Wuerfel_21 said:
When you use flexspin on the command line you need to add -2 to enable P2 mode.

Good tip, but it still dislikes this line: txDelay long 0-0[MAX_PORTS_8]
>flexspin -2 TCUv4P2_EIM_U_HF_AllFeig.spin2 Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc. Version 5.9.10 Compiled on: Apr 24 2022 TCUv4P2_EIM_U_HF_AllFeig.spin2 |-MultiPortSerial210216c.spin2 C:/GlueLogix/Development/Products/LineLogix/EncodeInMotion/TcuV4Spin/P2/MultiPortSerial210216c.spin2:173: error: syntax error, unexpected '[', expecting end of line or ','
There are no further error messages, so I guess -2 let it digest setq, testb, testp, etc.

Wuerfel_21 · 2024-05-04 19:31

Version 5.9.10 Compiled on: Apr 24 2022
Ancient version, bug has been fixed some while ago

The must be placed in memory error is caused by a particular issue: To be used in inline assembly, the variable needs to be stored in a register. To be able to take the address of a variable (@ operator), it needs to be stored in memory. So you can't do both. Additionally, for compatibility edge-case reasons, if one variable is in memory, all variables in that function need to be (I actually made a PR the other day to mostly fix that one...). (In PNut, this issue doesn't come up because variables are always stored in memory and are copied into registers at runtime, which leads to a different annoying limitation, wherein only the first 16 variables on the stack frame can be used in inline ASM).

Is there a Recommendation for Binary Distribution of P2 code?

Comments