All items in this section are future ideas and should not be considered part of the specification.
Some future version of this spec may implement some of the following features.
The spec defines several additions to the Device Tree which enable a debugger to discover hart IDs and supported triggers for all the harts in the system.
DTMs can function as general bus slaves, so they would look like regular RAM to bus masters.
Harts can be divided into groups. All the harts in the same group can be halted/run/stepped simultaneously. When a hart hits a breakpoint, all the other harts in the same group also halt within a few clock cycles.
DTMs are specified for protocols like USB, I2C, SPI, and SWD.
The debugger can communicate with the power manager to power cores up or down, and to query their status.
Serial ports can raise an interrupt when a send/receive queue becomes full/empty.
The debug interrupt can be masked by running code. If the interrupt is asserted, then deasserted, and then asserted again the debug interrupt happens anyway. This mechanism can be used to e.g. read/write memory with minimal interruption, making sure never to interrupt during a critical piece of code.
The Debug Module can include a serial interface for re-using the DTM interface as a generic communication interface.
The Debug Module may implement up to 8 serial ports. They support basic flow control and full duplex data transfer between a component and the debugger, essentially allowing the Debug Transport to be used to communicate with a debug monitor running on a hart, or more generally emulate devices which aren’t present. All these uses require software support, and are not further specified here. Only the DMI side of the Debug Module serial registers are defined in this specification as the core side interface should look like a peripheral device.