Repository navigation
regression: timeout waiting for breakpoint with cortex-m-rt 0.7.1 #426
Description
(This originally started as knurling-rs/probe-run#316. I have tracked the issue down to the cortex-m-rt 0.7 branch and so am filing a new, more specific, issue here.)
I have been trying to update the nucleo-h743zi crate to use the latest cortex-m-rt and am hitting a timeout error when probe-run attempts to start and debug the board with newly flashed firmware. It does so by setting a hardware breakpoint and then running. I assume the expected breakpoint is never hit, and so probe-run does not enter the expected state and throws a timeout error.
This timeout is a regression from cortex-m-rt 0.6.15, where the issue does not happen. Using git bisect on the archived https://github.com/rust-embedded/cortex-m-rt, I discovered that the first commit with the problematic behavior is rust-embedded/cortex-m-rt@1fd84a8. Unfortunately the relevant issues at play here are outside my familiarity and it would be slow going for me to pursue this further.
Activity
kelleyk commentedon Apr 7, 2022
Thanks @astraw for all of the effort so far in tracking down the culprit commit!
I've run into this issue as well. I'm using Nucleo-H745ZI-Q boards, which are very similar to the Nucleo-H743ZI2-Q boards except that the STM32H745 has a Cortex-M4F core onboard (which, for the purposes of this issue, I'm not using).
I haven't had a chance to really dig in myself, but I just noticed that in the current version of
link.x.inmany of the changes that rust-embedded/cortex-m-rt@1fd84a8 made have been unwound.From some quick reading around bf99836 (which did a bunch of that unwinding), I found a few PRs/issues that look like they might be relevant:
Is it possible that this is a similar problem?
kelleyk commentedon Apr 8, 2022
The project where I ran into this problem was based on @antoinevg's BSP for the Nucleo boards (https://github.com/antoinevg/nucleo-h7xx and https://github.com/antoinevg/hello-nucleo-h7xx); I ran into the problem when upgrading dependencies, much like what @astraw mentioned trying to do.
I just tried something simpler---I cloned a fresh copy of https://github.com/stm32-rs/stm32h7xx-hal (
masteris 884a50b) and tried to build and run one of the examples.... and it works! I was using probe-run v0.2.6 (the latest that supports defmt v2) and then upgraded to probe-run v0.3.3 (the latest release), which behaves identically. I also tried checking out
v0.11.0of the HAL (the latest release), and it works just fine as well.I think that there's something about these BSP crates that is causing trouble when we try to upgrade versions in existing projects.
kelleyk commentedon Apr 8, 2022
I've just followed the instructions in https://github.com/knurling-rs/app-template and that works perfectly, too. One of the steps there is to copy over
memory.x(the memory layout) from the HAL crate, and I notice that that is different from the version in the project that was giving me trouble. I wonder if the trouble is because I didn't re-copy that file when upgrading the version of thestm32h7xx-halcrate that I was using.astraw commentedon Apr 8, 2022
Thank you so much. This solves the local issue for my case.
Could cortex-m-rt (or some other crate) could do a check (ideally compile-time) that the memory layout is as expected and give an explicit and clear error if not?
adamgreig commentedon Apr 8, 2022
Are you able to copy/link to the old non-working and new working memory.x? As far as I can think we haven't really changed what's required in that file between versions, so I'm surprised that's somehow breaking it unless something non-standard was there.
We do already have a bunch of checks in the linker script, so without working out what exactly was going wrong in this case it's hard to know what else to check for.
astraw commentedon Apr 8, 2022
astraw/nucleo-h743zi@161aac7 is the commit which finally allowed
probe-runto work without error usingcortex-m-rt0.7.1. It looks likeINSERT AFTER .bss;inmemory.xis the key change.Is that the information you want? (I hope so, because these linker scripts are outside of my experience.)
kelleyk commentedon Apr 8, 2022
Looking around the workspace that I was using to work through this issue, I see three versions of
memory.xfrom the outside world. I did a little bit of testing, remembering tocargo cleanafter modifyingmemory.x(per the docs). I'm usingprobe-run@v0.3.3.The first one is from antoinevg/nucleo-h7xx@v0.1.2 (same as current
main). This one exhibits the timeout error withprobe-run, and also does not build unless I disableflip-link(Error: "MEMORY.RAM not found after scanning linker scripts").The second one is from stm32-rs/stm32h7xx-hal@v0.9.0 (same as @v0.10.0). This one causes the timeout error with
probe-run, though it builds withflip-link.The third one is from stm32-rs/stm32h7xx-hal@v0.11.0 (same as current
master). This one works correctly withprobe-runand builds withflip-link.I haven't tried to narrow down which of the differences is causing the problem, though I suspect it's related to the issues/PRs that I linked above (which are when those changes were made).
I agree with @astraw that it would be nice to have a way of reminding people that the
memory.xthat they (or someone producing a template for them) have copied from the HAL into their own project (as https://github.com/knurling-rs/app-template instructs) might need to be updated when they update dependencies. It shouldn't need to be fancy; just a "hey, this is revision 123 ofmemory.xbut you're using a version of the HAL that was released with revision 124!" to let people avoid this particular footgun.Then again, there are probably more elegant ways of addressing the problem. What do you think?
kelleyk commentedon Apr 8, 2022
Actually looking at the diff between the versions of
memory.xin stm32h7xx-hal@{v0.9.0,v0.10.0} and @v0.11.0, the removal ofINSERT AFTER .bssfrom theSECTIONSblock at the end is the only change, which lines up with what @astraw noticed above.I suspect that there's some interaction with the changes that were made to
link.x.inin thecortex-m-rtcrate, though I haven't tried testing version pairs.newAM commentedon Jun 30, 2024
I'm triaging Cortex-M issues today; I wasn't able to reproduce this one with
probe-rs 0.24.0 (git commit: crates.io)and a Nucleo-H743ZI2 on cortex-m-rt 0.7.3 (0.7.1 has been yanked). I'm going to close the issue, but please re-open if it is still an issue!