CMSIS-Pack  Version 1.4.9
Delivery Mechanism for Software Packs
 All Pages
Debug access sequences

Debug access sequences define the activities of development tools to connect to a device using the debug channel for debugging, tracing, or flash programming. Several debug access sequences are pre-defined and executed in specific context. Refer to sequences for details.

Software development tools should implement Default debug access sequences. These default sequences can be overwritten by device specific sequences using the sequence element in the sequences section of the PDSC file. Additionally, a PDSC file can contain user-defined sequences, for example to reuse access sequence fragments:

  • Usage of debug access sequences explains how the sequences are used from a development tool point of view.
  • Default debug access sequences lists all debug access sequences that are pre-defined by the CMSIS-Pack standard and shows the details of the default debug access sequences.
  • Writing debug access sequences explains how to write custom debug access sequences. These can be used to either override default sequences or to define device specific sequences.

Usage of debug access sequences

Pre-defined Debug Access Sequences are used in the following context:

  • Connect Debugger to Device is executed when debugging or flash programming with the target starts.
  • Reset Device is executed to reset the target.
  • Verify Code is executed to verify the content after flash programming.
  • Disconnect Debugger is executed when debugging or flash programming with the target stops.

The following diagrams show how the Debug Access Sequences are executed by a development tool.

Connect Debugger to Device is executed when debugging or flash programming with the target starts.

DebugConnect.png

Reset Device is executed to reset the target.

Reset.png

Verify Code is executed to verify the content after flash programming.

CodeVerify.png

Disconnect Debugger is executed when debugging or flash programming with the target stops.

DebugDisconnect.png

Default debug access sequences

Debug access sequences get defined in the sequence element. The following table lists the available pre-defined debug access sequences. Default debug access sequences are executed if they are not overwritten using a sequence element. Refer to Usage of debug access sequences for more information about the execution of these sequences.

For debug access sequences marked in ItalicRed, no default sequence exists. The usage in a debug description requires a related sequence element to be present. The other sequences should be implemented in a development tool. They are executed when no sequence definition exists in the PDSC file.

Note
Default debug access sequences read the System Control Space (SCS) of the processor and assume that the SCS offset is implemented as defined in the ARMv6-M/ARMv7-M/ARMv8-M architecture reference manual.
name= Description
DebugPortSetup Prepare the target debug port for connection; is executed before acquiring access to the debug port.
May include for example an SWJ-DP switch sequence as defined in the ARM Debug Interface (ADI) Architecture Specification.
This sequence must not contain debug port/access port register and target memory accesses other than:
  • Reading the DPIDR debug port register to release an SWD connection from its line reset.
  • Writing the TARGETSEL debug port register (SWD protocol v2).
DebugPortStart Connect to the target debug port and power it up; is executed after DebugPortSetup.
The parent debugport is default debug port for this sequence.
This sequence must not contain access port register and target memory accesses.
DebugPortStop Power down and disconnect from target debug port.
Executed as last step during target disconnect unless another debugger connection to this port is active. The parent debugport is default debug port for this sequence.
This sequence must not contain access port register and target memory accesses.
DebugDeviceUnlock Check if the device is in a locked state and unlock it. Use query command elements for user confirmation.
Executed after having powered up the debug port.
DebugCoreStart Initialize core debug system.
Executed after having connected and powered up the default debug port for the connection.
DebugCoreStop Uninitialize core debug system.
Executed as last step during disconnect before powering down any debug ports no longer required for concurrent connections.
DebugCodeMemRemap Remap memory to execution location.
Executed before verifying memory content after flash programming. This is required to replicate a memory remap of a device bootloader (that is not executed during debug connection).
ResetSystem Execute a system-wide reset via software mechanisms.
ResetProcessor Execute a processor reset via software mechanisms.
ResetHardware Execute a system-wide reset via the dedicated debugger reset line, e.g. nRST.
ResetHardwareAssert Assert a system-wide reset via the dedicated debugger reset line, e.g. nRST.
ResetHardwareDeassert Deassert a system-wide reset via the dedicated debugger reset line, e.g. nRST.
ResetCatchSet Executed before a target reset to configure the vector catch to stop code execution after the reset.
The implementation of ResetCatchSet requires an implementation of ResetCatchClear to free any hardware resources used for stopping the core.
ResetCatchClear Executed after a target reset to free hardware resources allocated by ResetCatchSet.
FlashEraseDone Executed after erasing flash memory.
FlashProgramDone Eexecuted after programming flash memory.
TraceStart Enable target trace capture.
Executed before the debugger powers up and configures standard CoreSight trace components, e.g. after the initial target connection as well as after a system-wide reset.
TraceStop Disable target trace capture.
Executed after the debugger disabled and powered down standard CoreSight trace components.
RecoverySupportStart Executed before step or run command to support recovery from a lost target connection, e.g. after a low power mode.
RecoverySupportStop Executed after step or run command in context of the RecoverySupportStart sequence.
RecoveryAcknowledge Debugger acknowledge after recovering from a lost target connection. Can be executed independently from a RecoverySupportStart sequence.

Pre-defined default debug access sequences

The following sections the show the details of the pre-defined default debug access sequences.

DebugPortSetup

Prepare the target debug port for connection.

<sequence name="DebugPortSetup">
<block>
__var isSWJ = ((__protocol &amp; 0x00010000) != 0);
__var protType = __protocol &amp; 0x0000FFFF;
</block>
<!-- JTAG Protocol -->
<control if="protType == 1">
<control if="isSWJ">
<block atomic="1">
// Ensure current debug interface is in reset state
DAP_SWJ_Sequence(51, 0x0007FFFFFFFFFFFF);
// Execute SWJ-DP Switch Sequence SWD to JTAG (0xE73C)
// Change if SWJ-DP uses deprecated switch code (0xAEAE)
DAP_SWJ_Sequence(16, 0xE73C);
// Ensure JTAG interface is reset
DAP_SWJ_Sequence(6, 0x3F);
</block>
</control>
<block atomic="1">
// JTAG "Soft" Reset
DAP_JTAG_Sequence(6, 1, 0x3F);
DAP_JTAG_Sequence(1, 0, 0x01);
</block>
</control>
<!-- SWD Protocol -->
<control if="protType == 2">
<control if="isSWJ">
<block atomic="1">
// Ensure current debug interface is in reset state
DAP_SWJ_Sequence(51, 0x0007FFFFFFFFFFFF);
// Execute SWJ-DP Switch Sequence JTAG to SWD (0xE79E)
// Change if SWJ-DP uses deprecated switch code (0xEDB6)
DAP_SWJ_Sequence(16, 0xE79E);
// Enter SWD Line Reset State
DAP_SWJ_Sequence(51, 0x0007FFFFFFFFFFFF); // &gt; 50 cycles SWDIO/TMS High
DAP_SWJ_Sequence(3, 0x00); // At least 2 idle cycles (SWDIO/TMS Low)
</block>
</control>
<control if="!isSWJ">
<block atomic="1">
// Enter SWD Line Reset State
DAP_SWJ_Sequence(51, 0x0007FFFFFFFFFFFF); // &gt; 50 cycles SWDIO/TMS High
DAP_SWJ_Sequence(3, 0x00); // At least 2 idle cycles (SWDIO/TMS Low)
</block>
</control>
<block>
// Read DPIDR to enable SWD interface (SW-DPv1 and SW-DPv2)
ReadDP(0x0);
</block>
</control>
</sequence>

DebugPortStart

Connect to the target debug port and power it up.

<sequence name="DebugPortStart">
<block>
__var SW_DP_ABORT = 0x0;
__var DP_CTRL_STAT = 0x4;
__var DP_SELECT = 0x8;
__var powered_down = 0;
// Switch to DP Register Bank 0
WriteDP(DP_SELECT, 0x00000000);
// Read DP CTRL/STAT Register and check if CSYSPWRUPACK and CDBGPWRUPACK bits are set
powered_down = ((ReadDP(DP_CTRL_STAT) &amp; 0xA0000000) != 0xA0000000);
</block>
<control if="powered_down">
<block>
// Request Debug/System Power-Up
WriteDP(DP_CTRL_STAT, 0x50000000);
</block>
<!-- Wait for Power-Up Request to be acknowledged -->
<control while="(ReadDP(DP_CTRL_STAT) &amp; 0xA0000000) != 0xA0000000" timeout="1000000"/>
<block>
// Request Debug Reset
WriteDP(DP_CTRL_STAT, 0x54000000);
</block>
<!-- Wait for Debug Reset to be acknowledged, don't issue error on timeout to deal with improperly connected Debug Reset -->
<control while="(ReadDP(DP_CTRL_STAT) &amp; 0xA8000000) != 0xA8000000" timeout="300000"/>
<!-- JTAG Specific Part of sequence -->
<control if="__protocol == 1">
<block>
// Init AP Transfer Mode, Transaction Counter, and Lane Mask (Normal Transfer Mode, Include all Byte Lanes)
// Additionally clear STICKYORUN, STICKYCMP, and STICKYERR bits by writing '1'
WriteDP(DP_CTRL_STAT, 0x50000F32);
</block>
</control>
<!-- SWD Specific Part of sequence -->
<control if="__protocol == 2">
<block>
// Init AP Transfer Mode, Transaction Counter, and Lane Mask (Normal Transfer Mode, Include all Byte Lanes)
WriteDP(DP_CTRL_STAT, 0x50000F00);
// Clear WDATAERR, STICKYORUN, STICKYCMP, and STICKYERR bits of CTRL/STAT Register by write to ABORT register
WriteDP(SW_DP_ABORT, 0x0000001E);
</block>
</control>
</control>
</sequence>

DebugPortStop

Power down and disconnect from target debug port.

<sequence name="DebugPortStop">
<block>
__var DP_CTRL_STAT = 0x4;
__var DP_SELECT = 0x8;
// Switch to DP Register Bank 0
WriteDP(DP_SELECT, 0x00000000);
// Power Down Debug port
WriteDP(DP_CTRL_STAT, 0x00000000);
</block>
</sequence>

DebugCoreStart

Initialize core debug system.

<sequence name="DebugCoreStart">
<block>
// System Control Space (SCS) offset as defined in ARMv6-M/ARMv7-M.
__var SCS_Addr = 0xE000E000;
__var DHCSR_Addr = SCS_Addr + 0xDF0;
// Enable Core Debug via DHCSR
Write32(DHCSR_Addr, 0xA05F0001);
</block>
</sequence>

DebugCoreStop

Un-initialize core debug system.

<sequence name="DebugCoreStop">
<block>
// System Control Space (SCS) offset as defined in ARMv6-M/ARMv7-M.
__var SCS_Addr = 0xE000E000;
__var DHCSR_Addr = SCS_Addr + 0xDF0;
__var DEMCR_Addr = SCS_Addr + 0xDFC;
// Disable Core Debug via DHCSR
Write32(DHCSR_Addr, 0xA05F0000);
// Disable DWT and ITM blocks, DebugMonitor handler,
// halting debug traps, and Reset Vector Catch.
Write32(DEMCR_Addr, 0x00000000);
</block>
</sequence>

ResetSystem

Execute a system-wide reset via software mechanisms.

<sequence name="ResetSystem">
<block>
// System Control Space (SCS) offset as defined in ARMv6-M/ARMv7-M.
__var SCS_Addr = 0xE000E000;
__var AIRCR_Addr = SCS_Addr + 0xD0C;
__var DHCSR_Addr = SCS_Addr + 0xDF0;
// Execute SYSRESETREQ via AIRCR
Write32(AIRCR_Addr, 0x05FA0004);
</block>
<!-- Reset Recovery: Wait for DHCSR.S_RESET_ST bit to clear on read -->
<control while="(Read32(DHCSR_Addr) &amp; 0x02000000) == 0" timeout="500000"/>
</sequence>

ResetProcessor

Execute a processor reset via software mechanisms.

Note
This Default Debug Access Sequence is empty for ARMv6-M based processors.
<sequence name="ResetProcessor">
<block>
// System Control Space (SCS) offset as defined in ARMv7-M.
__var SCS_Addr = 0xE000E000;
__var AIRCR_Addr = SCS_Addr + 0xD0C;
__var DHCSR_Addr = SCS_Addr + 0xDF0;
// Execute VECTRESET via AIRCR
Write32(AIRCR_Addr, 0x05FA0001);
</block>
<!-- Reset Recovery: Wait for DHCSR.S_RESET_ST bit to clear on read -->
<control while="(Read32(DHCSR_Addr) &amp; 0x02000000) == 0" timeout="500000"/>
</sequence>

ResetHardware

Execute a system-wide reset via the dedicated debugger reset line nRST.

<sequence name="ResetHardware">
<block>
__var nReset = 0x80;
__var canReadPins = 0;
// Deassert nRESET line
canReadPins = (DAP_SWJ_Pins(0x00, nReset, 0) != 0xFFFFFFFF);
</block>
<!-- Keep reset active for 50 ms -->
<control while="1" timeout="50000"/>
<control if="canReadPins">
<!-- Assert nRESET line and wait max. 1s for recovery -->
<control while="(DAP_SWJ_Pins(nReset, nReset, 0) &amp; nReset) == 0" timeout="1000000"/>
</control>
<control if="!canReadPins">
<block>
// Assert nRESET line
DAP_SWJ_Pins(nReset, nReset, 0);
</block>
<!-- Wait 100ms for recovery if nRESET not readable -->
<control while="1" timeout="100000"/>
</control>
</sequence>

ResetHardwareAssert

Assert a system-wide reset line nRST.

<sequence name="ResetHardwareAssert">
<block>
__var nReset = 0x80;
// Deassert nRESET line to activate the hardware reset
DAP_SWJ_Pins(0, nReset, 0);
</block>
</sequence>

ResetHardwareDeassert

De-Assert a system-wide reset line nRST.

<sequence name="ResetHardwareDeassert">
<block>
__var nReset = 0x80;
__var canReadPins = 0;
// Assert nRESET line and check if nRESET is readable
canReadPins = (DAP_SWJ_Pins(nReset, nReset, 0) != 0xFFFFFFFF);
</block>
<!-- Wait max. 1s for nRESET to recover from reset if readable-->
<control if="canReadPins" while="(DAP_SWJ_Pins(nReset, nReset, 0) &amp; nReset) == 0" timeout="1000000"/>
<!-- Wait 100ms for recovery if nRESET not readable -->
<control if="!canReadPins" while="1" timeout="100000"/>
</sequence>

ResetCatchSet

Configure the target to stop code execution after a reset.

<sequence name="ResetCatchSet">
<block>
// System Control Space (SCS) offset as defined
// in ARMv6-M/ARMv7-M. Reimplement this sequence
// if the SCS is located at a different offset.
__var SCS_Addr = 0xE000E000;
__var DHCSR_Addr = SCS_Addr + 0xDF0;
__var DEMCR_Addr = SCS_Addr + 0xDFC;
__var value = 0;
// Enable Reset Vector Catch in DEMCR
value = Read32(DEMCR_Addr);
Write32(DEMCR_Addr, (value | 0x00000001));
// Read DHCSR to clear potentially set DHCSR.S_RESET_ST bit
Read32(DHCSR_Addr);
</block>
</sequence>

ResetCatchClear

Free hardware resources allocated by ResetCatchSet.

<sequence name="ResetCatchClear">
<block>
// System Control Space (SCS) offset as defined
// in ARMv6-M/ARMv7-M. Reimplement this sequence
// if the SCS is located at a different offset.
__var SCS_Addr = 0xE000E000;
__var DEMCR_Addr = SCS_Addr + 0xDFC;
__var value = 0;
// Disable Reset Vector Catch in DEMCR
value = Read32(DEMCR_Addr);
Write32(DEMCR_Addr, (value &amp; (~0x00000001)));
</block>
</sequence>

Writing debug access sequences

To override a default sequence or to create a custom (default) sequence, you need to write sequence elements. The following sections show how to use the built-in debug access syntax, expressions, and debug access functions to create custom sequences.

Debug access syntax rules

Debug accesses are described in block elements of a debug access sequence (sequence element). The following syntax is used for this purpose:

  • The contents of a block element is a series of statements.
  • Each statement must begin in a new line and is terminated by a ; character.
  • A typical statement consists of variable, followed by a = character and an expression, where the = character is an assignment of the expression result to the variable:
    variable = expression;
  • Alternatively, a statement can be a sole expression without storing its result to a variable.
    expression;
  • Comments begin with two slashes (//) and end with a linebreak:
    // Whole line is a comment
    variable = expression; // Comment appended to statement
  • Variables must be defined using the keyword __var. The definition must include an initalization of the variable:
    __var variable = 0;
  • Variables can be defined only once within a scope. Scopes beging with entering a debug access sequence or a control element. They are extended to child control elements. Variables of a parent scope can be modified. Leaving a scope destroys all variables defined in it.
    block elements do not begin a new scope.
    <sequence name="MySequence">
    <block info="Block 1">
    __var condvar = 1;
    __var myvar1 = 5;
    __var myvar2 = 0;
    </block>
    <control if="condvar">
    <block>
    // __var myvar1 = 2; // Redefinition, not allowed!
    __var myvar3 = 2;
    myvar2 = myvar1 + myvar3; // Assign value (5+2) = 7
    </block>
    </control>
    <block info="Block 2">
    myvar1 = myvar2 + 1; // Variable myvar1 holds the value '8' after this statement
    // myvar2 = myvar3; // myvar3 does not exist in this scope, not allowed!
    </block>
    </sequence>
  • The debug access variables __dp, __ap, and __errorcontrol can be modified within a debug access sequence. An assigned value is held until leaving the sequence. Calling another sequence by the Sequence debug access function will push their values on a sequence execution stack. The values are restored when returning from such a call.

Expression rules

Expressions are used in various places to describe one of the following:

  • A value as assigned in a debug access statement.
  • A condition to use in the if attribute of a control element.
  • A condition to use in the while attribute of a control element.
  • A parameter to a debug access function as described below.

An expression may consist of the following:

  • Constant numbers in decimal and hexadecimal representation (prefix 0x).
  • Arithmetic operators such as +, -, *, /, and %.
  • Bit-arithmetic operators such as &, |, ~, ^, >>, and <<.
  • Comparison-operators such as ==, !=, <, >, <=, and >=.
  • Logic operators such as !, &&, ||, and ==.
  • Conditional expression operations like:
    (x < y) ? a : b
  • Precedence of sub-expressions is indicated by brackets ((, )). C-like precedence applies if brackets are omitted.
  • References to debug access variables for evaluating debug settings.
  • Calls to debug access functions.
Note
  • All values used in expressions resolve to 64-bit unsigned integer values.
  • All logic-operations and comparisons resolve to the value 1 if true, to 0 otherwise.
  • XML prohibits the use of the characters &, <, and >. Use the corresponding XML entity names instead: &amp;, &lt;, and &gt;.

 

Debug access functions

Debug access functions can be called in expressions in order to interact with the target device and the user. Parameters to functions can again be expressions.
By default, a debugger must abort the execution of a debug access sequence if a function call fails. However, this behavior can be controlled from a sequence by the __errorcontrol debug access variable.

The following table describes the existing debug access functions, their parameters and the debug access variables which are evaluated for the function call.

Function Description
Sequence("name")

Execute a debug access sequence. Calling a sequence by this function causes the modifiable debug access variables __dp, __ap, and __errorcontrol to be pushed on a sequence execution stack. Returning from such a call will restore the state of these variables.

Parameters:

  • name: Name of the sequence to execute. It must be enclosed by quotes.

Return Value:
Always returns 0.

Read8(addr)

Read an 8-bit value from target memory. A device must support native 8-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to read from.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
The 8-bit value as read from target memory.

Read16(addr)

Read an 16-bit value from target memory. A device must support native 16-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to read from.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
The 16-bit value as read from target memory.

Read32(addr)

Read an 32-bit value from target memory. A device must support native 32-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to read from.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
The 32-bit value as read from target memory.

Code Example:
Refer to ResetSystem

Read64(addr)

Read an 64-bit value from target memory. A device must support native 64-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to read from.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
The 64-bit value as read from target memory.

ReadAP(addr)

Read a 32-bit value from an access port register.

Parameters:

  • addr: AP register address to read from. Addresses larger than 0xF automatically cause an AP register bank switch.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
The 32-bit value as read from the AP register.

ReadDP(addr)

Read a 32-bit value from a debug port register.

Parameters:

  • addr: DP register address to read from.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.

Return Value:
The 32-bit value as read from the DP register.

Code Example:
Refer to DebugPortSetup

Write8(addr, val)

Write an 8-bit value to target memory. A device must support native 8-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
Always returns 0.

Write16(addr, val)

Write a 16-bit value to target memory. A device must support native 16-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
Always returns 0.

Write32(addr, val)

Write a 32-bit value to target memory. A device must support native 32-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
Always returns 0.

Code Example:
Refer to DebugCoreStart

Write64(addr, val)

Write a 64-bit value to target memory. A device must support native 64-bit memory accesses for this function to succeed.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
Always returns 0.

WriteAP(addr, val)

Write a 32-bit value to an access port register. Addresses larger than 0xF automatically cause an AP register bank switch.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.
  • __ap: The access port to use for this memory access.

Return Value:
Always returns 0.

WriteDP(addr, val)

Write a 32-bit value to a debug port register.

Parameters:

  • addr: Memory address to write to.
  • val: Value to write.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.

Return Value:
Always returns 0.

Code Example:
Refer to DebugPortStart

DAP_Delay(delay)

Debug probe command to wait for a specific delay.

Parameters:

  • delay: Wait time in microseconds.

Return Value:
Always returns 0.

DAP_WriteABORT(value)

Debug probe command to write an abort request to the CoreSight ABORT register of the target debug port.

Parameters:

  • value: 32-bit value to write into the CoreSight ABORT register.

Debug Access Variables:

  • __dp: The debug port to use for this memory access.

Return Value:
Always returns 0.

DAP_SWJ_Pins(pinout, pinselect, pinwait)

Debug proble command to monitor and control the I/O Pins including the nRESET device reset line.
I/O Pin Mapping for pinout, pinselect, and pinwait:

  • Bit 0: SWCLK/TCK
  • Bit 1: SWDIO/TMS
  • Bit 2: TDI
  • Bit 3: TDO
  • Bit 5: nTRST
  • Bit 7: nRESET


The pinwait time is useful in systems where the nRESET pin is implemented as open-drain output. After nRESET is de-asserted by the debugger, external circuit may still hold the target Device under reset for a time. Using the pinwait time, the debugger may monitor selected I/O Pins and wait until they the expected value appears or a timeout expires.

Parameters:

  • pinout: Value for selected output pins.
  • pinselect: Selects which output pins will be modified.
  • pinwait: Wait timeout for the selected output to stabilize. A debugger must extend this timeout to the closest possible time granularity.
    • 0 = no wait
    • 1 .. 3000000 = time in microseconds (max 3s)

Return Value:
The state of the I/O Pins at the end of this operation. If a debugger is not capable of monitoring the I/O Pins, it must return a value of 0xFFFFFFFF.

DAP_SWJ_Clock(val)

Debug probe command to set the clock frequency for JTAG and SWD communication mode.

Parameters:

  • val: Maximum SWD/JTAG Clock (SWCLK/TCK) value in Hz.

Return Value:
Always returns 0.

Code Example:
Refer to ResetHardware

DAP_SWJ_Sequence(cnt, val)

Debug probe command to generate required SWJ sequences, e.g. for SWD/JTAG Reset, SWD<->JTAG switch and Dormant operation.

Parameters:

  • cnt: Number of bits in sequence: 1..64. Larger sequences need to be implemented by multiple subsequent DAP_SWJ_Sequence calls. Such a sequence of DAP_SWJ_Sequence commands must be encapsulated in an atomic block to ensure correct execution.
  • val: Sequence generated on SWDIO/TMS (with clock @SWCLK/TCK), LSB transmitted first.

Return Value:
Always returns 0.

Code Example:
Refer to DebugPortSetup

DAP_JTAG_Sequence(cnt, tms, tdi)

Debug probe command to generate a JTAG sequence with fixed TMS value and capture TDO.

Parameters:

  • cnt: Length of the JTAG sequence (number of TCK cycles and TDI bits): 1..64
  • tms: Fixed TMS value: 0..1
  • tdi: Data generated on TDI with one bit per TCK cycle, LSB transmitted first.

Return Value:
Data captured from TDO with one bit per TCK cycle, LSB captured first and padded with 0s.

Query(type, "message", default)

Query user input. The sequence execution stalls depending on the used type. If the debugger runs in a batch mode, this function returns the value default.

Parameters:

  • type: Query type. Can be one of:
    • 0 : Query_Ok, displays an informative message which has to be confirmed by the user. This type allows the result OK.
    • 1 : Query_YesNo, displays a query with the allowed results Yes and No.
    • 2 : Query_YesNoCancel, displays a query with the allowed results Yes, No, and Cancel.
    • 3 : Query_OkCancel, displays a query with the allowed results OK and Cancel.
  • message: A constant string with the query message to display. It must not be an expression and it must be enclosed by quotes.
  • default: The default value to return if the debugger runs in batch mode. See Return Values for a list of allowed values.

Return Value:
The result of the query. The user input maps to the following numbers:

  • Error : 0
  • OK : 1
  • Cancel : 2
  • Yes : 3
  • No : 4

Code Example:
Refer to DebugPortSetup

QueryValue("message", default)

Query input value from user. The sequence execution stalls until the user has entered a value or canceled the query. This function returns the default value if the user canceled the query or if the debugger runs in a batch mode.

Parameters:

  • message: A constant string with the query message to display. It must not be an expression and it must be enclosed by quotes.
  • default: The default value to return if the user cancels the query or if the debugger runs in batch mode.

Return Value:
The queried value.

Message(type, "format", ...)

Outputs a message to a log window.

Parameters:

  • type: Message type. Can be one of:
    • 0 : Info, outputs an informative message.
    • 1 : Warning, outputs a warning.
    • 2 : Error, outputs an error. Sequence execution aborts.
  • format: A constant string with the message format. It must not be an expression and it must be enclosed by quotes. The string has the following format:
    %[flags][width][.precision]specifier
    • Specifiers:
      • %u: 32-bit unsigned decimal integer.
      • %llu: 64-bit unsigned decimal integer.
      • %x: 32-bit unsigned hexadecimal integer, lower case letters.
      • %llx: 64-bit unsigned hexadecimal integer, lower case letters.
      • %X: 32-bit unsigned hexadecimal integer, upper case letters.
      • %llX: 64-bit unsigned hexadecimal integer, upper case letters.
      • %o: 32-bit unsigned octal integer.
      • %llo: 64-bit unsigned octal integer.
      • %b: 32-bit unsigned binary integer.
      • %llb: 64-bit unsigned binary integer.
      • %f: Single-precision (32-bit) floating point value.
      • %Lf: Double-precision (64-bit) floating point value.
      • %s: Constant character string. Must not be an expression.
      • %%: Print % character.
    • Flags:
      • 0: Pad the displayed value with zeros instead of spaces if padding is required by the width option.
    • Width: Minimum number of displayed characters. If width is less than the number of characters of the value, then the value is padded with spaces to the left.
    • .Precision:
      • Integer: Minimum number of displayed digits. Padded with zeros to the left if the value has less digits than specified with .precision.
      • Floating Point: Number of displayed digits after decimal point. Defaults to 6 if not specified.
      • Constant String: Maximum number of displayed characters.
  • ... : Additional function parameters to replace format string specifiers. Each parameter can be a constant string, or an expression that resolves to an unsigned 64-bit integer. A parameter type must match the corresponding specifier type.

Return Value:
Always returns 0.

Note
For 32-bit specifiers the Message command must print the lower 32 Bit of a 64 Bit debug access variable.
LoadDebugInfo("file")

Loads DWARF debug information from an application executable.

Parameters:

  • file: A constant string with the path to the executable. The path must be relative to the root folder of the pack and use the format path/name.extension. It must not be an expression and it must be enclosed by quotes.

Return Value:
Returns 0 after successful debug information load.
Returns 1 if debug information load failed.

Note
  • Target memory access functions must perform a debug access of the size indicated by their name. The target system must support debug accesses of this size.
  • Results of all functions are casted to 64-bit unsigned integer values.
  • Some target access functions determine the used debug and access port by the current values of the __dp and __ap debug access variables. If a target access requires a different debug or access port than the default ones, it must change these values. This change is held until finishing the sequence the change has occurred in.