The MCX  N series are MCUs with an integrated flash memory like many traditional MCU series. Having an embedded flash memory is particularly useful, as facilitates board design, development, simplifies BOM, software development.  However, the size of the embedded flash might not meet applications required memory footprint. Some customers simply need more flash memory. For example, Graphical applications require store large image buffers in a non-volatile memory. Data logger devices that need to store large amounts of data. Or heavy inference models for object recognition.  Applications that need to store backup versions of their firmware or are way too complex and big. To solve this requirement the MCX N94x provides the capability to interface a great variety of wider and external memories. There are several traditional options to expand flash storage, but the one we are addressing is the use of external NOR  flash memories. To access an external memory the MCX N94x integrates modules that support external memory interfacing, those are  FlexIO and the FlexSPI. The FlexSPI module is capable of communicating with several kinds of memories. One of them is the Serial NOR flash which can be used as booting device. The goal of this article is to present the solution of a customer case scenario: How to run code from an external flash memory. Demonstrating the flexibility of the MCX N94x platform as well as introducing several tools, peripherals, and concepts that a developer will need to be familiar with while developing an application that runs from an external flash memory. The below figure illustrates the goal of this article, Run code from an external flash memory. The same hello world application can be run from the internal and external memory, for example, a NOR serial QuadSPI memory, without any functionality changes. The core simply will fetch and execute the instructions, using dedicated peripherals like FlexSPI.   Figure 1 Executing same code from internal memory vs external memory. The MCX N94x series integrates a FlexSPI module, which enables running code from an external NOR flash memory.   Figure 2 MCX N94x block diagram To follow this article, you will need the  FRDM-MCXN947 Development board. Which is the evaluation board for the MCX N94x and N54x MCUs. The FRDM-MCXN947 integrates a W25Q64JVSSIQ QuadSPI flash memory. Therefore, this platform is perfect for creating an application that runs from an external flash memory. Figure 3 External NOR flash memory on FRDM-MCXN947   Boot, PFR, and SPSDK   With the boot ROM  that the MCX  N integrates you can erase, program, and read the on-chip or external flash memory, which means you can use the boot ROM to download a boot image into the on-chip or external flash memory via the ISP interfaces. This article shows how to load a customized led_blinky demo, from the SDK  to the external flash memory using the boot ROM. However, other application projects may be used as well. Also, the boot ROM takes responsibility for the boot flow. It selects whether to boot from on-chip flash memory, external flash memory, or ISP mode.  The figure below shows an extremely simplified boot flow, which gives an overall understanding of the chip boot flow.  For more details on the boot flow mechanism refer to the section Top-level boot flow of the MCX Nx4x Reference manual.   Figure 4 Simplified boot Flow After the reset handling routine, the boot ROM will take control of the chip’s boot flow. It will begin with pertinent chip’s initialization. Then will check the status of the ISP pin. If the ISP pin is currently asserted, the ISP boot handling routine will be executed. ISP or  In-system programming is an execution mode where the boot ROM will wait for commands from an external host, over protocols like UART or USB, to do actions like read and write the chip memory, burn fuses, and many more. If the ISP pin is not asserted, the boot ROM will continue to determine the boot mode. Boot mode can be controlled with the CMPA[BOOT_SOURCE] bit of the CMPA of the PFR or eFUSES. If  CMPA[BOOT_SOURCE]= 01b the boot ROM will run FlexSPI NOR boot handling routine. If CMPA[BOOT_SOURCE] is 00b or 11b internal flash memory handling routine is executed. After the boot mode selection, the image will be validated. If it is not valid, for example, is not present in memory, is corrupted, or does not have proper format,  the ISP boot handling routine is executed. If the image is valid, finally the boot ROM will perform the jump to the user´s application. The default boot flow is by internal flash, most of the SDK examples will be configured to boot from internal flash, as CMPA[BOOT_SOURCE] equals zero by default, or when CMPA area is erased. According to the Simplified bot Flow diagram, we need to make boot ROM go to FlexSPI NOR boot handling routine, to boot from the external flash. Therefore, we need to make   CMPA[BOOT_SOURCE] = 01b. The PFR holds critical boot and security settings that are monitored by the boot ROM after every reset. As just described earlier, the CMPA area can be used to control boot mode. Therefore, PFR areas need to be carefully configured, as they control boot flow and also security features of the chip. The below figure shows a very minimalistic representation of the PFR containing the CMPA, next to the internal flash.   Figure 5 PFR's CMPA area   For specific details of the PFR  please refer to the MCXNx4x_IFR.xlsx, attached to the MCX Nx4x Reference Manual. To facilitate writing into the CMPA and other areas of the  PFR, signing applications, burning fuses.  programming applications, NXP already developed several host command tools, APIs, and applications and integrated into a python tool called SPSDK. The below figure shows all the tools contained by the SPSDK. To get  details on the SPSDK and description of APIs, Applications, and tools  refer to SPSDK documentation at  https://spsdk.readthedocs.io/en/latest/spsdk.html#   Figure 6 SPSDK API modules, applications, and tools The above figure highlights 3 applications, provided by the SPSDK,  that is going to be used to configure the chip to boot from the external flash memory those are: nxpdebugmbox, PRF, and BLHOST. Detailed step-by-step usage of these applications will be described later on.  The nxpdebugmbox application sends interfaces with the chip’s debug mailbox over SWD. The purpose of this tool is set MCU into ISP mode, without having to set low ISP pin,  also to make a mass erase to the chip's memory and PFR. Once the MCU enters ISP mode the host PC will be able to communicate with the boot ROM over UART or USB protocols. This enables the use of PFR and BLHOST applications. The PFR application will be used to write the CMPA[BOOT_SOURCE] = 01b and enable FlexSPI, port to probe and let the chip communicate with the external flash, in the CMPA area of the PFR. The BLHOST application will be used to erase the chip and program application image, in this particular case,  a led_blinky demo.    External Serial NOR flash interfacing   The following terms are critical to understand how we can execute code in an external NOR flash memory with the MCX N94x. First of all, Execute-in-Place refers to the capability that the MCU core has to fetch and execute instructions directly from the external memory. It refers to the capability that an MCU has to execute code from the flash memory instead of an internal and traditional flash. To do XIP the MCX  N94x requires a capable peripheral with the ability to fetch instructions from the external memory. The FlexSPI module is capable of doing this. The FlexSPI does support several types of external memories. One of them is Serial NOR Flash. To interface the external memory with the FlexSPI supports SPI. SPI is an excellent serial protocol for short-distance and high-speed communications. The term QuadSPI could be simply understood as an implementation of the SPI protocol, where instead of having a single Data line, there are 4 data lines. SPI also supports two, and eight data lines. Flexible Serial Peripheral Interface (FlexSPI) memory controller supports connection to external serial NOR, NAND, and RAMs. It supports two SPI channels and up to four external devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines). Flexible sequence engine (LUT table) to support various vendor devices (serial NOR, serial NAND, HyperBus, FPGA, etc). Memory-mapped read/write access by AHB Bus AHB RX Buffer implemented to reduce read latency. Total AHB RX Buffer size: 1024 Kbytes 8 flexible and configurable buffers in AHB RX Buffer Software triggered Flash read/write access by IP Bus IP RX FIFO implemented to buffer all read data from External device. FIFO size: 1024 Bytes IP TX FIFO implemented to buffer all Write data to External device. FIFO size: 1024 Bytes DMA support to fill IP TX FIFO DMA support to read IP RX FIFO   Figure 7 FlexSPI block diagram   FlexSPI system memory map regions are remapped to different addresses at the FlexSPI sub-module:   Figure 8 FlexSPI memory map FlexSPI can support serial devices compliant with JESD216. Pre-requisites You will need the following Hardware: FRDM-MCXN947 evaluation board. USB C cable. Windows or Linux PC. You will need to install the following Software. MCUXpresso IDE v11.9.0 or above.  FRDM-MCXN947 SDK v2.15.0 or above.  SPSDK and python.     SPSDK installation and virtual environment   We recommend to run the SPSDK on a python virtual environment, as this simplifies the installation of the SPSDK. Before proceeding with installation steps for the SPSDK we recommend to create a folder in your computer. This is where the virtual environment will be running, the SPSDK tools will be called,  and all the files generated by the SPSDK will be stored. Open a terminal, command, or Power Shell prompt  and navigate to your folder and follow the SPSDK installation  commands listed in this guide: Installation Guide — SPSDK documentation            To double check installation of the SPSDK run the following command in your virtual environment. spsdk --version         This figure shows the example of this command and the spsdk version used for this document.   Figure 9 SPSDK version.  Setup  This chapter describes all steps to generate and boot an image from the external memory.  To run the commands listed in this document you will need use your python’s virtual environment. Use the virtual environment you created during SPSDK installation.  PFR settings This section describes the settings that need to be done in the MCX N94x PFR and bootable image.        Create CMPA and CFPA yaml  templates   In the following steps, we are going to focus on editing CMPA area since it contains boot-related fields for external execution.  CFPA area is not required to be edited.            Note:The commands used to generate the templates are based on ‘pfr’ tool  For details on the capabilities of these commands, visit: User Guide - pfr — SPSDK documentation First we are going to use pfr to create our yml CMPA/CFPA templates. These templates contain only the default configurations specified for the CMPA and CFPA areas of  device. If the command run successful the templates will be generated. As shown in figure this figures   Figure 10 Yaml template created.   Edit the CMPA and CFPA yaml templates   Open CMPA   template in any text editor and follow the below steps. Set DEFAULT_BOOT_SOURCE to FLEXSPI_FLASH_XIP_0b01 Set FLEXSPI_AUTO_PROBE   to ENABLE Save the changes in the CMPA template.      Create and write the  CMPA and CFPA binaries         After editing the cmpa yaml, you will generate the CMPA/CFPA binaries from the yml templates.     Import and edit image   This section shows how to create an XIP bootable image from the  MCUXpresso SDK  led_blinky example.    Import the led_blinky demo from the SDK.  Click on “Import SDK example(s)…” (1), then search and select the FRDM-MCXN947 (2), and click “Next” (3). Inside the “SDK import wizard” search and select the “led_blinky  demo (4) and click on “Finish” (5)     Figure 11 Import the blinky example.      Once the demo project is imported open the project properties. Do a right-click in the project’s name (1), then click on “Properties” option (2) and open the project properties(3)   Figure 12 Project ´properties Navigate to the Properties> C/C++ Build > MCU settings section       Figure 13 MCU settings window Make sure that there are two  Flash areas for the external memory: QSPI_FLASH and             QSPI_FCB as shown in Figure 14. If the areas are missing add them as shown in the next step.     Figure 14 External flash areas in the linker.     Add the two flash areas for the  QSPI_FLASH and QSPI_FCB in the “Memory details” table, the move them to the Top.  Click in “Add Flash”  (1) twice, then click on “Move selected memory up in table” (2), the two newly created flash areas should be placed at the top.   Note: Moving a memory area to the top of the “Memory details” table indicates the linker that text and data should be placed preferably in that area. Update the newly created flash areas name and parameters with the ones from the below table.   Type Name Alias Location Size Driver Flash QSPI_FLASH Flash 0x80001000 0xFFFF000 MCXN9xx_SFDP_FlexSPI.cfx Flash QSPI_FCB Flash 2 0x80000400 0x400 MCXN9xx_SFDP_FlexSPI.cfx     Make sure that the flash areas match the ones shown in the Figure 15.     Figure 15 Configured flash areas    Click “Build” (1), once compilation is finished, should return 0 errors (2).   Figure 16 Successfully compiled image.                                      Note: You should see that the QSPI_FLASH section is being used and that the PROGRAM_FLASH section is not. Generate the binary. Navigate to the project’s debug folder and locate generated .axf (1). Then do a right-click in the .axf, and click on Binary utilities > Create Binary.   Figure 17 Create binary.   7 The binary should appear in the debug folder. Get  easily get the binary location by doing a right click on the binary and navigating to  “Show in>System Explorer”   Figure 18 Get created binary with ease. 8. Paste the binary into the workspace where you created the cmpa_bin.bin. This step is only to simplify the commands shown later on.   Erase and ISP mode entry        ISP (In system programming ) is a mode where a host is able to instruct the ROM bootloader to program a new image or the PFR. The which holds the CMPA field with our configuration to do XIP from the external flash memory. Basically, the Host computer sends commands to the ROM bootloader to program the PFR using NXP’s BLHOST. To enter into ISP mode there are two options: ISP pin entry and Debugger mailbox. ISP pin entry requires keeping ISP pin asserted during reset sequence and de-asserting this pin after reset has been completed. Debugger mailbox only requires to use of a SWD debugger to make the ROM entry ISP mode. To enter into ISP mode over ISP pins follow is necessary keep ISP pin asserted during reset sequence and de-assert this pin after reset has been completed. To use the debugger mailbox is only needed having a debugger. For simplicity, the communication protocol will be USB. However, UART can be used as well. Erase the flash memory and enter ISP mode using the nxpdebugmbox. Proceed to run each command nxpdebugmbox erase  nxpdebugmbox ispmode -m 0   This figure shows the expected output when running the two commands from above.   This operation will erase the contents on the internal and external flash memory. Also the PFR contents. Repeating this operation can be useful to get the chip to boot from internal flash memory. Note:  nxpdebugmbox commands need to be run using a SWD-JTAG debugger. For this example on-board debugger of the FRDM-MCXN947 is used. Ping rom Bootloader  Run the following command to ping the rom Bootloader, this way we can ensure that the device was set correctly in ISP mode. blhost  -t 2000 -p COMxxx,115200 -j -- get-property 1     Figure 19 Ping rom Bootloader From now on, an external debugger is not strictly required. The communication with the rom bootloader can be done over UART or USB. For simplicity, the UART protocol-based commands are used from now on in the rest of this document. Write  image and PFR and run demo   We are going to follow the steps to write image.  1 Write CMPA binary. pfr write -p COMxxx,115200 -t cmpa -f mcxn9xx -b cmpa_bin.bin   2 Write CFPA binary. pfr write -p COM140,115200 -t cfpa -f mcxn9xx -b cfpa_bin.bin   3 Provide FlexSPI flash memory configuration blhost  -t 2000 -p COMxxx,115200 -- fill-memory 0x20000000 0x04 0xc0000405   4 Configure and fill memory. blhost  -t 2000 -p COMxxx,115200 -- configure-memory 0x09 0x20000000 blhost  -t 2000 -p COMxxx,115200 -- fill-memory 0x20003000 0x04 0xf000000f   5 Erase flash blhost  -t 2000 -p COMxxx,115200 -- flash-erase-region 0x80000000 0x100000   6 Configure memory. blhost  -t 2000 -p COMxxx,115200 -- configure-memory 0x09 0x20003000    7 Write image. blhost  -t 2000 -p COMxxx,115200 write-memory 0x80001000 frdmmcxn947_led_blinky.bin   8 Reset. blhost  -t 2000 -p COMxxx,115200 reset You might use this command or directly press the reset button from the FRDM board. The below image shows the successful execution of each command. Your FRDM-MCXN947  should be blinking by now. Figure 20 Successful image write and reset. Once the board is reset you will notice that the loaded example will begin to execute.    Double-check execution from external flash    To double-check that the image is executing from the external flash you can use the disassembly view from MCUXpresso. 1  Attach the debugger to the running target and place a breakpoint at any part of the code.   Figure 21 Attach debugger to a running target. Once your debug probe is discovered, click “OK.”   Halt the processor execution. Use the debug button.   Figure 22 halt execution. Reset processor. Use the “Restart button”. The program should be stop at the first line of the main function.   Figure 23 Breakpoint at main. Find and open the disassembly view. Click on “Instruction Stepping Mode” button or search for disassembly. Any option will open the MCUXpresso “Disassembly” view.   Figure 24 Open "Disassembly" view Processor must be running at 0x8000_0000 address space. On the disassembly view you can check that the instructions are executed from address on the range of 0x8000_xxxx which is assigned for external flash.   Figure 25 Running code from external flash. If you want to return the device to run from internal memory, then you need to go back to default values. If there are no modifications, to the ones shown in this document,  to the CMPA and CMPA areas, the nxpdebugmbox command can be executed.      

Ⅰ、Introduction MCXA153 supports Read Out Protection (ROP) to protect code from reading from the device internal flash. This read out protection is a mechanism that allows user to enable different levels of protection in the system. This article explains in detail the configuration of the four ROP levels as well as the relationships between the different levels and the corresponding life cycles. Ⅱ、Four levels of Read Out Protection (ROP) The ROP is controlled by ROP_STATE bits, It is a 32-bit field stored in IFR0. It can be programmed by customer. Below is an introduction to the four ROP levels： 1.ROP_LEVEL0 ROP_STATE = 0xFFFF_FFFF (erased FLASH value), No ROP. Default for blank state. 2.ROP_LEVEL1 ROP_STATE = 0x0000_0003 Debug is disabled and unlocked, however it can be modified by customer, only limited debug mailbox commands are available. 3 .ROP_LEVEL2 ROP_STATE = 0x0000_0001 Debug is disabled and locked, it cannot be modified by customer, only limited debug mailbox commands are available. 4.ROP_LEVEL3 ROP_STATE = 0x0000_0000 Debug is disabled and locked, it cannot be modified by customer, no debug mailbox commands are available NOTE：Anything else = ROP3-like behavior (Debug disabled/Locked, ISP disabled). When the ROP level is 0, we can change the ROP level to 1, 2, and 3 by modifying the value of ROP_STATE in IFR0.When the ROP level is 1 or 2, we can change the ROP level to 0 through the ISP or DM-AP command. ROP level 3 is a one-way trip, so be careful. Below is a diagram of the relationship between the four levels：   Ⅲ、Life cycle and ROP When the chip is delivered to the customer from NXP, the life cycle is “NXP Provisioned”, we can also call it “OEM Open”, ”OEM Field return”, “NXP Field Return”. Because at this point, the chip is completely blank, and ISP and debugging functions are allowed. Of course, the ROP level at this point is 0. In this lifecycle, customers can develop and debug. During customer production, customers can impose certain restrictions on ISP and debugging based on their needs through ROP. Customers can choose between ROP level 1 or ROP level 2. The lifecycle at this point is “OEM Closed”. In this lifecycle, when there are some quality issues, customers can use the ISP or DM-AP command to erase the entire chip, or use the DM-AP command “set FA” to transfer the chip life cycle to the initial state, and return it to NXP’s factory for analysis without storing any IP assets. In some scenarios, customers may need to completely disable ISP and debugging functions. In that case, customers can set the ROP level to 3, and the chip’s lifecycle is “OEM No Return”. Please note that at this point, even NXP cannot restore the chip. So once there are some CQC issues, our factory cannot conduct further analysis. Also, we can transfer the chip to a ‘Bricked’ state in any lifecycle. During “Bricked” lifecycle, the chip will not be booted and will become a brick. The following table shows the relationship between life cycle and ROP: Ⅳ. Impact of different ROP levels on SWD and ISP The supported SWD and ISP commands are different at different ROP levels. From ROP0 to ROP3, fewer commands are supported. The following figure shows the commands supported by SWD and ISP at different ROP Levels. ISP commands supported in ROP0-ROP3:   SWD DM-AP commands supported in ROP0-ROP3:   Ⅴ、Configure ROP with SEC tool We can configure ROP through the MCUXpresso Secure Provisioning( SEC) tool. The MCUXpresso Secure Provisioning Tool is a GUI-based application provided to simplify generation and provisioning of bootable executables on NXP MCU devices. Hardware requirements: FRDM-MCXA153 board、Type-C USB cable Software requirements: MCUXpresso Secure Provisioning (MCUXpresso Secure Provisioning v8_b240110 or later.) Configuration steps: Step1. Create a new workspace After opening the software, click File->New Workspace, select "MCX A14x/A15x" -> MCXA153 -> Click "create". Refer to the following figure: Step2. Connection with Target Processor Enter ISP mode：Press and hold SW3(ISP key) => Press and release SW1 (RESET key) => Release SW3 Go to your workspace and click “Target”->Connection, the Connection with Target Processor window is displayed. Here, we make Connection through UART and select port and baud rate. Refer to the following figure: We can click "Test connection" to check whether the connection is successful. If the connection is successful, the result will display "OK". We can also see the life cycle of the current board: OEM Open. Refer to the following figure: Step3.Select Life Cycle Settings ROP Click on the toolbar "OEM Open" According to the requirements, select the appropriate ROP, in this case ROP 2. NOTE: Use ROP 3 with caution. Refer to the following figure: Step4. Build image After completing the above operations, we need to load the .s19 or .hex file generated by MCUXpresso IDE into the Source executable image. After the file is loaded, the start address is automatically identified. If the start address is not 0x00000000, you cannot "built image". Then click on "built image". Refer to the following figure: After completing the built image, "SUCCECC: built image" will be displayed. Click "close". Refer to the following figure: Step5. Write image We can see that the required .bin file has been generated automatically in "write image", or we can import the corresponding .bin file we wrote by "import". The Image path file will be automatically loaded. Clicking "write image" will pop up to confirm, and then click "ok" to run the script automatically. After the file is successfully written, the message "SUCCESS: write image" is displayed. Refer to the following figure: Step6. Check When we complete the configuration of ROP 2, we can check the status of registers through "PFR configuration". The used registers cannot be read out and unknown is displayed, as shown in the following figure: Finally, by pressing the RESET key on the board to exit ISP mode. At this point, the board has entered ROP 2, debug is disabled. The method of entering other ROP levels is the same. So how do we get back to the other ROP levels? ROP 2 state debugging is disabled, even the IDE cannot operate, we can only use ISP command and SWD command to operate. The SEC tool integrates SWD bulk erase command to return to ROP 0. However, we can also use the Blhost software to use ISP command, enter the ISP mode, enter “blhost -p comxx -- flash-erase-all” and return to ROP 0. Next, we'll look at using the SWD bulk erase command. Click on the toolbar "Dbg": The Select Debug Probe window is displayed. Refer to the following figure: Select “Probe: ”and click “erase”. After the erase succeeds, the following message is displayed: Flash mass erase succeeded! So we've successfully returned to ROP 0. Ⅶ、Summary ROP function protects the security of the chip, users can set different levels of ROP according to the requirements of their own applications. Using MCUXpresso Secure Provisionin simplifies the ROP configuration process. Configuring different ROPs requires modifying the status bits of ROP_STAT and ROP_STAT_DP in CMPA. The SEC tool helps us automate this work through a GUI interface.                               

Ⅰ、Introduction The MCUXpresso Secure Provisioning Tool (SEC) tool is a GUI-based application provided to simplify generation and provisioning of bootable executables on NXP MCU platforms. The latest version of SEC v8 adds FCB configuration function to help users program image to external flash. The MCX N94x family is a typical product series of MCX. A controller with a flexible serial peripheral interface (FlexSPI) that supports external memory. The external flash has a large storage capacity, high flexibility. It is relatively independent of the replacement or upgrade of the main chip, and has high reliability and lifecycle. This article focuses on how to use SEC tools to configure and program MCXN947 external flash quickly and easily. Ⅱ、Configuration steps This article uses the FRDM-MCXN947 board as an example to configure FCB and download an external flash image. Hardware requirements: FRDM-MCXN947 board、Type-C USB cable Software requirements: MCUXpresso Secure Provisioning Tool | NXP Semiconductors Step1. Create new workspace  After opening the software, click File->New Workspace, select "MCX N94x/N54x" -> MCXN947 -> Click "create". Refer to the following figure: Step2. Connection with Target Processor Enter ISP mode：Press and hold SW3(ISP key) => Press and release SW1 (RESET key) => Release SW3 Go to your workspace and click “Target”->Connection, the Connection with Target Processor window is displayed. Here, we make Connection through UART and select port and baud rate. Refer to the following figure: We can click "Test connection" to check whether the connection is successful. If the connection is successful, the result will display "OK". Refer to the following figure: Step3. Boot memory configuration Next we need to configure FCB. Click on "Target"-> Boot Memory… ,The Boot memory configuration window is displayed. First we need to select the Boot memory type, this part allows selection of the boot memory type, and optionally instance. The selection contains all memory types but unsupported types are disabled. FlexSPI NOR flash can be configured in two ways: By using the flashloader/ROM based simple configuration in the Boot Memory Configuration dialog or By using the complete FCB (FCB binary), which can be prepared from the boot device configuration as well, or via MCUXpresso IDE by adding the FCB component into Peripheral Drivers in Peripherals tools, where the full configuration can be specified. Here we use a simple configuration, click "FlexSPI NOR-simplified", on this Predefined template, select W25Q64JW and click apply. Then, corresponding parameters on W25Q64JW will be automatically created on Boot memory configuration parameters. Normally, keep the default value. Refer to the following figure: We use "Test the configuration" to check whether the configuration is correct. After clicking "Test", the script will pop up to run automatically, and "SUCCESS" will be displayed after running. Refer to the following figure: Then click "convert to FCB" and the "convert to FCB" dialog box will pop up. Keep the default position of "FCB file path". Select "Apply the converted FCB as boot device configuration" and click "convert". The script automatically runs and generates "converted_fcb.bin". The FlexSPI NOR-complete FCB window is displayed. Refer to the following figure: The generated converted_fcb.bin file is automatically loaded to FCB file for runtime and FCB File for write. Click "Test" and "SUCCESS" will be displayed. Click "OK" to close the window. Refer to the following figure: Step4. Build image After completing the above operations, we need to load the .s19 or .hex file generated by MCUXpresso IDE into the Source executable image. Note: The start address of the external flash of the project needs to be changed to 0x80001000. This section does not explain how to change the start address. For details, see “How to config booting from external flash”. After the file is loaded, the start address is automatically identified. If the start address is not 0x80001000, you cannot "built image". Then click on "built image". Refer to the following figure: After completing the built image, "SUCCECC: built image" will be displayed. Click "close". Refer to the following figure: Step5. Write image We can see that the required .bin file has been generated automatically in "write image", or we can import the corresponding .bin file we wrote by "import". The Image path file will be automatically loaded. Click "write image" to run the script automatically. After the file is successfully written, "SUCCESS: write image" is displayed. Refer to the following figure: Finally, by pressing the RESET key on the board to exit ISP mode, we completed the configuration and downloaded the external flash image. Ⅲ、Summarize We use SEC Tool to configure FCB and download external flash images via GUI. This is just a simple method, and users can choose different ways according to their requirements.

Device manufacturers spend months or years developing application software for their end products, which is one of the most valuable assets.   During the software development phase, the engineering teams use development platforms with easy access to critical electronics development components, but this is no longer the case when the projects move to the manufacturing phase. Once the project is ready to go to manufacturing the exposure of the electronics components changes drastically from a development environment. In Most cases the programming connector is not accessible because PCB now resides inside an assembled enclosure or has been removed to reduce PCB cost or very important, for security reasons. On Any case you still need to download manufacture testing FW or final product firmware to the microcontrollers in the system and to help with that NXP MCX microcontrollers have embedded tools called the In-system programming to assist with the FW provisioning. In-System programming (ISP) is a method of erasing and programing the on-chip FLASH or RAM memory using a ROM bootloader firmware without using an external Debug tool. NXP MCX Microcontroller family have ISP support over several serial peripherals like: UART SPI I2C USB High-Speed USB Full-Speed CAN Depending on the MCX microcontroller you are using the ISP supported peripherals will change so it is important to review the “In-system Programming” reference manual chapter on the specific MCX microcontroller that will be used. One important thing to remark is that the ISP firmware resides inside a ROM section on the MCX microcontrollers, meaning that the entire flash of the device can be used for the main application without the need of reserving on-chip FLASH for a firmware provisioning bootloader. The flash bootloader code is executed automatically every time the part is powered on or reset. The bootloader can execute the ISP command handler or pass execution to the user application code depending on several conditions. When the internal flash in empty the MCX microcontroller automatically enters ISP mode. Translating this to the manufacturing, Microcontrollers are ready to get firmware using ISP after the PCB assembly process. In-circuit programming features can be tested using any FRDM or EVK boards available for MCX family. You can find instructions of how to use the ISP mode alongside many other MCX examples, demos and tools directly on NXP Application Code Hub   Here are some Application Code Hub for ISP on MCX FRDM boards: How to use In-System Programming (ISP) on FRDM-MCXN947 How to use In-System Programming (ISP) on FRDM-MCXA153   Security is at the core of NXP. Not only do we want each element of our devices or software to be safe and secure, but it is just as critical that we enable the manufacturing of each customer's product to be secure. Manufacturing processes should be worry-free and hassle-free with the backing of highly secure technology, even if the manufacturing site itself cannot provide strong assurances of security. NXP is offers a variety of features that enable OEMs to protect their IP and revenue. Utilizing our MCUXpresso Secure Provisioning tool (SEC) and Secure Provisioning SDK (SPSDK)   MCXpresso Secure Provisioning tool (SEC) The MCUXpresso Secure Provisioning tool (SEC) is a GUI-based application that provides firmware provisioning operations such as setting up e-fuses/OTP, building secure boot image, flash programming, keys generation, trust provisioning, etc.   NXP SEC tool features: Easy-to-use configuration of secure provisioning project settings Enables direct communication with attached device for provisioning and programming. Supports generation of executable scripts for production use Manufacturing mode for simplified production line use     Secure Provisioning SDK (SPSDK) Secure Provisioning SDK (SPSDK) is an open-source development kit with its source code released on Github and PyPI. It contains a set of API modules for custom production tool development which requires more advanced secure provisioning flow. SPSDK enables connection and communication with NXP’s microcontrollers for the following purposes:   Generation of Secure Binary (SB) bootable images Security features configuration (CMPA, CFPA, Trustzone, secure bootloader, debug authentication, etc.) Generation and management of cryptographic keys and certificates Trust provisioning and secure programming through MCU Bootloader Debug authentication through J-Link, PEmicro and PyOCD debug probes   For more information about NXP development ecosystem for microcontrollers please visit: MCUXpresso Suite of Software and Tools https://nxp.com/mcuxpresso  

FRDM-MCXA153 FRDM-MCXN947    Hardware & Software To do this, surely you have to download the next software. MCU Link JTAG/SWD Debug Probe | NXP Semiconductors MCUXpresso IDE for NXP MCUs | Linux, Windows and MacOS | NXP Semiconductors | NXP Semiconductors About the hardware. FRDM-MCXN947 FRDM-MCXA153 MCU Link Firmware update. We will need the firmware to update the LPC55s69 on the board, the MCU Link firmware version 2.263 is compatible with the MCX. You may need the EVK connected to the computer under DFU mode, in the schematic of the EVK does not mention the DFU but has the named jumper of ISP [JP21] MCX - N or [JP8] MCX - A, sure you put the LPC55s69 in ISP, not the MCX, review the schematic below. MCX - N MCX - A When you have installed this version on your computer, go to the locations. ROOT: C:\nxp\MCU-LINK_installer_2.263\scripts Then open the CMD prompt console and run the script for CMSIS. The console asks if you have the appropriate jumper, if yes click enter again. If everything is right the message successfully will appear. Then in the MCUXpresso, you can see the debugger probe. Happy Debugging.