|ARM Technical Support Knowledge Articles|
These functions are in Chapter 3 - Common Debug Port (DP) Features in the ARM Debug Interface v5 Architecture Specification, and therefore apply to all types of DP. They are detailed in section 3.4. Section 6.2.3 indicates how to access the CTRL/STAT register for each type of DP.
The REQ bits in the CTRL/STAT register drive the corresponding output ports of the DAP while the ACK bits in the CTRL/STAT reflect the state of the corresponding input ports. The only relevant functionality inside the DAP is that debug requests from the debugger will not be propagated to the Debug bus while the corresponding PWRUPACK is not asserted.
The main functionality of these bits is in your on-chip logic outside of the ARM IP components, and therefore beyond the scope of any test which might be shipped with your ARM IP. However, you should be able to use the SWJIM module, if you have this, to exercise these features of the (DAP + external controller) on your chip.
CDBGPWRUPREQ and CSYSPWRUPREQ request your power and clock controller to restore power and clocks to the Debug bus domain and the main system domain. The corresponding C***PWRUPACK signals are asserted by your power and clock controller once the respective domains have power and clocks restored. If you are not using power or clock gating on your chip, feed each REQ back to the corresponding ACK.
NOTE: CDBPWRUPACK and CSYSPWRUPACK cannot simply be tied HIGH, as this violates the ARM Debug Interface v5 Architecture Specifcation requirement that C***PRWUPACK defaults to LOW and that a debugger may only assert a power-up request when the corresponding ACK is LOW.
The CDBGRSTREQ / CDBGRSTACK feature is an optional feature to allow the debugger to interact with the chip's Reset Controller logic in the case where the Debug bus appears to be locked up for any unexplained reason. If you implement this feature, your Reset Controller would be expected to reset the DAP bus in the DAPCLK domain plus any additional Debug buses such as the Debug APB bus driven by an APB-AP and the Trace bus in the ATCLK domain, for example. The exact set of buses included in this is imprecise, as it depends upon the debug structure of your particular chip.
The front side of the DP (the SWCLK/TCK domain) is NOT included in this reset request scope, therefore the CDBGRSTACK will not be corrupted by the action of the CDBGRSTREQ. Debuggers should be designed to poll the CDBGRSTACK for completion, and if no CDBGRSTACK is returned after a suitable time-out, to deduce that CDBGRSTREQ is not implemented on this chip.
The relevant description is in section 3.4.5 of the ARM Debug Interface v5 Architecture Specification:
The DP Control/Status register provides two bits, bits [27:26], for reset control of the debug domain, see The Control/Status Register, CTRL/STAT on page 6-10. The debug domain controlled by these signals covers the internal DAP and the connection between the DAP and the debug components, for example the debug bus. The two bits provide a debug reset request, CDBGRSTREQ, and a reset acknowledge, CDBGRSTACK. The associated signals provide a connection to a system reset controller.
The DP registers are in the always-on power domain on the external interface side of the DP. Therefore, the registers can be driven at any time, to generate a reset request to the system reset controller.
See also section 6.8 of the CoreSight Technology System Design Guide:
Tools controlled debug reset
The control and status register provides 2 bits for reset control of the debug domain, DAPRESETn, PRESETDBGn, ATRESETn.
Please note that the final bullet point in section 6.8
* If you do not require this functionality, you must connect CDBGRSTACK to CDBGRSTREQ.
is incorrect, and the CDBGRSTACK should be tied LOW if the function is not implemented.
Did you find this article helpful? Yes No
How can we improve this article?