SAM L11 Debug Access Level

Debug Access Level Overview

The SAM L11 has the following configurable Debug Access Levels (DAL), which restrict programming and debug access to Secure and Non-Secure resources in the system:

  • DAL2: Debug access with no restrictions in terms of memory and peripheral accesses.
  • DAL1: Access is limited to the Non-Secure memory regions. Secure memory region accesses are forbidden.
  • DAL0: No access is authorized except with a debugger using the Boot ROM Interactive mode.

The DAL is combined with three key-protected ChipErase commands, which provide three levels of Non-Volatile Memory (NVM) erase granularity as shown in Figure 1.

SAML11_DAL.png
Figure 1


Decreasing the DAL is done using the NVM Controller (NVMCTRL) peripheral command from the debugger or the CPU. For security reasons, increasing the DAL is only possible during Boot ROM execution and will be always preceded by a specific chip erase depending on the DAL.

Related Peripherals

The related peripheral to change DAL is the NVMCTRL. The Device Service Unit (DSU) is the peripheral that applies the DAL once the device reboots after having read the NVM Rows. See also SAM L11 Secure boot.

Developer Approaches

The combination of the system DAL and ChipErase with ARM® TrustZone® for Cortex-M23 architecture enables developers to adopt the following development and deployment approaches:

  • Single-developer approach (Customer A)
  • Dual-developer approach (Customer A + Customer B)

Atmel Studio 7 integrated development environment provides a full set of advanced features to accelerate the development of a SAM L11 application. The following sections illustrate the approaches to be followed by Customer A and Customer B to create and customize their application.

Single-Developer Approach

In a single developer approach, the developer (Customer A) is in charge of developing and deploying a Secure and Non-Secure code. The application of Customer A can be protected by using DAL0. Figure 2 illustrates a single developer approach on SAM L11.

saml11-dal_single_dev.png
Figure 2

Dual-Developer Approach

In this approach, the first developer (Customer A) is in charge of developing the Secure application and its associated Non-Secure Callable (NSC) library (.lib/.h), and providing a predefined linker file to the second developer (Customer B). This Secure application is then loaded in the SAM L11 Flash and protected using the set DAL1 command to prevent further access to the Secure memory region of the device.

A second developer (Customer B) will then start his/her development on a preprogrammed SAM L11 with limited access to Secure resources (call to Non-Secure API only). To achieve this, Customer B will use a linker file and the NSC library provided by customer A. Figure 3 illustrates a dual developer approach on SAM L11.

saml11-dal_dual_dev.png
Figure 3

  Return to Top

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.