Ordered Halting

Ordered halting means that the target device cannot accept any commands while running. When you issue a run or single-step command, the subsequent commands will be held until the target device halts. You can regard the run command just as any other command in the command queue, except it does not produce the result immediately, but only after the target halts.

The disadvantage of the ordered halting is that you cannot communicate with the target device while it runs. However ordered halting lets you issue commands which will automatically execute immediately after the halt. This lets you run fast automated tests. For example, consider this pseudo-code:

  debugSession.enableExecBreakpoint(id,BreakAddress,0)

  // Prepare the commands
  for i = 1 to N {
    debugSession.run
    debugSession.readRegister(RegisterId)
  }

  // Send all the commands to NSDSP at once
  debugSession.flush

  // Retrieve the results
  for i = 1 to N {
    debugSession.waitForHalt
    Array[i] = debugSession.fetchWord
  }

This code installs a hardware breakpoint at a certain location. Then the code issues a number of run commands, each followed by a command to read a register. Then it flushes all commands out, so that they are passed to NSDSP all at the same time. This is the most efficient method of communicating with NSDSP.

Once the commands are queued, the second loop fetches the data. Notice how the fetching functions are called in the same order as the requests were issued. The waitForHalt function matches the run command and retrieves the information sent when the target was halted. Then the fetchWord function matches the readRegister command and retrieves the register value. If you called these functions in different order, the debug session would fail.

In the end you receive an array containing the value of the register recorded at each halt.