riscv/riscv-debug-spec

how to modify code in debug mode in riscv

deepakkapoor624 opened this issue · 4 comments

deepakkapoor624 commented

I am looking for any documentation which can help in modifying debug mode behavior.
As a part of experiment I am trying to put hart in halted state by executing ebreak instruction. as I am trying to implement semihosting without using external debugger.
but I am not able to understand how can i resume the hart again using firmware only.

pdonahue-ventana commented

The way to resume from debug mode is to use the resumereq mechanism in dmcontrol in the DM. Depending on whether the implementation has a memory-mapped DTM that allows firmware to access DM registers, this might or might not be possible. Debug mode is the mode you enter when you hand control to the external debugger. The external debugger can be something on the other side of some JTAG pins or it could theoretically be firmware running on a different CPU but that decision is implementation-specific.

rtwfroody commented

Just want to add that if you don't have an external debugger attached, it is not possible to enter the halted state. Without an external debugger, all you can do is have ebreak take a trap. Then your semihosting code would execute in the trap handler, and execution resumes simply be returning from that trap handler.

deepakkapoor624 commented

yes using ebreak we can enter the debug mode but how to come out from debug Mode.
I understand we can use resumereq mechanism but can i modify the debug Mode interrupt handler. Is it configurable or it is a part of rom code?

pdonahue-ventana commented

The ways to enter debug mode are:

  1. ebreak. This requires dcsr.ebreakm=1 (or one of the other dcsr.ebreak* bits). Those bits reset to 0 and can only be set either via an abstract CSR write command (which requires the existence of an external debugger) or from debug mode (which requires us to first get into debug mode via one of the other 5 mechanisms).
  2. a trigger with action=1. This can only be written from debug mode (which requires us to first get into debug mode via one of the other 5 mechanisms).
  3. haltreq. This is sent by the DM when the external debugger writes dmcontrol.haltreq.
  4. single step via dcsr.step. This is similar to item 1.
  5. resethaltreq. This required an external debugger to set resethaltreq via dmcontrol.
  6. halt group. This required an external debugger to program a halt group.

They all require an external debugger which is what @rtwfroody was talking about.

(The double trap extension will add another way to enter debug mode but, like items 1 and 4, it will first require an external debugger to write a bit in dcsr.)