Microchip Technology SAM L11 Reference Manual

AN5365

SAM L11 Security Reference Guide

Introduction

This document is intended to help the developer to use SAM L11 security features for building secure
embedded applications.

The following application development aspects are covered in this document:

• Single and dual developer approach

• Secure solution development using SAM L11 ecosystem

• Secure software protection using ARM® TrustZone® for cortex®-M and Debug Access Levels

• System root of trust using Secure boot

The use of key security features is illustrated using bare-metal software examples on the following:

• Using SAM L11 Secure, Non-Secure, and Mix Secured peripherals.

• Using an embedded Cryptographic Accelerator (CRYA) for AES-128, SHA-256, and GCM algorithm.

• Using Data Flash and Trust RAM for storing and protecting application secrets using tamper
detection, scrambling, and silent accesses.

© 2019 Microchip Technology Inc.

DS70005365B-page 1

AN5365

Table of Contents

Introduction......................................................................................................................1

1. Introduction to SAM L11 Security Features............................................................... 3

1.1. TrustZone for ARMv8-M ..............................................................................................................3

1.2. Secure and Non-Secure Peripherals............................................................................................9

1.3. Mix-Secure Integrated Peripherals.............................................................................................10

1.4. Debug Access Level (DAL) and Chip Erase.............................................................................. 13

1.5. Secure Boot................................................................................................................................17

2. SAM L11 Application Development (Customer A and Customer B)........................21

2.1. Single-Developer Approach....................................................................................................... 21

2.2. Dual-Developer Approach.......................................................................................................... 21

2.3. Develop a Secure Solution (Customer A).................................................................................. 22

2.4. Develop a Non-Secure Project (Customer B)............................................................................ 40

2.5. Developing Solution with Secure Boot Program (Customer A).................................................. 56

3. Software Use Case Examples.................................................................................66

3.1. Non-Secure Peripheral (TC0).....................................................................................................66

3.2. Secure Peripheral (TC0)............................................................................................................ 68

3.3. Mix-Secure Peripheral (EIC)...................................................................................................... 70

3.4. TrustRAM................................................................................................................................... 74

3.5. Cryptographic Accelerator (CRYA).............................................................................................76

3.6. Data Flash.................................................................................................................................. 78

4. Revision History.......................................................................................................80

The Microchip Web Site................................................................................................ 81

Customer Change Notification Service..........................................................................81

Customer Support......................................................................................................... 81

Microchip Devices Code Protection Feature................................................................. 81

Legal Notice...................................................................................................................82

Trademarks................................................................................................................... 82

Quality Management System Certified by DNV.............................................................83

Worldwide Sales and Service........................................................................................84

© 2019 Microchip Technology Inc.

DS70005365B-page 2

Introduction to SAM L11 Security Features

1. Introduction to SAM L11 Security Features

1.1 TrustZone for ARMv8-M

The central security element for the Microchip SAM L11 microcontroller (MCU) is the implementation of
the TrustZone for an ARMv8-M device. The TrustZone technology is a System-on-Chip (SoC) and MCU
system-wide approach to security that enables Secure and Non-Secure application code to run on a
single MCU.

TrustZone for an ARMv8-M device is based on a specific hardware that is implemented in the Cortex-M23
core, which is combined with a dedicated secure instructions set. It enables creating multiple software
security domains that restricts access to selected memory, peripherals, and I/O to trusted software
without compromising the system performances.

The main goal of the TrustZone for a ARMv8-M device is to simplify security assessment of a deeply
embedded device. The principle behind the TrustZone for a ARMv8-M embedded software application is
illustrated in the figure below.

Figure 1-1. Standard Interactions Between Secure and Non-Secure States

AN5365

In the SAM L11 Cortex-M23 Core implementation, the security management is done using the
Implementation Defined Attribution Unit (IDAU). The IDAU interface controls the access to the execution
of specific instructions which are based on the current core security state and the address of the
instruction. The figure below illustrates the Core/Debugger access verification, performed by the system
prior to allowing access to specific memory region.

© 2019 Microchip Technology Inc.

DS70005365B-page 3

Figure 1-2. IDAU Interface and Memory Accesses

Core/Debugger

access

Combine

IDAU

Responder

IDAU

Interface

Non-

Secure

MPU

Secure

MPU

Access to

memory

Cortex-M23

Address

S / NS / NCS

SAM L11

AN5365

Introduction to SAM L11 Security Features

Thanks to this implementation, a simple function call or an interrupt processing results in a branch to a
specific security state as illustrated in the figure below. This allows for efficient calling by avoiding any
code and execution overhead.

Figure 1-3. ARMv8-M with TrustZone States Transition

© 2019 Microchip Technology Inc.

DS70005365B-page 4

1.1.1 Memory Security Attribution

SecureFlash

(BOOTRegion)

Non‐SecureCallableFlash

(BOOTRegion)

Non‐SecureFlash

(BOOTRegion)

SecureFlash

(APPLICATIONRegion)

Non‐SecureCallableFlash

(APPLICATIONRegion)

Non‐SecureFlash

(APPLICATIONRegion)

0x00000000

BS x0x100– BNSC x0x20

BOOTPROT x0x100

BS x0x100

(BOOTPROT +AS)x0x100–

ANSC x0x20

(BOOTPROT +AS)x0x100

0x00010000

Flash(Upto64KB)

SecureSRAM

Non‐SecureSRAM

SRAM(Upto16KB)

SecureDataFlash

Non‐SecureDataFlash

DataFlash(2KB)

0x400000

0x400000+(DS*0x20)

0x400800

0x20000000

0x20000000+(RS*0x80)

0x20004000

To differentiate and isolate the Secure code from the Non-Secure code, the SAM L11 memory is divided
into ten memory regions as shown in the figure below. Each region size can be configured using
dedicated NVM fuses, such as BS, BNSC, BOOTPROT, AS, ANSC, DS, and RS.

Figure 1-4. SAM L11 Memory Regions

AN5365

Introduction to SAM L11 Security Features

Each memory region is preconfigured in the hardware with one of the following attributes:

• Non-Secure (NS): Non-Secure addresses are used for memory and peripherals, which are

• Secure (S): Secure addresses are used for memory and peripherals, which are accessible only by

• Non-Secure Callable (NSC): NSC is a special type of Secure memory location. It enables software

The security attribute of each region will define the security state of the code stored in this region.

1.1.2 Secure and Non-Secure Function Call Mechanism

To prevent Secure code and data from being accessed from a Non-Secure state, the Secure code must
meet several requirements. The responsibility for meeting these requirements is shared between the
MCU architecture, software architecture, and the toolchain configuration.

At the core level, a set of Secure instructions dedicated to ARMv8-M devices are used to preserve and
protect the secure register values during the CPU security state transition.

• Secure Gateway (SG): Used for switching from a Non-Secure to a Secure state at the first instruction

• Branch with exchange to Non-Secure state (BXNS): Used by the Secure software to branch, or

• Branch with link and exchange to Non-Secure state (BLXNS): Used by the Secure software to call

At the toolchain level, a ‘C’ language Extension (CMSE) provided by ARM must be used to ensure the
use of AMRv8-M Secure instruction.

© 2019 Microchip Technology Inc.

accessible by all software running on the device.

Secure software.

transition from a Non-Secure to a Secure state.

of a Secure entry point.

return to the Non-Secure program.

the Non-Secure functions.

DS70005365B-page 5

At the software architecture level, specific Secure and Non-Secure function call mechanisms must be
used to ensure security, which are described in the following sections:

1.1.2.1 Non-Secure Callable APIs

When working with TrustZone for ARMv8-M, the application developer can define a set of Non-Secure
callable APIs which can be used to access the Secure code from the Non-Secure world. These APIs,
known as Secure Gateways (SG) or veneers are in charge of the CPU Security state switch and allow the
decoupling of Secure entry points from the rest of the Secure code. Therefore, limiting the amount of
code that can potentially be accessed by the Non-Secure state.

SG are expected to be placed in NSC memory regions, which are executable only when the CPU is in
Non-Secure state. The rest of the Secure code is expected to be placed in the Secure memory regions
which are not accessible when the CPU is in Non-Secure state, see figure below.

Figure 1-5. Non-Secure Callable APIs Mechanism

AN5365

Introduction to SAM L11 Security Features

Using Non-Secure callable APIs require the use of specific Cortex-M23 instructions that ensure security
during the core security state switching. A direct API function call from the Non-Secure to the Secure
software entry points is allowed only if the first instruction of the entry point is a SG and is in a Non­Secure callable memory location. The use of the special instructions (BXNS and BLXNS) are also
required to branch to Non-Secure code.

The following code illustrates Secure function and its SG APIs declaration and definition using ARM GCC
toolchain with a ‘’C language Extension (CMSE).

Veneer.h:

/* Non-secure callable functions */
extern int nsc_func1(int x);

Veneer.c (linked in the NSC memory region of the device):

/* Non-secure callable (entry) function */
int __attribute__((cmse_nonsecure_entry)) nsc_func1(int x)
{
return secure_func1(x);
}

© 2019 Microchip Technology Inc.

DS70005365B-page 6

Secure_function.c (linked in the secure memory region of the device):

int secure_func1(int x)
{
return x + 3;
}

1.1.2.2 Non-Secure Software Callbacks

The Secure code can define and use software callbacks to execute functions from the Non-Secure world.
This is a consequence of separating Secure and Non-Secure code into separate executable files. The
following figure shows the software callback approach.

Figure 1-6. Non-Secure Software Callbacks Flow Chart

AN5365

Introduction to SAM L11 Security Features

The management of callback functions can be performed using the BLXNS instruction. The following
figure illustrates the Non-Secure callback mechanism

© 2019 Microchip Technology Inc.

DS70005365B-page 7

Non-Secure

…
MOVr0,#10
MOV r1,#abc
ADD r2,r0,r1
…
BLXsecure_addr
CMP r1,#result
…

Secure NSC

…

SG

MOVS r1,#0
MOVS r3,#1
…
…

Secure

DCD0xE97FE97F
MOVSr1,#0
MOVSr3,#1
…
BXNSlr
…

Introduction to SAM L11 Security Features

Figure 1-7. Non-Secure Software Callback Mechanism

AN5365

Note:  The definition of Non-Secure software callback is done through pointer to Non-Secure code

location . If not correctly checked in the Secure application, a wrong use of pointers can lead to security
weakness that enables execution of any Secure functions by the Non-Secure code. To overcome this
disadvantages, a set of CMSE functions based on the new Cortex-M23 TT instructions is provided.

1.1.2.3 Security State and Call Mismatch

Any attempts to access Secure regions from the Non-Secure code, or a mismatch between the code that
is executed and the security state of the system results in a HardFault exception as shown in the
following figure.

Figure 1-8. Security State and Call Mismatch

© 2019 Microchip Technology Inc.

DS70005365B-page 8

1.1.3 Secure and Non-Secure Interrupts Handling

The Cortex-M23 (ARMv8-M architecture) uses the same exception stacking mechanism as the ARMv7-M
architecture, where a subset of core registers is stored automatically into the stack (hardware context
saving). This permits immediate execution of the interrupt handler without the need to perform a context
save in the software. ARMV8-M extends this mechanism to provide enhanced security based on two
different stack pointers (a Secure stack pointer and a Non-Secure stack pointer).

According to the priority settings configured in the Nested Vector Interrupt Controller (NVIC), Secure code
execution can interrupt Non-Secure code execution, and Non-Secure code can interrupt Secure code
execution. The NVIC registers at the core level are duplicated. This allows two vector table definitions,
one for Secure and another for Non-Secure.

At product start-up, all interrupts are mapped by default to the Secure world (Secure vector table).
Specific CMSIS functions accessible in the Secure world, allocate each interrupt vector to a Non-Secure
handler (declared in Non-Secure vector table).

As illustrated in the figure below, if the Secure code is running when a higher priority Non-Secure interrupt
arrives, the core pushes all its register content into a dedicated Secure stack. Registers are then zeroed
automatically to prevent any information being read, and the core executes the Non-Secure exception
handler. When the Non-Secure handler execution is finished, the hardware recovers all the registers from
the Secure stack automatically. This mechanism is managed in hardware and does not require any
software intervention. This allows a Secure handover from running Secure code to a Non-Secure
interrupt handler and returning to running Secure code.

AN5365

Introduction to SAM L11 Security Features

Figure 1-9. Cortex-M 23 Interrupt Mechanism

1.2 Secure and Non-Secure Peripherals

The SAM L11 extends the concept of TrustZone to its integrated peripherals and offers the possibility to
allocate specific peripheral to Secure and Non-Secure world. the management of each peripheral security
attribution is done through the Peripheral Access Controller (PAC).

As shown in the figure below, The PAC controller embeds a set of registers that define the security
attribution of each integrated peripheral of the system. These registers are configured at device startup by
the ROM code which set the PAC.NONSECx registers according to the user configuration stored in the
User Row (UROW) fuses.

© 2019 Microchip Technology Inc.

DS70005365B-page 9

Introduction to SAM L11 Security Features

Figure 1-10. PAC.NONSECx Registers Description

Important:  The peripherals security attribution cannot be changed by accessing the

PAC.NONSECx registers during application run-time. Any changes must be done using the
User Row fuses and require a reset of the SAM L11 device. The application can read the
PAC.NONSECx register to get the current attribution of integrated peripherals.

AN5365

Peripherals can be categorized into two groups depending on their PAC security attribution and their
internal secure partitioning capabilities (standard/mix-secure):

• Non-Secure peripheral: A standard peripheral configured as Non-Secure in the PAC. The security
attribution of the whole peripheral is defined by the associated NONSECx fuse set to one. Secure
and Non-Secure accesses to the peripheral are granted.

• Secure peripheral: A standard peripheral configured as Secure in the PAC. The security attribution of
the whole peripheral is defined by the associated NONSECx fuse set to zero. Secure accesses to the
peripheral are granted where Non-Secure accesses are discarded (Write is ignored, Read 0x0), and
a PAC error is triggered.

When a peripheral is allocated to the Secure world, only Secure accesses to its registers are granted,
and interrupt handling should be managed in the Secure world only.

1.3 Mix-Secure Integrated Peripherals

The SAM L11 embeds five Mix-Secure peripherals, which allow part of their internal resources to be
shared between Secure and Non-Secure worlds. A complete list of SAM L11 Mix-Secure peripherals and
their shared resources are as follows:

• Peripheral Access Controller (PAC): Manages the peripherals security attribution (Secure or Non­Secure).

• Non-Volatile Memory Controller (NVMCTRL): Handles the Secure and Non-Secure Flash region
programming.

• I/O Pin Controller (PORT): Supports individual allocation of each I/O to the Secure or Non-Secure
applications.

• External Interrupt Controller (EIC): Supports individual assignment of each external interrupt to the
Secure or Non-Secure applications.

© 2019 Microchip Technology Inc.

DS70005365B-page 10

• Event System (EVSYS): Supports individual assignment of each event channel to the Secure or Non­Secure applications.

The capability for a Mix-Secure peripheral to share its internal resources depends on the security
attribution of that peripheral in the PAC peripheral (PAC Secured or PAC Non-Secured).

• When a Mix-Secure peripheral is Secured (NONSECx fuse set to zero), the Secure world can
allocate internal peripheral resources to the Non-Secure world using dedicated registers.

• When a Mix-Secure peripheral is Non-Secure (NONSECx fuse set to one), the peripheral behaves as
a standard Non-Secure peripheral. Secure and Non-Secure accesses to the peripheral register are
granted.

1.3.1 Mix-Secure Peripheral (PAC Secured)

When a Mix-Secure peripheral is PAC Secured (associated PAC NONSECx fuses set to 0), the peripheral
register is banked and accessible through two different memory aliases, as shown in the figure below.

Figure 1-11. PAC Secured Mix-Secure Peripheral Registers Addressing

AN5365

Introduction to SAM L11 Security Features

The Secure world can then independently enable Non-Secure access to the internal peripheral resources
using the NONSEC register, as shown in the following figure for the External Interrupt Controller.

© 2019 Microchip Technology Inc.

DS70005365B-page 11

Figure 1-12. NONSEC Register

AN5365

Introduction to SAM L11 Security Features

The NONSEC register content can only be modified by the Secure world through the peripheral register
Secure alias (PERIPH_SEC.NONSEC).

Setting a specific internal feature bit field in the NONSEC register, enables the access to the different bit
fields associated to this feature in the peripheral Non-Secure alias.

1.3.2 Mix-Secure Peripheral (PAC Non-Secured)

When a Mix-Secure peripheral is PAC Non-Secured (associated NONSECx fuses set to 1), the peripheral
behaves as a standard Non-Secure peripheral.

Secure and Non-Secure accesses to the peripheral register are granted. The Peripheral register mapping
is shown in the figure below:

© 2019 Microchip Technology Inc.

DS70005365B-page 12

Introduction to SAM L11 Security Features

Figure 1-13. PAC Non-Secured Mix-Secure Peripheral Registers Addressing

AN5365

Managing PAC Non-Secured, Mix-Secured peripherals at the application level is similar to managing a
standard Non-Secure peripheral.

1.4 Debug Access Level (DAL) and Chip Erase

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.

Note:  For additional information on Boot Interactive mode, refer to the chapter “Boot ROM” in the “SAM
L11 Data Sheet” (DS60001513).

The Debug Access Level is combined with three key-protected ChipErase commands, which provide
three levels of Non-Volatile Memory erase granularity as shown in the figure below.

© 2019 Microchip Technology Inc.

DS70005365B-page 13

Figure 1-14. ChipErase Commands

CMDCEx:NSSAll

CMDCEx:NSSAll

SecureFlash

(BOOTRegion)

Non‐SecureCallableFlash

(BOOTRegion)

Non‐SecureFlash

(BOOTRegion)

SecureFlash

(APPLICATIONRegion)

Non‐SecureCallableFlash

(APPLICATIONRegion)

Non‐SecureFlash

(APPLICATIONRegion)

SecureDataFlash

Non‐SecureDataFlash

AN5365

Introduction to SAM L11 Security Features

The configuration of the ChipErase command protection Key is done through the BOCOR bit field
configuration, as shown in the following figure.

© 2019 Microchip Technology Inc.

DS70005365B-page 14

Introduction to SAM L11 Security Features

Figure 1-15. SAM L11 Configurable ChipErase Key Fuses

AN5365

The different ChipErase commands are used to increase the DAL level without compromising the code
security. Therefore, erase the code before changing to a higher DAL level, as illustrated in the figure
below.

Figure 1-16. SAM L11 DAL and ChipErase Mechanism

The Device Programming Utility provided within Atmel Studio 7 offers the easiest way to set the DAL
commands and ChipErase commands. It can also be used to access device fuses, as shown in the
following figures.

© 2019 Microchip Technology Inc.

DS70005365B-page 15

Introduction to SAM L11 Security Features

Figure 1-17. ChipErase Commands Under AS7 Device Programming

AN5365

© 2019 Microchip Technology Inc.

DS70005365B-page 16

Introduction to SAM L11 Security Features

Figure 1-18. ChipErase Key Fuses Setting Under AS7 Device Programming

AN5365

1.5 Secure Boot

The SAM L11 Boot ROM is always executed at product startup. This software is ROM coded into the
device and cannot be bypassed by the user. Depending on the Boot Configuration Row (BOCOR) fuse
setting, the Boot ROM knows if a Secure Boot region is defined in the system.

The Boot ROM can perform an integrity check (SHA-256) or authenticate (SHA-256 + BOOTKEY) the
firmware stored in the Secure Boot region prior to executing it. This verification mechanism is a key
element to consider for ensuring the system root of trust during deployment and execution of the Secure
firmware. The following figure illustrates the Secure Boot process with BS (including BNSC) verification.

© 2019 Microchip Technology Inc.

DS70005365B-page 17

SecureFlash

(BOOTRegion)

Non‐SecureCallableFlash

(BOOTRegion)

Non‐SecureFlash

(BOOTRegion)

SecureFlash

(APPLICATIONRegion)

Non‐SecureCallableFlash

(APPLICATIONRegion)

Non‐SecureFlash

(APPLICATIONRegion)

0x00000000

BS x0x100– BNSC x0x20

BS x0x100

0x00010000

Flash(Upto64KB)

BootROM

ROM

‐ VerifySecureBoot

Region(optional)

‐ Jumpataddress

0x00000000

Introduction to SAM L11 Security Features

Figure 1-19.  Secure Boot Process with BS+BNSC Verification

AN5365

To validate the Secure Bootloader code stored in the Device Flash BS+BNSC memory section, the ROM
code computes the hash of the Flash BS+BNSC regions using the crypto accelerator (CRYA) and
compares it to a reference hash (256 bits/32 bytes) stored in the device BS memory section. This
reference hash (256 bits) must be stored in the last 256 bits of the Secure Flash (BOOT Region) as
shown in the following figure.

© 2019 Microchip Technology Inc.

DS70005365B-page 18

AN5365

Introduction to SAM L11 Security Features

Figure 1-20. Boot Secure Reference Hash Location

If the verification result is equal to the reference hashes, the Boot ROM starts the Secure Bootloader
execution. Any mismatch in the value puts the device in an endless reset loop preventing Flash code
execution. Only a ChipErase_ALL command allows the recovery from this device state. The
ChipErase_ALL commands erase the full memory content and reset the fuses to their factory settings.

The following fuses are used in the Secure Boot process configuration:

• BOOTPROT, BS and BSNC: Defines the configuration of the boot section in product Flash. The size
of the Secure, Non-Secure and Non-Secure-Callable boot sections can be customized according to
the application need. These fuses are used for security memory allocation in product IDAU and for
integrity and authentication mechanisms when configured in the BOOTOPT fuse. Any change of the
fuse setting requires a reset to be considered by the device as only the Boot ROM can change IDAU
setting.

• BOOTOPT: Defines the type of verification to be performed as Secure or Non-Secure.

– 0: No verification method

– 1: Integrity check (SHA256)

– 2 or 3: Authentication check (SHA-256 with BOOTKEY)

Note:  Using the Secure Boot Authentication feature has an impact on the product start up time. Refer to
the “ SAM L10/L11 Data Sheet” (DS60001513) for additional information.

BOOTKEY: 256-bit BOOTKEY used for Authentication mechanism.

The figure below highlights the fuses used for configuring the Secure boot process.

© 2019 Microchip Technology Inc.

DS70005365B-page 19

Figure 1-21. Secure Boot Process Fuses

AN5365

Introduction to SAM L11 Security Features

© 2019 Microchip Technology Inc.

DS70005365B-page 20

AN5365

SAM L11 Application Development (Customer A ...

2. SAM L11 Application Development (Customer A and Customer B)

The combination of the system DAL and ChipErase with TrustZone for Cortex-M architecture enables the
developers to follow the following development and deployment approaches:

• Single-developer approach (Customer A)

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

Atmel Studio 7 integrated development platform 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.

2.1 Single-Developer Approach

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

Figure 2-1. Single Developer Approach

2.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 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 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. The figure below illustrates a dual developer
approach on SAM L11.

© 2019 Microchip Technology Inc.

DS70005365B-page 21

Figure 2-2. Dual-Developer Approach

Blank

SAML11

Securepre‐programmed

L11/Modules

FinalApplication

Non‐secureLinkerfile

+

NSClibrary(.lib/.h)

AN5365

SAM L11 Application Development (Customer A ...

The following sections describe the application development and deployment process to be implemented
for Customer A and Customer B.

2.3 Develop a Secure Solution (Customer A)

To help Customer A to start with SAM L11 (regardless of single or dual developer approaches), Atmel
Studio 7 provides a pre-configured Secure Solution template that illustrates the basic Secure and Non­Secure application execution as shown in the figure below. This template can be used to evaluate and
understand the TrustZone for ARMv8-M implementation in the device, or as a start-up point for custom
solution development.

© 2019 Microchip Technology Inc.

DS70005365B-page 22

SecureProject

SystemStart

Securefunction1

Securefunction2

NonsecureProject

Userapplication

TrustZone
forCortex‐M

Start

Functioncall

Functioncall

SAM L11 Application Development (Customer A ...

Figure 2-3. Secure Solution Template Overview

AN5365

2.3.1 Creating SAM L11 Secure Solution from Atmel Studio Secure Solution Template

Creating a Secure Solution from the pre-configured template available in Atmel Studio 7 can be done by
following these steps :

1. Open Atmel Studio 7.

2. Select File > New > Project….

3. Configure new solution in the New Project window (See image below):

3.1. Under Installed, select C/C++ .

3.2. Select SAM L11 Secure Solution.

3.3. Enter details for Name, Location, Solution, and Solution Name and then click OK.

© 2019 Microchip Technology Inc.

DS70005365B-page 23

SAM L11 Application Development (Customer A ...

Figure 2-4. Creating SAM L11 Solution Under AS7

AN5365

© 2019 Microchip Technology Inc.

DS70005365B-page 24

AN5365

SAM L11 Application Development (Customer A ...

When created, the SAM L11 Secure Solution should appear in the Atmel Studio 7 IDE, as shown below:

Figure 2-5. SAM L11 Secure Solution Under AS7

© 2019 Microchip Technology Inc.

DS70005365B-page 25

2.3.2 Secure Solution Template Description

BOCOR/UROW files : Contains fuses setting definition

Secure Linker file : Contains link configuration for the

Secure application

Secure Startup file : Contains the Secure vector table and

Secure Reset Handler

Secure System file : Contains the initialization functions

for the system resources allocated to Secure application

Secure .c/.h files : Contains the Secure function examples

Secure Main File : Contains the secure Application main

routine

Veneer .c/.h files : Contains the definition and declaration

of the Non-Secure Callable (NSC) gateway to the secure
functions declared in secure.c/.h

Any solution created from the SAM L11 Secure Solution Template, provided with Atmel Studio 7, is
composed of preconfigured Non-Secure and Secure projects.

All the configuration aspects related to TrustZone for ARMv8-M implementation are already implemented
to facilitate the development process. The following sections describe the content of the template and the
key elements to be modified to customize the solution according to the application needs.

2.3.2.1 Secure Project Description

The goal of the Secure project included in the SAM L11 Secure Solution template is to provide a
preconfigured development base for Secure code development on SAM L11. The Secure project is
preconfigured to illustrate the following applicative aspects of a standard Secure application on SAM L11:

• Device resources attribution to Secure and Non-Secure worlds (fuse settings)

• Initialization of the system security

• Definition and declaration of Secure functions example

• Definition and declaration of Secure gateways with Non-Secure world (veneers)

• Secure call to the Non-Secure application

The following figure describes the file architecture of the preconfigured Secure project:

AN5365

SAM L11 Application Development (Customer A ...

Figure 2-6. Secure Project Architecture

The following figure describes the main routine of the pre-configured Secure project:

© 2019 Microchip Technology Inc.

DS70005365B-page 26