14.4 Functional Description

SAM L10 Boot ROM Flow

The SAM L10 Boot ROM checks firstly if a debugger is present to enter the Boot Interactive mode which allows the user to perform specific tasks via a debugger connection.

Before jumping to the application, the Boot ROM can also enter in a specific mode called CPU Park to allow the debugger to get access to the resources of the device depending on Debug Access Level (DAL).

Note: Boot Interactive and CPU Park modes are described later on.

Typical Boot Timings

The delay is given from the release of the CPU reset to the execution of the first instruction of the user code:

Table 14-1. SAM L10 Typical Boot Timing
Time to reach User Code
1.33 ms

SAM L11 Boot ROM Flow

The SAM L11 Boot ROM sequence consists in performing several security tasks (integrity checks, memories and peripherals security attribution, secure boot...) before starting the application.

The Boot ROM checks firstly if a debugger is present to enter the Boot Interactive mode which allows the user to perform specific tasks via a debugger connection.

Before jumping to the application in Secure state, the Boot ROM can also enter in a specific mode called CPU Park to allow the debugger to get access to the resources of the device depending on Debug Access Level (DAL).

Note: Boot Interactive and CPU Park modes are described later on.

Device Integrity Checks

For SAM L11 devices, the Boot ROM performs security checks on two CRCs:

The User Row CRC (USERCRC) which is located in the NVM User Row (UROW) at: [0x80401C:0x80401F]:
UROW Offset Bit Position Name
0x1C-0x1F 255:224 USERCRC
The Boot Configuration Row CRC (BOCORCRC) which is located in the NVM Boot Configuration Row (BOCOR) at: [0x80C008:0x80C00B]:
BCOR Offset Bit Position Name
0x08-0x0B 95:64 BOCORCRC

UROW Offset	Bit Position	Name
0x1C-0x1F	255:224	USERCRC

BCOR Offset	Bit Position	Name
0x08-0x0B	95:64	BOCORCRC

User Row CRC (USER CRC)

USERCRC allows to check the following fuses parameters integrity:

AS, ANSC, DS, RS
URWEN
NONSECA, NONSECB, NONSECC

USERCRC is the CRC of the NVM User row area which starts from 0x00804008 and finish at 0x0080401B (bit 64 to bit 223):

Table 14-2. SAM L11 UROW Area Computed in USERCRC
Offset	Bit Pos.	Name
0x08	71:64	AS
0x09	79:72	Reserved		ANSC
0x0A	87:80	Reserved			DS
0x0B	95:88	Reserved	RS
0x0C	103:96	Reserved				URWEN
0x0D-0xF	127:104	Reserved
0x10-0x13	159:128	NONSECA
0x14-0x17	191:160	NONSECB
0x18-0x1B	223:192	NONSECC

Boot Configuration Row CRC (BOCORCRC)

BOCORCRC allows to check the following fuses parameters integrity:

BS, BNSC
BOOTOPT
BOOTPROT, BCWEN, BCREN

BOCORCRC is the CRC of the NVM Boot Configuration row area, which starts from 0x0080C000 and finish at 0x00800C007 (bit 0 to bit 63).

Table 14-3. SAM L11 BOCOR Area Computed in BOCORCRC
Offset	Bit Pos.	Name
0x00	7:0	Reserved
0x01	15:8	BS
0x02	23:16	Reserved	BNSC
0x03	31:24	BOOTOPT
0x04	39:32	BOOTPROT
0x05	47:40	Reserved
0x06	55:48	Reserved		BCREN	BCWEN
0x07	63:56	Reserved

If one of the checks fails, the Boot ROM will report the error to the DSU peripheral and will enter the Boot Interactive mode:

This will allow, if a debugger is connected, to put the device in the highest debug access level mode (DAL = 2) by issuing a Chip Erase command . Once in that mode, it is possible for a programming tool to reprogram the NVM Rows.
When the check fails and no debugger is connected, the part will reset and restart the check sequence again.

Note: Boot Interactive mode is described later in this chapter.

CRC Computation and Programming

The CRCs needs to be recalculated and updated in their respective NVM row as soon as a data from any of the checked regions is changed.

Important: USERCRC and BOCORCRC CRCs programming must be done by any programming tool supporting the SAM L11 devices.

The algorithm is a CRC-32 module embedded in the DSU peripheral and that uses for both CRC calculation with the following parameters:

Width = 32 bits
Polynomial = 0x04C11DB7 (Poly)
Initial Value = 0xFFFFFFFF (Init)
Input Data is reflected (RefIn)
Output Data is reflected (RefOut)
No XOR is performed on the output CRC (XorOut)

Example: the DSU CRC of 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39 is 0x340BC6D9

Memories and Peripherals Configurations Initialization

For SAM L11 devices, memories and peripherals security attributions are done by reading the different fuses values from the NVM User (UROW) and Boot Configuration (BOCOR) rows.

The Boot ROM is responsible for setting these attributions on the different concerned memory and peripheral controllers:

Set memory security attribution according to AS, ANSC, DS, RS, BS, BSNC and BOOTPROT fuses
Set peripherals security attribution according to NONSECA, NONSECB and NONSECC fuses

Important: The Boot ROM does not perform any consistency checks on the configured memory attributions (e.g setting BS>BOOTPROT will not trigger any errors during Boot ROM execution).

Secure Boot

Depending on the BOOTOPT fuse value (from BOCOR NVM row), the following secure boot integrity checks will be performed on:

The Secure Flash (BS region) which is composed by:
- The Secure Flash (BOOT region)
- The Non-Secure Callable Flash (BOOT region)
And the NVM Boot Configuration row (BOCOR)

Table 14-4. Secure Boot Options
BOOTOPT	Verified Areas	Verification Method
0	None	-
1	Secure Flash (BS region) + NVM BOCOR row	SHA-256
2 or 3	Secure Flash (BS region) + NVM BOCOR row	SHA-256 with BOOTKEY (defined in BOCOR)

If the verification fails, the Boot ROM will report the error to the DSU peripheral and will enter the Boot Interactive mode. This will allow, if a debugger is connected, to put the device in the highest debug level access mode (DAL = 2) by issuing a Chip Erase command. Once in that mode, it is possible for a programming tool to reprogram the different memory regions and/or NVM rows.

When verification fails and no debugger is connected, the part will reset and restart the integrity checks sequences again.

Hash algorithm (SHA-256) Verification Method

The verifications are done using the standard SHA256 hash algorithm.

Both Secure Flash (BS region) and NVM BOCOR row digests are computed on the defined memory/row area and compared to their expected reference digest value.

Note: The digest consists of 256 bits, i.e. 32 bytes.

SHA256 with BOOTKEY Variant

To prevent unauthorized change of the bootloader code, the digest computation can be slightly modified to require a key to produce a valid digest.

When SHA with BOOTKEY is selected (BOOTOPT=2 or =3), the digest computation (for both Secure Flash (BS region) and NVM BOCOR row) starts by processing the secure boot key (BOOTKEY) data twice, then proceeds with the rest of data.

This secure boot key (BOOTKEY) is located in the NVM Boot Configuration row (BOCOR) at [0x80C0050:0x80C006F]:


BOCOR Offset	Bit Position	Name
0x50-0x6F	895:640	BOOTKEY

BS Verification

When BOOTOPT>0, the bootloader authentication starts allowing a secure bootloader code to be protected against inadvertent or malicious changes.

The digest is computed on the Secure Flash (BOOT region) and the Non-Secure Callable Flash (BOOT region).

The digest reference value for this area is stored at the end of the Secure Flash (BOOT region), just before the Non-Secure Callable Flash (BOOT region).

Note: The last 256 bits where the digest is stored are not included in the computation.

Figure 14-4. BS Digest location in BS memory area

Important: The Non-Secure Flash (BOOT region) as well as Flash (APPLICATION region) are not part of the Secure Boot verification. So if an authentication of one of these memory regions is required, it must be handled by the user code itself.

BOCOR Verification

When BOOTOPT>0, the digest for the NVM BOCOR row is computed on the whole NVM BOCOR row excluding BOCORHASH fuse value which is the fuse where to store the digest reference value [0x80C00E0:0x80C00FF]:


BOCOR Offset	Bit Position	Name
0xE0-0xFF	2047:1792	BOCORHASH

Typical Boot Timings

Depending on the boot authentication options, the Boot ROM will require a certain time to complete its different tasks.

The delay is given from the release of the CPU reset to the execution of the first instruction of the user code.

Table 14-5. SAM L11 Typical Boot Timings
Boot options	Time to reach User Code
BOOTOPT=0	2.30 ms
BOOTOPT=1, BS=0x40	207 ms
BOOTOPT=1, BS=0x80	409 ms
BOOTOPT=2, BS=0x40	209 ms
BOOTOPT=2, BS=0x80	411 ms

Debug Access Levels

The SAM L10 has only two debug access levels (DAL):

DAL2: Highest debug level access with no restrictions in term of memory and peripheral accesses.
DAL0: No access is authorized except with a debugger using the Boot ROM Interactive mode.

The possible transitions between each debug access level are described below:

Figure 14-5. SAM L10 Debug Access Levels Transitions

The SAM L11 has three possible debug access levels (DAL):

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

The possible transitions between each debug access level are described below:

Figure 14-6. SAM L11 Debug Access Levels Transitions

Decreasing the Debug Level Access is done using the NVMCTRL peripheral command from the debugger or the CPU.

Note: Refer to NVMCTRL – Nonvolatile Memory Controller for more information.

For security reasons, increasing the Debug Level Access is only possible during Boot ROM execution and will be always preceded by a specific chip erase depending on the Debug Access Level.

Chip Erase

The chip erase commands allow to erase memories of the device and provide secure transitions between the different Debug Access Levels.

Important: Chip Erase commands are only issued using the Boot ROM Interactive mode (CMD_CE0, CMD_CE1, CMD_CE2 and CMD_CHIPERASE commands).

For SAM L10, the chip erase command does not require a key.

For SAM L11, the chip erase commands are protected with keys (CEKEYx) defined in the NVM BOCOR row.

Note: The chip erase keys can only be read if BOCOR.BCREN=1.

By default, the devices are delivered with these keys set at “All 1s”.

Important: If the key is set at “All 0s”, the corresponding chip erase command is disabled and it will be impossible for the debugger to use it. If both the ChipErase_ALL (CE2) key is set at "All 0s" and BOCOR.BCWEN=0, full chip erase is permanently disabled. Depending on Debug Access Levels (DAL0 or DAL1), Microchip’s failure analysis capabilities are limited when this feature is used.

The following table gives the effect of the Chip Erase commands on the different memories:

Table 14-6. Chip Erase Commands Effects
	SAM L11			SAM L10
Boot ROM Command	ChipErase_NS (CE0)	ChipErase_S (CE1)	ChipErase_ALL (CE2)	ChipErase (CHIPERASE)
Key Requirement	Yes (CEKEY0)	Yes (CEKEY1)	Yes (CEKEY2)	No
Flash (BOOT region) BOOTPROT (BS+BNSC+BNS)	No	No	Yes	No
Flash (APPLICATION region)	-	-	-	Yes
Data Flash	-	-	-	Yes
Secure Flash (AS region)	No	Yes	Yes	-
Non-Secure Flash (APPLICATION region)	Yes	Yes	Yes	-
Secure Data Flash (DS)	No	Yes	Yes	-
Non-Secure Data Flash	Yes	Yes	Yes	-
NVM User Row (UROW)	No	No	Yes	No
NVM Boot Configuration Row (BOCOR)	No	No	Yes	No
Volatile Memories	Yes	Yes	Yes	Yes
Debugger Access Level after reset	2 (if DAL was 2) else 1	2 (if DAL was 2 or BS==0) else 1	2	2

Note: Only the ChipErase_ALL (CE2) command affects rows belonging to the BOOT area (BOOTPROT fuse bits) and the BOCOR row.

Boot ROM Interactive Mode

The interactive mode allows the user to perform several actions on the device during the Boot ROM execution via a debugger connection.

The debugger communicates with the device using the DSU Boot Communication Channels (BCC) through the external address range of the DSU peripheral, regardless of the DAL setting. This communication is bi-directional and allows the debugger to post commands and receive status from the Boot ROM.

Note: Refer to Device Service Unit for more information on BCC.

Enter Interactive Mode (CMD_INIT)

This command allows launching the Boot Interactive command mode of the Boot ROM.

To reach interactive mode, the debugger will trigger a “cold plugging” sequence as described in DSU chapter.

Important: Debugger must not clear DSU.STATUSA.BREXT bit before clearing DSU.STATUSA.CRSTEXT bit.

When CRSTEXT is cleared, CPU starts Boot ROM Interactive mode execution. After a small delay (5ms advised), the debugger must check if the Boot ROM has not flagged any errors by checking the BCCD1 bit in DSU.STATUSB register.

If errors are reported, the debugger can get the error type by checking the DSU.BCC1 register from the DSU external address space.

Note: Errors reported by the Boot ROM in the DSU.BCC1 register are listed later on in the Boot Interactive Mode Status section.

If no error is reported, the debugger writes the CMD_INIT command to DSU.BCC0 register to request Boot ROM Interactive mode entry. When command is successful, Boot ROM will place the “SIG_COMM” status in DSU.BCC1 register.

CMD_INIT

Exit Interactive Mode (CMD_EXIT)

This command allows exiting the Boot Interactive mode.

Exiting the Boot Interactive mode allows to jump to one of the following:

The Application
The CPU Park Mode

CMD_EXIT

System Reset Request (CMD_RESET)

This command allows resetting the system using a system reset request. Since the reset is executed immediately after receiving the command, no reply is sent to the debugger.

After reset, the CPU executes the Boot ROM code from the beginning

Chip Erase (CMD_CHIPERASE) - SAM L10 only

CMD_CHIPERASE command erases the entire device except BOOT area, and reverts to Debug Access Level 2.

CMD_CHIPERASE (SAM L10 only)

Figure 14-10. CMD_CHIPERASE Flow diagram

Chip Erase (CMD_CEx) - SAM L11 only

CMD_CEx commands are used to erase specific part of the device and to increase the Debug Access Level.

CMD_CEx (SAM L11 only)

NVM Memory Regions Integrity Checks (CMD_CRC)

The Boot ROM provides a way to check the integrity of the embedded non-volatile memories which may be of interest in case of a failure analysis.

This requires the user to place tables describing the memory area to be checked with their expected CRC values.

Note: During this integrity check process, the debugger sends the CRC table address to the device.

Important: The table(s) must be programmed by the programming tool in addition to the application binaries.

CRC Table format

Table 14-7. CRC Table Fields Description
Description	Header	Start Address (1)	Size in bytes (2)	Expected value (3)
Field	HDR	ADDR	SIZE	REFVAL
Offset	0x0	0x4	0x8	0xC
Value	0x43524349	0x00000000	0x100	0xAABBCCDD

Note 1: ADDR must be a multiple of 4 (Only ADDR[31:2] are used).

Note 2: SIZE must be a multiple of 4 (Only SIZE[31:2] are used).

Note 3: The expected value is the computed CRC32 value of the memory target.

Requirements

Each table occupies 16 bytes in memory.
The table must start at a 16byte aligned address. (i.e. 0xXXXXXXX0)
The table must be placed in the same memory region as its target memory range. (i.e. a table placed in the Secure Flash (APPLICATION region) can only target Secure Flash (APPLICATION region) memory addresses).
Note: There are two exceptions to this rule:
- For SAM L10: all non-volatile memories are considered as a single region (e.g. a table located in Data Flash can target Flash)
- For SAM L11: ANSC and BNSC regions are considered to belong to the same region as their “parent” region: AS for ANSC and BS for BNSC.

CRC Command Key

The CRC command (CMD_ CRC) requires an access key (CRCKEY) which is in the NVM BOCOR row at: [0x80C040:0x80C04F]:


BOCOR Offeset	Bit Position	Name
0x40-0x4F	639:512	CRCKEY

Just like the ChipErase keys, the key can be set to all 0s to prevent any access to the command.

CMD_CRC

Random Session Key Generation (CMD_DCEK) - SAM L11 only

This command allows using a challenge-response scheme to prevent exposure of the keys in clear text on the debugger communication lines.

The different keys sent by the debugger during the Boot ROM for Chip Erase (CMD_CEx) and CRC (CMD_CRC) commands execution are:

CRCKEY for CMD_CRC command
CEKEYx for CMD_CEx commands

Note: The CMD_DCEK command has no effect on the SAM L10, the key derivation will not be enabled.

The random challenge value is generated using the TRNG of the device. It is generated once the CMD_DCEK is received and communicated to the debugger.

The next CMD_CEx or CMD_CRC commands will expect the key value to be replaced by the computed response corresponding to the challenge.

The challenge value is valid only for the next CMD_CEx/ CMD_CRC command.

Before sending a new CMD_CEx/ CMD_CRC command, a CMD_DCEK shall be used to re-enable the challenge-response scheme a get a new challenge value.

On the debugger side, the response shall be computed using the following algorithm:

Where KeyIndex is:

0 for ChipErase_NS
1 for ChipErase_S
2 for ChipErase_ALL
3 for CRC Command

Note:

HMAC is described in FIPS PUB 198-1
The hash used for HMAC is SHA-256
The output of the HMAC-SHA256 is truncated to obtain an HMAC-SHA256-128 as explained in RFC4868

CMD_DCEK (SAM L11 only)

NVM Rows Content Checks (CMD_RAUX)

The Boot ROM provides a way to check the content of the NVM rows.

When device is secured (DAL0), the fuse configuration can still be read by the debugger using the Read Auxiliary command (CMD_RAUX).

The following areas are accessible:

Table 14-8. Accessible Memory Range by Read Auxiliary Row Command⁽¹⁾
Area	Start address	End address
User row (UROW)	0x00804000	0x0080401F
Software Calibration row	0x00806020	0x0080602F
Temperature Log row	0x00806038	0x0080603F

Note:

Boot Configuration row (BOCOR) is not accessible by the Read Auxiliary Row command.

CMD_RAUX

Boot Interactive Mode Commands

Table 14-9. Boot Interactive Mode Commands
Command Name	Description	Command prefix	Command
CMD_INIT	Entering Interactive Mode	0x444247	55
CMD_EXIT	Exit Interactive Mode	0x444247	AA
CMD_RESET	System Reset Request	0x444247	52
CMD_CE0	ChipErase_NS for SAM L11	0x444247	E0
CMD_CE1	ChipErase_S for SAM L11	0x444247	E1
CMD_CE2	ChipErase_ALL for SAM L11	0x444247	E2
CMD_CHIPERASE	ChipErase for SAM L10	0x444247	E3
CMD_CRC	NVM Memory Regions Integrity Checks	0x444247	C0
CMD_DCEK	Random Session Key Generation for SAM L11	0x444247	44
CMD_RAUX	NVM Rows Integrity Checks	0x444247	4C

Boot Interactive Mode Status

Table 14-10. Boot Interactive Mode Status
Status Name	Description	Status prefix	Status coding
SIG_NO	No Error	0xEC0000	00
SIG_SAN_FFF	Fresh from factory error	0xEC0000	10
SIG_SAN_UROW	UROW checksum error	0xEC0000	11
SIG_SAN_SECEN	SECEN parameter error	0xEC0000	12
SIG_SAN_BOCOR	BOCOR checksum error	0xEC0000	13
SIG_SAN_BOOTPROT	BOOTPROT parameter error	0xEC0000	14
SIG_SAN_NOSECREG	No secure register parameter error	0xEC0000	15
SIG_COMM	Debugger start communication command	0xEC0000	20
SIG_CMD_SUCCESS	Debugger command success	0xEC0000	21
SIG_CMD_FAIL	Debugger command fail	0xEC0000	22
SIG_CMD_BADKEY	Debugger bad key	0xEC0000	23
SIG_CMD_VALID	Valid command	0xEC0000	24
SIG_CMD_INVALID	Invalid command	0xEC0000	25
SIG_ARG_VALID	Valid argument	0xEC0000	26
SIG_ARG_INVALID	Invalid argument	0xEC0000	27
SIG_CE_CVM	Chip erase error: CVM	0xEC0000	30
SIG_CE_ARRAY_ERASEFAIL	Chip erase error: array erase fail	0xEC0000	31
SIG_CE_ARRAY_NVME	Chip erase error: array NVME	0xEC0000	32
SIG_CE_DATA_ERASEFAIL	Chip erase error: data erase fail	0xEC0000	33
SIG_CE_DATA_NVME	Chip erase error: data NVME	0xEC0000	34
SIG_CE_BCUR	Chip erase error: BOCOR, UROW	0xEC0000	35
SIG_CE_BC	Chip erase error: BC check	0xEC0000	36
SIG_BOOT_OPT	BOOTOPT parameter error	0xEC0000	40
SIG_BOOT_ERR	Boot image digest verify fail	0xEC0000	41
SIG_BOCOR_HASH	BOCOR hash error	0xEC0000	42
SIG_CRC_BADTBL	Bad CRC table	0xEC0000	50
SIG_SECEN0_ERR	PAC or IDAU cfg check failure	0xEC0000	60
SIG_SECEN1_ERR	PAC or IDAU cfg check failure	0xEC0000	61
SIG_EXIT_ERR	Exit: BC or check error	0xEC0000	70
SIG_HARDFAULT	Hardfault error	0xEC0000	F0
SIG_BOOTOK	Boot ROM ok to exit	0xEC0000	39

CPU Park mode

This mode allows the debugger to get access to the resources of the device during Boot ROM execution while the CPU is trapped in a while loop. The debug access level when entering that mode corresponds to the DAL value which is programmed in the device.

Important: This mode is the recommended way to enter a debugging session in a safe way even if it is also possible to launch a debug session when the application is running.

This mode is reached by sending the Exit command (CMD_EXIT) without clearing the DSU.STATUSA.BREXT bit to the Boot ROM.

As soon as the BREXT bit is cleared, the device exits this state and performs a system reset.

At this point, the MPU is still enabled and prevents software execution elsewhere than in Boot ROM region.

If the host needs to run software on the device, MPU shall be disabled by accessing the Cortex-M23 MPU CTRL register with the debugger.