Difference between revisions of "J-Link ARMv8-M"

From SEGGER Wiki
Jump to: navigation, search
(Secure debug access)
 
(4 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
== TrustZone ==
 
== TrustZone ==
 
=== Secure debug access===
 
=== Secure debug access===
In secure mode, access to all system resources (memory, peripherals, ...) is possible. The secure part of the application can be debugged in this mode, only.
+
In secure mode, access to all system resources (memory, peripherals, ...) is allowed. In this mode, the non-secure part as well as the secure part can be debugged. Latter one can be debugged in this mode, only.
   
 
=== Non-secure debug access===
 
=== Non-secure debug access===
In non-secure mode, access to certain system resources (memory, peripherals, ...) is limited to protect resources which are classified as secure. The following list gives an overview of restrictions which need to be considered:
+
In non-secure mode, access to certain system resources (memory, peripherals, ...) is limited to protect resources which are classified as secure. If the DHCSR.S_SDE bit is cleared, secure invasive debug (switching from non-secure to secure domain) is prohibited. Otherwise, the debugger can switch to secure debug domain in order to perform secure accesses.<br>The following list gives an overview of restrictions which need to be considered in non-secure mode:
 
*The reset functionality (via SYSRESETREQ) can be disabled for non-secure mode using the AIRCR.SYSRESETREQS bit. Unfortunately, the debugger cannot read the SYSRESETREQS bit in non-secure mode thus cannot determine if reset functionality is available or not. The only possibility to determine if it's available or not is to issue a reset via AIRCR.SYSRESETREQ and to check if DHCSR.S_RESET_ST gets set afterwards. If not, reset is not available in the current configuration.
 
*The reset functionality (via SYSRESETREQ) can be disabled for non-secure mode using the AIRCR.SYSRESETREQS bit. Unfortunately, the debugger cannot read the SYSRESETREQS bit in non-secure mode thus cannot determine if reset functionality is available or not. The only possibility to determine if it's available or not is to issue a reset via AIRCR.SYSRESETREQ and to check if DHCSR.S_RESET_ST gets set afterwards. If not, reset is not available in the current configuration.

Latest revision as of 14:09, 8 May 2024

This article describes the debugging specifics for devices based on the ARMv8-M architecture.

TrustZone

Secure debug access

In secure mode, access to all system resources (memory, peripherals, ...) is allowed. In this mode, the non-secure part as well as the secure part can be debugged. Latter one can be debugged in this mode, only.

Non-secure debug access

In non-secure mode, access to certain system resources (memory, peripherals, ...) is limited to protect resources which are classified as secure. If the DHCSR.S_SDE bit is cleared, secure invasive debug (switching from non-secure to secure domain) is prohibited. Otherwise, the debugger can switch to secure debug domain in order to perform secure accesses.
The following list gives an overview of restrictions which need to be considered in non-secure mode:

  • The reset functionality (via SYSRESETREQ) can be disabled for non-secure mode using the AIRCR.SYSRESETREQS bit. Unfortunately, the debugger cannot read the SYSRESETREQS bit in non-secure mode thus cannot determine if reset functionality is available or not. The only possibility to determine if it's available or not is to issue a reset via AIRCR.SYSRESETREQ and to check if DHCSR.S_RESET_ST gets set afterwards. If not, reset is not available in the current configuration.