Skip to content

fix(firmware): bound the Power Good wait so a stuck PG line cannot block boot - #628

Open
jsschwrz wants to merge 1 commit into
Cephla-Lab:masterfrom
jsschwrz:fix/firmware-pg-bounded-wait
Open

fix(firmware): bound the Power Good wait so a stuck PG line cannot block boot#628
jsschwrz wants to merge 1 commit into
Cephla-Lab:masterfrom
jsschwrz:fix/firmware-pg-bounded-wait

Conversation

@jsschwrz

@jsschwrz jsschwrz commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

init_power() spun in an unbounded while (!digitalRead(pin_PG)) inside setup(),
so a Power Good line that never asserts hangs the controller before loop() is
ever reached. The board still enumerates over USB, because Teensy 4.1 brings USB
up in startup code before setup() runs — so the failure presents exactly like a
bad flash: the port opens, and then zero bytes forever.

On the CustomerBuild20260802 demo unit PG does not assert even with the controller rail
powered and reseated, which makes the stock firmware unbootable on that hardware.

Wait up to 2s for PG, then continue regardless. The wait is bounded rather than
removed outright: where PG does work, this still lets the rail settle before
init_stages() configures the TMC4361A/TMC2660 drivers over SPI. Note that a board
booted with the rail down will now configure those drivers against a dead rail,
so bring rail power up before power-cycling the Teensy.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

…ock boot

init_power() spun in an unbounded `while (!digitalRead(pin_PG))` inside setup(),
so a Power Good line that never asserts hangs the controller before loop() is
ever reached. The board still enumerates over USB, because Teensy 4.1 brings USB
up in startup code before setup() runs — so the failure presents exactly like a
bad flash: the port opens, and then zero bytes forever.

On the CustomerBuild20260802 demo unit PG does not assert even with the controller rail
powered and reseated, which makes the stock firmware unbootable on that hardware.

Wait up to 2s for PG, then continue regardless. The wait is bounded rather than
removed outright: where PG does work, this still lets the rail settle before
init_stages() configures the TMC4361A/TMC2660 drivers over SPI. Note that a board
booted with the rail down will now configure those drivers against a dead rail,
so bring rail power up before power-cycling the Teensy.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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