Unable to get Micropython to respond to terminal input
Long time listener, first time poster
So I finally got a P2 Edge board for a project. I installed Micropython per the instructions, and I get the REPL displayed on boot. The problem is that after that the P2 is essentially "dead".
I can input to the terminal and see the blue LED flicker on the Prop Plug, but the red LED is unmoved.
Something feels off here, like the 3 year old build of Micropython isn't compatible or something?
Does anyone have any insight?
Example showing 'shell.c' works:
mounted host file system as /host cmd> ls 1310 LICENSE.txt 2346 README.md 8645 shell.c 750344 shell.p2asm 1707702 shell.lst 147096 shell.binary cmd> cat README.md # Simple shell for copying files
But Micropython is deaf:
######################### # Native P2 MicroPython # # Heap Size: 128 kB # ######################### Heap ptr = 0x434d9, Stack ptr = 0x7f760 MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X 8C4M64P Type "help()" for more information. \>\>\>
(added backslashes because the md parser couldn't deal with the REPL prompt)
I was really hoping to use Micropython, since I've got a board where either a P2 or a Pico will interface, and I think I could run nearly exactly the same code on both.
Thanks,
--Perry
Comments
Hmm thats odd but I vaguely recall something like this, perhaps around xtal or baud rates. I can look at it tomorrow with Ozprop if you don't have it solved by then
which p2 board are you using Perry?
Where are said instructions?
I'm using a P2 edge with the mini breakout board, the promo Parallax was running recently. If baud was a problem, I'd expect the bootstrap process to not work and the REPL to not even display properly. It's like it goes dead after REPL. The last P2NMP release was 3 years ago and even the documentation on getting Micropython (on Linux) required some interpretation of tongues. I'm wondering if the lack of maintenance and testing has caught of with rev E?
I'm guessing you're loading the binary in using FlexProp?
Might be worth trying these loadp2 settings from dgately
https://forums.parallax.com/discussion/comment/1481670/#Comment_1481670
There might also be some other clues in that same thread
Thanks, that did the trick! This is what I did exactly:
It would seem the bootstrapping method with flexprop isn't working properly.
My recollection is a bit vague but I think the size of the image has something to do with it. Happy to add instructions once we know what they need to be, or give you access. I'm glad it wasn't something to do with the oscillator on the edge, which was one difference I don't think we had tested much
Btw P2NMP isn't dead, we're just wrapping up hardware aspects on a longer term project, at some point we'll ask Roger to bring it up to the latest MP version. I watch the monthly MP meetup and news sessions for things that may be relevant to the P2, but there's not that much of relevance - most of the revisions are about streamlining other micros and improving usability/portability. The bytecode engine did get an overhaul not long ago. More recently they have started considering how to approach the multicore problems, which is something we talked with Damien about several years ago when the P2 was taking shape.
Thanks for the update on uP. How many threads can uP run on the P2? The Pico allows for 1 thread plus the main thread, but it's clear the raw horsepower the P2 has just blows the Pico out of the water (at a considerable price difference though).
Here's what I'm working on:
Micropython itself runs its own single COG thread, but (non-MP) COGs can be spawned to do other things such as displaying video output from a frame buffer etc. ozpropdev has an editor environment built around this too.
Ok, so to confirm uP on P2 is single threaded only and you have to spawn other COGs more or less manually?
Do you have any links to examples of starting another COG from uP?
Yeah there was something done here to show a video COG being spawned but I'm not sure whether it still works. I think I had to paste it in smaller chunks to avoid serial buffer overrun (according to comments in the example), but that issue might have only been for the RISC-V variant (Eric's version of MP). YMMV.
https://forums.parallax.com/discussion/comment/1486771/#Comment_1486771
I got this working today:
Hi, so it turns out this problem was not solved.
If I do a loadp2 then uP works after loading, but after reset I don't get any echo from the terminal. It's spitting out text that I can see, so I assume the baud rate is correct.
Is there some magic I'm missing?
To clarify and give more detail. After
loadp2
I am able to talk to the P2. If IRun binary
in flexprop, that works too.The problem is after I burn the program to flash, it boots and displays the prompt, but there is no terminal echo after that.
Is this a serial issue or something else?
I don't know of anyone else having such issue.
loadp2 - a loader for the propeller 2 - version 0.057 Dec 12 2022
PS: That might be my own build date.
Well, it loads the code, because the code runs on startup. Is there a way to do a write-verify on downloads to flash? I want to confirm this isn't a corruption of the download.
Loadp2's
P2ES_flashloader.spin2
doesn't do a verify step, no. Dunno what else there is for Loadp2.Pnut's
flash_loader.spin2
doesn't verify either.I know Proploader verifies on the Prop1.
EDIT: There is Payload or some such with Catalina. Ross will be able to give guidance on how it could be used here.
I think this is some kind of loader offset issue with loadp2
I went back to my flexgui 4.0.6 that we did NMP development work with, from its .config this is what it has stored:
flashcmd {cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b230400 "@0=%D/board/P2ES_flashloader.bin,@1000+%B" -t -k}
So perhaps thats worth a try. Failing that, if there are characters coming up, perhaps a baud rate change is occurring after load for some reason
I have come to the conclusion that the current build of uP is totally broken or the loader barfs.
The uP binary is exactly 512KB, so there is no room for the loader and program in RAM, therefore there must be a resident flasher.
That's what the first bootloader stage appears to be. But I find it stops half the time I exit the terminal.
If you use loadp2 to load the program into RAM, it works fine. If you follow the instructions to flash it, it boots but then appears to just hang. Either that or I have a bad board.
I tried to run proptool on Windows 11 and I get problems with the com port. It ships with unsigned drivers, so I installed the FTDI drivers. It identifies the board, but then throws a "communication stalled due to system problem" error.
I don't understand if I'm the perfect storm or I'm just finding all sort of problems?
Proptool doesn't work on Windows 11, which is every computer sold in the last 4 years.
I've scrutinized the P2ES loader command and made sure the binary is loaded at 0x8000, so I really have no idea what the problem is.
I would like for someone else to try and reproduce by following the exact directions here: https://www.parallax.com/propeller-2/get-started/micropython/
Ok, knowing that the bootloader must be memory resident, I tried this:
Just to take all the flash programming stuff out of the window, try using SD boot (place the file as
_BOOT_P2.BIX
on SD card root. Make sure the card is FAT32. Might need to change the DIP switches.)And then write a tool that will burn the binary fron the SD to the flash sector by sector. The problem seems to be the binary too long, so it is truncated and then cannot work.
I wrote a flasher some time ago. It was written to flash the cog drivers and other resources defined directly as files, so it is not a binary - from - SD flasher. It can be however modified to be one. The bitbanged_flash driver I used can coexist with SD card, although the SD has to be unmounted before flashing. It can be mounted again then, so it should be possible to burn the 512 kB binary in, for example, 128 kB fragments. https://gitlab.com/pik33/P2-retromachine/-/tree/main/Propeller/Burner
You can try this, I know this works reliably as far as REPL etc. We've done a lot of work with exactly that binary image, but mostly with P2Eval boards and Propeller Tool (yes Windows 10). I think the edge drops power to SD card in reset, so it should be reliable now.
I tried SD last night, but didn't work. I need to procure a smallish empty SD card for this. My only unused SD is a 64GB ExFAT card right now.
You can reformat larger cards as FAT32. The 32GB limit is entirely arbitrary. On windows use this: http://ridgecrop.co.uk/index.htm?guiformat.htm
It also doesn't really need to be empty. It always works on my well-filled card, but sometimes there can be issues.
I tried the SD flasher last night, I checked the checksum on the SD card and while the file was 512288 length, the md5sum was different than the uP binary. I'm guessing the SD flasher isn't using the P9 protocol to send files to the SD card for flashing, it's just writing memory to disk.
I then catted the uP binary into the file and that didn't boot, probably the fragmentation thing I'd guess.
From what I can see, the problem is that the flasher program is 32KB and the uP binary is 512KB,
loadp2
wants to load 512KB to P2 memory, but it ends up missing the end of the uP binary.If I load the uP binary to RAM, it runs fine, but there is no zero footprint flasher that I can see.
I tried the SD card route, it starts spamming the console with this:
Every time it boots from SD, it ends up sending the 4 byte string B00294FD over and over.
I tried a fresh FAT32 format, using SD downloader, using
shell.c
to copy it, copying the file directly, etc.At this point I'm issuing a challenge for anyone to get uP working on a P2 Edge from SD or flash
You have to document your steps to win the challenge!
The NMP binary is 512,488 bytes, which is 500KB (but not 512KB)
@pedward are you working with the Step1.spin2 and Step2.spin2 loaders that come in the P2NMP113.zip? Do you get the flashing leds at the end of Step1?
I think i misled on the required flexgui settings, per the Step2 comments, @0= may be required rather than @1000=
cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%B" -t -k
hopefully this is it
Just in case others find this thread in the future, here are the full comments from step1 and step2, from the P2NMP113.zip file
I tried that loader, yes. What I found was that now it stops blinking when I disconnect terminal.
I tried another experiment, it seems that when Flexprop closes the terminal, it resets the propeller.
I loaded a variant of "blink1.spin2" that flashes fast, into flash, so it loads on start.
I run the step1.spin2 and it blinks slower, then close terminal and it blinks fast. This points to the P2 being reset by closing the terminal.
I then tried flashing the step1 loader into flash, but then I realized the first step to loading a program is to reset the P2, so a running program can't negotiate and act as a flash bootstrapper.
There appears to be 511071 bytes of code in the uP blob, which means there is no way it and the flasher can reside in RAM.
Without SD boot, I see no way this could be flashed to a P2 and work. It will run from RAM, but there is not enough RAM to write to flash.
One thing I'm curious about is whether the propkey is supposed to reset the device when you exit the terminal? I found this happens on any terminal program. I'm sure it has something to do with fiddling the DTR? line that is used for /RESn.
I also wonder if my 10yo propkey is compatible with this setup, I don't have a newer one, just the one I got with the DE0 nano Parallax sent me back in the day.