You copied the Doc URL to your clipboard.

How do I access the memory system of a Cortex-M processor from my own debug transactor?

Information in this article applies to:

  • Cortex-M3

  • Cortex-M4

  • Cortex-M0

  • Cortex-M0Plus

  • Cortex-M7

Problem/Question

How do I access the memory system of a Cortex-M processor from my own debug transactor?

Scenario

This knowledge article relates the Cortex-M3 processor or other Cortex-M processor RTL. The article is for designers who have designed a chip containing the processor that is configured with the debug capability, and who want to use their own transactor to drive the debug port of the chip.

This article describes how to implement a minimal debug sequence to access the memory system of the processor.

Answer

Cortex-M3 RTL is delivered with an example system. This example system contains an SWJIM transactor that drives the supplied CoreSight Debug Access Port (DAP) in Cortex-M3. For Cortex-M3, this DAP consists of the following:

  • A stand-alone SWJ-DP Debug Port in the Cortex-M3 integration level.

  • A customized version of AHB-AP Access Port inside the Cortex-M3 level.

Two test programs are supplied that have the '.cdapml' extension. This extension means that the source files contain some C code to run on the processor, and some DAP Macro Language (DAPML) instructions for the SWJIM. The C code is a copy of Dhrystone, and the DAPML performs various debug activities. These debug activities include some redundant operations. The two '.cdapml' test programs perform the same set of actions: one test uses the default JTAG protocol on the debug connection, the other test uses the Serial Wire Debug (SWD) protocol. The source code for these tests is contained in the files that are named 'CM3_J_CM3Trace1.cdapml' and 'CM3_S_CM3Trace1.cdapml'.

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

Accessing the memory system using only JTAG protocol requires the following sequence of operations, as a minimum requirement;

1. Power-up handshake:

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

2. Activate the correct AP:

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

3. Set the AP access size and address mode:

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

4. Set the initial AHB address to access:

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

5. Access the memory system at that address:

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

To use the SWD protocol, add the following two steps to the start of the previous sequence of operations:

 - issue the benign TMS sequence that 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 that are located in 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'.

If you run 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

For more information on the SWD protocol, see Chapter 4 of the ARM Debug Interface Architecture Specification ADIv5.0 to ADIv5.2, or the ARM Debug Interface Architecture Specification ADIv5.2. An SWD operation consists of the following:

  • A request packet from the debugger.

  • An acknowledge packet from the target.

  • 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. The inline comment is followed by the individual SWD operations and any associated data processing that implements the DAPML operation. The SWD requests are represented as read (R) or write (W) to the Access 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 get and test a data value that is returned by a read operation. This '.bsi' file represents the minimal SWD debug sequence to make successful debug accesses into the memory system of the Cortex-M3, assuming the DP is already in SWD mode.

Running the test in SWD mode, as described previously, means that the only action that is required in the 'Minimal2_dapml_SWJIM.bsi' file is the TMS scan sequence. The TMS scan sequence switches the mode to SWD, enclosed within the 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 that are used to implement the DAPML program in JTAG. However, the DAPML program is not as easy to read as the 'Minimal2_SWIM.bsi' file that is used in the 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 that can be found in the Cortex-M3 example system at ./coresight/doc/. .

All other Cortex-M processors (not Cortex-M3) are delivered with a different implementation of the example MCU design and testbench. This implementation is called the Integration Kit (IK), and it uses a debug driver to stimulate the debug port of the target processor. The debug driver is a small microcontroller that can issue various predefined debug sequences under the control of the target processor itself. The debug sequences are controlled by the GPIO pin connections between the target system and the debug driver.

In these non-Cortex-M3 systems, debug actions can be correlated against signal activity on the debug port by comparing the programmed actions against the debug port signal waveforms in the simulation. Diagnostic information about the debug driver activity can be added to the simulation transcript by #defining DEBUGDRIVER_PRINTF, or similar, in the configuration file 'IKConfig.h'. However, there is no intermediate low-level file to describe the debug activity in the same way as when using DAPML and SWJIM.

Note: Although 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 steps required to access the memory system of the Cortex-M are the same as those for the Cortex-M3.

Workaround

N/A

Example

N/A

Related Information

N/A

Was this page helpful? Yes No