fix(fdcan): model asynchronous TX so TXBRP polling blocks (#336)#342
Open
w1ne wants to merge 1 commit into
Open
fix(fdcan): model asynchronous TX so TXBRP polling blocks (#336)#342w1ne wants to merge 1 commit into
w1ne wants to merge 1 commit into
Conversation
TXBRP now stays asserted from the TXBAR write until the next tick(),
matching real M_CAN behavior where the bit clears only after the frame
leaves the node on the physical bus. The completion flags (TXBTO,
IR.TFE, IR.TC) are posted in drain_pending_tx(), called at the start
of every tick().
Previously, request_tx() resolved everything synchronously: firmware
polling `while (TXBRP & 1) {}` never blocked, so the simulator
false-passed code that called NVIC_SystemReset before its CAN frame
was actually transmitted (the udslib #88 failure class).
Frame delivery to loopback/bus/tx_frames is also deferred to tick()
so the frame and the completion flags are always consistent.
The new txbrp_stays_set_until_tick_then_txbto_is_set integration test
covers the issue directly. Existing tests updated to tick once after
TXBAR before inspecting completion state.
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
1 participant
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.
Summary
request_tx()previously resolved TXBRP→0, TXBTO, and IR flags synchronously on the TXBAR write, so firmware pollingwhile (TXBRP & 1) {}never blocked in simulation.NVIC_SystemResetbefore its CAN frame was actually transmitted — the udslib fix: wire I2C1 into STM32F401 descriptor #88 failure class that FDCAN async-TX needed: #88 reset smoke false-passes a firmware that resets before TX-complete #336 tracks.request_tx()now sets TXBRP and queues the frame intopending_tx;drain_pending_tx()(called at the top oftick()) does the actual delivery and posts completion flags. TXBRP stays asserted from the TXBAR write until the next tick, matching real M_CAN silicon behavior.Changes
crates/core/src/peripherals/fdcan.rs: addedpending_tx: VecDeque<(u32, CanFrame)>field; split the old synchronousrequest_txbody into a deferreddrain_pending_txcalled fromtick(); updatedtxfqs()to reflect pending count.crates/core/tests/fdcan.rs: new testtxbrp_stays_set_until_tick_then_txbto_is_setproves the fix; three existing bus-interconnect tests updated to tick the transmitting node before the bus tick (required because the frame now reaches the channel indrain_pending_tx).fdcan.rsmod tests): 7 tests that asserted completion state immediately after TXBAR updated to calldev.tick()first.Test plan
cargo fmt --all -- --checkcleancargo clippy --all-targets -- -D warningscleancargo test -p labwired-core --lib fdcan— 16/16 passedcargo test -p labwired-core --test fdcan— 4/4 passed (including newtxbrp_stays_set_until_tick_then_txbto_is_set)cargo test --workspace --lib— all passedcargo test -p labwired-core --test h563_conformance— 6/6 passedCloses #336