13.4 Functional Description

PIC32CM LE00 Boot ROM

First the PIC32CM LE00 Boot ROM checks if a debugger is present to enter the Boot Interactive mode which allows the user to perform specific tasks through 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 in the later sections of this document..

PIC32CM LS00/LS60 Boot ROM

The PIC32CM LS00/LS60 Boot ROM sequence consists in performing several security tasks (integrity checks, memories and peripherals security attribution, Secure Boot, DICE CDI key generation...) before starting the application.

Note: Secure Boot and DICE CDI key generation are independent features and may be enabled simultaneously or without the other.

The Boot ROM first checks 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.

Figure 13-3. PIC32CM LS00/LS60 Boot ROM Flow

Device Integrity Checks

For PIC32CM LS00/LS60 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:
UROW Offset Bit Position Name
0x20-0x23 287:256 USERCRC
The Boot Configuration Row CRC (BOCORCRC) which is located in the NVM Boot Configuration Row (BOCOR) at:
BCOR Offset Bit Position Name
0x08-0x0B 95:64 BOCORCRC

UROW Offset	Bit Position	Name
0x20-0x23	287:256	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
CDIROFFSET

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

Table 13-1. PIC32CM LS00/LS60 UROW Area Computed in USERCRC
Offset	Bit Pos.	Name
0x08	71:64	AS
0x09	79:72	ANSC		AS
0x0A	87:80	DS	Reserved	ANSC
0x0B	95:88	Reserved	DS
0x0C	103:96	RS
0x0D	111:104	Reserved		URWEN	Reserved	RS
0x0E-0xF	127:112	Reserved
0x10-0x13	159:128	NONSECA
0x14-0x17	191:160	NONSECB
0x18-0x1B	223:192	NONSECC
0x1C-0x1F	255:224	CDIROFFSET

Boot Configuration Row CRC (BOCORCRC)

BOCORCRC allows to check the following fuses parameters integrity:

BOOTPROT, BNSC, BOOTOPT
SECCFGLOCK, DICEEN
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 13-2. PIC32CM LS00/LS60 BOCOR Area Computed in BOCORCRC
Offset	Bit Pos.	Name
0x00-0x1	15:0	Reserved
0x02	23:16	BNSC			Reserved
0x03	31:24	Reserved		BNSC
0x04	39:32	BOOTOPT
0x05	47:40	BOOTPROT
0x06	55:48	Reserved	DICEEN	SECCFGLOCK	BOOTPROT
0x07	63:56	Reserved				BCREN	BCWEN

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 Configuration 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 Configuration 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 PIC32CM LS00/LS60 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 PIC32CM LS00/LS60 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, BNSC 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.

Secure Boot

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

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

Different verification methods are supported depending on BOCOR.BOOTOPT value:

Table 13-3. PIC32CM LS00 Secure Boot Verification Methods
BOOTOPT	BOOTPROT region Verification Method	NVM Boot Configuration Row (BOCOR)
0	Secure Boot Disabled
1	SHA-256
2	SHA-256 with BOOTKEY⁽¹⁾
3	HMAC with BOOTKEY⁽¹⁾
Others	Reserved

Note:

BOOTKEY is defined in BOCOR row

Table 13-4. PIC32CM LS60 Secure Boot Verification Methods
BOOTOPT	BOOTPROT region Verification Method	NVM Boot Configuration Row (BOCOR)
0	Secure Boot Disabled
1	SHA-based Secure Boot
2	SHA-based Secure Boot with BOOTKEY⁽¹⁾
3	HMAC-based Secure Boot with BOOTKEY⁽¹⁾
4	ATECC608B-based Secure Boot	SHA
5	ATECC608B-based Secure Boot	SHA with BOOTKEY⁽¹⁾
6-255	ATECC608B-based Secure Boot	HMAC with BOOTKEY⁽¹⁾

Note:

BOOTKEY is defined in BOCOR row

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 Configuration rows.

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

BOOTPROT Region Verification Using SHA-256 or HMAC

The digest (SHA-256) / MAC (HMAC) is computed on the whole BOOTPROT region, which is composed by the Secure Flash (BOOT region) and the Non-Secure Callable Flash (BOOT region).

The digest/MAC 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).

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

Figure 13-4. Reference digest/MAC location

Important: The Flash (APPLICATION region) is not part of the Secure Boot verification. So if an authentication of this memory region is required, it must be handled by the user code itself.

SHA-256 Verification Method

This verification method uses the standard SHA-256 hash algorithm which produces a digest of 256 bits, i.e. 32 bytes that is compared against the value placed at the end of the Secure Flash (BOOT Region).

SHA-256 with BOOTKEY Verification Method

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

When SHA-256 with BOOTKEY is selected, the digest computation (for both BOOTPROT 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):


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

HMAC with BOOTKEY Verification Method

The verification method uses the standard HMAC hash algorithm (defined in FIPS PUB 198-1).

The hash used for HMAC is SHA-256 which produces a MAC of 256 bits, 32 bytes, that is compared against the value placed at the end of the Secure Flash (BOOT Region). The key used is BOOTKEY from BOCOR NVM Configuration row.

BOOTPROT Region Verification using the ATECC608B (PIC32CM LS60 only)

When BOOTOPT>0, the Boot ROM uses the ATECC608B to assist in authenticating and checking the integrity of an application code (usually a boot loader) that is to be subsequently executed.

This authentication process is done in two steps:

An ECDSA signature of the application image must first be generated and stored on the application image
Secure Boot execution will then authenticate the application code

The ECDSA signature (64 bytes) is computed on the overall BOOTPROT region, which is composed by the Secure Flash (BOOT region) and the Non-Secure Callable Flash (BOOT region).

The signature for this area must be stored at the end of the Secure Flash (BOOT region), just before the Non-Secure Callable Flash (BOOT region).

Important: The last 64 bytes where the signature is stored are not included in the computation.

Important: The Flash (APPLICATION region) is not part of the Secure Boot verification. So, if an authentication of this memory region is required, it must be handled by the user code itself.

ATECC608B-Based Secure Boot Verification Method

This verification method uses the ATECC608B.

The ATECC608B is configured to operate in the Stored Secure Boot (FullDig) mode, where:

The digest is stored in Slot 7
The public key required to verify the SecureBoot is stored in Slot 15
Note: The public key must be initially provisioned in Slot 15.

The Stored Secure Boot (FullDig) mode executes the ATECC608B SecureBoot command in the following modes:

FullCopy mode
FullStore (Digest) mode

FullCopy mode is executed the first time the code used to authenticate is verified: the Boot ROM passes both the digest and signature to the ATECC608B for verification and stores the digest in the ATECC608B.

Figure 13-7. Secure Boot FullCopy Mode Overview

FullStore (Digest) mode is then executed. In that mode, the Boot ROM passes only the digest to the ATECC608B, which performs a compare with the Digest that has been stored upon the first authentication of the code.

Figure 13-8. Secure Boot FullStore Mode Overview

The communication between the PIC32CM LS60 microcontroller and the ATECC608B is encrypted using an I/O Protection Key. This unique key is initially provisioned in both the ATECC608B Slot 6 and the microcontroller BOCOR NVM Configuration Row (IOPROTKEY).

The ATECC608B Slot 6 is not locked by default, hence if a Full ChipErase is done on the microcontroller (where BOCOR IOPROTKEY will be erased), both the microcontroller and the ATECC608B can be provisioned with a new key value.

CAUTION: If the ATECC608B Slot 6 is locked (i.e. no new I/O Protection Key value can be reprogrammed), it is mandatory for the application to ensure that the microcontroller never executes a Full Chip Erase command or it will break the ATECC608B pairing required for SecureBoot.

Refer to the Chapter “I/O Protection Key” from the ATECC608B-TFLXTLS CryptoAuthentication™ Data Sheet to get the ATECC608B commands support this feature.

NVM Boot Configuration Row (BOCOR) Verification

When BOOTOPT>0, the digest/MAC for the NVM BOCOR row is computed on the whole NVM BOCOR row (excluding BOCORHASH value) and compared with the digest/MAC reference value (BOCORHASH):


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

Device Identity Composition Engine (DICE)

The Device Identifier Composition Engine (DICE) is a standard developed by the Trusted Computing Group (TCG) for implementing attestation in low cost IoT devices.

When enabled using BOCOR.DICEEN fuse, the DICE engine generates the Compound Device Identifier (CDI) at boot time that is based on a stored Unique Device Secret (UDS) key and the digest/MAC of the boot flash image (BOOTPROT region).


BOCOR Offset	Bit Position	Name
0x06	52	DICEEN

The CDI is written in the SRAM at the offset specified by the UROW.CDIROFFSET fuse, making it available for the boot Flash code for attestation purpose. The boot Flash code can optionally use the CDI to derive other keys for attestation and encryption.


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

The Boot ROM checks that CDIROFFSET is within the maximum SRAM range; if not, the CDI is not written.

Important: It’s up to the user to ensure the CDI is written in the Secure SRAM region.

DICE CDI Key Generation Flow

Figure 13-10. DICE CDI Key Generation Flow

Unique Device Secret (UDS)

The Unique Device Secret (UDS) is a 256-bit symmetric key used to generate the CDI. The UDS key is only accessible to the DICE engine and is only used for calculating the CDI at boot time.

Important: The UDS must be accessible only during Boot ROM execution: BOCOR.BCWEN and BOCOR.BCREN must be set both to ‘0’ and BOCOR.SECCFGLOCK must be set to ‘1’ to follow DICE standard.

The Unique Device Secret must be provisioned on BOCOR.UDS fuse. It must be unique for each device and have a strong entropy.

If DICE is enabled but the UDS key is not provisioned (BOCOR.UDS is all 1s), all zeros are written to the CDI output.

Important: Devices can be factory programmed with securely key provisioned software. Contact your local Microchip sales office for more information.

CAUTION: A ChipErase_ALL (CE2) will reset the whole BOCOR including the provisioned UDS.

Compound Device Identifier (CDI)

The Compound Device Identifier (CDI) is the output of the DICE module that is passed to the boot flash code at a specified memory location in SRAM.

The CDI can be used by the boot flash code directly for attestation or to derive other keys.

The CDI is a 256 bit value calculated as follows:

CDI = HMAC-SHA-256( UDS, H(BOOTPROT region) )

Where:

The hash function H() calculated over the boot Flash image is SHA-256.
The BOOTPROT region is composed by the Secure Flash (BOOT region) and the NSC Flash (BOOT region)

Note: Secure Boot feature requires another digest/MAC

(or signature)

which is stored in the Secure Flash (BOOT region). This digest/MAC is not included in the computation of the BOOTPROT region for CDI generation, to be independent of the Secure Boot operations.

Debug Access Levels

The PIC32CM LE00 has the following 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 13-11. PIC32CM LE00 Debug Access Levels Transitions

The PIC32CM LS00/LS60 has the following 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 13-12. PIC32CM LS00/LS60 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 Non-volatile Memory Controller (NVMCTRL) for additional 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).

The Chip erase commands are executed whatever the Flash regions are locked or not. Refer to the Region Unlock Bits in the NVMCTRL chapter.

For PIC32CM LE00, the chip erase command does not require a key.

For PIC32CM LS00/LS60, 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 a 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 13-5. Chip Erase Commands Effects
	PIC32CM LS00/LS60			PIC32CM LE00
Boot ROM Command	ChipErase_NS (CE0)	ChipErase_S (CE1)	ChipErase_ALL (CE2)	ChipErase (CHIPERASE)	ChipErase_ALL (CHIPERASE_ALL)
Key Requirement	Yes (CEKEY0)	Yes (CEKEY1)	Yes (CEKEY2)	No
Flash (BOOT region)	No		Yes	No	Yes
Flash (APPLICATION region)	-			Yes
Data Flash	-			Yes
Secure Flash (AS region)	No	Yes		-
Non-Secure Flash (APPLICATION region)	Yes			-
Secure Data Flash (DS)	No	Yes		-
Non-Secure Data Flash	Yes			-
NVM User Row (UROW)	No		Yes	No	Yes
NVM Boot Configuration Row (BOCOR)	No		Yes	No	Yes
Volatile Memories	Yes			Yes
Debugger Access Level after reset	2 (if DAL was 2) else 1	2 (if DAL was 2 or BOOTPROT==0) else 1	2	2

Note: Only the ChipErase_ALL (CHIPERASE_ALL or CE2) commands affect 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 through 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 additional 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 the DSU.STATUSA.BREXT bit before clearing the DSU.STATUSA.CRSTEXT bit.

When CRSTEXT is cleared, CPU starts Boot ROM Interactive mode execution. After a small delay (5 ms is advised), the debugger must check if the Boot ROM has not flagged any errors by checking the BCCD1 bit in the 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 the DSU.BCC0 register to request Boot ROM Interactive mode entry. When command is successful, Boot ROM will place the “SIG_COMM” status in the 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, because 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.

PIC32CM LE00 Chip Erase (CMD_CHIPERASE and CMD_CHIPERASE_ALL)

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

The CMD_CHIPERASE_ALL command erases the entire device including the BOOT area, and reverts to Debug Access Level 2.

Figure 13-16. CMD_CHIPERASE and CM_CHIPERASE_ALL Flow diagram

PIC32CM LS00/LS60 Chip Erase (CMD_CEx)

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

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 tables must be programmed by the programming tool in addition to the application binaries.

CRC Table format

Table 13-6. 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 16 byte 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).
The exceptions to this rule are as follows:
- For PIC32CM LE00: all non-volatile memories are considered as a single region (e.g. a table located in Data Flash can target Flash)
- For PIC32CM LS00/LS60: ANSC and BNSC regions are considered to belong to the same region as their “parent” region: AS for ANSC and BOOTPROT 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

Similar to 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) - PIC32CM LS00/LS60 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 PIC32CM LE00, 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-SHA-256 is truncated to obtain an HMAC-SHA-256-128 as explained in RFC4868.

CMD_DCEK (PIC32CM LS00/LS60 only)

NVM Configuration Rows Content Checks (CMD_RAUX)

The Boot ROM provides a way to check the content of the NVM Configuration 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 13-7. Accessible Memory Range by Read Auxiliary Row Command⁽¹⁾
Area	Start address	End address
User row (UROW)	0x00804000	0x008040FF
Software Calibration row	0x00806020	0x00806023

Note:

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

CMD_RAUX

Boot Interactive Mode Commands

Table 13-8. 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 PIC32CM LS00/LS60	0x444247	E0
CMD_CE1	ChipErase_S for PIC32CM LS00/LS60	0x444247	E1
CMD_CE2	ChipErase_ALL for PIC32CM LS00/LS60	0x444247	E2
CMD_CHIPERASE	ChipErase for PIC32CM LE00	0x444247	E3
CMD_CHIPERASE_ALL	ChipErase_ALL for PIC32CM LE00	0x444247	E4
CMD_CRC	NVM Memory Regions Integrity Checks	0x444247	C0
CMD_DCEK	Random Session Key Generation for PIC32CM LS00/LS60	0x444247	44
CMD_RAUX	NVM Configuration Rows Integrity Checks	0x444247	4C

Boot Interactive Mode Status

Table 13-9. 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 hash 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 must be disabled by accessing the Cortex-M23 MPU CTRL register with the debugger.