After some trial and error as well as help from this community, I can now successfully place the Macropad into bootloader mode. I can also successfully modify QMK firmware for Macropad and compile it into .uf2 file. At this point I am only making simple changes to keymap.c file in order to redefine the keys, nothing fancy. In fact I can verify that the changes I am making do end up in the .uf2 file because:
When I perform binary comparison between “before” and “after” .uf2 files, I can see small number of bytes changed after I change few definitions in the keymap.c file
If I purposefully plant a syntax error in keymap.c, it fails to compile.
So I know that I do deliver the changes into correct source code file and that these changes compile into correct, updated .uf2 file.
Yet, when I try to flash this file into Macropad, it takes it, then reboots as expected (the removable drive disappears), but the Macropad continues to generate keystrokes according to the old keymap, not the one I am trying to flash.
I tried flashing using two methods, result was the same:
Placing the Macropad into bootloader mode and issuing qmk flash -kb framework/macropad -km default command (I am patching default keymap.c file)
Placing the Macropad into bootloader mode and copying applicable .uf2 file directly onto the macropad’s removable drive
Interestingly enough, during about 20 attempts that I have made, once Macropad took my firmware successfully, because it now issues keystrokes for that intermediate version (in which only portion of the desired key was configured correctly). So I know it is possible, but I do not understand what I am doing wrong. I can’t say what exactly I have done differently during that one successful attempt.
I did try removing and re-inserting the Macropad in order to power-cycle it after flashing, it did not help.
Thank you, this appears to be helping resolve the issue. I still do not understand why it would work without explicit EEPROM reset on two other occasions (I had another random occasion of successful re-flashing ever since I posted this thread and read your response), this product is full of mysteries. But at least it seems like I now have a way to reliably flash the Macropad. Once again, thank you for all your assistance!
If you just wish to change key mappings, why change the firmware, when changing eeprom would also do the job?
There are also other tools already available that change mappings.
Even if you want to do more, you’d still start with a small change like altering the keymap, to check that flashing works as expected & there are no issues.
There is a lot you can do that isn’t available in Via. Via doesn’t even offer tap dance or combos. With an RGB keyboard like the macropad, you’re pretty limited in lighting configuration in Via. Also, mouse keys aren’t enabled in the default firmware, (I think that was an oversight).
As I have explained earlier in this post, all these “other tools” do not work reliably even for the simplest tasks of assigning key mappings. I wasted a lot of time with these and half of the keys would not map for no particular reason. Second reason is that all these tools allow you to configure 20 utterly useless animation effects and have other bells and whistles, but do not allow you to set even something as simple as static per-key RGB lighting. So as a software engineer, I would much rather patch the firmware source code than waste my time with these buggy software toys.
I want to put my own code on the RP2040 that is on the macropad. If I do that there’s a good chance the code will get stuck in a loop or whatnot, so I’d need a way to get to mas storage mode to get working code back on there. Are the boot modes I’ve seen hardware or firmware? Is the RP2040 BOOT function somehow tied to hardware?
Is the BOOT signal available somewhere on the PCB?
Are the SWD pins available somewhere on the PCB?
The boot button pretty much just sabotages the flash while the micro is starting and no flash=bootloader mode. You can also deliberately reboot into bootloader mode from software but that may be an issue if you have borked software.
Yes, it sort of does that. There’s a short window at startup where the SS line is an input and the RP2040 samples the state then. If it’s low (there’s a pullup on the input) then the boot ROM is entered. I was wondering if the key matrix had been wired to the BOOT signal.
I’ve wired a switch in now, so I’m OK.
It’s the chip select for the flash, so it kinda is an input of the flash which makes it not talk to the rp204 which in turn makes the rp2040 start in bootloader mode.
Hmm, I don’t think that’s the way it works. From the RP2040 datasheet:
The QSPI_SS signal is a special case. It is connected to the flash directly, but it also has two resistors connected to it.
The first (R2) is a pull-up to the 3.3V supply. The flash memory requires the chip-select input to be at the same voltage
as its own 3.3V supply pin as the device is powered up, otherwise, it does not function correctly. When the RP2040 is
powered up, its QSPI_SS pin will automatically default to a pull-up, but there is a short period of time during switch-on
where the state of the QSPI_SS pin cannot be guaranteed. The addition of a pull-up resistor ensures that this
requirement will always be satisfied. R2 is marked as DNF (Do Not Fit) on the schematic, as we have found that with
this particular flash device, the external pull-up is unnecessary. However, if a different flash is used, it may become
important to be able to insert a 10kΩ resistor here, so it has been included just in case. The second resistor (R1) is a
1kΩ resistor, connected to a header (J2) labelled ‘USB_BOOT’. This is because the QSPI_SS pin is used as a ‘boot strap’;
RP2040 checks the value of this I/O during the boot sequence, and if it is found to be a logic 0, then RP2040 reverts to
the BOOTSEL mode, where RP2040 presents itself as a USB mass storage device, and code can be copied directly to it.
If we simply place a jumper wire between the pins of J2, we pull QSPI_SS pin to ground, and if the device is then
subsequently reset (e.g. by toggling the RUN pin), RP2040 will restart in BOOTSEL mode instead of attempting to run the
contents of the flash.
The important bit is this:
This is because the QSPI_SS pin is used as a ‘boot strap’; RP2040 checks the value of this I/O during the boot sequence, and if it is found to be a logic 0, then RP2040 reverts to the BOOTSEL mode, where RP2040 presents itself as a USB mass storage device, and code can be copied directly to it.
If the SPI flash was just not talking then the RP2040 would crash, rather than run boot ROM code.
Hmm, interesting. Not sure how that works. I suppose the RP2040 starts in ROM and could check that the SPI is working by checking the device ID and then decide to try using it if BOOT isn’t low?
What does your board do?