I made a external housing for input modules, with a USB hub. I’ve tested it, and it works great for both my custom modules (based on the “microcontroller input module” in the framework git repo, as well as one based on the LED Matrix schematics on the git repo) and the framework keyboard. However, when I insert the stock framework LED module, I get unusual behavior: the input module is stuck in RPi bootloader mode, and won’t start up the actual application code.
Flipping the dip switches doesn’t have an effect, and I can insert the card into my framework chassis and it boots up fine. It also enumerates correctly on USB…just as the bootloader device. You can upload new firmware to it, but when it restarts it still stays in bootloader mode.
Some googling I’ve done indicates that the RP2040 getting stuck in bootloader mode can be due to unstable power supplies that glitch the RPi during startup, but in my case this happens during warm boot as well. I’ve commented out all the code related to the --bootloader option in the led Matrix firmware, and the same thing happens, but it’s possible we’re getting into the application code and panicking and the rust runtime is switching us to bootloader mode?
I’m wondering if someone from framework (@nrp?) could tell me if there are any hardware differences on the production led Matrix card, that aren’t in the published amitech schematic, which could lead to this behavior. (It’s known that the published schematic doesn’t match the production module in at least some respects: it is missing a connection for the SLEEP pin.) Are the sleep or board ID pins wired up in some way which could cause this behavior if my external enclosure doesn’t provide them in exactly the same way the FW16 does?
I’ve also tested the LED Matrix against the framework “spring adapter” development card, which framework was kind enough to supply me with, and it works correctly there. The primary differences between my enclosure and the spring adapter are: (a) I have a USB hub upstream so I can supply more than one set of pogo pins, (b) the sleep pin is wired up to the hub suspend signal in what may be a bogus way (but testing on the spring adapter card with the sleep switch set in all different ways doesn’t seem to reproduce this behavior), (c) board ID is left floating, and (d) the 3.3v supply is fed from a 200mA regulator instead of the 600mA regulator on the spring adapter (but I’ve disconnected my on-board regulator and replaced it with a beefy bench 3.3v supply without causing a difference in behavior).
The schematic for my external enclosure PCB on github.
Can anyone offer some ideas on why the production LED Matrix card is getting stuck in bootloader mode? Even just confirming that the wiring of the BOOTSEL, SLEEP, and BOARD_ID pins on the production LED Matrix module matches the Amitech schematic would help me eliminate some possibilities as I try to debug this.