Improve description of cmderr "busy"

- Improve the wording of what happens if another abstract command
  is started while the previous one still executes. Make the
  order of events very clear.

- Unify the wording of cmderr "busy" requirement for all concerned
  DM registers. Make it clearer to the reader that the prescribed
  behavior is the same in all the cases.

Author: JanMatCodasip

debug_module.adoc

@@ -328,12 +328,15 @@ that case, the command will return "not supported".
 ====
 
 Debuggers execute abstract commands by writing them to {dm-command}. They can
-determine whether an abstract command is complete by reading {abstractcs-busy} in {dm-abstractcs}. If the debugger starts a new command while {abstractcs-busy} is set, {abstractcs-cmderr} becomes 1 (busy), the
-currently executing command still gets to run to completion, but any
-error generated by the currently executing command is lost. After
+determine whether an abstract command is complete by reading {abstractcs-busy} in {dm-abstractcs}. After
 completion, {abstractcs-cmderr} indicates whether the command was successful or not.
 Commands may fail because a hart is not halted, not running,
-unavailable, or because they encounter an error during execution.
+unavailable, because they encounter an error during execution.
+
+If the debugger attempts to start a new command while {abstractcs-busy} is set,
+the new command will not get started and the currently executing command still
+gets to run to completion. After that, {abstractcs-cmderr} becomes 1 (busy),
+and any error generated by the completed command is lost.
 
 If the command takes arguments, the debugger must write them to the
 `data` registers before writing to {dm-command}. If a command returns results, the

xml/dm_registers.xml

@@ -471,7 +471,7 @@ same project unless stated otherwise.
     <register name="Abstract Control and Status" short="abstractcs" address="0x16">
         Writing this register while an abstract command is executing causes
         {abstractcs-cmderr} to become 1 (busy) once the command completes
-        ({abstractcs-busy} becomes 0).
+        (once {abstractcs-busy} becomes 0).
 
         [NOTE]
         ====
@@ -573,7 +573,7 @@ same project unless stated otherwise.
 
         Writing this register while an abstract command is executing causes
         {abstractcs-cmderr} to become 1 (busy) once the command completes
-        (busy becomes 0).
+        (once {abstractcs-busy} becomes 0).
 
         If {abstractcs-cmderr} is non-zero, writes to this register are ignored.
 
@@ -609,7 +609,7 @@ same project unless stated otherwise.
         If this register is written while an abstract command is executing
         then the write is ignored and
         {abstractcs-cmderr} becomes 1 (busy) once the command completes
-        (busy becomes 0).
+        (once {abstractcs-busy} becomes 0).
 
         <field name="autoexecprogbuf" bits="31:16" access="WARL" reset="0">
             When a bit in this field is 1, read or write accesses to the
@@ -677,7 +677,8 @@ same project unless stated otherwise.
         registers.
 
         Accessing these registers while an abstract command is executing causes
-        {abstractcs-cmderr} to be set to 1 (busy) if it is 0.
+        {abstractcs-cmderr} to become 1 (busy) once the command completes
+        (once {abstractcs-busy} becomes 0).
 
         Attempts to write them while {abstractcs-busy} is set does not change their value.
 
@@ -712,7 +713,8 @@ same project unless stated otherwise.
         implemented starting at {dm-progbuf0}, counting up.
 
         Accessing these registers while an abstract command is executing causes
-        {abstractcs-cmderr} to be set to 1 (busy) if it is 0.
+        {abstractcs-cmderr} to become 1 (busy) once the command completes
+        (once {abstractcs-busy} becomes 0).
 
         Attempts to write them while {abstractcs-busy} is set does not change their value.