Skip to content

fix: resolve first-board bring-up issues (power, OLED, XBee diagnostics, button naming) - #53

Merged
thePunderWoman merged 2 commits into
mainfrom
hardware-bringup-fixes
Sep 23, 2026
Merged

thePunderWoman merged 2 commits into
mainfrom
hardware-bringup-fixes

Conversation

@thePunderWoman

Copy link
Copy Markdown
Owner

Summary

Everything found and fixed while doing hands-on bring-up of the first assembled board:

  • Power-button auto-shutdown: the sense pin's polarity was assumed active-high but is actually active-low (external pull-up to 3V3, switch pulls to GND when held) — firmware read the button as continuously held from boot and triggered graceful shutdown 3 seconds into every session.
  • OLED crash when not present: Adafruit_SSD1306::begin() never actually validates I2C ACKs and never allocates its frame buffer unless called — so when the display genuinely isn't there, any later render() call wrote through a null pointer (StoreProhibited panic → boot loop). Added a real I2C presence probe (address 0x3C with 0x3D fallback), a full bus-scan diagnostic when neither responds, and a readiness guard on every OledDisplay method.
  • Serial never reached the USB port: this board has no external USB-UART bridge chip, and ARDUINO_USB_CDC_ON_BOOT wasn't set, so Serial was silently going to unconnected UART0 pins instead of the native USB-CDC port used for flashing/monitoring.
  • Early boot diagnostics getting lost: native USB-CDC has to fully re-enumerate with the host after every reset, which took longer than the firmware needed to reach its first prints — lost even with a monitor already open and watching. Added a bounded (2s) wait for an actual host connection before continuing.
  • XBee bring-up diagnostic: added a boot-time read of the ATTN pin to help separate SPI wiring issues from module/firmware issues in ongoing debugging.
  • Left/Right button naming was backwards: kLeftUp/kLeftDown and kRightUp/kRightDown were mapped to the physically wrong button pairs (Vol/Trigger swapped) — confirmed against the real controller and corrected. Nothing else in the codebase hardcodes the physical mapping, so this one change fixes it everywhere (menu-open combo, uplink suppression, Button Test display).
  • Button Test screen never updated after the first press: the display's redraw logic only watched currentScreen()/selectedMainMenuItem(), not lastTestedButtonIndex() — pressing a button while already on that screen changed neither, so the screen silently never refreshed.
  • KiCad: the OLED Qwiic connector's pin assignment in SnipsControllers:SSD1306_OLED_4pin was wrong on two counts, both found by testing against real hardware — VCC/GND were swapped, and once fixed, SCL/SDA turned out to be swapped too. Both corrected in the symbol (library file + schematic's embedded copy); the PCB itself still needs Update PCB from Schematic (F8) and a small copper rework near the connector for the next revision.

Test plan

  • pio test -e native — 262/262 passing
  • pio run -e esp32s3 — builds clean
  • All fixes verified against real hardware this session: power-button hold no longer triggers spurious shutdown, OLED boot splash renders correctly once the connector was rewired to match the corrected pinout, Serial output reliably visible from the very first boot line, Button Test screen updates live and shows the physically-correct button names
  • XBee SPI communication still failing (ATTN pull-up confirmed intact via the new diagnostic) — separate ongoing investigation, not addressed by this PR

🤖 Generated with Claude Code

thePunderWoman and others added 2 commits September 22, 2026 21:29
…cs, button naming)

Found and fixed during hands-on bring-up of the first assembled board:

- Power-button-sense polarity was inverted (assumed active-high, actually
  active-low via an external pull-up) -- read the button as continuously
  held from boot and triggered an unwanted graceful shutdown 3s into every
  session.
- OledDisplay could crash (StoreProhibited/null-buffer write) whenever the
  display wasn't present, because Adafruit_SSD1306::begin() never
  allocates its frame buffer unless its own begin() is called, and nothing
  else in the call chain checked readiness before rendering. Added a real
  I2C presence check (Adafruit's begin() never actually verifies an ACK)
  with fallback between 0x3C/0x3D, a full bus-scan diagnostic on total
  failure, and a readiness guard on every OledDisplay method.
- Serial never reached the USB port at all: this board has no external
  USB-UART bridge, and ARDUINO_USB_CDC_ON_BOOT wasn't set, so Serial was
  going to unconnected UART0 pins instead of the native USB-CDC port.
- Early boot diagnostics were getting lost even with a monitor already
  open, because native USB-CDC has to re-enumerate with the host after
  every reset. Added a bounded wait for an actual host connection before
  continuing.
- Added an XBee ATTN pin read at boot to help isolate SPI wiring issues
  from module/firmware issues.
- Buttons::kLeftUp/kLeftDown and kRightUp/kRightDown were mapped to the
  physically wrong button pairs (Vol/Trigger swapped) -- confirmed against
  the real controller and corrected.
- The Button Test screen never updated after the first button press --
  the display's change-detection only watched currentScreen()/
  selectedMainMenuItem(), not lastTestedButtonIndex(), so pressing a
  button while already on that screen never triggered a redraw.
- KiCad: the OLED Qwiic connector's pin assignment in
  SnipsControllers:SSD1306_OLED_4pin was wrong on two counts, both found
  by testing against real hardware -- VCC/GND were swapped, and once that
  was fixed, SCL/SDA turned out to be swapped too. Both corrected in the
  symbol (library file + schematic's embedded copy); the PCB itself still
  needs Update PCB from Schematic + a small copper rework for the next
  rev.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@thePunderWoman
thePunderWoman merged commit 2b4a10b into main Sep 23, 2026
2 checks passed
@thePunderWoman
thePunderWoman deleted the hardware-bringup-fixes branch September 23, 2026 04:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant