Closed cjmarsden1701 closed 2 years ago
Is it somehow possible by changing micropython-picow.cmake? After removing the blocking comment the uf2 is not recognized by thonny. Randomly excluding other parts (for more RAM) didn't help.
I'm also experiencing this issue with a Pico W
The libraries for Unicorn Pack and Scroll Pack have been temporarily removed from the Pico W MicroPython build as they need some refactoring before they will work.
(I think including them in their current state causes the problems with Thonny that @yresk encountered above...)
Thanks for confirming @helgibbons - will be good when they're back in :)
Thanks for confirming @helgibbons . Will Pimoroni be updating the product details on the web site to indicate there is a compatibility issue?
@yresk it's only Pico Unicorn and another product that really allocate any significant RAM, and they do so whether they're in use or not. I have a work-in-progress fix for this which you might want to try. See this commit- https://github.com/pimoroni/pimoroni-pico/commit/da88573c8f1a9b035c30352416b021b53d757f3d
@Gadgetoid After updating I tried the branch "patch-picow-memory-issues" -> thonny can't find the board "git checkout main" -> rebuild -> thonny finds the board (of course without unicorn)
I used mircopython 5bf3765631e645412dbd62a616cfdadeca5ea0c3.
Is there a simple way to build the pico w image? I extracted the info from micropython-picow.yml and setting-up-the-pico-sdk.md and I get the image somehow. I tried "act" on the repo, but it terminates quickly.
I was able to build with the da88573 commit and successfully light up the leds. Haven't run in to any other issues so far. Because it took quite a bit of research, I'll provide the commands I used here.
sudo apt install cmake gcc-arm-none-eabi build-essential ccache
mkdir pico
cd pico
git clone -b master https://github.com/raspberrypi/pico-sdk.git
cd pico-sdk/
export PICO_SDK_PATH=$(realpath .)
git submodule update --init
cd ..
git clone -b master https://github.com/raspberrypi/pico-examples.git
git clone -b master https://github.com/micropython/micropython.git
cd micropython
git checkout 5bf3765631e645412dbd62a616cfdadeca5ea0c3 # had build issues with the latest master, this commit worked (thanks @yresk)
git submodule update --init -- lib/pico-sdk lib/tinyusb
cd ..
git clone https://github.com/pimoroni/pimoroni-pico.git
cd pimoroni-pico
git checkout da88573c8f1a9b035c30352416b021b53d757f3d
git submodule update --init
cd ..
cd micropython/ports/rp2/
make BOARD=PICO_W submodules
cmake -S . -B build-PICO_W -DPICO_BUILD_DOCS=0 -DUSER_C_MODULES=../../../pimoroni-pico/micropython/modules/micropython-picow.cmake -DMICROPY_BOARD=PICO_W -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache
cmake --build build-PICO_W -j 2
The firmware image will be at build-PICO_W/firmware.uf2
in the micropython/ports/rp2
directory.
@RedKrieg 💯 points for your thoroughness. Thank you!
tl;dr: thx to @RedKrieg and @Gadgetoid / building on arm macos does not produce a working uf2
First I tried the commands listed by @RedKrieg, slightly adjusted for the macos shell. The uf2 fails. Building the main branch works. Because apparently at least three other persons got it to work I switched the system from macos 12.4 (arm M1max) to Ubuntu-20.04 within the WSL on Windows 11 (Intel). It took 2.5 hours to build (fallback to -j1), but that uf2 works. I tried the rainbow.py sample and a webserver sample.
Looks like there's a good chance these changes actually work as expected- thank you for forging ahead and testing them. Aim to get these in a release today as I try to claw back our regular release schedule!
tl;dr: thx to @RedKrieg and @Gadgetoid / building on arm macos does not produce a working uf2
There's something extremely weird or marginal going on, since the CI (which grabs the same compiler version I use on my local machine) is also failing to build a working .uf2, yet my own local build seems to work.
This should - hopefully - work as of https://github.com/pimoroni/pimoroni-pico/releases/tag/v1.19.4
@yresk if you still have a broken .uf2, could you ping over the accomanying .elf file? Or run:
arm-none-eabi-nm --demangle=gnu-v3 --print-size --size-sort firmware.elf | grep d_print_comp_inner
@Gadgetoid I can confirm that the 1.19.4 release is working as well as my custom build for me. Thank you.
Still cannot build a working micropython/unicorn uf2 on the Mac.
The older working uf2 and the non-responding uf2 both have d_print_comp_inner.
The problem seems to be in PicoUnicorn::init. If I add a "return;" before the first access of bitstream the uf2 is responsive (the unicorn parts of course don't work). Even if I add "bitstream[0]=0;" before the added "return;" the uf2 does not start up. I tried:
All these variants freeze after transferring the uf2. I have no idea left, what the compiler or linker are doing there. I also tried "bitstream" as static member or tried to allocate at runtime. Then the uf2 boots but the rainbow.py example freezes the pico and leaves the unicorn with vertical stripes.
pimoroni-pico/examples/pico_unicorn and pimoroni-pico/examples/pico_unicorn_plasma build on the same Mac both work.
I tried it on Intel and Arm Mac (brew tap ArmMbed/homebrew-formulae; brew install arm-none-eabi-gcc)
But I updated my Linux-only device from Ubuntu 18.04 (cmake to old) to 22.04 and the uf2 built there is OK!
I can confirm that Version 1.19.6
resolves the issue for me. Is anyone still experiencing it?
Hopefully recent builds should be Unicorn-friendly - but feel free to reopen if you're still having issues!
Is there an issue with the pico W micropython firmware? Trying to run a pico unicorn with a new pico w and can't import picounicorn. It works on older firmware but I need network support.