I wanted to remap some keys in the firmware of my Pocket’s keyboard, swapping ; and ' mainly, and so I followed the instructions in the handbook. It doesn’t mention installing the pico-sdk-source package, which seems to be needed by the build script (maybe this needs to be in install-fw-dependencies?) and also, to copy it to the keyboard, it says to run sudo picotool load build/pocket-hid.uf2 -f --bus 1, which in my case accidentally flashed the keyboard firmware to the system controller. That could be because I’m on the A311d module and not the standard one? But still.
This is in the PDF and HTML versions. After re-flashing the system controller with the right firmware (after first disassembling and getting it to stop sending an infinite string of ts), I noticed there’s a flash.sh script in the pocket-hid folder, which worked fine.
Anyway. I don’t know if those docs are maintained, but it might help the next person to fix them up.
The Pocket Reform has two RP2040 in it: one in the keyboard and one as the sysctl. Could the --vid and --pid be passed to picotool load to select the correct device? At least the picotool help load output suggests that these options exist. On the other hand, when I try to use either I get:
ERROR: unexpected option: --vid
Maybe @zeha has an idea how to better use picotool and properly select the correct device to flash?
Ouch, what a bother.
Yes, the docs are getting new revisions. I am trying to submit issues and MRs to the respective git repos in the hope that they help to improve things.
Do you have an account on source.mnt.re? Then you could submit issues yourself as well.
Yeah, I realized a couple days after I filed this that I should have filed proper bug reports over on source.mnt.re. I’ve been working on a different project, building a new case for the pocket around a 19mm spaced ergo keyboard. (since it’s significantly wider, all the guts should fit in the base, so just the screen is in the lid). Even after some remapping, I’m really finding the keyboard too cramped. I was going to sell it a while back, but playing with it a bit reminded me how neat it really is.
I’m also realizing my system might’ve been in a weird state (the programming switch may have been ‘ON’) because I had issues earlier and had poked around inside looking for issues. If the system is in its default state, I don’t think the switch is on, so the system controller shouldn’t be programmable, right?
IIRC one needs to use --ser and pass the serial number. This works when the pico is in flash mode (otherwise you cannot use picotool anyway).
The program switch is (ttbomk) necessary if the sysctl pico doesn’t properly boot/respond for some reason. Otherwise you can use reform-mcu-tool to put it into flash mode (or use fwupd).
I think something is broken here actually: install-fw-dependencies clones the pico-sdk repository but fails to use it. My suspicion is that it used to need the latest from git, but now appears to work fine with the pico-sdk in Debian? There was a point where I had to do some manual workarounds to get it to build but I don’t think I wrote them down.
You need the serial number of the pico device which was running. IOW before you triggered the reset into bootloader mode.
I’m not sure exactly how picotool does the serial number check, but I’m seeing the same behaviour - after entering bootloader mode the serial number of the device changes to some E0C… string.
The serial number that is necessary (in my case) starts with DE…
If your device is supported by reform-mcu-tool, it prints the --ser value after triggering bootloader mode. Just in case you want to crosscheck the values.
