shims: let the transceiver boot before clocking SPI - #4
Open
ericrwx wants to merge 1 commit into
Open
Conversation
ericrwx
force-pushed
the
fix-reset-settle-delay
branch
2 times, most recently
from
July 28, 2026 21:28
bcbad63 to
87350fb
Compare
mmhal_wlan_hard_reset() waited 20ms after releasing RESET_N. That covers the reset pulse but not the transceiver's boot, and the SD over SPI startup handshake begins clocking as soon as it returns: a training sequence, then a poll for the command response, well over a thousand clock edges. A transceiver that is still booting can latch onto a bit phase that is not byte aligned with the host's framing and hold it for the rest of the boot. The symptom is misleading. Every SPI transfer succeeds and the response itself is intact, just offset by a few bit periods, so the driver rejects it as an invalid ack and the failure presents as absent or faulty hardware. It is intermittent, and more likely on boards where concurrent activity delays the handshake relative to the reset. Wait CONFIG_MM_RESET_SETTLE_MS before the first clock edge instead. This is Kconfig rather than a constant because the delay a board needs depends on its transceiver and firmware image, so a board with a known-shorter boot can tune it down. The 20ms default is unchanged for backwards compatibility, but systems that need a longer duration can now override this. For example, on an ESP32-C5 with an MM8108, boots failed at 20ms and were clean from 30ms upward; a reset settle delay of 100ms would provide a safe margin to ensure successful transceiver boot. Signed-off-by: Eric Wang <eric@rwx.one>
ericrwx
force-pushed
the
fix-reset-settle-delay
branch
from
July 30, 2026 01:27
87350fb to
243f91a
Compare
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
2 participants
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.
Problem:
mmhal_wlan_hard_reset() waited 20ms after releasing RESET_N. That covers the reset pulse but not the transceiver's boot, and the SD over SPI startup handshake begins clocking as soon as it returns: a training sequence, then a poll for the command response, well over a thousand clock edges. A transceiver that is still booting can latch onto a bit phase that is not byte aligned with the host's framing and hold it for the rest of the boot.
The symptom is misleading. Every SPI transfer succeeds and the response itself is intact, just offset by a few bit periods, so the driver rejects it as an invalid ack and the failure presents as absent or faulty hardware. It is intermittent, and more likely on boards where concurrent activity delays the handshake relative to the reset.
Fix:
Wait CONFIG_MM_RESET_SETTLE_MS before the first clock edge instead. This is Kconfig rather than a constant because the delay a board needs depends on its transceiver and firmware image, so a board with a known boot time can tune it up or down.