Unordered Halting

Unordered halting allows communications with the target even when the target is not halted. You may be able to read memory and reconfigure breakpoints while the target is running, without waiting for the halt. When you issue a run command the target device starts running, but the command queue keeps processing commands at the same time. The halt itself may happen at any time and doesn't affect the command queue. If the target halts, the command processing will keep going, and you cannot tell if the command was executed before or after the halt.

Unordered halting gives you access to the device without halting it, which is a huge advantage while debugging.

However, unordered halting imposes an important restriction: after a run command, you cannot issue a new run, single step, or multi-step command until the target device is halted and you have received the halt notification.

If you want to read memory at certain point in your code, you need to set up a breakpoint to halt the target at the desired point. Then you must wait for the target to get halted at this breakpoint. Only after the halt can you send the command to read the data.

  debugSession.enableExecBreakpoint(id,BreakAddress,0)

  for i = 1 to N {
    debugSession.run
    // must flush and wait to synchronize
    debugSession.flush
    debugSession.waitForHalt

    // now halted, can read the value
    debugSession.readRegister(RegisterId)
    debugSession.flush
    Array[i] = debugSession.fetchWord
  }

In this case, constant waiting for the halts slows communications down dramatically. Compare this to the same example for ordered halting.