-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debug Description: Programmatic indication of an error happening while __errorcontrol is set to ignore errors #325
Comments
It seems that I am one of those who asked about this feature. Firstly, I would like to mention that there is already a such variable in place, namely the Secondly, I have observed that during the execution of debug access sequences, the DHCSR register is periodically polled. This sometimes leads to unexpected results. For instance, a system reset is performed and then DebugPortSetup is executed. Under certain circumstances, an error message appears when executing one of the Best regards. |
Thanks, @MarianSavchuk , for sharing these thoughts!
Thanks for highlighting the The more I think about it, the more I like the idea. One way to repurpose it without breaking existing sequences could be to explicitly request writing target access errors to It imposes a little extra effort on sequences making use of the feature. In the sense of being responsible for clearing Also, there is the loophole of older debugger implementations not honoring the new control bit. We might need a read-only capability bit in What do you think, @MarianSavchuk ? I'll digest the above a little further and will turn it into a less verbose proposal. Two things I'd like to spend some more thought on are:
Thanks again for injecting that thought! I think this brings us much closer to a solution. :-)
I need to have a look at this in our implementation in uVision. I agree that particularly around reset recovery and recovery from connection losses, debug sequences shouldn't be interrupted by periodic DHCSR reads. This sounds rather like a defect in the uVision implementation (we need to see if we can reproduce this easily) and out of scope of this CMSIS debug description specification issue. Having said that, we should add some recommendations to the spec about what a debugger should avoid in certain scenarios to avoid unpredictable/unexpected behavior. I'll separate this into a new issue here on Github. |
See #327 for the second part of above thoughts. |
@jreineckearm, Regarding the two questions, you are considering.
Basically, both implementation options are acceptable. However, in terms of making things intuitive:
|
The CMSIS debug description comes with a mechanism to instruct the debugger to ignore access errors. It uses a bit in the
__errorcontrol
debug access variable to activate/deactivate that mode. See https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/debug_description.html#DebugVarsHistorically, this mechanism was designed for write accesses. For example, depending on the HW design, a write to
AIRCR.SYSRESETREQ
could cause a temporary debug connection loss which ended in a protocol error because the SWDIO and SWDCLK lines weren't driven as expected.Since then, we've seen this mechanism being used more and more for polling the device state while secured bootloaders run. During such a phase, debug may be turned off to protected sensitive assets.
Depending on the polled device state register (could be a single bit), the lack of a well-defined return value for read functions in case of an error, or even better a state variable to indicate success of the last target access becomes more and more of an issue. This gap needs to be closed.
Given that a return value (instead of a data value) may cause new corner cases where the mechanism fails (one device requires a single bit check for
0
where the other requires a1
), a proper success indicator is preferred. There are a couple approaches to the latter:__errorcontrol
. This may however become a fiddly with bitwise operations.__errorstate
or__lasterror
indicating success of the last called debug access function.Happy to work on a proposal for this and open a docs PR for discussion.
The text was updated successfully, but these errors were encountered: