ITM: don't test reserved bits in is_fifo_ready #219
Conversation
On ARMv7-M, bits 31:1 of the value read from STIMx are reserved, so comparing them against zero is a bad idea. On ARMv8-M, bit 1 has been repurposed to indicate DISABLED. This means that the is_fifo_ready impl hangs forever when ITM is disabled on a Cortex-M33 (for example). Changed to test only the FIFOREADY bit.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thejpster (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
S-waiting-on-review
|
Build succeeded: |
|
Ugh. So, I have bad news. On the one hand, this change makes v7-M more correct. On the other hand, it turns out that this isn't sufficient to fix v8-M. Here's the deal.
So, on reset, with no debugger attached, if one wants ITM writes to succeed, you've got two options:
While ARM described the bits on ARMv7-M as reserved, if you look at their pseudocode, they're treating anything other than 0 as ready to write. This logic works on both v7-M and v8-M but is technically dealing in reserved bits. I'm happy to fix this either way, but I wonder if anyone has a strong opinion on approach? |
|
Ah, that's a nuisance! I think architecture-specific logic is the way to go then. Keep the current behaviour for thumbv7 and add the alternative check of DISABLED and FIFOREADY for thumbv8. We already do this sort of check extensively in this crate so I don't see any reason not to do it here. |
227: ITM: don't test reserved bits in is_fifo_ready r=adamgreig a=bcantrill This is a follow up to the discussion in #219, capturing the conclusion by @cbiffle and @adamgreig there: to indicate that the ITM FIFO is ready on FIFOREADY (only) on ARMv7-M (only) and to indicate the FIFI is ready on *either* FIFOREADY *or* DISABLED on ARMv8-M. ITM has been tested and verified on an ARMv7-M CPU (an STM32F407, a Cortex-M4) and an ARMv8-M CPU (an LPC55S69, a Cortex-M33). Without this fix, any use of ITM will hang on ARMv8-M -- which may in fact be the root cause of #74... Co-authored-by: Cliff L. Biffle <[email protected]>
219: Inline attr. macro docs and fix links r=therealprof a=jonas-schievink This makes `cortex-m-rt-macros` purely an implementation detail, so I've put a warning in place to reflect that. This should close rust-embedded/cortex-m-rt#138 Co-authored-by: Jonas Schievink <[email protected]>
On ARMv7-M, bits 31:1 of the value read from STIMx are reserved, so
comparing them against zero is a bad idea.
On ARMv8-M, bit 1 has been repurposed to indicate DISABLED. This means
that the is_fifo_ready impl hangs forever when ITM is disabled on a
Cortex-M33 (for example).
Changed to test only the FIFOREADY bit.
@bcantrill