Processor-specific workflows

This chapter takes you through the steps you must take to successfully boot up your device to the required security level. It describes the creation of the bootable image, connecting your device, setting up your boot preferences, and writing the image into the selected boot memory. Common steps are described first, followed by device family-specific content. It is assumed the image is executed on an NXP evaluation board.

This chapter addresses image preparation for the following toolchains:

  • MCUXpresso IDE 11

  • Keil MDK 5 μVision

  • IAR Embedded Workbench 8

  • CodeWarrior Development Studio

On the following pages you will learn how to:

  • Get MCUXpresso SDK with an example project for a processor

  • Open an example project for the processor in the toolchain

  • Start with the SEC

  • Prepare asymmetric keys

  • Build a plain image in the selected toolchain

  • Build a bootable image by SEC

  • Connect the NXP evaluation board

  • Write a bootable image into the processor and (optionally) secure the processor and advance the life cycle

Common steps

This section provides common steps of the process.

Downloading MCUXpresso SDK

The MCUXpresso SDK offers open source drivers, middleware, and reference example applications to speed your software development. In this section, you can find information about downloading MCUXpresso SDK as a ZIP package or as a CMSIS pack and how to open an example project from the package. It is recommended to start with iled_blinky example, because it offers a simple check whether the resulting application is working - LED flashes with a 1 sec period.

  • Downloading MCUXpresso SDK package for MCUXpresso IDE, VSCode or CodeWarrior Development Studio

    1. Visit the MCUXpresso page.

    2. Select your board.

    3. Build an SDK package for the selected toolchain and download it. Note: Starting with MCUXpresso IDE v11.1.0, you can download and install the MCUXpresso SDK package directly in the tool.

  • Downloading MCUXpresso SDK CMSIS pack

    Alternatively, for the MDK µVision and IAR Embedded Workbench you can download CMSIS packs for the selected processor and board:

    • Device Family Pack (DFP): NXP.{processor}_DFP.#.#.#.pack

    • Board Support Pack (BSP): NXP.EVK-{processor}_BSP.#.#.#.pack

  • Downloading an example project for Keil MDK or IAR Embedded Workbench

    For Keil MDK or IAR Embedded Workbench, it is also possible to download a single example project only. Once you have the SDK build available on MCUXpresso SDK Dashboard, click the download link and select Download Standalone Example Project. This project contains all sources and project files needed for the build.

Opening example project

  • MCUXpresso IDE

    1. Drag-and-drop the downloaded MCUXpresso SDK package into the Installed SDKs view to install the package.

    2. Select File > New > Import SDK examples….

    3. Select your processor and board and on the next page select the iled_blinky example.

  • Keil MDK 5 + Example package

    1. Unpack the SDK package into the selected folder and open boards\evkmimxrt10##\demo_apps\led_blinky\mdk\iled_blinky.uvmpw.

    2. If you have downloaded a single example project only, unzip it into the selected folder and open the workspace file.

    3. Go to Project > Options > Output to ensure the option Create HEX File is selected.

  • Keil MDK 5 + CMSIS packs

    1. Select Project > Manage > Pack Installer.

    2. In the Devices view, select All Devices > NXP > MIMXRT10##.

    3. In the Packs view, ensure that the following device-specific packs are installed: NXP::{processor}#_DFP and NXP::EVK-{processor}_BSP.

    4. Select the BSP pack

    5. In the Examples view, copy the iled_blinky example project into the selected folder.

      Go to Project > Options > Output to ensure the option Create HEX File is selected.

  • IAR Embedded Workbench + MCUXpresso SDK package

    1. Unpack the SDK package into the selected folder and open boards\evkmimxrt10##\demo_apps\led_blinky\iar\iled_blinky.eww.

    2. If you have downloaded a single example project only, unzip it into the selected folder and open the workspace file.

  • CodeWarrior Development Studio

    1. Unpack the SDK package into the selected folder and import project in the Commander pane.

    2. If the MCUXpresso Config Tools was used to create a project template, import this project template as described in point 1.

  • MCUXpresso for Visual Studio Code

    1. Unpack the SDK package into the selected folder.

    2. Use command > MCUXpresso for VSCode: Import Local/Remote repository; select local and select the path of the SDK folder.

    3. Use command > MCUXpresso for VSCode: Import Example Application from Installed Repository; fill all the items and confirm by clicking the Create button.

Building example project

Detailed information about project configuration and build is in the processor-specific sections below. For a quick evaluation, there are prebuilt application images from SDK examples for NXP evaluation boards provided in the installation layout. For details, refer to the installation subfolder <SEC>sample_data/targets/{processor}/source_images.

Setting up Secure Provisioning Tool

  1. Start MCUXpresso Secure Provisioning Tool:

    • Windows: Double-click the desktop shortcut, or use the Windows Start menu to locate the tool.

    • MacOS: Click the shortcut in the Dock, or use the Launchpad to locate the tool.

    • Linux: Click the shortcut in the Launcher, or use the Dash to locate the tool.

  2. Create a new workspace by selecting File > New Workspace … from the menu bar. Select the device series and the processor and click Create.

  3. Connect the device to the host through USB, UART, SPI, or I2C.

  4. Confirm that the connection is working by selecting Target > Connection … from the menu bar and clicking the Test button. Tweak if necessary.

Preparing secure keys

This section describes the generation of keys necessary for authenticated or encrypted image creation. This operation is done only once and the keys can be used for all use-cases.

  1. Select the PKI management view.

  2. Ensure it does not already contain keys.

  3. Click Generate keys.

  4. In the Generate keys dialog, confirm the default settings and click Generate.

Note: The generated keys are located in the keys/ subfolder and certificates (if any) in the crts/ subfolder. It is recommended to back up generated keys before they are burned into fuses in the processor.

i.MX 9x device workflow

This section describes the i.MX 93 and i.MX 95 device workflow in detail.

Preparing images for build for i.MX 9x devices

In this step, select the target memory where the image(s) is to be executed.

i.MX 9x devices have the following cores where image(s) can be executed:

  • i.MX 93:

    • Cortex-M33, boot core

    • Cortex-A55, boot core

  • i.MX 95:

    • Cortex-M33, boot core

    • Cortex-M7

    • Cortex-A55

The following target memories are available for i.MX 9x devices:

  • Image running in RAM

This image can be on an SD card/eMMC, will be copied into RAM and executed from there during the boot. The following RAM types are supported:

  • internal RAM

  • SDRAM (DDR SDRAM)

There are several images required to build the resulting bootable image containing the AHAB container set.

  • i.MX 93 images:

    • Primary image container set:

      • ELE firmware

      • LPDDR4 firmware files with U-Boot SPL

      • [Optional] Cortex-M33 application

    • Secondary image container set:

      • ARM Trusted Firmware (bl31 binary)

      • U-Boot

      • [Optional] TEE binary

  • i.MX 95 images:

    • Primary image container set:

      • ELE firmware

      • DDR (LPDDR4 or LPDDR5) firmware files with the OEI DDR firmware

      • CM33 OEI TCM

      • CM33 System manager

      • U-Boot SPL

      • [Optional] Cortex-M7 application

    • Secondary image container set:

      • ARM Trusted Firmware (bl31 binary)

      • U-Boot

      • TEE binary

For the image with Cortex-M7 and Cortex-M33 application, use the MCUXpresso SDK example. There is no need to modify the default configuration. This image is built to run in internal RAM.

DDR firmware files and ELE firmware can be downloaded from the Yocto Project:

For details regarding the latest packages, see i.MX Linux Release Notes (document RN00210).

The rest of the images are built from source code. Use the following repos on https://github.com/nxp-imx

For additional Linux release materials, see Embedded Linux for i.MX Applications Processors

For example details, see main menu > Help > SPSDK Online Documentation:

  • Examples - AHAB - i.MX 95 AHAB with U-Boot

  • Examples - AHAB - i.MX 93 signed and encrypted AHAB image.

Connecting the board for i.MX 9x devices

This section contains information about configuring the evaluation board and connecting it to the SEC tool:

  • IMX95LPD5EVK-19 (IMX95LPD5BB-19 base board with IMX95LP5CPU-19 CPU board)

  • MCIMX93-EVK (MCIMX93-BB base board with MCIMX93-SOM CPU board)

  • MCIMX93-QSB

Table DIP Switches: Boot mode selection for board for Cortex-M33

Boot mode/ Device

Serial bootloader (ISP mode)

eMMC

SD card

FlexSPI NOR

IMX95LPD5EVK-19

SW7: 1001

SW7: 1010

SW7: 1101

SW7: 1100 (N/A)

MCIMX93-EVK

SW7: 1101

SW7: 0001

SW7: 0101

SW7: 1011 (N/A)

MCIMX93-QSB

SW7: 1001

SW7: 1010

SW7: 1011

SW7: 1100 (N/A)

Table DIP Switches: Boot mode selection for board for Cortex-A55

Boot mode/ Device

Serial bootloader (ISP mode)

eMMC

SD card

FlexSPI NOR

MCIMX93-EVK

SW7: 1100

SW7: 0000

SW7: 0100

SW7: 1010 (N/A)

MCIMX93-QSB

SW7: 0001

SW7: 0010

SW7: 0011

SW7: 0100 (N/A)

  1. See Table DIP Switches: Boot mode selection for board for Cortex-M33 or Table DIP Switches: Boot mode selection for board for Cortex-A55 in Connecting the board for i.MX 9x devices for instructions on how to set boot mode using DIP switches.

  2. Connect to the USB1/USB port with the USB cable to your PC for the download link.

  3. Connect to the DBG port with the USB cable to your PC for console output.

  4. Power the board to POWER JACK/USB PD and power on the POWER SWITCH.

  5. Ensure that the SEC tool is already running with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  6. Open the Connection dialog and test the board connection.

Booting from SD card

For booting from an SD card, do the following:

  1. Insert a micro SDHC card into the board.

  2. Select SD card, SDHC SD-card 64 GB in the Boot Memory Configuration.

Booting from eMMC

For booting from an eMMC, do the following:

  1. Check that the connected board already contains eMMC 64 GB.

  2. Select eMMC: SDHC eMMC 64 GB in the Boot Memory Configuration.

Booting images for i.MX 9x devices

This section describes the building and writing process of bootable images.

i.MX 93 bootable image examples

  • A container set with the Cortex-M33 application. It is written to on-chip RAM by the nxpuuu tool during write and then started from there.

_images/images_imx93_for_container_cm33app.png

Additional images for Container set with Cortex-M7 application

  • A container set with Cortex-A55 U-Boot (bootloader). It is written to the eMMC/SD card by the nxpuuu tool during write. During the boot, this bootloader is used to boot the Linux kernel image.

_images/images_imx93_for_container_uboot.png

Additional images for Container set with Cortex-A55 U-Boot

i.MX 95 bootable image examples

  • A container set with the Cortex-M7 application. It is written to on-chip RAM by the nxpuuu tool during write and then started from there.

_images/images_imx95_for_container_cm7app.png

Additional images for Container set with Cortex-M7 application

  • A container set with Cortex-A55 U-Boot (bootloader). It is written to the eMMC/SD card by the nxpuuu tool during write. During the boot, this bootloader is used to boot the Linux kernel image.

_images/images_imx95_for_container_uboot.png

Additional images for Container set with Cortex-A55 U-Boot

Booting/loading unsigned image

First, build a bootable image:

  1. Select the Unsigned boot type in the Toolbar.

  2. Select boot device in the Toolbar.

  3. Switch to the Build image

  4. Open the Additional User/OEM Image dialog by clicking the Additional images button.

  5. Configure the images for the image container, see i.MX 93 bootable image examples or i.MX 95 bootable image examples. Select the prepared images from Preparing images for build for i.MX 9x devices.

    • Enable the image in the Enabled column.

    • Select the image entry using Type

    • Select the binary(s) in the Image binary path.

    • Select Container set, it should be either Primary image or Secondary image.

    • All other parameters are preset with default values for the selected image entry type. These parameters can be customized.

  6. Close the dialog by clicking the OK button.

  7. Click the Build image button to build a bootable image, flash.bin.

When the bootable image has been successfully built:

  1. Make sure that the board is in Serial bootloader (ISP) mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

    • The nxpuuu tool is used to load the bootable image to the device.

  5. If the write operation was successful:

    • For eMMC or SD card, switch boot mode (see Table DIP Switches: Boot mode selection for board for Cortex-M33 or Table DIP Switches: Boot mode selection for board for Cortex-A55 in Connecting the board for i.MX 9x devices) and reset the board. The applications shall run, hello_world in Cortex-M7 and/or U-Boot in Cortex-A55.

    • For Onchip RAM, the Cortex-M7/Cortex-M33 application runs after it is written.

Booting signed image (bootloader for Cortex-A55) for i.MX 93

This section describes the building and writing of a signed image, bootloader for Cortex-A55 for i.MX 93. Keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys.

First, build a bootable image (bootloader for Cortex-A55):

  1. In the Toolbar set Boot type to Signed.

  2. Select boot device in the Toolbar.

  3. Switch to the Build image

  4. Open the Additional User/OEM Image dialog and configure the images for the bootloader. See the example configuration Additional images for Container set with Cortex-A55 U-Boot in i.MX 93 bootable image examples and Build U-Boot with AHAB secure boot features.

  5. For Authentication key select any key, for example, SRK1.

  6. Select the OEM Open or OEM Closed life cycle. See chapter Get ELE events with nxpele tool how to verify the application in the OEM Open life cycle.

  7. Click the Build image button.

  8. Check that the bootable image was built successfully.

When the bootable image has been successfully built:

  1. Make sure that the board is in Serial bootloader (ISP) mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected. This will write the built bootloader to the selected boot device.

    Note: To write another prepared bootable image, another bootloader or a complete image with Linux kernel, unselect the checkbox and select your image. The bootloader built on Build image is still used during write to write fuses and to update the life cycle with the nxpele tool.

  4. Click the Write image button.

    • The nxpuuu tool is used to load the bootloader, with U-Boot, to RAM.

    • The nxpele tool is used to write fuses and to update life cycle.

    • The nxpuuu tool is used to load the bootloader/your prepared bootable image to the boot device.

  5. In the following window, confirm to write fuses and update the life cycle:

    • OK - Continue writing the image and burning fuses.

    • Cancel - Abort writing the image and burning fuses.

_images/burn_fuses_imx93_signed.png

Burn fuses

  1. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for board for Cortex-A55 in Connecting the board for i.MX 9x devices) and reset the board. The applications shall run U-Boot/your prepared bootable image in Cortex-A55.

Write fuses and update life cycle with nxpele over U-Boot

The nxpele tool is used during provisioning to write fuses or to update life cycle. It is also used to read fuses in the OTP Configuration dialog. The nxpele tool communicates with EdgeLock Enclave over U-Boot, which must be running on the target.

In these cases, the bootable image configured in the Additional User/OEM Image dialog is used as a bootloader with the U-Boot. The U-Boot must be built with AHAB features, see Build U-Boot with AHAB secure boot features for details. During the device provisioning, the bootloader is loaded to the target and started.

Build U-Boot with AHAB secure boot features

The U-Boot/SPL https://github.com/nxp-imx/uboot-imx provides extra secure boot features. The features enable the nxpele tool to communicate with EdgeLock Enclave. The support is enabled by setting CONFIG_AHAB_BOOT=y in the build.

If the nxpele tool over fastboot is used, multiplexing of the console output to fastboot must be enabled by setting CONFIG_CONSOLE_MUX=y.

Get ELE events with nxpele tool

The nxpele get-event command can retrieve stored events in EdgeLock Enclave. The nxpele tool communicates with ELE over U-Boot, which must be running on the target.

Thanks to this, we can, for example, check the container authentication status in the OEM Open life cycle:

  1. See Booting signed image (bootloader for Cortex-A55) for i.MX 93. In this procedure, keep the life cycle in OEM Open. In the OEM Open life cycle, the authentication result is ignored.

  2. Connect the DBG port to your PC.

  3. Switch to boot mode and reset the board.

  4. Check what serial COM port is the U-Boot console output.

  5. Close the serial connection session if opened in a terminal.

  6. Execute nxpele get-events

Example when authentication succeeds:

C:\nxp\MCUX_Provi_25.03\bin\_internal\tools\spsdk>nxpele -f mimx9352 -p COM21 get-events
ELE get events ends successfully.
Event count:     0

Example when authentication fails:

C:\nxp\MCUX_Provi_25.03\bin\_internal\tools\spsdk>nxpele -f mimx9352 -p COM21 get-events
ELE get events ends successfully.
Event count:     2
Event[0]:      0x0287FAD6
  IPC ID:        Application Processor message unit
  Command:       OEM Container authenticate
  Indication:    The key hash verification does not match OTP
  Status:        The request was successful
Event[1]:      0x0287FAD6
  IPC ID:        Application Processor message unit
  Command:       OEM Container authenticate
  Indication:    The key hash verification does not match OTP
  Status:        The request was successful

KW45xx/K32W1xx/MCXW71xx device workflow

This chapter describes workflow for KW45xx/K32W1xx/MCXW71xx processors.

Preparing source image for KW45xx/K32W1xx/MCXW71xx devices

In this step, select the target memory where the image is executed. The following options are available for KW45xx/K32W1xx/MCXW71xx devices:

  • Image running from an internal flash

It is the only supported boot memory for the KW45xx/K32W1xx/MCXW71xx device family. The image is executed directly from internal flash memory.

There is no need to modify the default configuration, build the MCUXpresso SDK example as it is.

Connecting the board for KW45xx/K32W1xx/MCXW71xx devices

This section contains information about configuring the following evaluation boards and connecting them to SEC:

  • KW45B41Z-EVK

  • K32W148-EVK

  • MCXW71-FRDM

It is assumed that the SEC tool is already running with a workspace created for an KW45xx/K32W1xx//MCXW71xx device. For more information, see Setting up Secure Provisioning Tool.

For the KW45B41Z-EVK and K32W148-EVK development boards:

  1. Connect the J14 port to your PC with a USB cable.

  2. Set the JP25 jumper to enable the SW4 button.

  3. Enable the ISP boot mode by holding the SW4 button and reset.

  4. In the Connection dialog, test the connection to the processor.

For the MCXW71-FRDM development board:

  1. Connect the J10 port to your PC with a USB cable.

  2. Enable the ISP boot mode by holding the SW3 button and reset.

  3. In the Connection dialog, test the connection to the processor.

Booting images for KW45xx/K32W1xx/MCXW71xx devices

This section describes the building and writing of bootable images. For KW45xx/K32W1xx/MCXW71xx, SEC tool supports XIP images only.

Booting plain or CRC image

Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. Dual image boot is supported only for secure boot types.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparation of OEM-specific inputs as a Source executable image.

  4. If there is a binary image, set the start address to 0x0.

  5. Click the Build image button to build a bootable image. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation was successful, reset the board.

Booting signed image

This section describes building and writing a signed image.

Build a bootable image:

  1. Select the Plain signed boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparation of OEM-specific inputs (see Preparation of OEM-specific inputs) as a Source executable image.

  4. Ensure you have the keys on PKI management. Evaluation boards KW45B41Z-EVK, K32W148-EVK, and MCXW71-FRDM are produced with preprogrammed ROKTH and SB3KDK keys in the fuses CUST_PROD_OEMFW_AUTH_PUK and CUST_PROD_OEMFW_ENC_SK. These keys are also distributed in the SEC tool and can be imported from the tool folder bin\data\targets\<processor>\evk_keys or bin\data\targets\<processor>\frdm_keys. See Import/Export keys. These keys are intended for evaluation purposes only and must not be used for production.

  5. For Authentication key select any key, for example ROT1: IMG1_1

  6. Use an imported value or create your own (random) one for SB3KDK symmetric key.

  7. If needed, open Dual image boot and configure. Image must be linked to the Flash Logical Window.

  8. Keep Development in the life cycle.

  9. Click the Build image button to build a bootable image. The result is an SB3 capsule for installation into the processor.

When the bootable image and SB3 capsule have been successfully built, you can upload to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Keep OEM Open in the life cycle.

  5. Make sure that the IFR fields written in otp_config.sb are not burned already. All IFR fields are one time programmable.

  6. Click the Write image button.

Note: If IFR fields are written in the otp_config.sb, it is not possible to receive otp_config.sb multiple times.

Booting PRINCE encrypted image

Encrypted unsigned images, images with CRC or signed images are supported. The process of creating an encrypted image is similar to a signed image. In addition, configure encrypted regions in the Build image view. Use the PRINCE regions button to configure encrypted regions. In combination with the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1.

Image encryption is performed when the image is written to the target memory.

The regions configuration is included into the ROMCFG page.

Note: Open OTP/IFR configuration to review the PRINCE settings in the ROMCFG block(s) as the block must be completely specified and can be written only once. It is an irreversible operation.

Life cycle for KW45xx/K32W1xx/MCXW71xx devices

The default life cycle, which should be used for development, is OEM Open. Before you deploy the application, set the OEM Closed or OEM Locked life cycle (see documentation for the target processor for detailed description).

Note: Change of the life cycle is irreversible.

Once the processor is in “OEM Closed” or “OEM Locked” mode, the tool does not allow initializing the ROMCFG page. The application can still be updated via the SB file.

Table Boot type and life cycle for KW45xx/K32W1xx/MCXW71xx

OEM OPEN

OEM CLOSED/LOCKED

Plain unsigned or CRC boot type

- Only user fuses burnt
- SB file not used

- life cycle fuse burnt
- SB file not used

Plain signed boot type

- RKTH and SB3KDK burnt in write script
- user fuses in write script or OTP SB file
- SB file used

- RKTH and SB3KDK burnt in write script
- user fuses in OTP SB file
- SB file used

Encrypted boot type

- RKTH and SB3KDK burnt in write script
- user fuses and IFR in encryption write script or OTP SB file
- SB file used

- RKTH and SB3KDK burnt in write script
- user fuses and IFR encryption in OTP SB file
- SB file used

The table below shows the security assets installed in different life cycles and trust provisioning types:

Open life cycle, no Trust Provisioning

Closed life cycle, no Trust Provisioning

Open life cycle, EdgeLock 2GO

Closed life cycle, EdgeLock 2GO

SB3KDK

Write script

Write script

sb3kdk.asc

sb3kdk.asc

RKTH fuses

Write script

Write script

rkth.bin

rkth.bin

Other custom fuses and IFR

Write script or otp_config.sb

otp_config.sb

otp_config.sb

otp_config.sb

EdgeLock 2GO

EdgeLock 2GO is described in EdgeLock 2GO Trust Provisioning workflow. Below are KW45xx/K32W1xx/MCXW71xx specific comments:

  • The life cycle is set to the life cycle set to the secure objects. The RKTH and SB3KDK fuses are always burned during provisioning, even in the development life cycle.

  • Address for secure objects must be in internal flash, provisioning firmware erases the area before writing the secure objects.

Update NBU firmware

The NBU firmware is distributed within MCUxpresso SDK as SB3 file or as binary file (*.xip), in folder middleware\wireless\ble_controller\bin. There are two options to update the NBU firmware. First, use a prepared SB file with NBU firmware. It can be used for the EVK and FRDM boards with provisioned NXP keys. The other way is to prepare a custom SB file that will load the NBU firmware.

SB file with NXP keys

  1. Create or open a workspace for KW45xx/K32W1xx/MCXW71xx.

  2. In the menu bar, select Tools > Manufacturing Tool.

  3. Select the Apply SB file operation.

  4. Provide the SB file.

  5. Detect a connected device by clicking the Auto detect button.

  6. Load the SB file by clicking the Start button.

Custom SB file

  1. Open a workspace for KW45xx/K32W1xx/MCXW71xx with the custom keys that were provisioned to the device.

  2. In the menu bar, select Tools > SB Editor.

  3. Fill the Properties tab or import a setting from the SB file created on the Build tab.

  4. Switch to the Commands tab.

  5. Add two low level SB commands: erase and load.

  6. For erase, set the address to 0x48800000 and the size to 0x30000

  7. Set the load address to 0x48800000 and provide the firmware image.

  8. Configure the output paths.

  9. Prepare the final SB file by clicking the Generate button.

  10. Click the To Manufacturing tool button to switch to the manufacturing window with preselected Apply SB file operation and preselected SB file.

  11. Detect a connected device by clicking the Auto detect button.

  12. Load the SB file by clicking the Start button.

KW47xx/MCXW727x device workflow

This chapter describes the workflow for KW47xx/MCXW727x processors.

Preparing source image for KW47xx/MCXW727x devices

In this step, select the target memory where the image is executed. The following options are available for KW47xx/MCXW727x devices:

  • Image running from an internal flash

It is the only supported boot memory for the KW47xx/MCXW727x device family. The image is executed directly from internal flash memory.

There is no need to modify the default configuration, build the MCUXpresso SDK example as it is.

Connecting the board for KW47xx/MCXW727x devices

This section contains information about configuring the following evaluation boards and connecting them to SEC:

  • KW47-EVK

It is assumed that the SEC tool is already running with a workspace created for an KW47x. For more information, see Setting up Secure Provisioning Tool.

For the KW47-EVK development board:

  1. Connect the J14 port to your PC with a USB cable.

  2. Enable the ISP boot mode by holding the SW4 button and reset.

  3. In the Connection dialog, test the connection to the processor.

Booting images for KW47xx/MCXW727x devices

This section describes building and writing of bootable images. For KW47xx, the SEC tool supports XIP images only.

Booting plain image or plain with CRC image

Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly. Dual image boot is supported only for secure boot types.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparation of OEM-specific inputs (see Preparation of OEM-specific inputs) as a Source executable image.

  4. If there is a binary image, set the start address to 0x0.

  5. Click the Build image button to build a bootable image. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation was successful, reset the board.

Life cycle for KW47xx/MCXW727x devices

At this moment only the OEM Open is supported in the SEC tool for KW47xx/MCXW727x.

LPC55(S)0x/1x/2x/6x device workflow

This chapter describes workflow for LPC55(S)0x/1x/2x/6x, NHS52S04, and MCXW236 processors.

Preparing source image for LPC55(S)0x/1x/2x/6x devices

In this step, you must select the target memory where the image will be executed. The following option is available for LPC55Sxx devices:

  • Image running from an internal flash

    It is the only supported boot memory for the LPC55Sxx/LPC55xx device family. The image is executed directly from internal flash memory. (XIP)

Image running from internal flash

  • MCUXpresso IDE

  1. Build the project.

  2. Open the debug folder.

  3. Right-click the named <your.project>.axf file.

  4. Select Binary Utilities > Create binary.

  • IAR

  1. In Project > Options > Output Converter, check Generate additional output and select Raw binary output format.

_images/iar.png

IAR options

  1. Build the project.

You will find the output image built as boards\lpc55s##\demo_apps\led_blinky\iar\led_blinky\led_blinky.bin.

  • Keil MDK 5

  1. In Project > Options > User > After Build/Rebuild, check the Run #1 option.

  2. Enter the following in the User Command path (where myprog is the project’s Name of Executable): C:\Keil\ARM\ARMCC\bin\fromelf.exe –bin –output=myprog.bin myprog.axf.

  3. Build the image.

You will find the output image built as boards\lpc55s##\demo_apps\led_blinky\mdk\led_blinky\led_blinky.bin.

Connecting the board for LPC55(S)0x/1x/2x/6x devices

This section contains information about configuring the following LPC5Sxx evaluation boards and connecting them to SEC:

  • LPCexpresso55S69

  • LPCexpresso55S66

  • LPCexpresso55S28

  • LPCexpresso55S26

  • LPCexpresso55S16

  • LPCexpresso55S14

  • LPCexpresso55S06

  • LPCexpresso55S04

  • NHS52Sxx-EVK

  • FRDM-MCXW236B

It is assumed that the SEC tool is already running with a workspace created for an LPC device. For more information, see Setting up Secure Provisioning Tool.

  1. To communicate via UART, connect USB cable to P6 connector, for USB communication use P9 connector.

  2. Enable the ISP boot mode by holding the ISP button and reset.

  3. Ensure you have selected the Unsigned boot type in the Toolbar.

  4. In the Connection dialog, set the connection to USB or UART according to the selected port and test the connection to the processor.

Booting images for LPC55(S)0x/1x/2x/6x devices

This section describes the building and writing of images.

Security levels

The following security levels are supported in SEC:

Unsigned boot types : Default processor configuration that does not provide any security. It is recommended to start with the unsigned boot type to ensure the bootable image works on the processor. Unsigned boot types are intended for development only.

Signed or encrypted boot types - unsealed : Unsealed boot types are also designed to be used during development to ensure the selected boot type works well. In the KeyStore, CFPA, and CMPA pages are written into the processor. CMPA page is not sealed and can be updated or erased.

Signed or encrypted boot types - sealed : A sealed CMPA page is recommended for production. Select the Deployment life cycle in the Write image view to seal the CMPA page. Once sealed, it cannot be changed or erased.

Booting Plain/Plain with CRC image

This section describes the building and writing of plain/plain with CRC image.

  1. In the Toolbar, set Boot Type to Plain unsigned or Plain with CRC.

  2. As a Source executable image, use the image from Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  3. In the case of a binary image, set the start address to 0x0.

  4. If needed, open Dual image boot and configure.

  5. Click the Build image button.

  6. Check that the bootable image was built successfully.

Once the image has been successfully built, do the following:

  1. Make sure that the board is in ISP mode.

  2. Click the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation was successful, reset the board.

Booting plain signed or PRINCE encrypted image

This section describes the building and writing of an authenticated or PRINCE encrypted image. Keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys.

Note: The keys are also used for Encrypted (PRINCE) Plain and with CRC boot type because the bootable image is updated using SB capsule, which must be signed.

  1. In the Toolbar, set Boot type to Plain signed, Encrypted (PRINCE) unsigned, Encrypted (PRINCE) with CRC, or Encrypted (PRINCE) signed.

  2. In the Build image view, use the image from Preparing source image for LPC55(S)0x/1x/2x/6x devices as a source executable image.

  3. For Authentication key, select any keychain, for example, ROT1: IMG1_1_1.

  4. Open the PRINCE configuration and check the configuration. Set the size of the PRINCE region based on the size of the bootable image.

  5. If needed, open Dual image boot and configure. For a PRINCE encrypted image, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Select the Write image view.

  2. Make sure that the board is connected and the ISP mode is enabled (See Connecting the board for LPC55(S)0x/1x/2x/6x devices )

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

    If the write operation was successful, reset the board.

Once the image can be successfully executed in the processor, select the Deployment life cycle to permanently seal the device security with sha256 signature of the CMPA page. If the option remains unselected the security can be reconfigured. After you select the Deployment life cycle, click the Build image button in the Build image view. Then click the Write image button again and confirm the following message box:

_images/confirm_write.png

Confirm write

If the write operation was successful, reset the board.

Note: It is necessary to completely erase the entire processor before returning from PRINCE encryption to a non-encrypted image.

PFR and PUF KeyStore

This section provides information about PFR and PUF KeyStore.

PUF KeyStore initialization

SEC initializes KeyStore on LPC55Sxx devices only once in the device life cycle.

KeyStore enrollment status for the device is reported in the Connection dialog, using the Test button.

_images/keystore.png

KeyStore connection

It is possible to update the keys in the KeyStore, so it should not be needed to re-initialize KeyStore. In case of unexpected troubles, you can try to erase KeyStore, however, it is not recommended. With the KeyStore, it is recommended to also clear the CFPA page, as PRINCE IV fields in CFPA depend on the KeyStore. The device does not boot if you enroll the KeyStore and try to use it with previous IV fields.

How to erase KeyStore (example for LPC55S69)

bin/tools/blhost/win/blhost -u 0x1FC9,0x0021 -j -- set-property 29 1

bin/tools/blhost/win/blhost -u 0x1FC9,0x0021 -j -- write-memory 0x9E600 zero_1536.bin

zero_1536.bin is a file that contains zeros, and the file size is 3*512 bytes.

How to update CFPA page (example for LPC55S69)

  1. Increment the version in cfpa.json: it is recommended to add at least 0x10 from the last known version as the version is also incremented during PRINCE IV updates.

  2. Run the following commands to update the CFPA page into the processor:

    bin/tools/spsdk/pfr generate -c cfpa.json -o cfpa.bin
bin/tools/spsdk/blhost -u 0x1FC9,0x0021 -j -- write-memory 0x0009DE00 cfpa.bin

DCFG_CC_SOCU problem on LPC55Sxx

LPC55S0x/1x/2x/6x processors do not support theDCFG_CC_SOCU field configured in CFPA, while DCFG_CC_SOCU in CMPA is zero (not configured yet) and the processor may stop work (lock) if the configuration happens. It is recommended to always configure CMPA first and erase CFPA (+reset) in case erasing of CMPA is needed.

LPC55(S)3x device workflow

Preparing source image for LPC55(S)3x devices

In this step, select the target memory where the image is executed. The following options are available for LPC55(S)3x devices:

  • Image running from internal FLASH - XIP (eXecution In Place) image, which means that the image is executed directly from the memory where it is located.

    It is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is.

  • Image running from external FLASH - XIP (eXecution In Place) image, which means that the image is executed directly from the memory where it is located.

    The image must start at address 0x8001000. The other locations are not supported now. There is no need to modify the default configuration.

    For custom external FLASH, the configuration of external FLASH for booting can be adjusted in CMPA.

Connecting the board for LPC55(S)3x devices

This section contains information about configuring the evaluation board LPC55S36-EVK and connecting it to SEC.

Table Boot mode selection for EVK

Board

In-System Programming (ISP) Boot

Boot from internal FLASH

Boot from external FLASH

LPC55S36-EVK

J43: 1-2 open 3-4 closed

J43: 1-2 closed 3-4 closed

J43: 1-2 closed 3-4 open

  1. Select ISP boot mode, see Table Boot mode selection for EVK in Connecting the board for LPC55(S)3x devices.

  2. Connect the J3 port to your PC with a USB cable.

  3. Ensure SEC runs with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  4. Make sure that the boot memory in the toolbar matches NOR FLASH used on EVK board (for example, flex-spi-nor/ISxxxx) or internal flash.

  5. Set the connection to USB and test the board connection.

Booting images for LPC55(S)3x devices

This section describes building and writing of bootable images. For LPC55S3x, the SEC tool supports XIP images only.

Booting plain unsigned or CRC image

A plain image is typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select image built in Preparing source image for LPC55(S)3x devices as a Source executable image.

  4. If there is a binary image, set the start address to 0x0 for internal flash, or 0x8001000 for external flash.

  5. If needed, open Dual image boot and configure.

  6. Click the Build image button to build a bootable image. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation is successful, switch boot mode (see Table Boot mode selection for EVK in Connecting the board for LPC55(S)3x devices) and reset the board.

Booting plain signed image

This section describes building and writing a plain signed image.

Build a bootable image:

  1. Select the Plain signed boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select image built in Preparing source image for LPC55(S)3x devices as a Source executable image.

  4. For Authentication key select any key, for example ROT1: IMG1_1

  5. Use random value for “CUST_MK_SK” and “OEM seed” symmetric keys.

  6. If needed, open Dual image boot and configure.

  7. Open the PFR configuration and on the CMPA page check, that the bit-field SEC_BOOT_EN in the SECURE_BOOT_CFG field is configured. It is necessary to select any type of image check.

  8. Make sure that the board is connected and the processor is in ISP mode. During building processes, provisioning SB file for installation of CUST_MK_SK into processor is prepared.

    Note: The processor is reset after the SB file is built.

  9. Keep Develop in life cycle

  10. Click the Build image button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor.

When the bootable image has been successfully built, you can upload to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

Booting encrypted image

Encrypted images with CRC or signed images are supported. The process of creation an encrypted image is similar to a signed image. In addition, configure encrypted regions in the Build image view:

  • Use the PRINCE Regions button to configure encrypted regions for internal FLASH

  • Use the IPED Regions button to configure encrypted regions for external FLASH

In both cases, the whole image is encrypted by default. For clock limitations when using encrypted images, see documentation for the target processor. With the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1.

Image encryption is performed when the image is written to the target memory. The encrypted region is configured in the SB file. The decrypted regions are configured in the CMPA page, so make sure these two are aligned.

Test life cycle

To test processor behavior in the advanced life cycle, it is possible to temporarily change the life cycle to some higher level by setting control register PMC->LIFECYCLESTATE to the required level. This life-cycle state is valid until HW is reset.

Required steps:

  1. Prepare the image and generate keys.

  2. Set access control in SOCU registers.

  3. Build the image

  4. Execute write operation.

  5. Run the application.

  6. Connect a debug probe.

  7. On the write tab, click the Test life cycle button and in the displayed dialog set the required life cycle state.

  8. Click Apply to move the processor into the selected life cycle. Now, it is possible to test the processor behavior.

_images/Figure90_new.png

Lifecycle test

Life cycle for LPC55(S)3x devices

The default life cycle, which should be used for development, is Develop. Before you deploy the application, set the “In Field” or “In Field Locked” life cycle (see documentation for the target processor for detailed description).

Note: Change of the life cycle is irreversible.

When changing to In Field life cycle, CMPA and CFPA pages are installed in the dev_hsm_provi.sb file. It is supposed that in this mode, the pages are installed into an empty processor, so there are not any failures (the page update may fail, so in development mode, these pages are updated in write script, where the progress and error report are much better). Once the processor is in In Field state, the SEC tool supports only update of the application image; updates of CMPA and CFPA are not supported.

_images/Figure90_new.png

Lifecycle test

LPC865 workflow

This section describes the LPC865 device workflow in detail.

Preparing images for build for LPC865

The processor supports only images executed from internal flash (XIP). Use the default toolchain settings to build the application image.

Connecting the board for LPC865

This section contains information about configuring the evaluation board LPCXpresso860-MAX and connecting it to the SEC tool.

  1. To power the board, connect the J4 USB port with the USB cable to your power adapter or PC.

  2. Connect pins 2(RX) and 4(TX) at the J2 connector to the UART converter and connect to your PC.

  3. To switch the processor into ISP mode, hold the ISP(SW1) button and press RESET(SW3).

  4. Ensure that the SEC tool is already running with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  5. Open the Connection dialog and test the board connection. Mind the first board synchronization take a longer time.

Booting images for LPC865

This chapter describes the building and writing of plain bootable image.

Booting unsigned plain image

Plain unsigned is the only boot mode supported by this processor.

First, build a bootable image:

  1. Switch to the Build image view.

  2. Select an image built in Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices as a Source executable image.

  3. If there is a binary image, set the start address to 0x0.

  4. Click the Build image button to build a bootable image. During this operation, the following changes are applied to the image: life cycle (=code read protection) and CRC.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation is successful, reset the board. The processor will boot after several seconds.

Life cycles

The processor does not support real life cycles, so the code read protection can be configured instead of life cycle.

MC56F818xx/7xx/6xx and MWCT2xD2/12 devices workflow

This chapter describes workflow for MC56F818xx/7xx/6xx and MWCT2xD2/12 processors.

Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices

In this step, select the target memory where the image is executed. The following options are available for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices:

  • Image running from an internal flash - XIP (eXecution In Place) image, which means that the image is executed directly from the internal flash memory. There is no need to modify the default configuration, build the MCUXpresso SDK example as it is.

Connecting the board for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices

This section contains information about configuring the evaluation boards and connecting it to SEC:

  • MC56F81868-EVK

  • MC56F81000-EVK

  • WCT-QI2

  1. Power the board from USB_TYPE_C port (WCT-QI2).

  2. Connect the J4 1-TX, 3-RX, 5-GND port (WCT-QI2) via the MCU-Link to your PC.

  3. In the Connection dialog, set the connection to UART

  4. To get to ISP boot mode, send a blhost command to the processor within 5 seconds after the board startup, for example click the Test connection button in the Connection dialog.

Note: The processor boots from internal flash when there is no blhost command sent within 5 seconds after the startup.

Booting images for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices

This chapter describes the building and writing of plain and signed bootable images.

Booting plain unsigned or CRC image

Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices as a Source executable image.

  4. If there is a binary image, set the start address to 0x0.

  5. Click the Build image button to build a bootable image. The result is a binary bootable image. For secure processors there are also separated boot headers binary (BCA, FCB) and binary with application. This is due to the DUKB area in the internal flash that must stay untouched during the write.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation is successful, reset the board. The processor will boot after 5 seconds.

Booting plain signed image

This section describes building and writing a plain signed image.

Build a bootable image:

  1. Select the Plain signed boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices as a Source executable image.

  4. For Authentication key, select ROT1.

  5. Make sure that the board is connected and the processor is in ISP mode. During building processes, an SBx file is prepared. The processor is used as HSM to create an encrypted SBx file.

  6. Keep OEM Open in the life cycle. See Life cycle and device HSM trust provisioning for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices for OEM Closed life cycle.

  7. Click the Build image button to build a bootable image. The result is a binary bootable image, boot headers binary (BCA, FCB), and SBx capsule for installation of the image into the processor.

When the bootable image has been successfully built, you can upload to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

Life cycle and device HSM trust provisioning for MC56F818xx/7xx/6xx and MWCT2xD2/12 devices

The default life cycle used for development is OEM Open. Before you deploy the application, set the OEM Closed life cycle (see documentation for the target processor for a detailed description).

When the OEM Closed life cycle and Device HSM are set in the toolbar, the trust provisioning SBx file is created during the build. The IFR ISK_CERT_HASH fields are written to IFR by the dev_hsm_provi.sbx file. It is supposed that in this mode, the IFR fields have default values in the processor.

Note: Writing of IFR fields is irreversible.

Note: It is possible to reset the life cycle into an OEM Open state if needed. There are two possibilities:

  • Keep the Plain signed boot type, set the OEM Open life cycle, disable trust provisioning and do build and write. With this, the application is updated and the life cycle is set to OEM Open. Fields in IFR remain unchanged.

  • Set Plain unsigned boot type, OEM Open life cycle, disable trust provisioning and do build and write. With this, the entire flash memory is erased and the life cycle is set to OEM Open. Fields in IFR remain unchanged.

Attention: The blhost flash-erase-all command erases the entire memory, which also affects the life cycle state. After flash-erase-all and device reset the life cycle is in the Closed state. For details on how to reset the life cycle, see the second option.

Table Life cycle and device HSM trust provisioning

ISK_CERT_HASH

SBx file

OEM Open lifecycle, Signed boot type

Included in FCB

SBx used to write/update the application image

OEM Closed life cycle, Signed boot type

Irreversibly written to IFR in trust provisioning SBx file

SBx used to write/update the application image

MCX A14x/A15x device workflow

This chapter describes workflow for A14x/A15x processors.

Preparing source image for MCX A14x/A15x devices

  • Image running from internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is.

  • Image running from internal RAM; when creating this example, select the link application to RAM.

Connecting the board

This section contains information about configuring the evaluation boards FRDM-MCXA153 and FRDM-MCXA156 and connecting them to SEC.

Table Connecting the board

Board

In-System Programming (ISP) Boot

Boot from internal FLASH

FRDM-MCXA153

SW2/JP8

By default

FRDM-MCXA156

SW3

By default

To connect the board, follow the steps below:

  1. Select ISP boot mode, see the table above.

  2. Connect the UART/USB port to your PC with a USB cable.

  3. Ensure SEC runs with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  4. Go to main menu > Target > Connection, select UART/USB and test the connection.

Booting images MCX A14x/A15x devices

Booting plain unsigned and plain with CRC image is the same as for the MCXN devices. For details, see Booting plain or CRC image for MCX Nx4x/N23x devices.

Life cycle for MCX A14x/A15x devices

The default life cycle that should be used for development is OEM Open. Before you deploy the application, set the “In Field ROP 1”, “In Field ROP 2” or “In Field ROP 3” life cycle (see the documentation for the target processor for a detailed description).

Note: Change of the life cycle is irreversible.

MCX C041/C242/C444 device workflow

This chapter describes the workflow for Cx4x processors.

Preparing source image for MCX C041/C242/C444 devices

  • An image running from the internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as it is.

  • An image runs from internal RAM when this example is created. Select the link application to RAM. The option is not supported on MCXC041.

Connecting the board for MCX C041/C242/C444 devices

This section contains information about configuring the evaluation boards FRDM-MCXC041, FRDM-MCXC242, FRDM-MCXC444, and connecting them to SEC.

Table MCXC boards

Board

In-System Programming (ISP) Boot

Boot from internal FLASH

FRDM-MCXC041

SW3

By default

FRDM-MCXC242

SW3

By default

FRDM-MCXC444

SW3

By default

  1. Select ISP boot mode. For details, see the table above.

  2. Connect the UART/USB port to your PC with a USB cable.

  3. Ensure SEC runs with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  4. Go to main menu > Target > Connection, select UART and test the connection.

Booting images for MCX C041/C242/C444 devices

This section describes building and writing of bootable images into the internal flash and booting.

Booting plain unsigned image

First, build a bootable image:

  1. Switch to the Build image view.

  2. Select an image built in Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  3. If there is a binary image, set the start address to 0x00000000.

  4. If needed, open BCA/FCF configure.

  5. To build a bootable image, click the Build image button. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in the ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation is successful, reset the board to boot the image.

BCA and FCF pages

In the development life cycle, the BCA and FCF pages are not set into the bootable image unless there is any user requirement set to the page. If any requirement is set, the whole page is written, fields that have no user value are set to the default value. In that case, make sure that any value that was set in the source image is not unintentionally overwritten with the default values.

Note: When the life cycle is set to secured flash state, FCF is set into the bootable image even if there are no user requirements.

In the BCA/FCF configuration dialog, the current field values can be read from two sources:

  1. From the flash of the connected processor.

  2. From the source image selected on the build tab.

Life cycle for MCX C041/C242/C444 devices

The default life cycle that should be used for development is Flash unsecured. Before deploying the application, set the Flash secured (see documentation for the target processor for a detailed description). When switching the life cycle, the best practice is to set BCA and FCF pages. Chip with the flash security enabled can be erased, if ISP is available and the FCF field ‘mass erase’ is enabled.

Backdoor key

The advanced life cycle can be temporarily disabled if the backdoor key was set and the backdoor key comparison is enabled in FCF. After the backdoor key verification, the processor behaves as if in the OEM Open life cycle until the next reset. If the verification fails, further verification is not possible until flash reset.

MCX Nx4x/N23x device workflow

This chapter describes the workflow for Nx4x/N23x processors.

Preparing source image for MCX Nx4x/N23x devices

  • Image running from internal FLASH is the default option for almost all SDK examples. There is no need to modify the default configuration, build the example as is.

  • Image running from external FLASH must start at address 0x80001000, edit this address when creating an example in MCUXpressoIDE in advance setting.

  • Image running from internal RAM when creating this example select link application to RAM.

Connecting the board for MCX Nx4x/N23x devices

This section contains information about configuring the evaluation boards FRDM-MCXN947, MCX-N9XX-EVK, MCX-N5XX-EVK, and connecting it to SEC.

Table MCX boards

Board

In-System Programming (ISP) Boot

Boot from external FLASH

Boot from internal FLASH

MCX-N9XX-EVK

SW3/JP49

Boot source defined in CMPA

FRDM-MCXN947

SW3

Boot source defined in CMPA

MCX-N5XX-EVK

SW3/JP49

Boot source defined in CMPA

FRDM-MCXN236

SW3

N/A

By default

  1. Select ISP boot mode, see the table above.

  2. Connect the UART/USB port to your PC with a USB cable.

  3. Ensure SEC runs with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  4. Go to main menu > Target > Connection and select UART and test the connection.

Booting images for MCX Nx4x/N23x devices

This section describes building and writing of bootable images into the internal flash and booting. Booting from the external flash is similar, but the image linked to the external flash is used.

Booting plain or CRC image for MCX Nx4x/N23x devices

Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  4. If there is a binary image, set the start address to 0x00000000 (for external flash 0x80001000).

  5. If needed, open Dual image boot and configure.

  6. Click the Build image button to build a bootable image. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation is successful, remove the ISP jumper and reset the board to boot the image.

Booting plain signed image

This section describes building and writing a plain signed image.

Build a bootable image:

  1. Select the Plain signed boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  4. Generate keys on PKI tab.

  5. Back on the Build image view and select any Authentication key from the drop-down menu, for example ROT1: IMG1_1.

  6. Use random value for “CUST_MK_SK” and “OEM seed” symmetric keys.

  7. If needed, open Dual image boot and configure.

  8. Make sure that the board is connected and the processor is in ISP mode. During building processes, a provisioning SB3 file for installation of CUST_MK_SK into processor is prepared. If no board is connected, the build will fail when preparing the provisioning SB3 file. But other build processes were completed.

    Note: The processor is reset after the SB file is built.

  9. Click the Build image button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor.

When the bootable image has been successfully built, you can upload to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

Booting encrypted image

Encrypted images with CRC or signed images are supported. The process of creation an encrypted image is similar to a signed image. In addition, configure encrypted regions in the Build image view:

  • Use the PRINCE Regions button to configure encrypted regions for internal FLASH

  • Use the IPED Regions button to configure encrypted regions for external FLASH

In both cases, the image is encrypted by default. For clock limitations when using encrypted images, see documentation for the target processor. In combination with the dual boot, set one region for image0 and one for image1. Setting a region only for image0 does not encrypt image1.

Image encryption is performed when the image is written to the target memory. The encrypted region is configured in the SB file. The decrypted regions are configured in the CMPA page, so make sure these two are aligned.

Life cycle for MCX Nx4x/N23x devices

The default life cycle that should be used for development is Develop. Before you deploy the application, set the In Field or In Field Locked life cycle (see documentation for the target processor for a detailed description). When switching the lifecycle, the best practice is to burn the ROTKH and PRINCE or IPED region settings into fuses. ROTKH fuses are set by the tool automatically, but the PRINCE or IPED setting is up to the user to be set.

Note: Change of the life cycle is irreversible.

The life-cycle configuration also affects the way how the security assets are installed. In the development life cycle, some assets are installed in a write script so it is easier to debug the changes and problems.

The table below contains detailed information on how the security assets are installed based on the selected life cycle:

Table Life cycle and trust provisioning

Trust provisioning Life cycle

Device HSM Develop

Device HSM In Field

EdgeLock 2GO Develop

EdgeLock 2GO In Field

CMPA

Device HSM SB file

Device HSM SB file

el2go_provi.sb3

el2go_provi.sb3

CUST MK SK

Device HSM SB file

Device HSM SB file

CUST-MK_SK

CUST-MK_SK

ROKTH in CMPA

Device HSM SB file

Device HSM SB file

RKTH

RKTH

CFPA

Write script

Device HSM SB file

Write script

el2go_provi.sb3

RKTH fuses

Not burnt unless requested by the user

Device HSM SB file

Not burnt unless requested by the user

el2go_provi.sb3

NPX and IPED fuses

Not burnt unless requested by the user

Device HSM SB file

Not burnt unless requested by the user

el2go_provi.sb3

Other custom fuses

Write script

Device HSM SB file

Write script by default; optionally el2go_provi.sb3

el2go_provi.sb3

In the Develop life cycle, the CFPA is written in the write script, so any failures can be easily detected. In the In Field life cycle, the provisioning is supposed to be done for an empty processor.

Once the processor is in In Field state, the write script still allows updating the application image; other updates are not supported by the write script but can be done using a custom SB file.

Test life cycle

MCX Nx4x/N23x variants can set the test life cycle on the CFPA page by setting the bit-field CFPA_LC_STATE and INV_CFPA_LC_STATE in the HEADER register. By writing this CFPA setting, MCU behaves as if the LF was moved in OTP.

Note: Use only the expected LC values, other values can brick the chip.

To move back from the advanced life cycle, set the bit-field CFPA_LC_STATE back to 0x0 and write it to the chip. If the LC is moved only in the CFPA, it is possible to rewrite the CFPA page after power-on reset by executing blhost -u 0x1fc9, 0x014f – write-memory 0x01000000 cfpa.bin.

Steps to advance LC and return:

  1. Open or prepare a workspace that has a secure boot type (signed or encrypted)

  2. In the OTP/PFR configuration, set CFPA_LC_STATE to 0xF and INV_CFPA_LC_STATE to 0xF0

  3. Build and write image

  4. Power-cycle the device into ISP

  5. In OTP/PFR configuration, read the CFPA page

  6. Reset the device by clicking the Reset button or using the blhost reset command

  7. Test the secure life-cycle behavior (limited commands, debug rights based on the SOCU register)

  8. After testing is done, power-cycle the device into the ISP

  9. Open the OTP/PFR configuration and set CFPA_LC_STATE to 0x0 and INV_CFPA_LC_STATE to 0xFF

  10. Enable advanced mode and write the CFPA page into the device

  11. After reset, the device will be back in normal LC

    Note: For EVK variants for power cycle follow these steps:

    1. Power off the board

    2. Add jumper to JP22

    3. Change the power supply to USB (J28)

    4. Hold the ISP button (or short the jumper for ISP) and connect the board via J28

    5. Remove jumper JP22

EdgeLock 2GO

EdgeLock 2GO is described in EdgeLock 2GO Trust Provisioning workflow. Below are MCXN-specific comments:

  • The assets installed by EdgeLock 2GO are different for the Develop and In Field life cycle, see Life cycle for MCX Nx4x/N23x devices for details.

  • There is the ed2go_provi.sb3 file generated in the SEC tool that contains burning of the additional fuses. For the EdgeLock 2GO firmware, this file is optional; however, the SEC tool uses the file to install the fuses in the In Field life cycle.

    To add the file to the EdgeLock 2GO server via web portal, use the following steps:

    • Create a Secure Binary Object

    • Select Binary File

    • Assign any name

    • Set Object Identified (OID) to 0x7FFF817C

    • Select a nonconfidential file

    • In the policies, select NONE

  • For development, use the Develop life cycle in the SEC tool and the Open policy in configuration with secure objects on the EdgeLock 2GO server. With these settings, the life cycle is not changed and it still erases the processor. For production, use the In Field life cycle and the Closed policy. This does not apply to the SB3 file above where the policy should be always NONE.

  • The CMPA page must be erased before provisioning firmware is started, so it can be properly provisioned. The el2go-host application clears CMPA with parameter -clear. In case the production is executed with new/empty processors, the parameter can be removed.

  • Address for secure objects must be in internal flash, provisioning firmware erases the area before writing the secure objects

RT10xx/RT116x/RT117x device workflow

This section describes the RT10xx/RT116x/RT117x device workflow in detail.

Preparing source image for RT10xx/RT116x/RT117x devices

In this step, you must select the target memory where the image will be executed. The following options are available for RT10xx/RT116x/RT117x devices:

  • Image running from an external NOR flash

    It is the so-called XIP(eXecution In Place) image, which means the image is executed directly from the memory where it is located.

  • Image running in internal RAM

    This image can be on an SD card/eMMC or in external flash (SPI NOR, SPI NAND, or SEMC NAND) and will be copied into internal RAM and executed from there during the boot.

  • Image running in SDRAM

    This image can be located in an SD card or external flash (SPI NOR, SPI NAND, or SEMC NAND) and during boot will be copied into SDRAM and executed from there.

Image running from external NOR flash

  • MCUXpresso IDE

    The led_blinky example is linked into external flash by default.

    1. Optionally go to Project > Properties > C/C++ Build > Settings > MCU C Compiler > Preprocessor > Defined symbols and set XIP_BOOT_HEADER_ENABLE to 0. This step is now optional, because a bootable image can be used as an input on the build tab.

    2. Build the image.

      You will find the resulting source image as Debug\evkmimxrt10##_iled_blinky.axf. You can later use it as a Source executable image by SEC.

  • Keil MDK 5

    1. In the toolbar, select iled_blinky flexspi_nor_debug target.

    2. Optionally, in Project > Options > “*C/C++*”, disable define symbol XIP_BOOT_HEADER_ENABLE=0 (set to 0). This step is now optional, because a bootable image can be used as an input on the build tab.

    3. In Project > Options > Linker, remove all –keep options and the predefined symbol XIP_BOOT_HEADER_ENABLE. As a result, Misc. controls contains only –remove.

    4. Build the image.

      You will find the output image as boards\evkmimxrt10##\demo_apps\led_blinky\mdk\flexspi_nor_debug\iled_blinky.hex.

  • IAR Embedded Workbench

    1. In Project > Edit Configurations …, select flexspi_nor_debug

    2. Optionally, in Project Options > C/C++ Compiler >Preprocessor>Defined Symbols, add, or change the existing XIP_BOOT_HEADER_ENABLE define to 0.This step is now optional, because a bootable image can be used as input on the build tab.

    3. On multicore processors set the Processor variant in Project > Options… > General Options > Target, for example Cortex-M7 for iled_blinky_cm7 on RT1176.

    4. Build the image. You will find the output image as boards\evkmimxrt10##\demo_apps\led_blinky\iar\flexspi_nor_debug\iled_blinky.out.

Image running in internal RAM

Note: Memory addresses and sizes in this section are used as an example and depend on the selected processor.

  • MCUXpresso IDE

    1. Select Project > Properties - C/C++ Build > Settings > Tool Settings > MCU Linker > Managed Linker Script and check Link application to RAM.

    2. In Project > Properties > C/C++ Build > MCU settings, delete Flash, and modify SRAM_ITC to start at 0x3000 with size 0x1D000.

_images/flash.png

SRAM_ITC

3.  Move **SRAM\_ITC** to the first position to make it default.
4.  Build the image.

    You can find the resulting source image named *Debug\\evkmimxrt10\#\#\_iled\_blinky.axf*.

  • Keil MDK 5

    1. In the toolbar, select iled_blinky debug target.

    2. Open Project > Options > Linker and click Edit to edit the Scatter file.

    3. Close the window and make the following changes in the linker file (changes highlighted):

      #define m_interrupts_start 0x00003000
#define m_interrupts_size 0x00000400

      #define m_text_start 0x00003400
#define m_text_size 0x0001DC00

    4. Build the image.

      You can find the resulting image as boards\evkmimxrt10##\demo_apps\led_blinky\mdk\debug\iled_blinky.hex.

  • IAR Embedded Workbench

    1. Select Project < Edit Configurations … > Debug.

    2. Open file MIMXRT10##xxxxx_ram.icf from project root folder and make the following changes:

      define symbol m_interrupts_start = 0x00003000;
define symbol m_interrupts_end = 0x000033FF;

      define symbol m_text_start = 0x00003400;
define symbol m_text_end = 0x0001FFFF;

    3. On multicore processors set the Processor variant in Project > Options… > General Options > Target, for example Cortex-M7 for iled_blinky_cm7 on RT1176.

    4. Save the changes and build the image.

      You can find the resulting image built as boards\evkmimxrt10##\demo_apps\led_blinky\iar\debug\iled_blinky.out.

Image running from external SDRAM

  • MCUXpresso IDE

    1. Select Project > Properties - C/C++ Build > Settings > Tool Settings > MCU Linker > Managed Linker Script and check Link application to RAM.

    2. Select Project > Properties - C/C++ Build > Settings > Tool Settings > MCU C Compiler > Preprocessor and add defined symbol SKIP_SYSCLK_INIT=1.

    3. In Project > Properties > C/C++ Build > MCU settings, delete Flash, and modify BOARD_SDRAM to start at 0x80002000 with size 0x1dfe000. Move BOARD_SDRAM to first position to make it default.

    4. Build the image. You can find the resulting source image named Debug\evkmimxrt10##_iled_blinky.axf.

  • Keil MDK 5

    1. In the toolbar, select iled_blinky sdram_debug target.

    2. Open Project > Options > Linker and click Edit to edit the Scatter file.

    3. Close the window and make the following changes in the linker file (changes highlighted):

      #define m_interrupts_start 0x80002000
#define m_interrupts_size 0x00000400

#define m_text_start 0x80002400
#define m_text_size 0x0001DC00

#define m_data_start 0x80020000
#define m_data_size 0x01DE0000

    4. Build the image.

      You can find the resulting image as boards\evkmimxrt10##\demo_apps\led_blinky\mdk\sdram_debug\iled_blinky.hex.

  • IAR Embedded Workbench

    1. Select Project > Edit Configurations … > sdram_debug.

    2. Open file MIMXRT10##xxxxx_sdram.icf from project root folder and make the following changes:

      define symbol m_interrupts_start = 0x80002000;
define symbol m_interrupts_end = 0x800023FF;

define symbol m_text_start = 0x80002400;
define symbol m_text_end = 0x8001FFFF;

define symbol m_data_start = 0x80020000;
define symbol m_data_end = 0x8002FFFF;

define symbol m_data2_start = 0x80200000;
define symbol m_data2_end = 0x8023FFFF;

define symbol m_data3_start = 0x80300000;
define symbol m_data3_end = 0x81DFFFFF;

define symbol m_ncache_start = 0x81E00000;
define symbol m_ncache_end = 0x81FFFFFF;

    3. On multicore processors set the Processor variant in Project > Options… > General Options > Target, for example Cortex-M7 for iled_blinky_cm7 on RT1176.

    4. Save the changes and build the image.

      You can find the resulting image built as boards\evkmimxrt10##\demo_apps\led_blinky\iar\sdram_debug\iled_blinky.out.

Connecting the board for RT10xx/RT116x/RT117x devices

This section contains information about configuring the following evaluation boards and connecting them to SEC:

  • MIMXRT1010-EVK

  • MIMXRT1015-EVK

  • MIMXRT1020-EVK

  • MIMXRT1024-EVK

  • MIMXRT1040-EVK

  • MIMXRT1050-EVKB

  • MIMXRT1060-EVK

  • MIMXRT1064-EVK

  • MIMXRT1160-EVK

  • MIMXRT1170-EVKB

  1. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for instructions on how to set boot mode using DIP switches.

  2. Make sure you have J1 (J38 on RT1176, RT1166) set to 3-4 to power the board from USB OTG.

  3. Connect to the J9 (J20 on RT1176, RT1166) port with the USB cable to your PC.

  4. Ensure that SEC is already running with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  5. Make sure that the Boot memory in the toolbar matches the NOR flash used on the EVK board (for exampleflex-spi-nor/ISxxxx).

  6. Set the connection to USB and test the board connection.

Booting from SD card

For booting from an SD card, do the following:

  1. Insert a micro SDHC card into the board.

  2. In the MCUXpresso Secure Provisioning Tool, select Boot memory: sdhc_sd_card/SDHC SD card 8 GB in the Toolbar.

Table DIP Switches: Boot mode selection for EVKs

Boot mode/Device

Serial bootloader (ISP mode)

Flex-SPI NOR (QSPI, HyperFlash)

Flex-SPI NOR + Encrypted XIP (BEE/OTFAD/IEE)

SD card

eMMC

SEMC NAND

FlexSPI NAND

RT1010-EVK

SW8: 0001

SW8: 0010

SW8: 0010

N/A

N/A

N/A

N/A

RT1015-EVK

SW8: 0001

SW8: 0010

SW8: 0010

N/A

N/A

N/A

N/A

RT1020-EVK

SW8: 0001

SW8: 0010

SW8: 0010

SW8: 0110

N/A

N/A

N/A

RT1024-EVK

SW8: 0001

SW8: 0010

SW8: 0010

SW8: 0110

N/A

N/A

N/A

RT1040-EVK

SW4: 0001

SW4: 0010

SW4: 0010 or 0110 SW2: 1000

SW4: 1010

N/A

N/A

N/A

RT1050-EVKB

SW7: 0001

SW7: 0110

SW7: 0010 or 0110 SW5: 1000

SW7: 1010

N/A

N/A

N/A

RT1060-EVK

SW7: 0001

SW7: 0010

SW7: 0010 or 0110 SW5: 1000

SW7: 1010

N/A

N/A

N/A

RT1064-EVK

SW7: 0001

SW7: 0010

SW7: 0010 or 0110 SW5: 1000

SW7: 1010

N/A

N/A

N/A

RT1160-EVK

SW1: 0001SW2: 0000000000

SW1: 0010SW2: 0000000000

SW1: 0010SW2: 0100000000

SW1: 0010SW2: 0000001000

SW1: 0010 SW2: 0000000100

SW1: 0010SW2: 0000010000

N/A

RT1170-EVKB

SW1: 0001SW2: 0000000000

SW1: 0010SW2: 0000000000

SW1: 0010SW2: 0100000000

SW1: 0010SW2: 0000001000

SW1: 0010 SW2: 0000000100

SW1: 0010SW2: 0000010000

N/A

Booting images for RT10xx/RT116x/RT117x devices

This section describes the building and writing of bootable images.

You can use several combinations of used memories:

Table Booting image

Memory where the image is executed

Memory where the image is written

DCD/XMCD needed

XIP

External NOR flash

External NOR flash1

No

Yes

Internal RAM

External NOR or NAND flash1

No

No

Internal RAM

SD card or eMMC

No

No

SDRAM

External NOR or NAND flash1

Yes

No

SDRAM

SD card or eMMC

Yes

No

Note: For RT116x/7x devices, two FlexSPI instances are supported for FlexSPI NOR and FlexSPI NAND boot devices. There is the FLEXSPI_INSTANCE fuse (BOOT_CFG2\[3\])/GPIO boot pin which determines which FlexSPI instance to use. Set a corresponding GPIO boot pin to use Instance 2 without burning the fuse.

Note:

Booting unsigned image

An unsigned image is typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Unsigned boot type in the Toolbar.

  2. Switch to the Build image view.

  3. Select the image built in Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  4. For images executed from SDRAM, configure SDRAM using DCD or XMCD (RT116x/7x). For EVK boards, the following DCD file can be used: data\targets\MIMXRT1###/evkmimxrt1xxx_SDRAM_dcd.bin. For RT116x/7x, the following XMCD configuration file can be used: data\targets\MIMXRT11##/evkmimxrt11xx_xmcd_semc_sdram_simplified.yaml.

    Note: For customization of DCD files, refer to Creating/Customizing DCD files.

  5. If needed, open Dual image boot and configure (supported only for RT116x/7x and FlexSPI NOR).

  6. Click the Build image button to build a bootable image.

When the bootable image has been successfully built:

  1. Make sure that the board is in Serial Boot mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation was successful, switch boot mode (Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices) and reset the board.

Booting authenticated (HAB) image

This section describes the building and writing of an authenticated image. If you want to use an encrypted image, you can skip this step.

  1. In the Toolbar set the Boot type to Authenticated (HAB).

  2. In the Build image view, use the image from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1: IMG1_1+CSF1_1.

  4. If needed, open Dual image boot and configure. (RT116x/7x - FlexSPI NOR)

  5. Select the HAB Closed life cycle.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, switch to Write image view.

  1. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices and reset the board. for more information.

  2. Make sure that the Use built image checkbox is selected.

  3. Click the Write image button.

  4. In the following window, confirm to write fuses:

    • Yes - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • No - Do not burn fuses, continue writing the image.

    • Cancel - Abort writing the image and burning fuses.

_images/fig51.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices) and reset the board. ) and reset the board.

Booting encrypted (HAB) authenticated image

This section describes the building and writing of an encrypted image. This image will be decrypted into RAM during booting operation, so an XIP image cannot be used.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (HAB) authenticated.

  2. As a Source executable image, use the image from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1: IMG1_1+CSF1_1.

  4. If needed, open Dual image boot and configure. (RT116x/7x - FlexSPI NOR)

  5. Select the HAB Closed life cycle.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • Cancel - Abort writing the image and burning fuses.

_images/fig52.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices ) and reset the board.

Note: Part of the encrypted image is a DEK key blob encrypted using a master key from the processor. This master key is specific for each processor and cannot be used for another processor.

Note: RT101x and RT102x processors do not support running encrypted images in the NOR flash. In case no other booting device is supported for those processors, the Encrypted (HAB) authenticated boot type is not available.

Booting XIP encrypted image (BEE OTPMK) authenticated (RT10xx)

This section describes the building and writing of an XIP encrypted image using the OTP master key. An authenticated image is built and then encrypted on-the-fly during the write operation. The source image for the encrypted XIP with the BEE feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar, set the Boot type to XIP encrypted (BEE OTPMK) authenticated.

  2. As a Source executable image, use the image running from external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. For Authentication key, select any key, for example, SRK1: IMG1_1+CSF1_1.

  4. Click XIP encryption (BEE OTPMK) to open the BEE OTPMK window. In the window, keep the default settings to encrypt the whole image or configure your own FAC Protected Region ranges within the first BEE encrypted region.

  5. Select the HAB Closed life cycle.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Make sure that the Use built image checkbox is selected.

  4. Enable XIP encryption by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  5. Click the Write image button.

  6. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • Cancel - Abort writing the image and burning fuses.

_images/fig53.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices ) and reset the board.

Note: Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration.

Booting XIP encrypted image (BEE user keys) unsigned (RT10xx)

This section describes the building and writing of an XIP encrypted image using user keys. The image itself is built in two steps. First, the unsigned bootable image is built and then this unsigned image is encrypted for use with enabled encrypted XIP. The source image for the encrypted XIP with the BEE feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar, set the Boot type to XIP encrypted (BEE user keys) unsigned.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. Click XIP encryption (BEE user keys) to open the BEE user keys window. In the window, keep the default settings to encrypt the whole image, or edit User keys data to provide your specific key. Furthermore, the window allows you to configure additional BEE parameters (Both regions (engines), user key(s) for regions, FAC Protected Region ranges, random key generation).

  4. Click the Build image button.

  5. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Ensure that Use built image checkbox is selected.

  4. Enable XIP encryption by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  5. Click the Write image button.

  6. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that it is not possible to modify them.

    • Cancel - Abort writing the image and burning fuses.

_images/fig54.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices ) and reset the board.

Note: Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration.

Booting XIP encrypted image (BEE user keys) authenticated (RT10xx)

This section describes the building and writing of an XIP encrypted image using user keys. The image itself is built in two steps. First, the authenticated bootable image is built and then this authenticated image is encrypted for use with enabled encrypted XIP. The source image for the encrypted XIP with the BEE feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar set the Boot type to XIP encrypted (BEE user keys) authenticated.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. For Authentication key, select any key, for example, SRK1: IMG1_1+CSF1_1.

  4. Click XIP encryption (BEE user keys) to open the BEE user keys window. In the window, keep the default settings to encrypt the whole image, or edit user keys data to provide your specific key. Additionally, the window allows you to configure additional BEE parameters (Both regions (engines), user key(s) for regions, FAC Protected Region ranges, random key generation).

  5. Select the HAB Closed life cycle.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Preparing source image for RT10xx/RT116x/RT117x devices for more information.

  3. Ensure that Use built image checkbox is selected.

  4. Enable XIP encryption by setting a corresponding GPIO pin (see Preparing source image for RT10xx/RT116x/RT117x devices for more information).

  5. Click the Write image button.

  6. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • Cancel - Abort writing the image and burning fuses.

_images/fig55.png

Burn fuses

If the write operation was successful, switch boot mode (see Preparing source image for RT10xx/RT116x/RT117x devices and reset the board.

Note: Step 5 can be replaced by setting the EncryptedXIP fuse in the OTP configuration.

Booting XIP encrypted image (OTFAD OTPMK) authenticated (RT10xx)

This section describes building and writing of an XIP encrypted image using the OTP master key. The authenticated image is built and then encrypted on-the-fly during the write operation. The source image for the encrypted XIP with the OTFAD feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar, set the Boot type to XIP encrypted (OTFAD OTPMK) authenticated.

  2. As a Source executable image, use the image running from external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. For Authentication key, select any key, for example, SRK1: IMG1_1+CSF1_1.

  4. Click XIP encryption (OTFAD OTPMK) to open the OTFAD OTPMK window. In the window, keep the default settings to encrypt the whole image or configure your own Protected Region ranges.

  5. Select the HAB Closed life cycle.

  6. Click the Build image button.

  7. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • Cancel - Abort writing the image and burning fuses.

_images/bf.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices and reset the board.

Booting OTFAD encrypted image unsigned with user keys.

This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps.

To build the image, do the following:

  1. In the Toolbar set Boot Type to Encrypted, (OTFAD) unsigned for RT116x/7x or XIP encrypted (OTFAD user keys) unsigned for RT10xx.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. Click OTFAD encryption/XIP encryption (OTFAD user keys) to open the OTFAD Configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions (contexts), KEK source (OTP or PUF KeyStore), KEK, Key scramble, user keys for regions, regions ranges, random key generation.

  4. Open OTP configuration and review the settings and fix any reported problems.

  5. Click the Build image button.

  6. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Reset the board if the OTFAD KEK source is set to PUF KeyStore. It is necessary so that the key store is enrolled successfully.

  4. Ensure that Use built image checkbox is selected.

  5. Enable XIP encryption (RT116x/7x) by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  6. Click the Write image button.

  7. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that it is not possible to modify them.

    • Cancel - Abort writing the image and burning fuses.

_images/otfad1.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices ) and reset the board.

Note: Step 6 (RT116x/7x) can be replaced by setting the ENCRYPT_XIP_EN fuse in the OTP configuration.

Booting OTFAD encrypted image authenticated with user keys

This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps. First, the authenticated bootable image is built and then this authenticated image is encrypted for use with OTFAD. The source image for the OTFAD feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar set Boot type to Encrypted (OTFAD) authenticated for RT116x/7x or XIP encrypted (OTFAD user keys) authenticated for RT10xx.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. Ensure you have keys generated in the PKI management view. For more information, see PKI management.

  4. For Authentication key select any key, for example, SRK1: IMG1_1+CSF1_1.

  5. Click OTFAD encryption / XIP encryption (OTFAD user keys) to open the OTFAD configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions (contexts), KEK source (OTP or KeyStore), KEK, Key scramble, user keys for regions, regions ranges, random key generation.

  6. Select the HAB Closed life cycle.

  7. Open OTP configuration and review the settings and fix any reported problems.

  8. Click the Build image button.

  9. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Reset the board if the OTFAD KEK source is set to KeyStore. It is necessary so that the KeyStore is enrolled successfully

  4. Ensure that Use built image checkbox is selected.

  5. Enable XIP encryption (RT116x/7x) by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  6. Click the Write image button.

  7. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

      Note: Burning fuses can only be done once, after that the processor can only execute authenticated images.

    • Cancel - Abort writing the image and burning fuses.

_images/otfad2.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices ) and reset the board.

Note: Step 6 (RT116x/7x) can be replaced by setting the ENCRYPT_XIP_EN fuse in OTP configuration.

Booting IEE encrypted image unsigned (RT116x/7x)

This section describes how to build and write an IEE encrypted image. The image itself is built in two steps. First, the unsigned bootable image is built, and then this unsigned image is encrypted for use with the IEE. The source image for the IEE feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (IEE) unsigned.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. Click IEE encryption to open the IEE Configuration window. In the window set random keys. The window allows you to configure the number of IEE regions (contexts), KEK, AES encryption mode, and user keys for regions, regions ranges, random key generation.

  4. Open the OTP configuration, review the settings, and fix any reported problems.

  5. Click the Build image button.

  6. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to the Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Reset the board. It is required for successful key store enrollment.

  4. Ensure that the Use built image checkbox is selected.

  5. Enable XIP encryption by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  6. Click the Write image button.

  7. In the following window, confirm to write fuses:

    OK - Continue writing the image and burning fuses.

    Note: Burning fuses can only be done once, after that it is not possible to modify them.

    Cancel - Abort writing the image and burning fuses.

_images/burn_fuses.png

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices) and reset the board.

Note: Step 5 can be replaced by setting the ENCRYPT_XIP_EN fuse in the OTP configuration.

Booting IEE encrypted image authenticated (RT116x/7x)

This section describes how to build and write an IEE encrypted image. The image itself is built in two steps. First, the unsigned bootable image is built, and then this unsigned image is encrypted for use with the IEE. The source image for the IEE feature must be an XIP image.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (IEE) authenticated.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT10xx/RT116x/RT117x devices as a Source executable image.

  3. Ensure you have keys generated in the PKI management view. For more information, see section PKI management in PKI management.

  4. For Authentication key select any key, for example, SRK1: IMG1_1+CSF1_1.

  5. Click IEE encryption to open the IEE Configuration window. In the window set random keys. The window allows you to configure the number of IEE regions (contexts), KEK, AES encryption mode, and user keys for regions, regions ranges, random key generation.

  6. Select the HAB Closed life cycle.

  7. Open the OTP configuration, review the settings, and fix any reported problems.

  8. Click the Build image button.

  9. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information.

  3. Reset the board. It is required for successful key store enrollment.

  4. Ensure that the Use built image checkbox is selected.

  5. Enable XIP encryption by setting a corresponding GPIO pin (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices for more information).

  6. Click the Write image button.

  7. In the following window, confirm to write fuses:

    OK - Continue writing the image and burning fuses.

    Note: Burning fuses can only be done once, after that it is not possible to modify them.

    Cancel - Abort writing the image and burning fuses.

_images/Figure64_new.PNG

Burn fuses

If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT10xx/RT116x/RT117x devices) and reset the board.

Note: Step 6 can be replaced by setting the ENCRYPT_XIP_EN fuse in the OTP configuration.

Creating/Customizing DCD files

It is recommended to use MCUXpresso Config Tools or MCUXpresso IDE to prepare a DCD binary file.

  1. In any of the tools open any project/configuration for the selected processor.

  2. Import existing DCD configuration from an SDK source code by selecting main menu > File > Import > MCUXpresso Config Tools > Import Source.

  3. Select the file from SDK package in boards\evkmimxrt10##\xip\evkmimxrt10##_sdram_ini_dcd.c.

  4. Switch to the Device Configuration tool by selecting main menu > Config Tools > Device Configuration.

  5. In the toolbar of the DCD view, select Output Format to binary.

  6. Navigate to Code Preview and in the toolbar click the Export button and select the location where to generate a binary file.

    Note: Refer to the documentation of the Device Configuration Tool for more information.

RT118x device workflow

This section describes the RT118x device workflow in detail.

Preparing source image for RT118x devices

In this step, select the target memory where the image will be executed. The following options are available for RT118x devices:

  • Image running from an external NOR flash

    It is the so-called XIP(eXecution In Place) image. It means that the image is executed directly from the memory where it is.

  • Image running in RAM

    This image can be on an SD card/eMMC or in external flash (FlexSPI NOR, FlexSPI NAND) and will be copied into RAM and executed from there during the boot. The following RAM types are supported:

    • internal RAM

    • SDRAM

    • HyperRAM The source image preparation is similar to RT116x/7x, see Preparing source image for RT10xx/RT116x/RT117x devices. Some RT118x specifics:

    • Select an example for core cm33 and then set the target to Cortex-M33. ELE firmware is distributed in MCUXpresso SDK in the ‘ELE crypto’ component, typically the firmware\edgelock\mxrt1180-ahab-container.img file.

Connecting the board for RT118x devices

This section contains information about configuring the following evaluation boards and connecting them to SEC:

  • MIMXRT1180-EVK

  • MIMXRT1180A-EVK

  • MIMXRT1180-144

  1. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices in for instructions on how to set boot mode using DIP switches.

  2. Make sure you have J1 set to 3-4 to power the board from USB (from UART on RT1180-144).

  3. Connect to the J33 (J53 on RT1180-144) port with the USB cable to your PC.

  4. Ensure that SEC is already running with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  5. Make sure that the Boot device in the Boot Memory Configuration matches the FlexSPI NOR flash used on the EVK board.

  6. Set the connection to USB (UART on MIMXRT1180-144) and test the board connection.

  • Booting from SD card

For booting from an SD card, do the following:

  1. Insert a micro SDHC card into the board.

  2. Select SD card, SDHC SD-card 8GB USDHC1 in the Boot Memory Configuration.

  • Booting from eMMC:

For booting from an eMMC, do the following:

  1. eMMC can be installed on board, or it is possible to connect eMMC through SD slot by SD/eMMC adapter.

  2. Select eMMC, SDHC eMMC 8 GB USDHC1 in the Boot Memory Configuration.

Table DIP Switches: Boot mode selection for EVKs

Boot mode/Device

Serial bootloader (ISP mode)

Flex-SPI NOR

SD card/ eMMC

FlexSPI NAND

RT1180-EVK

SW5: x001

SW5: x100

SW5: x011

SW5: x101 (N/A)

RT1180A-EVK

SW5: x001

SW5: x100

SW5: x011

SW5: x101 (N/A)

RT1180-144

SW5: x100

SW5: x001

SW5: x110

SW5: x101 (N/A)

Booting images for RT118x devices

This section describes the building and writing of bootable images.

You can use several combinations of used memories:

Memory where the image is executed

Boot memory: Memory where the image is written

XMCD needed

XIP

External NOR flash

External NOR flash

No

Yes

Internal RAM

External NOR or NAND flash

No

No

Internal RAM

SD card or eMMC

No

No

SDRAM/HyperRAM

External NOR or NAND flash

Yes

No

SDRAM/HyperRAM

SD card or eMMC

Yes

No

Note:

Booting unsigned image

An unsigned image is typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Unsigned boot type in the Toolbar.

  2. Switch to the Build image view.

  3. Select the image built in Preparing source image for RT118x devices as a Source executable image.

  4. For images executed from SDRAM/HyperRAM, configure SEMC SDRAM / FlexSPI HyperRAM using XMCD. For EVK boards, the following XMCD configuration files can be used: <SEC>/sample_data/targets/MIMXRT118#/evkmimxrt118#_xmcd_*_simplified.yaml.

  5. If needed, open Dual image boot and configure.

  6. Click the Build image button to build a bootable image.

When the bootable image has been successfully built:

  1. Make sure that the board is in Serial bootloader (ISP) mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices) and reset the board.

Booting signed image

This section describes the building and writing of a signed image. Keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys. If you want to use an encrypted image, you can skip this step.

First, build a bootable image:

  1. In the Toolbar set Boot type to Signed.

  2. In the Build image view, use the image from Preparing source image for RT118x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1.

  4. Select the OEM Closed life cycle.

  5. Click the Build image button.

  6. Check that the bootable image was built successfully.

To write the image, switch to Write image view.

  1. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices for more information.

  2. Make sure that the Use built image checkbox is selected.

  3. Click the Write image button.

  4. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

    • Cancel - Abort writing the image and burning fuses.

_images/burn_fuses_RT118x.png

Burn fuses

  1. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices) and reset the board.

Booting encrypted (AHAB) image

This section describes the building and writing of an encrypted image. This image is decrypted into RAM during booting operation, so an XIP image cannot be used. The keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (AHAB).

  2. As a Source executable image, use the image from Preparing source image for RT118x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1.

  4. Select the OEM Closed life cycle.

  5. Click the Build image button.

  6. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to the Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table 3 for more information.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image. button.

  5. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

    • Cancel - Abort writing the image and burning fuses.

  6. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices) and reset the board.

Note: Part of the encrypted image is a DEK key blob encrypted using a master key from the processor. This master key is specific for each processor and cannot be used for another processor. DEK key blob is generated during write and the AHAB image is then updated with this processor-specific key blob.

Booting OTFAD encrypted image

This section describes the building and writing of an OTFAD encrypted image. The image itself is built in two steps. First, the unsigned/signed AHAB image is built and then this AHAB image is encrypted for use with OTFAD. The source image for the OTFAD feature must be an XIP image. The Keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (OTFAD) signed or Encrypted (OTFAD) unsigned.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT118x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1.

  4. Click OTFAD encryption to open the OTFAD configuration window. In the window set random keys. The window allows you to configure the number of OTFAD regions (contexts), KEK source (OTP or DUK), KEK, Key scramble, user keys for regions, regions ranges, random key generation.

  5. Select the OEM Closed life cycle.

  6. Open the OTP configuration and review the settings and fix any reported problems.

  7. Click the Build image button.

  8. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices for more information.

  3. Ensure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

    • Cancel - Abort writing the image and burning fuses.

_images/burn_fuses_1.png

Burn fuses

  1. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices) and reset the board.

Booting IEE encrypted

This section describes the building and writing of an IEE encrypted image. The image itself is built in two steps. First, the unsigned/signed AHAB image is built and then this AHAB image is encrypted for use with IEE. The source image for the IEE feature must be an XIP image. The Keys generated in the PKI management view are needed in this step. For more information about generating keys, see Generate keys.

To build the image, do the following:

  1. In the Toolbar set the Boot type to Encrypted (IEE) signed or Encrypted (IEE) unsigned.

  2. As a Source executable image, use the image external NOR flash from Preparing source image for RT118x devices as a Source executable image.

  3. For Authentication key select any key, for example, SRK1.

  4. Click IEE encryption to open the IEE configuration window. In the window set random keys. The window allows you to configure the number of IEE regions (contexts), AES encryption mode, and user keys for regions, regions ranges, random key generation.

  5. Select the OEM Closed life cycle.

  6. Open the OTP configuration and review the settings and fix any reported problems.

  7. Click the Build image button.

  8. Check that the bootable image was built successfully.

To write the image, do the following:

  1. Switch to the Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. See Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices for more information.

  3. Ensure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. In the following window, confirm to write fuses:

    • OK - Continue writing the image and burning fuses.

    • Cancel - Abort writing the image and burning fuses.

_images/burn_fuses_1.png

Burn fuses

  1. If the write operation was successful, switch boot mode (see Table DIP Switches: Boot mode selection for EVKs in Connecting the board for RT118x devices) and reset the board.

Booting multicore images

This section describes how to build and write an image for multiple cores (Cortex M33 and Cortex M7). Only Cortex M33 is a bootable core. The source image used for Cortex M33 must trigger the second core in the code (Cortex M7). See demo_apps\multicore_trigger example in the SDK package for RT118x.

To build multicore images, do the following:

  • In this example, the Cortex M7 XIP image runs from external Flash (start address 0x2800B000) and the Cortex M33 image runs from internal RAM (start address 0xFFE0000):

  1. Set the Source executable image (image for Cortex M33) in the Build tab.

  2. Open the Additional User/OEM Image dialog via the Additional images button (the application binary image is automatically filled up).

  3. Specify a standalone Cortex M7 executable binary image running from the flash memory and set the following values:

    • Image offset - 0xA000. It is calculated as: Load address (0x2800B000) - FlexSPI NOR base address (0x28000000) - AHAB image offset in FlexSPI NOR (0x1000)

    • Load address - 0x2800B000

    • Entry point - 0x2800B000

    • Core Id - cortex-m7

    • Image type - executable

  4. Close the dialog by clicking the OK button.

  5. Click the Build image button.

  • In this example, the Cortex M7 image runs from internal ITCM RAM (start address 0x0) and the Cortex M33 XIP image runs from external flash (start address 0x2810B000). This use case requires additional fuses, so the internal RAM is properly accessible.

  1. Set the Source executable image (image for Cortex M33) in the Build tab.

  2. Open the Additional User/OEM Image dialog via the Additional images button (the application binary image is automatically filled up).

  3. Specify a standalone Cortex M7 executable binary image running from ITCM RAM and set the following values:

    • Image offset - 0x10F400 - this can be any value which does not overlap with other image (in this example the image was placed directly after the Cortex M33 image)

    • Load address - 0x303C0000 (secured alias of CM7 ITCM in the CM33 core address space)

    • Entry point - 0x0 (the start addresses of the image in the CM7 address space)

    • Core Id - cortex-m7

    • Image type - executable

  4. Close the dialog by clicking the OK button.

  5. Open the OTP Configuration dialog by clicking the OTP configuration button in the left-bottom corner.

  6. Set POR_PRELOAD_MC7_TCM_ECC and RELEASE_M7_RST_STAT fuses (BOOT_CFG7) to 1 and fix any reported problems.

  7. Close the dialog via the OK button.

  8. Click the Build image button.

Note: The write process of the multicore images is the same as for Booting IEE encrypted.

Life cycle for RT118x device workflow

The default life cycle, which should be used for development, is OEM Open. Before you deploy the application, set the OEM Closed or OEM Locked life cycle (see documentation for the target processor for detailed description).

Note: Change of the life cycle is irreversible.

Once the processor is in “OEM Closed” or “OEM Locked” mode:

  • The tool processor does not allow burn fuses via blhost. The application can still be updated.

  • The processor can only execute signed images

Firmware version

The firmware version value is included in the AHAB container header, field Fuse version. This version value is fused indirectly through the ELE commit API when the AHAB container is authenticated. This commit API must be called from the application itself.

The AHAB image with a lower fuse version than the version fused cannot be loaded during booting.

The firmware version is supported for signed images only.

RT5xx/6xx device workflow

This section describes the RT5xx/6xx device workflow in detail.

Preparing source image RT5xx/6xx devices

In this step, you must select the target memory where the image will be executed.

Supported boot memories are NOR flash, SD card, and eMMC.

The following boot types are available for RT5xx/6xx processors:

  • Image running in external flash: The XIP image (eXecuted In Place)

  • Image running in internal RAM: The image is copied from FLASH, SD card, or eMMC to RAM before the execution

It is recommended to use the gpio_led_output example for verification, the image is started properly. By default, this example triggers LED blinking only if the user button is clicked, but you can easily modify it to blink all the time.

Image running in external flash

The gpio_led_output example is linked into external flash by default. Disable the XIP Boot header, as it will be created by SEC.

  • MCUXpresso IDE

    1. Optional step: go to Project > Properties > C/C++ Build > Settings > MCU C Compiler > Preprocessor > Defined symbols and set BOOT_HEADER_ENABLE to 0.

    2. Build the image.

      You will find the resulting source image named as Debug\evkmimxrt685_gpio_led_output.axf. It can be used as an input for the bootable image in SEC.

  • Keil MDK

    1. In the Toolbar, select gpio_output_flash_debug target.

    2. Optional step: in Project > Options > “*C/C++*” disable define symbol BOOT_HEADER_ENABLE=0 (set to 0).

    3. In Project > Options > Output select the Create HEX file checkbox.

    4. Double-check that the application is linked to 0x8001000. If not, the following fix must be applied to the linker as a workaround for the problem:

_images/mdk.png

Keil MDK workaround

  1. Build the image.

You will find the output image as boards\evkmimxrt685\driver_examples\gpio\led_output\mdk\flash_debug\gpio_led_output.out

  • IAR Embedded Workbench

    1. In Project > Edit Configurations …, select flash_debug.

    2. Optional step: in Project Options > C/C++ Compiler > Preprocessor > Defined Symbols, add or change the existing BOOT_HEADER_ENABLE define to 0.

    3. Build the image.

      You will find the output image as boards\evkmimxrt###\driver_examples\gpio\led_output\iar\flash_debug\gpio_led_output.out.

Image running in internal RAM

  • MCUXpresso IDE

    1. Go to Project > Properties > C/C++ Build > Settings > MCU C Compiler > Preprocessor > Defined symbols and set BOOT_HEADER_ENABLE to 0.

    2. Select Project > Properties - C/C++ Build > Settings > Tool Settings > MCU Linker > Managed Linker Script and check Link application to RAM.

    3. Build the image.

      You will find the built image as Debug\evkmimxrt685_gpio_led_output.axf. You can later use it as a Source executable image by SEC.

  • Keil MDK

    Because example projects for MDK are not built into RAM, you must manually modify the linker file. Generic description of such changes is not documented yet.

  • IAR Embedded Workbench

    1. In Project > Edit Configurations …, select debug.

    2. In Project Options > C/C++ Compiler > Preprocessor > Defined Symbols, add or change the existing BOOT_HEADER_ENABLE define to 0.

    3. Build the image.

      You will find the output image built as boards\evkmimxrt###\driver_examples\gpio\led_output\iar\debug\gpio_led_output.out.

Connecting the board for RT5xx/6xx devices

This section contains information about configuring the following evaluation boards and connecting them to SEC:

  • MIMXRT595-EVK

  • MIMXRT685-EVK

Table RT5xx/6xx EVK boot configuration

Boot Mode/Device

ISP Mode

FlexSPI Boot

SD card

eMMC

MIMXRT595-EVK

SW7[1:3]: 100 (UART, SPI, I2C)SW7[1:3]: 101 (USB)

SW7[1:3]: 001

RT595 SW7[1:3] 011

RT595 SW7[1:3] 110

MIMXRT685-EVK

SW5[1:3]: 100

SW5[1:3]: 101

RT685 SW5[1:3] 011

RT685 SW5[1:3] 110

  1. Switch the board to ISP Mode and reset. For more information, see the above table.

  2. Connect to the J7 port with the USB cable to your PC.

  3. Ensure you have started SEC with a new workspace. For more information, see Setting up Secure Provisioning Tool.

  4. Set the connection to USB and test the board connection.

Booting from SD card:

For booting from an SD card, do the following:

  1. Insert SDHC card into the board in MCUXpresso Secure Provisioning Tool

  2. Select the Boot memory: sd_card/SDHC SD card 8 GB in the Toolbar.

  3. SDHC power cycle must be set to ENABLED for evk boards

Booting from eMMC:

For booting from an eMMC, do the following:

  1. eMMC can be installed on board, or it is possible to connect eMMC through SD slot by SD/eMMC adapter.

  2. Select Boot memory: eMMC/SDHC eMMC 8 GB in the Toolbar.

Booting images for RT5xx/6xx devices

This chapter describes the building and writing of plain and signed bootable images.

Booting a plain/plain with CRC image

A plain image is typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly.

To build a bootable image, follow these steps:

  1. In the Toolbar, select Plain unsigned or Plain with CRC in Boot type.

  2. Switch to the Build image view.

  3. Select image build in Preparing source image RT5xx/6xx devices as a Source executable image. If needed, open the Dual image boot and configure. If configured, open OTP configuration and review all reported problems. For fuse BOOT_CFG[3] being locked after write, it is necessary to specify the whole value as it is programmed only once.

  4. Click the Build image button to build a bootable image.

When the bootable image has been successfully built:

  1. Connect the board, see Connecting the board RT5xx/6xx devices.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Reset the board. If the write script is executed twice without resetting the board, the configuration of external memory may fail unless the fuse with the QSPI reset pin is not burnt.

  5. Click the Write image button.

If the write operation was successful, switch boot mode to FlexSPI boot (Table RT5xx/6xx EVK boot configuration in Connecting the board RT5xx/6xx devices) and reset the board.

Booting signed image using shadow registers

This section describes the building and writing of an authenticated image.

  1. In the Toolbar set Boot type to Plain signed.

  2. In the Build image view, use the image from Preparing source image RT5xx/6xx devices as a Source executable image.

  3. Ensure you have keys generated in the PKI management view. For more information, see PKI management.

  4. For Authentication key, select any key, for example, ROT1: IMG1_1.

  5. As a Key source, select OTP or KeyStore. KeyStore represents a higher security level, as PUF is used. See Securing the processor for the limitations.

  6. Generate a random User key and SBKEK.

  7. If needed, open Dual image boot and configure.

  8. Select the Development life cycle.

  9. Open OTP configuration and review all reported problems. For fuses BOOT_CFG[0] and BOOT_CFG[3] being locked after write, it is necessary to specify the whole value, as it will be programmed only once.

  10. Click the Build image button and check that the bootable image was built successfully.

To write the image, do the following:

  1. To write the image, switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. For more information, see Connecting the board RT5xx/6xx devices.

  3. Make sure that the Use built image checkbox is selected.

  4. Reset the board. It is necessary because:

    • Shadow registers cannot be updated or written twice, they can be set to a “clean” processor only.

    • If the fuse for the QSPI reset pin is not burnt, it is necessary to reset the flash manually before each configuration.

  5. Click the Write image button.

During the write operation, the following steps are performed:

  1. Fuses are checked to ensure that the board is in an unsecured mode.

  2. A simple application is written into RAM. The application initializes shadow registers.

  3. Shadow registers data are written into RAM. The application is started.

  4. The application resets the processor.

  5. The write_image script is started to configure external flash and write the application into flash.

Booting OTFAD encrypted image using shadow registers

This section describes the building and writing of an encrypted image (OTFAD encryption).

  1. In the Toolbar set Boot Type to Encrypted (OTFAD) with CRC or Encrypted (OTFAD) signed.

  2. In the Build image view, use the image from Preparing source image RT5xx/6xx devices as a Source executable image.

  3. Ensure you have keys generated in the PKI management view. For more information, see PKI management.

  4. For Authentication key, select any key, for example, ROT1: IMG1_1.

  5. As a Key source, select OTP or KeyStore. KeyStore represents a higher security level, as PUF is used. See Securing the processor for the limitations.

  6. Generate a random User key and SBKEK.

  7. Open OTFAD encryption and set random keys.

  8. If needed, open Dual image boot and configure.

  9. Select Development life cycle.

  10. Open OTP configuration and review all reported problems. For fuses BOOT_CFG[0] and BOOT_CFG[3] being locked after write, it is necessary to specify the whole value, as it will be programmed only once.

  11. Click the Build image button and check that the bootable image was built successfully.

To write the image, do the following:

  1. To write the image, switch to Write image view.

  2. Make sure that the board is set to Serial bootloader (ISP) mode. For more information, see Connecting the board RT5xx/6xx devices.

  3. Make sure that the Use built image checkbox is selected.

  4. Reset the board. It is necessary because:

    • Shadow registers cannot be updated or written twice, they can be set to a “clean” processor only.

    • If the fuse for the QSPI reset pin is not burnt, it is necessary to reset the flash manually before each configuration.

  5. Click the Write image button.

During the write operation, the following steps are performed:

  1. Fuses are checked to ensure that the board is in an unsecured mode.

  2. A simple application is written into RAM. The application initializes shadow registers.

  3. Shadow registers data are written into RAM. The application is started.

  4. The application resets the processor.

  5. The SB file is applied to the processor, and during this process, the following actions will be done:

    • Configure external flash

    • Erase flash (KeyStore is preserved if it is used)

    • Create an FCB block at the beginning of the flash

    • Write an encrypted application

    • Write OTFAD key blobs

Note: Repetitive Write to QSPI flash might fail if the board is not Reset.

Booting signed/encrypted image - burn fuses

Burning fuses is an irreversible operation, which should be performed only after the bootable image was tested with shadow registers. It is also recommended to safely back up all keys prior to burning fuses. The booting process is identical to the process described in Booting plain signed image using shadow registers with only one difference in write operation - the Deployment life cycle must be selected. During the write operation, the shadow registers will not be initialized, and the write image script will burn the fuses instead. The GUI will display confirmation with a list of fuses groups to be burnt.

Note: Detailed info about the modification of fuses can be reviewed in OTP/PFR/IFR configuration.

Securing the processor

To enable full security on RT5xx/6xx processors, DCFG_CC_SOCU and DCFG_CC_SOCU_AP fuses must be burnt.

SEC does not set up these fuses for burning by default (even if the Deployment life cycle is selected), but you can configure it in OTP/PFR configuration.

Once the DCFG_CC_SOCU fuses are set, it is no longer possible to modify security configuration parameters, and no changes in the key store are allowed using blhost. If KeyStore is used, the image can be updated in SEC only if:

  • ISP mode is still enabled, and

  • QSPI_ISP_AUTO_PROBE_EN bin in BOOT_CFG[1] fuse is enabled.

    This feature is not supported on RT6xx processors, and the image can be updated only using a custom bootloader.

If the keys are stored in OTP fuses, no limitation applies.

Note that OTFAD encryption on RT600 is not supported with KeyStore, because there is no support to back up and restore KeyStore during erasing the flash in the SB file.

To test the DCFG_CC_SOCU configuration in the shadow registers, the following steps must be followed:

  • prepare and test the application image without DCFG_CC_SOCU (for example, all DCFG_CC_SOCU must be zero)

  • once the image is running and the FCB configuration is valid and available in FLASH, configure DCFG_CC_SOCU. The processor will now be set to full security, so some blhost operations are no longer available. The processor can be updated via SB file only.

Device HSM provisioning

This section describes the provisioning of the processor using key blob encrypted using device HSM, which allows to transfer keys (fuses values) securely and application bootable image into the factory. Device HSM is supported for all secure boot types: Plain signed and OTFAD encrypted in the deployment life cycle. Device HSM can be selected from the toolbar in the trust provisioning type selection dialog.

In device HSM mode, several fuses are configured by trust provisioning firmware. These fuses must be configured, so the tool displays an error if the required value is not specified. The encryption of the fuses into the key blob is done using the EVK evaluation board. During the build operation, the fuses values are written into RAM, and then trust provisioning firmware creates a key blob.

To do the build, follow the steps below:

  1. On the toolbar, ensure that the Plain signed or Encrypted boot type is selected.

  2. On the toolbar, ensure that the Deployment life cycle is selected.

  3. On the toolbar, select Device HSM provisioning type.

  4. In OTP configuration, ensure that all fuses for device HSM are specified; additional fuses can be burnt in the application SB file.

  5. Connect EVK board using UART or USB connector.

  6. Open the Connection dialog and test the connection.

  7. Run the build. During the build, the bootable image and SB file are created and then the fuses values are written to processor RAM and then encrypted using provisioning firmware. The fuses of the processor are not affected in this step.

  8. After the build script, the encrypted key blob is read.

Note: Provisioning firmware is distributed in a restricted data package, see Preferences for details.

Write

Write operation is the same as secure boot type using a write script. The write script uses the same provisioning firmware to decrypt the key blob and burn selected fuses and then it resets the processor. It uses the SB file to install the application image. In case the booting device is selected by the fuse, ensure that the booting device is empty, so the processor falls into ISP mode after the reset and the application image can be uploaded.

Manufacturing package

For the manufacturing operation, it is recommended to create a manufacturing package. For more information, see Manufacturing workflow.

RT7xx device workflow

This section describes the RT7xx device workflow in details.

Preparing source image for RT7xx devices

In this step, select the target memory where the image is to be executed.

The supported boot memories are NOR flash (instance 0 or 1) or eMMC.

The following boot types are available for RT7xx processors:

  • Image running in external flash: the XIP image (eXecuted In Place)

  • Image running in internal RAM. The ROM during the boot time copies the image from FLASH or eMMC to RAM.

Connecting the board for RT7xx devices

This section contains information about configuring the MIMXRT700-EVK evaluation board and connecting it to SEC.

Table RTxxx EVK boot configuration

Board

ISP mode

XSPI0

XSPI1

eMMC

PSRAM

MIMXRT700-EVK

SW10: 1-4 OFF, 2-3 ON

SW10: 1-4 ON, 2-3 OFF

SW10: 1-4 ON, 2-3 ON

SW10: 1-4 OFF, 2-3 OFF

JP45 to 1-2

To connect the board, follow the steps below:

  1. Switch the board to ISP Mode and reset. For more information, see Table RTxxx EVK boot configuration in Connecting the board for RT7xx devices.

  2. Connect your PC to the U7 port using the USB cable.

  3. Ensure you have started SEC with a new workspace. For more information, see Setting up Secure Provisioning Tool.

  4. Set the connection to UART and test the board connection.

Booting from eMMC:

Select Boot memory eMMC in the toolbar.

Running image in external RAM:

The image located in XSPI0 flash can be copied into XSPI1 external RAM (PSRAM) during boot and executed from there. XMCD configuration must be used to initialize the external RAM.

Booting images for RT7xx devices

This chapter describes the building and writing of plain and signed bootable images.

You can use several combinations of used memories:

Memory where the image is executed

Memory where the image is written

XMCD needed

XIP

Supported

External NOR flash

External NOR flash

No

Yes

Yes

Internal RAM

External NOR or eMMC

No

No

Yes

External RAM

External NOR

Yes

No

Yes

External RAM

eMMC

n/a

n/a

No, ROM limitation

Life cycle for RT7xx devices

There are two types of life cycles supported: shadows and OTP. In the shadows, the OTP fuses are not burnt and instead shadow registers are used. The shadow registers are initialized via a debug probe so during write the debug probe must be connected with an ISP communication cable. The shadow registers can be used only for development, not for production.

Booting a plain unsigned/CRC image

Plain images are typically used for development. It is recommended to start with this boot type before working with secured images to verify that the executable image works properly.

To build a bootable image, follow these steps:

  1. In the toolbar, select Plain unsigned or Plain with CRC in Boot type.

  2. Switch to the Build image view.

  3. Select the image build in Preparing source image for RT7xx devices as a Source executable image. If needed, open the Dual image boot and configure. If configured, open OTP configuration and review all reported problems.

  4. Click the Build image button to build a bootable image.

When the bootable image is successfully built:

  1. Connect the board, see Connecting the board for RT7xx devices.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

If the write operation was successful, switch boot mode to XSPI boot(see Table RTxxx EVK boot configuration in Connecting the board for RT7xx devices.) and reset the board.

Booting plain signed image using shadow registers

This section describes the building and writing of an authenticated image.

A signed image cannot be used with the Development, OTP life cycle because the ROM does not contain any command to burn CUST-MK-SK without advancing the life cycle.

To build a signed image, use the following steps:

  1. In the toolbar, set the Boot type to Plain signed.

  2. In the toolbar, set life cycle to Development, shadows, InField, shadows or InField-Locked, shadows.

  3. In the Build image view, use the image from Preparing source image for RT7xx devices as a Source executable image.

  4. Ensure you have keys generated in the PKI management view. For more information, see PKI management.

  5. For Authentication key, select any key, for example, ROT1: IMG1_1.

  6. Generate a random CUST-MK-SK and OEM seed.

  7. If needed, open Dual image boot and configure.

  8. Open OTP configuration and review all reported problems.

  9. Click the Build image button and check that the bootable image was built successfully. During the build, the tool communicates with the processor to create the device HSM SB file. This does not cause any changes in the processor or in the flash memory.

To write the image, do the following:

  1. Switch to Write image view.

  2. Select main menu > Target > Debug Probe and select the debug probe. The debug probe is used to write the shadow registers.

  3. Make sure that the board is set to Serial bootloader (ISP) mode. For more information, see RT7xx device workflow.

  4. Make sure that the Use built image checkbox is selected.

  5. Click the Write image button.

During the write operation, the following steps are performed:

  1. The shadow registers for the fuses are initialized.

  2. The application is written to the processor via the SB file.

Change the ISP pins and do soft reset [button SW2] to start the application.

Device HSM

The table below shows how the shadows/fuses are configured:

Table Shadows/fuses configuration

Fuse

Any shadows life-cycle

InField, OTP life-cycle

CUST-MK_SK

The device HSM SB file is used to initialize the shadow registers.

Device HSM SB file

Other fuses

OTP shadow registers are initialized via the debug probe.

Device HSM SB file

RW61x device workflow

This chapter describes the workflow for RW61x processors.

Preparing source image for RW61x devices

The only available boot memory for the RT61x processor is external flash.

Optional step: to create the source image for the build in SEC tool, you can disable the boot header by defining the symbol BOOT_HEADER_ENABLE to 0 (in MCUXpresso IDE, go to Project > Properties > C/C++ Build > Settings > MCU C Compiler > Preprocessor > Defined symbols and set BOOT_HEADER_ENABLE to 0). From SEC tool v9, this step is optional. The SEC tool can parse the bootable image and retrieve the application image from the bootable image.

The image shall be at address 0x8001000 (default in MCUXpresso SDK examples).

Connecting the board for RW61x devices

This section contains information about configuring the evaluation boards RD-RW612-BGA or RD-RW61x-QFP or FRDM-RW612 and connecting it to SEC.

Table RD-RW boards

Board

In-System Programming (ISP) Boot

Boot from external FLASH

RD-RW612-BGA

U38 switch: 0001

U38 switch: 0000

RD-RW612-QFP

U38 switch: 0001

U38 switch: 0000

FRDM-RW612

Hold the SW3 button during reset.

Reset without the ISP button.

  1. Select ISP boot mode, see Table RD-RW boards in Connecting the board for RW61x devices.

  2. Connect the J7 port (on FRDM, it is J10) to your PC with a USB cable.

  3. Ensure SEC runs with a workspace created for the chosen device. For more information, see Setting up Secure Provisioning Tool.

  4. Go to main menu > Target > Connection and select UART and test the connection.

Shadow registers for fuses via debug probe

The SEC tool uses In-Field, shadow registers as the default life cycle. It means that the In-Field life cycle will be configured using shadow registers. For development, start with shadow registers to avoid irreversible changes in fuses, but this should not be used for production. The shadow registers configuration is done via a debug probe, so the probe must be selected first:

  1. Go to the main menu >Target > Debug Probe to open a dialog for debug probe selection.

  2. Select a debug probe from the drop-down menu

  3. Switch the board switch to boot mode from an external flash and reset the processor; click “Test connection” to check the connection with the debug probe

The processor does not allow using shadow registers in the “Develop” life cycle, so by default, the shadow registers for the life cycle will configure the “In-Field” state.

Also, to make image booting using shadow registers, it is necessary to configure the boot source in BOOT_CFG0 shadow register. As the fuse is locked after the first write, the tool will ask you to specify all the other bits (even for shadow registers). Go to OTP configuration to specify them.

In the shadow registers life cycle, the fuses shadow registers are configured immediately after the write image is successfully finished. The SEC tool launches the write_shadows script that will set the shadow registers and then resets the processor. After the reset, the processor boots the image.

For the encrypted mode, the application is written via the SB file, so RKTH and CUST_MK_SK fuses must be programmed (even if the shadow registers life cycle is selected).

Booting images for RW61x devices

This section describes building and writing bootable images into the external flash and booting.

The default SEC tool configuration is prepared for the EVK board. If you are using an FRDM board, use the FlexSPI configuration from the W25Q512 template. In case the flash is locked for write, it is possible to unlock it using the FCB provided in sample_data:

  1. Select main menu > Target > Boot Memory.

  2. Select FlexSPI NOR - complete FCB.

  3. Select the FCB file from the disk.

  4. Select the file sample_data\targets\RW612\source_images\frdmrw612_wb_reset_fcb_quad_spi_v2.fcb. This file must not be used for production.

Booting plain or CRC image

Plain images are typically used for development. Start with this boot type before working with secured images to verify that the executable image works properly.

First, build a bootable image:

  1. Make sure you have selected the Plain unsigned or Plain with CRC boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  4. If there is a binary image, set the start address to 0x8001000.

  5. Configure BOOT_CFG0 fuse (see the previous paragraph).

  6. If needed, open Dual image boot and configure.

  7. Click the Build image button to build a bootable image. The result is a binary bootable image.

When the bootable image is built, upload it to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

  5. If the write operation was successful, reset the board.

  • the image boots automatically if shadow registers are selected

  • otherwise switch boot mode (see Table RD-RW boards in Connecting the board for RW61x devices ) and reset the board to boot the image.

Booting plain signed image

This section describes building and writing a plain signed image.

Build a bootable image:

  1. Select the Plain signed boot type in the toolbar.

  2. Switch to the Build image view.

  3. Select an image built in Preparing source image for LPC55(S)0x/1x/2x/6x devices as a Source executable image.

  4. For Authentication key select any key, for example ROT1: IMG1_1

  5. Use random value for “CUST_MK_SK” and “OEM seed” symmetric keys.

  6. Ensure that there is no error in OTP configuration. For ECC p384 key length you will need to configure the BOOT_CFG3 fuse.

  7. Make sure that the board is connected and the processor is in ISP mode. During building processes, provisioning SB3 file for installation of CUST_MK_SK into processor is prepared.

    Note: The processor is reset after the SB file is built.

  8. Keep In-Field, shadow regs life cycle to avoid irreversible changes in the processor

  9. Click the Build image button to build a bootable image. The result is a binary bootable image and SB3 capsule for installation of the image into the processor.

When the bootable image and SB3 capsule have been successfully built, you can upload to the processor:

  1. Make sure that the processor is in ISP mode.

  2. Switch to the Write image view.

  3. Make sure that the Use built image checkbox is selected.

  4. Click the Write image button.

In the shadow register life cycle, no fuses are burnt. The signed application is written into the flash and then shadow registers are applied and the processor is reset to start the application.

Once you advance to the life cycle without shadow registers, the fuses will be burnt irreversibly and the SB3 capsule will be used to write the application into the flash.

Booting encrypted image

Encrypted images with plain, CRC, or signed images are supported. The process of creation an encrypted image is similar to a signed image.

In addition, it is necessary to configure encrypted regions via the IPED Regions button on the Build image view (by default, the whole application is encrypted). IPED region alignment is based on the page size of the target FLASH, which is retrieved from FCB flash configuration. See Boot memory configuration for details on how to convert Flex-SPI NOR simplified configuration to full FCB configuration.

Due to ROM limitations, the image must be always located inside the IPED region, it is not allowed to erase or write range that exceeds the encrypted region.

In combination with the dual boot, configure encryption for image0 only, and the same settings are applied for image1.

Image encryption is performed when the image is written to the target memory. The application is written via SB file, so RKTH and CUST_MK_SK fuses must be burnt, so the processor can decrypt and authenticate SB file content. Mind these fuses will be burnt even if the shadow registers are selected.

The encrypted region is configured in the SB file. The decrypted regions are configured in fuses, so make sure these two are aligned.

Device HSM and provisioning

The CUST_MK_SK is a customer key for SB file encryption/decryption and this key can be installed into the processor only using device HSM SB file. The key is stored in the fuses, so the installation is irreversible and once the fuse is written it is locked for write (the lock is also used to detect if the key is already installed or not). In the write script, there is an argument to decide whether the key shall be burnt or not.

To apply device HSM into the processor, it is necessary to use a device HSM loader FW distributed in restricted data (for details, see Preferences.

The content of device HSM depends on the life cycle, see Life cycle for RW61x devices for details.

Life cycle for RW61x devices

The following table provides an overview of fuses burnt by the write script for different configurations of life cycle and boot type and contains information on whether the SB3 capsule can be used to update the application image.

Table Boot type and life cycle for RW61x

Shadow regs life cycle

Develop life cycle

In-Field life cycle

Plain unsigned or CRC boot type

- No fuses burnt
- SB file not used

- Fuses burnt, see OTP Configuration dialog
- SB file not used

- Same as develop + life cycle fuse burnt
- SB file not used

Plain signed boot type

- No fuses burnt
- SB file not used, however it is generated during build

- Fuses burnt, see OTP Configuration dialog
- RKTH and CUST_MK_SK burnt
- SB file used

- Same as develop + life cycle fuse burnt
- SB file used

Encrypted boot type

- RKTH and CUST_MK_SK burnt
- SB file used
- No other fuses burnt

- Fuses burnt, see OTP Configuration dialog
- IPED, RKTH, and CUST_MK_SK burnt
- SB file used

- Same as develop + life cycle fuse burnt
- SB file used

The table below shows the security assets installed in different life cycles and trust provisioning types:

Table Life cycle and trust provisioning

Device HSM Develop

Device HSM In Field

EdgeLock 2GO Develop

EdgeLock 2GO In Field

CUST MK SK

Device HSM SB file

Device HSM SB file

CUST-MK_SK

CUST-MK_SK

RKTH fuses

Write script

Device HSM SB file

el2go_provi_otp.bin

el2go_provi_otp.bin

Other custom fuses

Write script

Device HSM SB file

el2go_provi_otp.bin

el2go_provi_otp.bin

DRY RUN - the EdgeLock 2GO is started in dry run mode, there are no irreversible changes in the processor. The secure objects are downloaded and written to flash, the trust provisioning firmware is started and checks the content of the secure objects.

EdgeLock 2GO

EdgeLock 2GO is described in EdgeLock 2GO Trust Provisioning workflow. Below are RW61x-specific comments:

  • The provisioning firmware does not work if the processor boots into ISP mode. The processor must be in RUN mode and the external flash must be erased. After resetting the processor, as there is no application in the flash, the processor will fall back into ISP mode and EdgeLock 2GO provisioning can be started.

  • The address for secure objects must be in external flash. After the provisioning is finished, all secure objects (even secure objects that are already installed) remain in the memory.

  • In case of the Develop life cycle, the provisioning works only in DRY RUN mode, allowing you to test the process affecting the processor. In this mode, the processor UUID is retrieved and sent to the EdgeLock 2GO server. Then, secure objects are downloaded, applied to the processor (external flash) and the provisioning firmware is executed. The firmware verifies the secure objects but does not burn fuses and does not change the life cycle. The application image is not provisioned, as the SB file cannot be loaded yet.

  • To upload the SB3 file into the EdgeLock 2GO server as a secure object, use the following parameters:

    • Create New Secure Object

    • Binary File

    • Assign any name

    • Set the Object Identified (OID) to 0x7FFF817C

    • Non confidential file

    • Add Policy/Select Device Life Cycle: Closed

    • Select permitted algorithm: NONE

    • Policies for this profile: NONE For uploading secure objects to the EdgeLock 2GO server, use the Closed/Locked policy. The Open policy is not a preferable option, as DRY RUN mode supports the Closed policies too.