Split out of #11, which bundles four RX lifecycle gaps. The PR for #11 implements three of them and deliberately leaves this one out, so it needs its own tracker rather than being closed silently along with the others.
The gap
TRM §6.4.5.2.2.3.6 lists "Optional RX frame size auto shut off" in the Peripheral Interface feature set. It is not modeled. In perif/perif_channel.py::_capture_byte(), reaching rx_frame_size sets rx_eof and zeroes _rx_byte_cnt, but leaves rx_en and _rx_started True, so the oversampler keeps capturing past the end of the frame.
Why it was not simply implemented
Clearing rx_en at EOF is not a local change — it reroutes the firmware's status read. perif/peripheral_interface.py:77:
byte = ch.rx_head() if ch.rx_en else ch.tx_status_byte()
R31 multiplexes on rx_en. Firmware that polls R31 to drain the RX FIFO after EOF would, the instant rx_en self-cleared, start reading the TX status byte instead of FIFO data. For a BiSS-C style read that is an all-ones payload and a CRC error, not a visibly broken model — the failure is silent and looks like a bad encoder.
So there are two coupled questions, and neither is answerable from the TRM text alone:
- Does the hardware really clear
rx_en on frame-size EOF, or does it stop the sampler while leaving the R31 mux pointed at the FIFO? The feature name says "shut off"; the R31 mux description does not say which signal it follows.
- If
rx_en genuinely clears, how does real firmware drain the last bytes? That implies the FIFO must remain readable through some path that the current model does not have.
What would settle it
A capture from real silicon, or a TI-internal answer on whether rx_en (Table 6-80) is cleared by the frame-size auto shut off or only by the r30 write. Guessing either way produces a model that is confidently wrong in a way tests cannot catch, which is worse than the present honest omission.
Related: #2, #3, #4, #5, #10, #11.
Split out of #11, which bundles four RX lifecycle gaps. The PR for #11 implements three of them and deliberately leaves this one out, so it needs its own tracker rather than being closed silently along with the others.
The gap
TRM §6.4.5.2.2.3.6 lists "Optional RX frame size auto shut off" in the Peripheral Interface feature set. It is not modeled. In
perif/perif_channel.py::_capture_byte(), reachingrx_frame_sizesetsrx_eofand zeroes_rx_byte_cnt, but leavesrx_enand_rx_startedTrue, so the oversampler keeps capturing past the end of the frame.Why it was not simply implemented
Clearing
rx_enat EOF is not a local change — it reroutes the firmware's status read.perif/peripheral_interface.py:77:R31 multiplexes on
rx_en. Firmware that polls R31 to drain the RX FIFO after EOF would, the instantrx_enself-cleared, start reading the TX status byte instead of FIFO data. For a BiSS-C style read that is an all-ones payload and a CRC error, not a visibly broken model — the failure is silent and looks like a bad encoder.So there are two coupled questions, and neither is answerable from the TRM text alone:
rx_enon frame-size EOF, or does it stop the sampler while leaving the R31 mux pointed at the FIFO? The feature name says "shut off"; the R31 mux description does not say which signal it follows.rx_engenuinely clears, how does real firmware drain the last bytes? That implies the FIFO must remain readable through some path that the current model does not have.What would settle it
A capture from real silicon, or a TI-internal answer on whether
rx_en(Table 6-80) is cleared by the frame-size auto shut off or only by the r30 write. Guessing either way produces a model that is confidently wrong in a way tests cannot catch, which is worse than the present honest omission.Related: #2, #3, #4, #5, #10, #11.