Release v1.1.2 — real-hardware UART PHY fixes (validated on ESP32-C3)#13
Merged
Conversation
…PHY to POSIX The module defaulted to the virtual PHY, which is implemented with POSIX termios and therefore failed to compile for any real board (ARM/RISC-V). Make the PHY choice track the target: virtual on native_sim/POSIX, UART on real hardware. The virtual PHY now depends on ARCH_POSIX so it cannot be mis-selected off POSIX. The sample no longer hardcodes a PHY.
The DLL booted in SIO mode and only left it upon electrical wake-up detection. A plain UART PHY cannot observe the C/Q wake-up pulse (detect_wakeup == NULL), so a device on real UART hardware stayed in SIO forever and never serviced M-sequences. Start in SDCI when the PHY has no wake-up detection (the already-established-COM contract of the UART PHY), so the device responds to the Master immediately. Verified end-to-end on an ESP32-C3 with a software Master: startup -> PREOPERATE -> OPERATE with checksum-verified Process Data exchange. The virtual PHY implements detect_wakeup, so native_sim behaviour is unchanged (21/21 host unit tests pass).
run_startup_sequence(send_wakeup=False) skips the 0x55 wake-up byte, which is a virtual-PHY simulation of the electrical C/Q pulse and would be spurious data that desynchronises M-sequence framing on a real UART. nucleo_master.py exposes this as --no-wakeup, plus --hold-lines to hold DTR/RTS low for boards whose USB-serial resets on control-line changes (e.g. ESP32-C3 native USB-Serial-JTAG). The wake-up=True path is unchanged, so virtual-PHY tests are unaffected. Verified on an ESP32-C3: --no-wakeup establishes communication to PREOPERATE on the first IDLE frame.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hotfix release surfaced by running the stack on real hardware (ESP32-C3, RISC-V).
Fixes
detect_wakeup == NULL, so a device on real UART hardware stayed in SIO forever and never serviced M-sequences. The DLL now starts in SDCI when the PHY cannot detect wake-up (the already-established-COM contract of the UART PHY).termios), sowest buildfailed for every real board (ARM + RISC-V). The PHY choice now tracks the target (virtual onnative_sim/POSIX, UART on hardware) and the virtual PHY can no longer be mis-selected off POSIX.--no-wakeup/--hold-linesso the software Master drives a real established-COM UART link cleanly.Validation
send/recv_byteround-trip; startup → PREOPERATE (10/10) → OPERATE (15/15) with checksum-verified Process Data (02 A5== device's{counter, 0xA5}).detect_wakeupsonative_simis unchanged.Regression safety
The DLL change only affects PHYs without
detect_wakeup; the Master change leaves thesend_wakeup=Truepath byte-identical.