riscv : fix the inverted logc interrupt-are-disabled-while-single-ste…

[mean00]

Detailed description

There is a small inverted logic in the "disable-interrupt-while-single-stepping" code
The STEPIE bit actually enables the interrupt while single stepping
The change inverts the logic (and let is "off" when leaving single step mode)
With that patch you dont go into timer interrupt as soon as you hit next with gdb
(on some platforms that bit is glued to zero, so the problem may not show)

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• [ till link] It builds for hardware native (see Building the firmware)
• It builds as BMDA (see Building the BMDA)
• I've tested it to the best of my ability : on ch32v30x
• My commit messages provide a useful short description of what the commits do

[klenSA]

Hello! I would really like to advance the state of the BMP code for using with ch32v30x , please give me a usage scenario - I will try to test the work.

[dragonmux]

Having finally managed to actually review the debug manual and this patch, the original behaviour is intended in that, with interrupts disabled it'll substantially change execution of the user firmware while stepping. Most parts we've seen seem lockstep their peripherals to core halt, allowing you to step through exactly how the firmware would execute without the debugger present. It would be interesting to see if the part you're debugging does not do this, leading to wanting interrupts while stepping to be disabled.

In either case though, if this patch is actually warranted, then not manipulating STEPIE at all would be more correct as the bit defaults to 0 on reset, and does not want to be on when executing normally - only potentially while single-stepping.

[mean00]

Thank you for the review
The part is CH32Vxxx
The goal was to mimick the Arm behavour within the blackmagic, where the Systick+ external configurable interrupts are disabled while single stepping
I'll have to look at it in detail, but on the CH32vxx you can lock timers, i2c etc.. to the debug state but apparently not the systick, so it was firing all the time (chapter 34.2.1 of the datasheet for reference).
I'll look at it again & see if just not touching STEPIE does the trick

[mean00]

I did a couple of quick tryouts :

• Not touching STEPIE at all as you suggested => works
• Additionally, i tried to let the STEPIE as it is but also setting STOP_COUNTERS and STOP_TIME=> does not seem to work (might be hardwired to zero, i'll look deeper into that).

Tested on the CH32V3xx, probably the same for CH32V2XX.
Thank you

[dragonmux]

Please rebase this PR on main and we will get it reviewed with a view to getting this merged.

[dragonmux]

With your permission, we'll do the rebase ourself so we can get progress on this PR and try to get it merged for v2.0

[mean00]

Sorry, i didnt notice the previous notification
I've quickly rebased the patch i've been using for a while. It works with the CH32vXX chips and contains the stop_time/stop_counter settings, those have no effect on CH32VXX but they may work on other chips
Thank you

[dragonmux]

If you can please rebase the 3 commits into one, keeping only the commit message with the first, fixed to remove the extra in front of the :, then we will get this merged. This looks good as implemented.

Thank you for the contribution!

[mean00]

did that too quickly, should be okay now
Thank you