Introduction

This document describes the dual-developer application development with Arm® TrustZone® features on the Microchip SAM L11 microcontroller units (MCUs). The dual-developer application use case involves two developers: Developer A is responsible for developing the Secure application and Developer B is responsible for developing the Non-Secure application.

The PIC32CM LSx family of devices has Arm® Cortex®-M23 core, and are similar to SAM L1x MCUs with Arm TrustZone technology as a key security feature. The PIC32CM LSx family is an extension of the SAM L1x family with the following additional features:

  • Extended memory options of up to 512 KB Flash and 64 KB RAM
  • Higher performance of up to 48 MHz
  • Pin and feature compatible with SAML10/L11 MCUs
  • PIC32CM LS60 features integrated ATECC608 secure element in a single in-line package for implementing advanced security
  • Available in the 48-pin, 64-pin, and 100-pin packages

This document can also be used to create a project which uses Dual-Developer use case on PIC32CM LSx family. For additional information, refer to the IP Protection and Sandboxing Using the PIC32CM LSx MCUs.

A Secure application implements software security domains that restrict access to selected memory, peripherals, and I/O to trusted software without compromising the system performances. It achieves this by configuring the microcontroller's memory regions, peripherals, and I/O in a secure mode. This contrasts with the Non-Secure application, where the memory regions, peripherals, and I/O functions do not implement any access restrictions.

Developer A develops the Secure application and configures the Chip Erase keys in the fuse settings to prevent the Secure memory regions being erased by the Non-Secure developer or an outsider. They also configure the secure peripherals and secure memory regions footprint. Using a compiling application, the Secure Gateway (SG) library and the header file (generally nonsecure_entry.h) containing the Secure Gateway APIs declarations are generated. Developer A programs the Secure application onto the SAM L11 Flash and sets the microcontroller to Debug Access Level 1 (DAL1) to prevent further access to the device's secure memory region. Finally, Developer A shares the generated files, resource assignments, such as Secure peripherals, pins, memory attribution, and the pre-programmed SAM L11 with Developer B.

Note: The SG Library is also called the Veneer library, which is generated by the Secure project and placed during the Secure project link into the Non-Secure Callable (NSC) memory region. The SG Library acts as a bridge between the Secure world and the Non-Secure worlds through the specific Secure Gateway.

Developer B starts developing a Non-Secure application on a pre-programmed SAM L11 microcontroller with limited access to secure resources (through calls to Non-Secure callable APIs only). To do so, Developer B will use a predefined linker file (SG library) and the Non-Secure entry header file nonsecure_entry.h provided by Developer A. After the development is completed, the Non-Secure application is programmed to the Non-Secure memory region of the device. Therefore, the device is programmed with a TrustZone-based application.

The following diagram illustrates the dual-developer application development use case scenario.

Figure . Dual-Developer Application Use Case