Shop OBEX P1 Docs P2 Docs Learn Events
Unable to get Micropython to respond to terminal input — Parallax Forums

Unable to get Micropython to respond to terminal input

pedwardpedward Posts: 1,642
edited 2023-05-31 03:32 in Propeller 2

Long time listener, first time poster :D

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

«134

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?

  • evanhevanh Posts: 15,912
    edited 2023-05-31 03:42

    Where are said instructions?

  • pedwardpedward Posts: 1,642
    edited 2023-05-31 03:46

    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

  • pedwardpedward Posts: 1,642
    edited 2023-05-31 05:39

    Thanks, that did the trick! This is what I did exactly:

    ./loadp2 -p /dev/ttyUSB0 -b 115200 -l 115200 -t -CHIP ~/git/p2nmp_bin/P2uP_1_0_124.binary
    

    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:

  • roglohrogloh Posts: 5,786
    edited 2023-05-31 06:33

    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.

  • @rogloh said:
    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 I Run 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?

  • evanhevanh Posts: 15,912
    edited 2023-06-08 22:04

    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.

  • evanhevanh Posts: 15,912
    edited 2023-06-09 01:27

    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

  • pedwardpedward Posts: 1,642
    edited 2023-06-09 07:45

    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:

    • Use loadp2 to load the oz_fs_up_image.binary into 0x0000
    • wait for blinky
    • unplug propkey from board
    • plug propkey in
    • run loadp2 with 0x0000 address
    • terminal comes up and REPL responds
    • hit reset
    • REPL prompt is displayed
    • P2 does not respond to input
  • 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.)

  • pik33pik33 Posts: 2,366

    @Wuerfel_21 said:
    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

  • @Wuerfel_21 said:
    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.)

    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.

  • Wuerfel_21Wuerfel_21 Posts: 5,051
    edited 2023-06-09 17:05

    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.

  • pedwardpedward Posts: 1,642
    edited 2023-06-09 21:16

    I tried the SD card route, it starts spamming the console with this:

    94  0[fe]
       D B# 02#94 #D B# 02#94 #D B# 02##4 FD#B0#0##9
                                                     F# B0Na2 t4 Fv B0 02 P4 FD B0M02 9c Fr B0Py2 th on  0 #2
                                                                                                             94  D B  0H 9e aDpB0 02S9i  z Be :2  4 1D B0802 94kFB B  0   4 F
     # 02#94##D#B0#02 9# F# B0##2 #4 F# B0 02 #4 FD#B0#02 9
    HD Ba 0  p4 tD r0  2 94 FD B0x024943F4 Bd 09 ,4  D S0 02a94cFDkB  0p 9t rD B0=02 90 Fx Bf 72 64 0D
                                                                                                      B0M02i94cFr Bo 0P y4 tD h0 02n94 FD B0 01 94.FD1B0302-98 F- Bg 42 b4 5D B0b023944Fd B8 0- d4 iD r0 02y94 FDoBn 0  92 0D2B00-2 14 F- B2 82 ;4  D B0202 94BFO BA 0R D4  4 w0 02t94hFD BP 0r 9o pDeB0l02l9e Fr B2 02P94 XD B0C02494MF6 B4 0P 
    D T By p2 e4  D B0h02e94lFp B( 0) "4  D f0 02 r4 FDmB0o02r94eF  Bi 0n f4 oD r0 02a94tFDiBo 0n 9. 
     B> 0> >4  D B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94 FD B0 02 94
    

    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 :D

    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

    'step1.spin2
    'P2 Native MicroPython extensions
    '  Propeller Tool: Press F10 to send this to P2 RAM.
    '     FlexPropGui: Control-R to send this to P2 RAM. Remember to close terminal window afterwards.
    'Upon success, led P56 will remain flashing
    
    'step2.spin2
    'P2 Native MicroPython binary
    'Perform this step after completing Step1, while led P56 is flashing
    '  Propeller Tool: Press F11 to send this to flash
    '     FlexPropGui: Change menu Commands/Configure Commands/Flash Command to
    '                       cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%B" -t -k
    '                       then Control-E to compile-and-flash binary
    
  • 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.

Sign In or Register to comment.