Dmexttrigger for haltgroup and resumegroup

[zhangdujiao]

Regarding the implementation of haltgroup and resumegroup through dmexttrigger, for example, we have two triggers: triggerin0 to halt the core and triggerin1 to resume the core.

For the debugger software, when dmcs2 is configured as haltgroup, the DM will trigger a core halt upon receiving triggerin0. Then, after reconfiguring dmcs2 as resumegroup, the core will resume upon receiving triggerin1.

The protocol mandates setting dmcontrol.haltreq=0 before resuming core (dmcontrol.resumereq=1). ——"resumereq is ignored if haltreq is set."
Is this equally required for dmexttrigger? Specifically, if the core is halted, must dmcontrol.haltreq=0 be set before triggering its resume?

Thanks a lot!

[pdonahue-ventana]

The protocol mandates setting dmcontrol.haltreq=0 before resuming core (dmcontrol.resumereq=1). ——"resumereq is ignored if haltreq is set."

I have a few comments on this:

1. The quoted statement doesn't require haltreq=0 "before" resumereq=1. This statement is related to the value of the two bits being written on a single write transaction.
2. This statement does not prohibit the debugger from writing dmcontrol with a value that has haltreq=1 and resumereq=1. If a debugger does this then the statement places a requirement on hardware to treat haltreq as higher priority than resumereq. However, it implicitly requires a debugger to have haltreq=0 when resumereq=1 if the debugger actually wants to resume (which is maybe what you meant).
3. Note that haltreq is different than the halt request bit. Writing dmcontrol.haltreq affects the underlying halt request bit. There is one dmcontrol.haltreq field per DM but there is one halt request bit per hart (up to 2²⁰ bits per DM).

Is this equally required for dmexttrigger? Specifically, if the core is halted, must dmcontrol.haltreq=0 be set before triggering its resume?

There is no concurrent write in this scenario so the statement doesn't apply. I don't believe that the halt request bit is affected by a resume group because I don't see anything that ties these two things together. If a hart is halted and its halt request bit is set and dmexttrigger causes it to resume then I believe that it will resume and then immediately halt. A debugger shouldn't be surprised by the fact that it halted. The debugger had previously done an explicit request for a halt (via dmcontrol) so the fact that something did an implicit resume (via dmexttrigger) shouldn't override the explicit request.