ARM Technical Support Knowledge Articles

How to access a Cortex-M processor's memory system from my own Debug transactor?

Applies to: Cortex-M0, Cortex-M0Plus, Cortex-M3, Cortex-M4

Scenario

I am a licensee of the Cortex-M3 processor or other Cortex-M processor RTL, and I have designed a chip containing the processor configured with the debug capability included. I am using my own transactor to drive the debug port of the chip. I want to implement a minimal debug sequence to access the processor's memory system. Please illustrate the simplest sequence of debug requests to achieve this.

Answer

Cortex-M3 RTL is delivered to licensees together with its "example" system, which contains a SWJIM transactor to drive the supplied CoreSight DAP in Cortex-M3. For Cortex-M3, this DAP consists of a stand-alone SWJ-DP Debug Port in the Cortex-M3 Integration level and a slightly customized version of AHB-AP Access Port inside the Cortex-M3 level.

Two test programs are provided which run some C code on the processor and at the same time stimulate the SWJIM to run some debug activity while the processor is running. The source files have the ".cdapml" extension, indicating that they contain some C code to run on the processor, and some DAP Macro Language (or DAPML) instructions for the SWJIM. The C code is a copy of Dhrystone, while the DAP Macro Language performs a number of debug activities. These debug activities include some redundant operations. The two .cdapml test programs perform the same set of actions, one using the default JTAG protocol on the debug connection, the other using the Serial Wire Debug (SWD) protocol. The source code for these tests is contained in files named "CM3_J_CM3Trace1.cdapml" and "CM3_S_CM3Trace1.cdapml" respectively.

The SWJ-DP delivered with Cortex-M3 resets into JTAG mode by default, and supports dynamic switching between JTAG and SWD modes.

The minimal requirement for accessing the memory system using only JTAG protocol requires the following sequence of operations;

Power-up handshake:

 - write 0x50000000 to the DP.CTRL/STAT register
 - poll the DP.CTRL/STAT resgister for 0xf0000000

Activate the correct AP:

 - write 0x0 to the DP.SELECT register to activate the AP at position 0 on the DAP bus

Set the AP access size and address mode:

 - write a suitable setting such as 0x22000012 to the AP.CSW register

Set the initial AHB address to access:

 - write the desired 32-bit address to the AP.TAR register

Access the memory system at that address:

- read or write the AP.DRW register to effect that access

 

To use the SWD protocol, the above procedure should be preceded by two initial steps:

 - issue the benign TMS sequence which switches the DP from JTAG to SWD mode
 - read the DP.IDCODE

 

In the Cortex-M3 example system, the attached program ("Minimal2.cdapml") can be run using the "run_example" script and selecting the "-cdapml" switch. (See the README file in the "example" directory for example invocations of "run_example".) For SWD mode, uncomment the block of four lines between the script configuration settings and the power-up handshake in the Minimal2.cdapml file, and run the "run_example" command; for example:

  run_example -build -v -mti -cdapml Minimal2

The .cdapml is processed to produce ".bsi" and ".hex" control files located under  the ./coresight/tests/bin/. directory. JTAG operations are placed in "<TESTNAME>_dapml.bsi", SWD operations are placed in "<testname>_dapml_SWIM.bsi", and SWJIM Control operations are placed in "<testname>_dapml_SWJIM.bsi".

 

Running the test in SWD mode, Minimal2.cdapml is processed into the following lower-level code in the "Minimal2_dapml_SWIM.bsi" file:

  PRINTF "Checking SW-DP IDCODE"

; DAP_READ_DPACC DPIDCODE 2BA01477
R DP 0 LFFFFFFFF EWAITnOK NOERR
GET 30
FAIL_NE 30 #2ba01477 00000000

; DAP_WRITE_DPACC DPCTL 0x50000000
W DP 1 50000000 LFFFFFFFF EWAITnOK NOERR

; DAP_READ_DPACC DPSTATUS 0xf0000000
R DP 1 LFFFFFFFF EWAITnOK NOERR
GET 30
FAIL_NE 30 #f0000000 00000000

; DAP_WRITE_AP CM3 0x00 0x22000012
W DP 2 00000000 LFFFFFFFF EWAITnOK NOERR
W AP 0 22000012 LFFFFFFFF EWAITnOK NOERR

; DAP_WRITE_APACC 0x1 0x00020000
W AP 1 00020000 LFFFFFFFF EWAITnOK NOERR

; DAP_WRITE_APACC 0x3 0x11223344
W AP 3 11223344 LFFFFFFFF EWAITnOK NOERR

; DAP_WRITE_APACC 0x3 0x55667788
W AP 3 55667788 LFFFFFFFF EWAITnOK NOERR

; DAP_WRITE_APACC 0x1 0x00020000
W AP 1 00020000 LFFFFFFFF EWAITnOK NOERR

; DAP_READ_APACC 0x3 0x11223344
R AP 3 LFFFFFFFF EWAITnOK NOERR
R DP 3 LFFFFFFFF EWAITnOK
GET 31
FAIL_NE 31 #11223344 00000000

; DAP_READ_APACC 0x3 0x55667788
R AP 3 LFFFFFFFF EWAITnOK NOERR
R DP 3 LFFFFFFFF EWAITnOK
GET 31
FAIL_NE 31 #55667788 00000000
PRINTF "** TEST PASSED OK **"
FINISH

The SWD protocol is described in detail in Chapter 4 of the "ARM® Debug Interface Architecture Specification ADIv5.0 to ADIv5.2", or "ADIv5.2". An SWD operation generally consists of a request packet from the debugger, an acknowledge packet from the host, and a data packet in one or other direction depending on whether the operation is a write or a read.

Each source DAPML line is shown in the .bsi file as an inline comment, followed by the individual SWD operations and any associated data processing which implement that DAPML operation. The SWD requests are represented as read ("R") or write ("W") to the Accesss Port ("AP") or Debug Port ("DP") followed by the selected register number, data values and control flags. The GET and FAIL_NE commands are used to acquire and test a data value returned by a read operation.

This .bsi file represents the minimal SWD debug sequence to make successful debug accesses into the Cortex-M3's memory system, assuming the DP is already in SWD mode.

Running the test in SWD mode, as described above, means that the only action required in the "Minimal2_dapml_SWJIM.bsi" file is the TMS scan sequence to switch mode to SWD, enclosed within soft DP reset sequences "50TMS":

50TMS
IN 0111100111100111
50TMS
STARTSWIM
FINISH

and the JTAG "Minimal2_dapml.bsi" contains only the initial script configuration settings:

CONFIG_NUM_TAPS 1
CONFIG_TAP 1 DAP 4 4
CONFIG_SELECT_TAP 1
PRINTF "Switch to SWD mode"
EXIT

 

Running the test in JTAG mode, the SWIM and SWJIM .bsi files contain no functional instructions. The "Minimal2_dapml.bsi" file contains the fully expanded low-level TMS and TDI sequences used to implement the DAPML program in JTAG, but this is in a less easily readable format than the "Minimal2_SWIM.bsi" file used in SWD mode.

The "Minimal2_dapml.bsi" file is attached here for reference.

 

The formats of the DAPML and BST commands are described in the documentation located at ./coresight/doc/. in the Cortex-M3 example system.

 

Cortex-M processors other than Cortex-M3 are delivered with a completely different implementation of example MCU design and testbench, called the "Integration Kit", which uses a "debug driver" to stimulate the debug port of the target processor. The "debug driver" is essentially a small microcontroller which can issue a number of predefined debug sequences under the control of the target processor itself, controlled through a number of GPIO pin connections between the target system and the debug driver.

In these systems, debug actions can be correlated against signal activity on the debug port by comparing the programmed actions against debug port signal waveforms in the simulation. Helpful diagnostic information about the debug driver activity can generally be added to the simulation transcript by #defining DEBUGDRIVER_PRINTF (or similar) in the configuration file "IKConfig.h", but there is no intermediate low-level file to describe the debug activity as there is when using DAPML and SWJIM.

While specific details (such as precise component ID codes and specific DAP implementations) differ between the different Cortex-M processors, the principles of operation and the minimum necessary steps required to access the Cortex-M's memory system are the same as those described above for the Cortex-M3.

Attachments

Minimal2.cdapml
Minimal2_dapml.bsi

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential