search

riscv / riscv-debug-spec

Working Draft of the RISC-V Debug Specification Standard
https://jira.riscv.org/browse/RVG-94
Other
459 stars 92 forks source link

abstractcs.cmderr is set when progbuf/data is read while hart is running #516

Closed deadsy closed 4 years ago

deadsy commented 4 years ago

Per the release spec:

abstractcs.cmderr gets set if an abstract command fails- but, that's not the only circumstance it can get set in.

Experimentally on a gd32vf103 (gigadevice, 32-bit andes core) if I read the implemented data/progbuf registers while the hart is running I will get the cmderr set to indicate a resume/halt failure. Note: I'm not running an abstract command. The hart is just running normally.

I suppose this implies I always need to clear the cmderr upon halting. I had previously assumed that if I cleared it at the conclusion of an failed abstract command it would remain cleared until the next abstract command.

Can a hart change the dataX values while it running (not in an abstract command)? Can a hart change the progbufX values while it running (not in an abstract command)?

If yes - then I can see why you'd want to signal an error on the read.

In any case, I didn't see this behavior documented anywhere.

Thanks.

timsifive commented 4 years ago
  1. cmderr should only be changed when an abstract command fails or when the debugger clears it. If you have hardware that behaves differently it's not compliant. We could discuss changing what the spec says, but not just because somebody implemented it.
  2. Neither dataX nor progbufX should spontaneously change.
deadsy commented 4 years ago

That's what I figured. Inevitably there's going to be some variance as independent entities implement their realization of the spec. I've been trying to track down some opensource which deals with the gd32vf103 quirks. Maybe none of them do, the main openocd repo segfaulted when I tried to connect. In any case, I have a SiFive core coming my way shortly so that should be fully spec compliant. :-)

deadsy commented 4 years ago

I thinks it turns out to be my problem (no surprises there..). While examining the chip I wrote all 1's to abstractauto to see what it had in the way of autoexec capabilities, then I forgot to turn it off (write all 0s). Any subsequent access to progbuf/data causes the abstract command to run with unpredicatable results.