I am evaluating the SWD-Port of the Cortex-M0 Designstart using the obfuscated component of the Eval distribution AT510-MN-80001-r2p0-00rel in a Modelsim Simulation.
For that purpose I composed a minimal system with ROM, RAM and ROMTABLE. It runs a test-software which shows activities as expected on the AHB-Lite Bus.
Then I wrote a testbench to communicate with the Cortex-A0 via SWD wich performs the following steps according to the ARM® Debug InterfaceArchitecture Specification:
Thus my question is whether the used version of the obfuscated Cortex-M0 supports connection to a Mem-AP. As far as I understood the docs it does.
If it supports the AP, can anybody tell me, whats wrong with my register read/write sequence? Or did I make an error in my system design? Below an overview of the system is shown:
Thank you for your replies,Bernhard.
The Cortex-M0 DesignStart Eval includes debug (single step with four breakpoints, two watchpoints and PC sampling) and Serial-Wire only interface.
However, the Eval version of the deliverables don't include the DAP, so there is no way to program the debug features in the processor. As, there is no master to drive its Debug interface, so no external debug is supported.
The Pro version of Cortex-M0 DesignStart does include the CM0DAP, so it is possible to use the debug features. You can apply for the Pro version here:
https://developer.arm.com/ip-products/designstart/pro/cortex-m
I am not sure if I cleary explained my request.I did setup a minimum ARM Cortex-M0 system with the obfuscated M0-Core. My goal is to evaluate the SWD-Interface interface in a simulation environement and access the Processor Debug Register File. Thus I tried to connect to the DP (Debug Port) in the DAP (Debug Access Port) and then connect to the MEM-AP in the DAP.The minimum system is instantiated in a testbench written by myself. The testbench further contains a SWD-test-process which acts as the master for the SWD-Interface. Thus there is a master that drives the Debug interface. The following picture shows this environnement:
As described in the document "ARM® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2" the SWD-test-process first resets the SWD-Interface.Then it reads the DPIDR Register from the DP in the DAP. The return value is the expected value 0x0BB11477.Thus the hardware-connection between the SWD-test-process and the DP (and thus the DAP) of the Cortex-M0 is working!
With the further commands (which I already described in my request above) unfortunately it was not possible to reach the MEM-AP which gives access to the Processor Debug Register File. Thus my question was whether I sent wrong commands and/or made wrong connections in the minimum system.
As you proposed I applied for the Pro-Version but I am not sure if this answers my question.
There was a discussion about a similar question some years ago that makes me expect that the processor registers are accessible via SWD, even in the Cortex-M0 DesignStart Eval version: community.arm.com/.../cortex-m0-designstart-r2
Thanks and best RegardsBernhard.
I incorrectly stated that the Cortex-M0 DesignStart Eval version didn't include the DAP, however in version r2p0 the DAP is included in the obfuscated logic for Cortex-M0.
How have you connected CDBGPWRUPREQ/ACK in your system? When the debugger first connects, it asserts CDBGPWRUPREQ and waits for CDBGPWRUPACK before it can gain access to the DAP. CDBGPWRUPREQ and CSYSPWRUPREQ request your power and clock controller to restore power and clocks to the Debug bus domainand 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 implementing a PMU and a multi power domain system, you must synchronize CDBGPWRUPREQ to SCLK and connect the synchronized signal to CDBGPWRUPACK. You must ensure when CDBGPWRUPACK is HIGH, all processor power domains are powered-up and all clocks are running. 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. 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. Section 6.2.3 indicates how to access the CTRL/STATs register for each type of DP. Please see the following link for further information:
https://developer.arm.com/documentation/dgi0012/d/Implementation/Debug-and-system-power-up
Regards,
Mahmood.
PROBLEM SOLVED
Thank you for your detailed explainations which helped me to find the error. In my SWD-test-process I found an error in the function which writes the DAP-Registers. Now it ist working fine as you can see in this timing:
It shows the following steps:(1) Reset of the SWD-Interface.(2) Read the DPIDIR of the Debug port which returns the correct value 0x0bb11477.(3) Activate CSYSPWRUPREQ and CDBGPWRUPREQ by writing 0x50000000 to the CTRL/STAT register of the DP.(4) Subsequent read of the CTRL/STAT register shows that CSYSPWRUPACK and CDBGPWRUPACK are set.(5) Write 0x000000f0 to the SELECT register of the DP which prepares to read IDR in AP0.(6) Read the IDR register of AP0, the value ist returnd in the next step.(7) Read the RDBUFF register of DP to get the value from IDR read. It shows the correct value 0x04770021
The system I am using is shown in my initial request at the top of this thread.
Best RegardsBernhard.