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 The MCX N has a Programmable Logic Unit (PLU) capable of creating combinational and sequential logic circuits that operate independently of the cores. The PLU does this by preprogramming look up tables or LUTs that dictate the behavior of designated outputs for all inputs of the PLU. The features of the MCX N PLU module includes: An array of 26 inter-connectable, 5-input look-up table (LUT) elements. 4 flip-flops. Six primary inputs pins. Eight primary output pins. An external clock to drive the four flip-flops if a sequential network is implemented. Capability to generate interrupts and wakeup requests from Sleep and Deep Sleep modes.   Module architecture The PLU is composed of 3 main elements: Look Up Tables (LUTs), Multiplexers and Flip Flops. Look Up Tables are used to create the actual logic of the PLU’s network, while multiplexers route these logic signals to and from other LUTs, as well as the PLU’s input and output pins. Flip Flops provide a method of gating logic signals from LUT elements to a shared clock input, adding a mechanism of synchronization and delay to the logic network.   Look Up Table (LUT) The PLU module has 26 inter-connectable Look Up Tables (LUTs), which can implement any combinational function with up to five inputs at once. The LUTs work by storing a pre-programmed output for every combination of inputs. This allows the look up tables to reproduce a specific output of logical 0 or 1 as soon as the input is changed without any processing required. By interconnecting LUT elements with one another, more complex programmable networks can be achieved, providing functionality of many logic gates at once.   Multiplexers The PLU module includes a variety of multiplexers that select the inputs and outputs for each Look Up Table (LUT) element. Each LUT element has 5 input multiplexers that route a signal to each of its 5 inputs. The available input signals for each LUT include: PLU Input pads. Other LUT element outputs. State Flip Flop outputs.   The PLU also has one output multiplexer for each PLU output pad (eight in total) that selects what Look-Up Table or Flip Flop state will drive each output pad.   Flip Flops The final PLU element is a type D flip flop that allows for retention of data, providing the means for sequential logic circuits and simple state machines.   The PLU module has 4 flip flops that are connected to the outputs of LUTs[3:0] as well as the external PLU_CLKIN signal that is used for timing and synchronization between flip flops. In order to use the flip flop elements, a clock signal must be supplied via the PLU_CLKIN pad. Note that since the flip flops are directly connected to the outputs of the first 4 LUT elements, the corresponding LUT elements must be set up in order to use each Flip Flop element.     PLU Setup The following steps must be done in order to achieve a logic network on the PLU module: Enable clocks for the PLU using the SYSCON_SYSAHBCLKCTRLx register and then toggle the PLU Reset bit from the SYSCON_PRESETCTRLx register. Assign pins using the PORTx_PCRn registers. Create logic network using the following steps: Write the logic behavior in the truth table register for each of the LUT elements that will be used. Program the input multiplexer registers to select the source of up to five inputs presented to each LUT. Program the output multiplexer register to select up to eight primary outputs from the PLU module. (Optional) Set the wakeup behavior by using the WAKEINT_CTRL register to select the outputs to be used as wakeup sources, as well as setting a deglitching method.   Creating logic networks Basic logic gates With a simple configuration of two inputs and one output on a single LUT element, all of the basic logic gates can be achieved. This would be achieved, for example, using a configuration of PLU_IN0 and PLU_IN1 pads as inputs and PLU_OUT0 pad as output for LUT0.   The first step of creating any logic network is to understand the truth table of the desired logic circuit. For a single AND gate using the previous configuration, the truth table would equate to the following: #   PLU_IN1 PLU_IN0 PLU_OUT0 0   0 0 0 1   0 1 0 2   1 0 0 3   1 1 1   The LUT would have to be set up in a way were the output is HIGH only when PLU_IN1 and PLU_IN0 are both HIGH, which is coincidentally the third combination of the LUT inputs for the previous truth table. Therefore, we need to program the LUT to output HIGH for combination #3. We can program this logic gate by writing a '1' on bit number 3 of the LUT’s truth table register. This way, when both LUT0 inputs are HIGH, the LUT element will “look up and find” a ‘1’, so it will output HIGH. On the other hand, for every other combination it will find a ‘0’ and output LOW. Combination # (Input) Truth table register (Output) 0 (0b00) 0 1 (0b01) 0 2 (0b10) 0 3 (0b11) 1   Taking this into account, it is easy to see that all the LUT element does is "look up" each combination of inputs on a predefined table to know what logic to output. This table is programmed via the 32 bit LUTa_TRUTH register for each LUT element. The 32 bit value required for the previous logic gate expressed in hexadecimal would then be as follows: AND gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 1 0 0 0 → 0x00000008 And, for the rest of the basic logic gates: OR gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 1 1 1 0 → 0x0000000E   XOR gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 0 1 1 0 → 0x00000006   NAND gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 0 1 1 1 → 0x00000007   NOR gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 0 0 0 1 → 0x00000001   XNOR gate LUT inputs[1:0] 11 10 01 00     LUT0_TRUTH 1 0 0 1 → 0x00000009   NOT gate LUT inputs[0] 1 0     LUT0_TRUTH 0 1 → 0x00000001   Buffer gate LUT inputs[0] 1 0     LUT0_TRUTH 1 0 → 0x00000002   Note that the truth table value for a NOR gate and a NOT gate is the same in this case, as both require an output of ‘1’ for the first combination of inputs and ‘0’ for the rest. This demonstrates how the PLU does not actually create an array of logic gates but rather, simply outputs predefined values from a table of all possible combinations of inputs. The previous tables show the register values to achieve all of the basic logic gates with the previous setup of LUT0. However, in order to achieve this configuration with input pins PLU_IN0 and PLU_IN1 as well as output pin PLU_OUT0, the multiplexers would have to be set up in the following manner:   In order to achieve this, pin PLU_IN0 must be routed as input[0] of LUT0 and PLU_IN1 as input[1] of LUT0. Additionally, the output of LUT0 will be routed to the PLU_OUT0 pad. This configuration to set up both input sources, route the output source and write the truth table register to result in an AND gate can be achieved with the following code:   /* Select input pin PLU_IN0 as LUT Input 0 (Input MUX0) for LUT0 on module PLU0 */ PLU_SetLutInputSource(PLU0, kPLU_LUT_0, kPLU_LUT_IN_0, kPLU_LUT_IN_SRC_PLU_IN_0); /* Select input pin PLU_IN1 as LUT Input 1 (Input MUX1) for LUT0 on module PLU0 */ PLU_SetLutInputSource(PLU0, kPLU_LUT_0, kPLU_LUT_IN_1, kPLU_LUT_IN_SRC_PLU_IN_1); /* Set Truth Table 0x08 for LUT element 0 on module PLU0 */ PLU_SetLutTruthTable(PLU0, kPLU_LUT_0, 0x08); // This will result in an AND gate /* Select LUT0 output as driver for PLU_OUT0 pin on module PLU0 */ PLU_SetOutputSource(PLU0, kPLU_OUTPUT_0, kPLU_OUT_SRC_LUT_0);   Conclusion The PLU module of the MCX N is modest when it comes to the complexity of the inner components as it is only made up from a series of look-up tables, multiplexers and flip flops. In spite of that, more elaborate and powerful logic networks can be achieved from those basic elements, providing on-chip solutions to many essential digital circuits and avoiding the need of external components for these digital applications. Not only that, but its interruption and wake up capabilities also enable the PLU to be a simple but effective addition to many low power applications. The PLU’s flexibility and built-in features enable this module to be a very effective addition to the MCX N series of MCUs that should not be overlooked. More information as well as example codes for combinational, sequential, and low-power applications can be found on the full article on Application Code Hub.

The Serial Peripheral Interface (SPI) is ubiquitous in embedded systems for interfacing to external peripherals such flash memories, EEPROMs, analog to digital converters and sensors. SPI controllers are essentially shift registers. When combined with DMA, SPI can be used for interesting use cases. In this paper we will look at an LED lighting application and hint at some other interesting use cases such as PDM audio streams.

The NXP MCXA153 is a useful microcontroller for small, embedded USB devices. Combined with the USB stack built into the SDK, or with the open source TinyUSB stack,  it is easy to creak your own USB protocol bridges and test tools. In this paper we showed to how to integrate TinyUSB into an MCUXpresso project and demonstrated  with a USB CDC / WebUSB application for a BLDC Motor controller test application.

When deploying a custom built model to replace the default models in MCUXpresso SDK examples, there are several modifications that need to be made as described in the eIQ Neutron NPU hands-on labs. Here are some common issues and error messages that you might encounter when using a new custom model with the SDK examples and how to solve them. If there is an issue not covered here, then please make a new thread to discuss that issue.    “Didn't find op for builtin opcode ‘<operator_name>’” Need to add that operator to MODEL_GetOpsResolver function found in source\model\model_name_ops_npu.cpp A full list of operators used by a model that can be copy-and-pasted into that file is automatically generated by Neutron Converter Tool with the dump-header-file option. Make sure to also increase the size of the static array s_microOpResolver to match the number of operators   “resolver size is too small” Need to increase the size of the static array s_microOpResolver in MODEL_GetOpsResolver function found in source\model\model_name_ops_npu.cpp to match the number of operators     “Failed to resize buffer” The scratch memory buffer is too small for the model and needs to be increased. The size of the memory buffer is set with the kTensorArenaSize variable found in the model data header file   “Internal Neutron NPU driver error 281b in model prepare!” or “Incompatible Neutron NPU microcode and driver versions!” Ensure the version of the eIQ Neutron Converter Tool used to convert the model is the correct one that is compatible with the NPU libraries used by the SDK project.  eIQ Toolkit v1.10.0 should be used with MCXUpresso SDK for MCX N 2.14.0. The Neutron Converter Tool version is 1.2.0+0X84d37e1f     Camera colors are incorrect on FRDM-MCXN947 board Modify solder jumpers SJ16, SJ26, and SJ27 on the back of board to move them to the left (dashed line side) to connect camera signals properly.             This modification will disable Ethernet functionality on the board due to a signal conflict with EZH D0 and ENET_TXCLK. If your project needs both camera and Ethernet functionality, then only move SJ16 and SJ26 to the left (dashed line side) and then connect a wire from P1_4 (J9 pin 😎 to the left side of R58. Then in the pin_mux.c file in the project, instead of using PORT1_PCR4 for EZH_Camera_D0, use PORT3_PCR0.                           

Ⅰ、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  

1. Overview The MCXN947 chip is a highly integrated microcontroller featuring robust processing capabilities, extensive peripheral support, and advanced security features. It is suitable for a wide range of complex applications. The NXP FRDM-MCXN947 board is a low-cost design and evaluation board based on the MCXN947 device. NXP provides a comprehensive set of tools and software support for the MCXN947, including hardware evaluation boards, an integrated development environment (IDE), example applications, and drivers. Micro-ROS is an embedded version of ROS 2 specifically designed to operate on embedded systems, enabling real-time control and communication for robotics and embedded devices. It extends the powerful features of ROS 2 to resource-constrained embedded platforms like microcontrollers and embedded systems. The introduction of Micro-ROS facilitates tighter integration between embedded systems and the ROS 2 ecosystem, enabling advanced robotic automation and control. This document explores the process of porting Micro-ROS to the MCXN947 board.‌   This document explores the process of porting Micro-ROS to the MCXN947 board. Hardware Environment：     FRDM-MCXN947 Software Environment:     Ubuntu 22.04     IDE：MCUXpresso IDE v11.9.0     SDK：SDK Builder | MCUXpresso SDK Builder (nxp.com) 2. ROS 2 Architecture Before delving into the Micro-ROS porting process, let us briefly introduce the new ROS 2 architecture. This is necessary because Micro-ROS heavily leverages ROS 2's abstraction layer source code in its design and implementation. Compared to its predecessor ROS 1, ROS 2 employs a distinct communication mechanism, most notably adopting the DDS (Data Distribution Service) protocol for communication and node discovery. ROS 1, by contrast, relies on the XML-RPC protocol and requires the master node to launch before other nodes can join. ROS 1's limited support for embedded devices stems from the XML-RPC mechanism, which introduces significant software dependencies in these environments. To address this issue, projects like rosserial developed lightweight communication protocols tailored for MCU-to-PC master node communication. ROS 2, on the other hand, integrates the industry-proven DDS protocol, which has demonstrated its stability in domains like military, aerospace, and financial systems. It is important to note that DDS is a standard protocol with various implementations, such as Cyclone DDS (Eclipse), Fast DDS, and Micro XRCE-DDS (eProsima). To ensure that upper-layer ROS 2 code remains unaffected by different DDS implementations, ROS 2 defines a series of abstract layer interfaces, such as RCL (ROS Client Library) and RMW (ROS Middleware). These DDS implementations provide a uniform RMW interface. On top of RMW is the RCL, implemented in C, which supports various programming languages, including C++, Python, and Java. Thus, successfully porting ROS 2 to a real-time operating system (RTOS) hinges on the RTOS supporting a specific DDS implementation and its corresponding RMW interface. Only then can upper-layer RCL and ROS application code run without modification. ROS 2 comprises RCL (ROS Client Library), RMW (ROS Middleware Interface), and DDS (Data Distribution Service). Porting ROS 2 to a new platform essentially involves creating a compatible RMW-DDS combination, leaving the RCL layer unaltered. Micro-ROS provides such an RMW-DDS combination. Specifically, Micro-ROS employs Micro XRCE-DDS (a DDS standard designed for extremely resource-constrained environments) with a corresponding RMW implementation. This enables Micro-ROS to be compatible with ROS 2's architecture while efficiently running on resource-limited embedded devices. Thus, porting Micro-ROS to different hardware platforms fundamentally involves interfacing communication protocols like UART (Universal Asynchronous Receiver-Transmitter) and UDP (User Datagram Protocol) with the Micro-ROS RMW-DDS combination. This process ensures effective communication between Micro-ROS and other nodes or external systems while maintaining the lightweight and efficient characteristics suitable for embedded devices. From the above introduction, we can see that MicroROS transplantation mainly has two parts: Connect UART/UDP communication and clock to implement the 5 functions in default_transport.cpp. Folder DDS+RMW+RCL generates libmicroros.a static library. 3. Micro-ROS Static Library Toolchain and Environment Configuration 3.1 Micro-ROS Static Library Toolchain and Environment Configuration First, install ROS 2 on Ubuntu 22.04 LTS and run the following commands: sudo apt update&&sudo apt install locales sudo locale-gen en_US en_US.UTF-8 sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 export LANG=en_US.UTF-8 sudo apt update && sudo apt install curl gnupg lsb-release sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg (1) sudo apt update: Updates the system’s package list to fetch the latest package information. (2) sudo apt install locales: Installs the locales package, which provides tools for managing and configuring localization. (3) sudo locale-gen en_US en_US.UTF-8: Generates the localization settings for US English, including UTF-8 encoding. (4) sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8: Updates the system’s localization settings to use UTF-8 encoding for US English. (5) export LANG=en_US.UTF-8: Sets the current terminal’s language encoding to US English UTF-8. (6) sudo apt install curl gnupg lsb-release: Installs additional tools (curl for network requests, gnupg for encryption, lsb-release for distribution information). (7) sudo curl: Downloads the ROS public key for verifying package integrity.   3.2 Installing ROS on Ubuntu Set up and build the Micro-ROS development environment with the following commands: sudo apt update && sudo apt upgrade && sudo apt install ros-humble-desktop source /opt/ros/humble/setup.bash && echo “source /opt/ros/humble/setup.bash” >>~/.bashrc source /opt/ros/$ROS_DISTRO/setup.bash mkdir uros_ws && cd uros_ws git clone -b iron https://github.com/micro-ROS/micro_ros_setup.git src/micro_ros_setup rosdep update && rosdep install --from-paths src --ignore-src -y colcon build source install/local_setup.bash ros2 run micro_ros_setup create_firmware_ws.sh generate_lib (1) Update the software and install ROS (Robot Operating System) (2) Set and save the configuration of the ROS environment. (3) These two commands create a new directory uros_ws (workspace), and then switch to this directory. (4) Clone the project named micro_ros_setup from the GitHub repository and place it in the src directory of the workspace. (5) These two commands are used to install the dependencies required by the project. (6) This command uses the colcon build system to compile and install the project. Colcon is a general-purpose build tool suitable for multiple programming languages and platforms. (7) create_firmware_ws.sh: This is the name of the executable file to be run. It might be a script that creates a firmware workspace. The purpose of this command is to run the create_firmware_ws.sh script in the micro_ros_setup package and pass the parameter generate_lib to generate a firmware workspace containing the Micro-ROS library. This step requires downloading a large amount of source code from github. After failure, the next generation will prompt that the firmware already exists and you need to rm this folder. If the following picture appears, it proves that the code download is successful. 4. Generating the Micro-ROS Static Library If the toolchain and environment setup are successful, you should have five folders in your workspace: build, firmware, install, log, and src. The firmware folder contains the Micro-ROS workspace. 4.1 Configure the toolchain.cmake file according to the target processor Enter the fireware directory. The colcon.meta and toolchain.cmake inside are the configuration files we need to specify to generate the static library. Colcon.meta describes the configuration of our micro-ros, and toolchain.cmake describes the microcontroller platform. We can open MCUXpresso to find MCXN947 related configuration. and create toolchain.cmake. set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_CROSSCOMPILING 1) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) # SET HERE THE PATH TO YOUR C99 AND C++ COMPILERS set(PIX /opt/gcc-arm-none-eabi-10.3-2021.10/bin) set(CMAKE_C_COMPILER ${PIX}/arm-none-eabi-gcc) set(CMAKE_CXX_COMPILER ${PIX}/arm-none-eabi-g++) set(CMAKE_C_COMPILER_WORKS 1 CACHE INTERNAL "") set(CMAKE_CXX_COMPILER_WORKS 1 CACHE INTERNAL "") # SET HERE YOUR BUILDING FLAGS set(FLAGS "-O2 -ffunction-sections -fdata-sections -fno-exceptions -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard -nostdlib -mthumb --param max-inline-insns-single=500 -D'RCUTILS_LOG_MIN_SEVERITY=RCUTILS_LOG_MIN_SEVERITY_NONE'" CACHE STRING "" FORCE) set(CMAKE_C_FLAGS_INIT "-std=c11 ${FLAGS} -DCLOCK_MONOTONIC=0 -D'__attribute__(x)='" CACHE STRING "" FORCE) set(CMAKE_CXX_FLAGS_INIT "-std=c++11 ${FLAGS} -fno-rtti -DCLOCK_MONOTONIC=0 -D'__attribute__(x)='" CACHE STRING "" FORCE) set(__BIG_ENDIAN__ 0) The above is how cmake is written. Among them, "-mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard": These options specify the architecture and floating point unit characteristics of the target processor. We can view the architecture and floating point unit characteristics of the MCXN947's target processor. We can open MCUXpresso IDE, open a MCXN947 project, and check mcpu=cortex-m33 -mfpu=fpv5-sp-d16 mfloat-abi=hard in All options in settings->MCU Linker. Therefore, the MCXN947 series is an M33 core. We need to change -mcpu=cortex-m7 to -mcpu=cortex-m33, and basically no other changes are needed. From this we can also see that a series of static libraries produced should be universal! 4.2 Configure the colcon.meta file according to Micro-ROS requirements The other file created sets the Micro-ROS library configurations. To set the transport layer type, here we want a custom transport layer, the configuration “-DUCLIENT_PROFILE_CUSTOM_TRANSPORT=ON” is set to “ON” and the configuration “-DRMW_UXRCE_TRANSPORT=custom” is set to “custom”. The other interesting settings are under the “rmw_microxrcedds” section. Here we can set the maximum number of nodes (1), publisher (5), subscribers (5), services (1) and clients (1) that should be supported, as well as the maximum message history (4) used for a reliable QoC mode. A more detailed description of all settings under this section, can be found in the eProsima Micro XRCE-DDS GitHub. An example configuration, the one I used, is shown below: touch colcon.meta { "names": { "tracetools": { "cmake-args": [ "-DTRACETOOLS_DISABLED=ON", "-DTRACETOOLS_STATUS_CHECKING_TOOL=OFF" ] }, "rosidl_typesupport": { "cmake-args": [ "-DROSIDL_TYPESUPPORT_SINGLE_TYPESUPPORT=ON" ] }, "rcl": { "cmake-args": [ "-DBUILD_TESTING=OFF", "-DRCL_COMMAND_LINE_ENABLED=OFF", "-DRCL_LOGGING_ENABLED=OFF" ] }, "rcutils": { "cmake-args": [ "-DENABLE_TESTING=OFF", "-DRCUTILS_NO_FILESYSTEM=ON", "-DRCUTILS_NO_THREAD_SUPPORT=ON", "-DRCUTILS_NO_64_ATOMIC=ON", "-DRCUTILS_AVOID_DYNAMIC_ALLOCATION=ON" ] }, "microxrcedds_client": { "cmake-args": [ "-DUCLIENT_PIC=OFF", "-DUCLIENT_PROFILE_UDP=OFF", "-DUCLIENT_PROFILE_TCP=OFF", "-DUCLIENT_PROFILE_DISCOVERY=OFF", "-DUCLIENT_PROFILE_SERIAL=OFF", "-UCLIENT_PROFILE_STREAM_FRAMING=ON", "-DUCLIENT_PROFILE_CUSTOM_TRANSPORT=ON", "-DUCLIENT_PROFILE_SHARED_MEMORY=ON", "-DUCLIENT_SHARED_MEMORY_MAX_ENTITIES=20" ] }, "rmw_microxrcedds": { "cmake-args": [ "-DRMW_UXRCE_MAX_NODES=5", "-DRMW_UXRCE_MAX_PUBLISHERS=6", "-DRMW_UXRCE_MAX_SUBSCRIPTIONS=4", "-DRMW_UXRCE_MAX_SERVICES=6", "-DRMW_UXRCE_MAX_CLIENTS=1", "-DRMW_UXRCE_MAX_HISTORY=4", "-DRMW_UXRCE_TRANSPORT=custom" ] } } } 4.3 Building the Micro-ROS Static Library Run the following commands: source install/local_setup.bash ros2 run micro_ros_setup build_firmware.sh $(pwd)/firmware/toolchain.cmake $(pwd)/firmware/colcon.meta If the static library is successfully generated, you will see libmicroros.a in the firmware/build file. 5. Integrating and Testing the Static Library Locally 5.1 Adding the Generated Micro-ros Static Library to the Local Project   (1) Create a folder named bsp_include. (2) Add all files from the include directory into your project under bsp_include. (3) Add all paths in the include file to the include path. (4) Add the generated libmicroros.a static library to the project, for example, add it to bsp_include.   (5) Add the libmicrorots.a static library and name path to Libraries(-l) and Library search path(-L). 5.2  Implementing the Serial Communication Interface Functions To port Micro-ROS to an MCU, you must provide transport layer functionalities for reading and writing through the communication interface. The required transport functions are defined as follows: rmw_ret_t rmw_uros_set_custom_transport( bool framing, void * args, open_custom_func open_cb, close_custom_func close_cb, write_custom_func write_cb, read_custom_func read_cb); ​ Through this structure, we can see that the communication interface function group mainly includes open, close, write, and read. open: This function is responsible for initializing (opening) peripheral devices used by the transport layer. This function is empty if the peripheral is initialized elsewhere and before the Micro-ROS function is called. close: This function is responsible for deinitializing (turning off) peripherals used by the transport layer. Because there is no need to deinitialize the function. This function is also empty. write: This function is responsible for writing data (bytes) on the peripheral device. The number of bytes to be written and the bytes themselves are given as parameters "len" and "buf" respectively. read: This function is responsible for reading data (bytes) from the peripheral device. The number of bytes to read is specified in the function parameter "len" and bytes should be returned via the function parameter "buf". bool transport_close(struct uxrCustomTransport * transport) { return true; } bool transport_open(struct uxrCustomTransport * transport) { return true; } size_t transport_write(struct uxrCustomTransport* transport, const uint8_t * buf, size_t len, uint8_t * err) { LPUART_WriteBlocking(DEMO_LPUART, buf, len); return len; } size_t transport_read(struct uxrCustomTransport* transport, uint8_t* buf, size_t len, int timeout, uint8_t* err) { LPUART_ReadBlocking(DEMO_LPUART, buf, len); return len; } Additionally, you need to implement a function to provide the system’s clock time. This clock does not have to provide real-time or world time, but rather elapsed time since startup or similar. For example: int clock_gettime(clock_t unused, struct timespec *tp) { (void)unused; IRTC_GetDatetime(RTC, &datetimeGet); tp->tv_sec = datetimeGet.second; tp->tv_nsec = (long)(datetimeGet.second) * 1000000; return 0; } 5.3 Testing To run Micro-ROS in practice, the setup includes two components: 1. A client running on the MCU. 2. An agent running on the host PC. Basic Micro-ROS Client (MCU) Below are the minimal steps and code needed to create and run a Micro-ROS client. These instructions are based on the Micro-ROS documentation for node creation. //Required global variables rcl_allocator_t allocator; rclc_support_t support; rcl_node_t node; rclc_executor_t executor; rmw_ret_t error; //Set Communication functions rmw_uros_set_custom_transport( true, NULL, rtt_transport_open, rtt_transport_close, rtt_transport_write, rtt_transport_read ); //Set Allocation functions (Optional) rcl_allocator_t allocator = rcutils_get_zero_initialized_allocator(); allocator.allocate = rtt_allocate; allocator.deallocate = rtt_deallocate; allocator.reallocate = rtt_reallocate; allocator.zero_allocate = rtt_zero_allocate; (void)!rcutils_set_default_allocator(&allocator); //Get allocator allocator = rcl_get_default_allocator(); //Create init_options error = rclc_support_init(&support, 0, NULL, &allocator); //Create node error = rclc_node_init_default(&node, "uROS_Terminal", "", &support); //Create executor error = rclc_executor_init(&executor, &support.context, 1, &allocator); //Call the executor periodically e.g. in the while(1) loop or a thread: while(1) { error = rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)); } ​ Setting up the Micro-ROS Agent (PC) The agent establishes an interface between the Micro-ROS client on the MCU and ROS 2 on the host PC. To set up the agent: # Go to the Micro-ROS workspace folder cd microros_ws # Source ROS 2 source /opt/ros/humble/setup.bash # Source local packages source install/local_setup.bash # Create Agent ros2 run micro_ros_setup create_agent_ws.sh # Build Agent ros2 run micro_ros_setup build_agent.sh # Possible ROS Update sudo rosdep init rosdep update  After successfully building the Micro ROS agent, the following bash command starts/runs the agent: # Go to the Micro-ROS workspace folder cd microros_ws # Source ROS 2 source /opt/ros/humble/setup.bash # Source local packages source install/local_setup.bash # Run Agent (serial connection) ros2 run micro_ros_agent micro_ros_agent serial --dev /dev/ttyACM0 Of these bash commands, the last one is the one that actually starts the Micro-ROS agent. It takes several parameters, the first is the type of connection to use, in this case a serial connection. Then there are two parameters that only apply to serial connections: "--dev/ttyACM0", which sets the serial interface to be used (to list all serial interfaces in linux, you can use the following bash command: "dmesg | grep tty".) After starting the Micro-ROS agent, the MCU can connect to the host PC via the serial interface and reset to establish a new connection. If the following Micro-ROS agent terminal output: This proves the success of transplanting Micro-Ros On Frdm-mcxm947.

In most cases, C project is generated and used. But assembly project has it’s own advantage, with assembly project, you can program with assembly language directly, can test assembly instruction with assembly mnemonic. Generally, C language is inefficient, so in order to test the performance of the core, or get peripheral highest performance, the assembly project is required. The doc discusses the procedure to create an assembly language project, in the end, gives an example to toggle a LED, which demos how to initialize the NVIC, CTimer, GPIO with assembly language. It also gives the example of subroutine.   1. The procedure to create an assembly language project based on MCUXPresso tools 1.1 Load MCUXPresso tools and drag SDK to the Installed SDK menu Then click “Create a new C/C++ project”   1.2 Select the board or processor, then clock “Next” software button   1.3 Name the project and Select the driver. In the menu, it is okay to use default configuration, then clock “Finish”   1.4 A New project called MCXN947_project is created with C language   1.5 Delete the MCXN947_project.c and add the main.s Click the “source” group with right mouse button, the click “New”->”source File”   1.6 Add the main.s as the following Fig and click “Finish”   1.7 The final project is like:   2.0 writing the assembly code in the main.s This is the code in main.s /* This assembly file uses GNU syntax */ .equ SYSCON_ANGCLKCTRLSET0,0x40000220 .equ SYSCON_AHBCLKCTRLSET1,0x40000224 .equ SYSCON_AHBCLKCTRLSET2,0x40000228 .equ SYSCON_CTIMER4CLKSEL, 0x4000027C .equ SYSCON_CTIMER4CLKDIV, 0x400003E0   /*PIO3_4 LED blue*/ .equ PORT3_PCR_BASE,0x40119000 .equ PORT3_PCR4,PORT3_PCR_BASE+0x90   .equ GPIO3_BASE,0x4009C000 .equ GPIO3_PDDR,GPIO3_BASE+0x54 .equ GPIO3_PDOR,GPIO3_BASE+0x40     /*PIT configuration*/ .equ CTIMER4_BASE,0x40010000 .equ CTIMER4_IR,CTIMER4_BASE+0x00 .equ CTIMER4_TCR,CTIMER4_BASE+0x04 .equ CTIMER4_MCR,CTIMER4_BASE+0x14 .equ CTIMER4_MR0,CTIMER4_BASE+0x18 .equ CTIMER4_MSR0,CTIMER4_BASE+0x78 .equ CTIMER4_PWMC,CTIMER4_BASE+0x74     /*NVIC configuration*/ /*refer to 4.2 Nested Vectored Interrupt Controller in Cortex-M4 Generic User's Guide.pdf*/ .equ NVIC_ISER0,0xE000E100 .equ NVIC_ISER1,0xE000E104   .equ NVIC_ICPR0,0xE000E284 .equ NVIC_ICPR1,0xE000E288   .equ NVIC_IPR12,0xE000E430 .equ NVIC_IPR14,0xE000E438           .global __user_mem_buffer1,__user_mem_buffer2     .text     .section   .rodata     .align  2     .LC0:       .text     .thumb     .align  2     .global main     .global CTIMER0_IRQHandler     .type main function   main:     push {r3, lr}     add r3, sp, #4     nop     BL peripheralInit     nop     nop     nop     nop     NOP     /*cpsie i*/ loop:     b loop     mov r3, #0     mov r0, r3     pop {r3, pc}     /*subroutine 1*/ /* copy 10 words from one place to another*/     .type MyFunc function     .func MyFunc:     push {r0,r1,r2,lr}     MOV R2,#0x00     LDR R0,=USER_MEM_BUFFER1     MOV R1,#0x00 loop1:     NOP     STR R1,[R0]     ADD R1,#0x10     ADD R0,#4     ADD R2,#1     CMP R2,#0x10     BNE loop1     AND R5,R1,R5 ;     ASR R3,R2,#1     ORR R5,R1,R5     ADD R3,R2,R3     ADC R3,R2,R3     AND R2,R1,R2 ; /*#0x0F*/     LDR R0,=0x1234     /*LDR R0, [R1], #4*/     nop     pop {r0,r1,r2,pc}     .endfunc /***************************************/   /*subroutine 2*/     .type peripheralInit function     .func peripheralInit:    //enable CTimer4 gated clock     LDR R0,=0x400000     LDR R1,=SYSCON_AHBCLKCTRLSET2     nop     STR R0, [R1]       MOV R0,#0x03 //select     LDR R1,=SYSCON_CTIMER4CLKSEL     nop     STR R0, [R1]         MOV R0,#0x09 //select     LDR R1,=SYSCON_CTIMER4CLKDIV     nop     STR R0, [R1]     /*setting CTimer0*/       //set Ctimer0_IR     MOV R3,#0x01     LDR R1,=CTIMER4_IR     Nop     LDR R2,[R1]     ORR R2,R2,R3     STR R2,[R1]     //set CTIMER4_MCR     MOV R3,#0x03     LDR R1,=CTIMER4_MCR     LDR R2,[R1]     ORR R2,R2,R3     STR R2,[R1]         LDR R0,=6000000     LDR R1,=CTIMER4_MR0     STR R0,[R1]       LDR R0,=6000000     LDR R1,=CTIMER4_MSR0     STR R0,[R1]         MOV R0,#00     LDR R1,=CTIMER4_PWMC     STR R0,[R1]       nop     nop //lop1: //  b lop1         /*setting interrupt, Ctimer4 IRQ 56*/     LDR R1,=NVIC_ISER1     LDR R0,[R1]     LDR R3,=0x01000000     ORR R0,R0,R3     STR R0,[R1]       LDR R1,=NVIC_ICPR1     LDR R0,[R1]     LDR R3,=0x01000000     ORR R0,R0,R3     STR R0,[R1]       MOV R0,#0x00     LDR R1,=NVIC_IPR14     STR R0,[R1]       /*pin mux setting*/     /*enable PORT3 and GPIO3 gated clock*/     LDR R0,=0x410000     LDR R1,=SYSCON_ANGCLKCTRLSET0     nop     STR R0, [R1]     /*set the GPIO3_4 as GPIO output mode*/     LDR R0,=#0x1000     LDR R1,=PORT3_PCR4     STR R0,[R1]         LDR R1,=GPIO3_PDDR     LDR R0,[R1]     LDR R3,=0x10     ORR R0,R0,R3     STR R0,[R1]       /*CTimer4 start*/     MOV R3,#0x01     LDR R1,=CTIMER4_TCR     LDR R0,[R1]     ORR R0, R0,R3     STR R0,[R1]     nop     nop     nop     /*cpsid i*/     BX LR     .endfunc /*********************************************/   /*subroutine 3*/     .text     .type testcal function     .func testCal:     LDR R0,=0x12345678     MOV R1,#0x0F     AND R0,R1     /*test saturation function*/     LDR R0,=0x8234     LDR R1,=0x8234     /*ADDS R5,R0,R1*/     QADD16 R6,R0,R1  /*saturation heppen, the R6 will become negative minumum 0x8000*/     nop     /***8888888*/       LDR R0,=0x6234     LDR R1,=0x6234     /*ADDS R5,R0,R1*/     SADD16 R6,R0,R1     nop     QADD16 R6,R0,R1 /*saturation heppen, the R6 will become negative minumum 0x7FFF*/     nop     SMUAD R6,R0,R1     BX LR     .endfunc /*********************************************/   /*interrupt service routine*/     .global CTIMER4_IRQHandler     .text     .align 2     .type CTIMER4_IRQHandler function     .func CTIMER4_IRQHandler:         /*clear interrupt*/     push {R0,R1,LR}     nop     nop     nop     LDR R1,=CTIMER4_IR     LDR R0,[R1] /*dummy reading*/     MOV R4,#0x10;     ORR R0,R0,R4     STR R0, [R1]     /*toggle a LED*/     LDR R1,=GPIO3_PDOR     LDR R0,[R1]     LDR R3,=0x10     EOR R0,R0,R3     STR R0,[R1]     NOP     POP {R0,R1,PC}     .endfunc     /******************************************************/ /*interrupt service routine*/     .global SVC_Handler     .text     .align 2     .type SVC_Handler function     .func SVC_Handler:     push {R0,R1,LR}            NOP     POP {R0,R1,PC} /******************************************************/       .align  2 .L3:     .word       .align 4     .section .contantData HELLO_TXT:     .space 0x100 Hello_END:     .ALIGN 4   /*.lcomm */   .lcomm USER_MEM_BUFFER1  0x100   .lcomm USER_MEM_BUFFER2  0x100     .end   3.0 code explanation   In the code, you have to define the main function, after the core has executed the code ResetISR(void), which is defined in startup_mcxn847_cm33_core0.c, it jump to main() function   The example code implement the function to initialize CTimer, GPIO and NVIC, SYSCON module so that the CTImer can generate interrupt, in the ISR of CTimer, a LED is toggled. After you run the code, you can see that the led is toggled. The peripheralInit Subroutine is used to initialize the CTimer, NVIC, GPIO, SYSCON module so that the CTimer can fire an interrupt and toggle a LED.The CTIMER4_IRQHandler is an ISR of CTimer4, which is defined in startup_mcxn847_cm33_core0.   The MyFunc function and testCal  Subroutines are just for testing a specific assembly instruction, and test how to establish and call a subroutines, they do not have a specific target.

Sometimes connecting things requires a lot of cables because the component you need alone doesn't have the correct connector to mount on an evaluation board.   A few weeks ago, we needed to connect this display Adafruit 1.54" 240x240 Wide Angle TFT LCD Display to some FRDM boards. We started using cables but ended up making a small card to mount the board and plug it directly into the PMOD port of the FRDM board.   We decided to make it available in case you have the same problem 😊   Adafruit 1.54" 240x240 Wide Angle TFT LCD Display PMOD Adapter Gerber files for fabrication are here Final Assembly   3D render     This is how it looks connected to a FRDM-RW612 board  enjoy!    

MCUXN947 Security Configuration (Secure Boot + Lifecycle)   1. Introduction This application note aims to guide developers on configuring Secure Boot and Lifecycle on the MCXN947 microcontroller. The goal is to ensure security during mass production, prevent code theft and tampering, and allow for secure firmware updates. By following this document, developers can better understand and implement best practices for secure boot and firmware updates. 2. Implementation Overview 2.1 Secure Boot (SB) Introduction The Secure Binary (SB) container brings secure and easy way to upload or update firmware in embedded device during either the manufacturing process or end-customer's device lifecycle. An SB file is a command-based firmware update image. The SB file can be considered a script (commands and data), with the ROM acting as the interpreter. The ROM supports version 3.1 of the SB image format. The SB container in version 3.1 (SB3.1) uses the latest cryptographic algorithms to ensure the authenticity and confidentiality of the carried firmware. The boot time and security level, which fit the best for the required use case, control the various available security configurations. The digital signature based on Elliptic Curve Cryptography (ECC) ensures the authenticity of the SB3.1 container. The use of the Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode ensures the confidentiality of the SB3.1 container. 2.2 Lifecycle Introduction The lifecycle state of a chip reflects its actual state and is used to guide how the chip protects its hosted assets at specific times. For example, when a project is completed, during mass production, or when the device is in use by the end customer, the chip's access permissions are much more restricted compared to the development stage. The MCXN947 microcontroller supports multiple secure lifecycle states. For detailed information, refer to the "Lifecycle States" chapter in the MCX Nx4x Security Reference Manual. Note that the lifecycle state is monotonic, meaning it can only increase, and access permissions become more restrictive. This document focuses on field configuration (In-field) to ensure security after deployment. 2.3 MCUXpresso Tool Introduction The MCUXpresso Security Configuration Tool is a GUI-based application that simplifies the generation and configuration of bootable executable files on NXP MCUs. This tool can be used to generate SB3.1 files and deploy MCU security configurations. 3. Implementation Steps 3.1 Preparation Software Two image files: frdmmcxn947_led_blinky_red.s19 and frdmmcxn947_led_blinky_green.s19 MCUXpresso Secure Provisioning Tool v9.0 (SPT Tool) Blhost Hardware FRDM-MCXN947 Development Board 2 USB Type-C Cables Computer 3.2 Steps 3.2.1 Restore MCU to Default Configuration Power on MCU with ISP Mode Hold the ISP key and power on the MCU (POR). This document uses the ISP-USB interface, so connect the USB cable to J11 (HS-USB) port. Configure CMPA and CFPA to Default State Open the SPT Tool, create a new workspace, and select the corresponding chip. Configure as follows:   Program CMPA and CFPA OK -> Build image, Write image, to burn the configured default CMPA and CFPA into the MCU. Erase Entire Flash Connect the board's debugging interface MCU-link via USB. Select the debug probe in the SPT Tool. After a successful connection, use Erase to erase the entire flash. The chip is restored to its default state with no enabled security configurations. 3.2.2 Configure Secure Boot and Lifecycle for Field Mode (In-field)  Generate Secure Boot Keys Select the PKI management interface -> Generate Keys... -> Generate   Configure Image File Open the "Build image" interface and configure as follows: Boot: Select Encrypted (PRINCE/IPED) and signed Source executable image: Select the application image file frdmmcxn947_led_blinky_green.s19 Start address: 0x00000000 Firmware version: 1 Authentication key: Choose any one of the 4 options CUST_MK_SK: Click Random to generate a random number OEM seed: Click Random to generate a random number   Configure CMPA and CFPA Open CMPA and CFPA, and configure to enable security: Generate Configuration Files and Image File After configuration, build the image to generate CMPA, CFPA configuration files, and the SB3-formatted image file.   3.2.3 Program Application Program Configuration Files and Image File Open the "Write image" window, click "Write image" to program the configuration files and the SB image file.   Verify Application Power on the board again, and you should see the green LED flashing, indicating that the application is running normally. Then, hold the ISP key and perform a software reset of the board (note that this must be a software reset for the CFPA lifecycle configuration to take effect; a power-on reset will not activate the CFPA configuration). If the development is complete and in the production stage, and OTP is used to manage the lifecycle, any reset will detect the OTP configuration. At this point, secure boot is enabled, and the lifecycle is configured for field mode. Therefore, the chip no longer supports SWD interface debugging or reading flash content via ISP. To update the flash program, only a valid SB3 file can be burned. 3.2.4 Update Application Create a New SB3 File Compile the SDK example frdmmcxn947_led_blinky to generate a .bin file or s19 file. For all supported formats by the SPT tool, refer to the SPT manual. Here, use the s19 file format frdmmcxn947_led_blinky_red.s19. Open the SPT tool and use the workspace created for the first application image file. This will import the necessary keys directly. Then, import frdmmcxn947_led_blinky_red.s19. The Image firmware version should be greater than 0. Since we have not configured Set minimal firmware version, the minimum version is 0. This involves the anti-rollback feature, which will be explained in detail later. After configuration, hold the ISP key and power on the board to restart. Then, build the image to generate frdmmcxn947_led_blinky_red.sb. Program the New SB3 File Use the blhost receive-sb-file command to burn the file: blhost.exe -u 0x1fc9 0x014f receive-sb-file frdmmcxn947_led_blinky_red.sb After burning, restart the MCU. The red LED flashing indicates that the firmware update was successful. 3.2.5 Verify Security Features After enabling secure boot and configuring the lifecycle for field mode, the MCU cannot read the flash via SWD or ISP, ensuring the security of the customer's code against theft and tampering. To test if the configuration is successful, you can use the SWD and ISP interfaces. You should find that the SWD interface cannot connect, and while the ISP interface can connect, it cannot read or write. Note that before testing, you need to hold the ISP key and perform a software reset (not a power-on reset).     4. Notes By following this document, developers can learn how to configure and manage the security lifecycle on the MCXN947 microcontroller, ensuring the security and reliability of the device at different stages. Following the steps in this document can effectively achieve secure boot and operation, as well as firmware updates.  

FRDM Boards Enclosures (3D Print)   Hi NXP FRDM enthusiasts! we want to share some 3D files that you can use to 3D print your own enclosures for the FRDM-MCX family!    FRDM-MCXN947 case step files are here   FRDM-MCXA153 case step files are here   FRDM-MCXW71 case step files are here

Using external PSRAM on the MCX N FlexSPI port can enable a large degree of application flexibility. In this paper we show how to add 8MB of Octal DDR PSRAM to the MCXN947 and execute baseline performance tests.

The open source hardware community is please to offer ECAD schematic symbols for the new MCX A153 and MCX N947 microcontrollers.     The MCX A153 schematic library has the QFP32, QFN48 and LQFP64 variants. The MCX N947 schematic library has the BGA184 and LQFP100 variants. The symbols were generated using data from the MCUXpresso Pin Config tool to ensure accuracy. The pin names include all pin mux options to make it easy to see all available peripheral functions and further simplify the symbol for your own design purpose The symbol data is provided in the open source KiCad V7 format and is attached to this post. The symbols can be imported into commercial tools such as Altium Designer. Enjoy!  

These lab guides provide step-by-step instructions on how to take a quantized TensorFlow Lite model and use the Neutron Conversion Tool found in eIQ Toolkit to convert the model to run on the eIQ Neutron NPU found on MCX N devices.  The eIQ Neutron NPU for MCUs Lab Guide - Part 1 - Mobilenet documents focus on using the eIQ Toolkit GUI method to convert a model and then import that converted model into an eIQ MCUXpresso SDK example. It is recommended to go through this lab first. There are two versions depending on if MCUXpresso SDK is downloaded from the MCUXpresso SDK Builder website as a zip file or if MCUXpresso SDK is downloaded from the NXP Github repository.    The eIQ Neutron NPU for MCUs Lab Guide - Part 2 - Face Detect.pdf document focuses on using the eIQ Toolkit command line utilities to convert a model for the eIQ Neutron NPU and integrate that newly converted model into the Face Detect demo found on the Application Code Hub. Both labs were designed to run on the FRDM-MCXN947 but the same concepts can be applied to other MCX N boards as well as other devices with eIQ Neutron NPUs like i.MX RT700.  Also be sure to also check out the Getting Started community post for more details on the eIQ Neutron NPU. --- Updated October 2025 for eIQ Toolkit 1.17 and MCUXpresso SDK 25.09

Developing code for MCXN family from Scratch The MCX family is a newly released MCU family, of course, the SDK package includes almost all the examples of the MCXN modules based on the SDK driver, for example led_blinky which shows the method of toggling GPIO, CTimer interrupt, etc. While the program in this article doesn’t use SDK driver. It focuses on understanding the related module from register level which is friendly to beginners to understand MCX working mechanism. The doc introduces how to toggle a GPIO, how to have CTimer generate interrupt, and in the CTimer ISR, toggle a LED, while it also describes how to initialize the NVIC so that CTimer can generate ISR by writing the module registers without calling the SDK driver. Environment: FRDM-MCXN947 board MCUXPresso IDE v11.9.0 IDE on Win10 OS   1. Toggle a LED On the FRDM-MCXN947 board, the PIO0_10(P0_10) of MCXN947 is connected to a LED. With MCUXPresso IDE with v11.9.0, you can add the code to test the LED toggling and CTimer interrupt function.   1.1 Configure the PIO0_10 pin as GPIO0_10 pin SYSCON->AHBCLKCTRLSET[0]=1<<13; PORT0->PCR[10]=0x1000; Before you initialize the PORT0 register to assign the PIO0_10 function, you have to enable the PORT0 gated clock in the SYSCON->AHBCLKCTRL0 reg. Write the PORT0->PCR[10]=0x1000; to configure the PIO0_10 as GPIO0_10 function. 1.2 Configure the GPIO0_10 pin as GPIO output mode and toggle the GPIO pin. SYSCON->AHBCLKCTRLSET[0]=1<<19; GPIO0->PDDR|=1<<10; GPIO0->PTOR=1<<10; Before you initialize the GPIO0 registers, you have to enable the GPIO0 gated clock in the SYSCON->AHBCLKCTRL0 reg. Set the bit 10 of GPIO0->PDDR so that the GPIO0_10 is in GPIO output mode. Toggle GPIO0_10 pin by writing the bit 10 in GPIO0->PTOR reg   Set a break point in the debugger on the GPIO0->PTOR=1<<10; line,and run step by step, you can see that led toggles.   2. Initialize CTimer 2.1 enable Ctimer gated clock and clock source and divider. Before you initialize the CTimer register, you have to enable the CTimer gated clock. For example, enable CTimer4 gated clock with the line： SYSCON->AHBCLKCTRLSET[2]=1<<22; You have to also select the CTimer clock source and Ctimer clock divider. For example, set the CTimer4 clock source and divider. SYSCON->CTIMERCLKSEL[4]=0x04; SYSCON->CTIMERCLKDIV[4]=0x02; //P0_10 is LED red void GPIOInit(void) { SYSCON->AHBCLKCTRLSET[0]=1<<13; PORT0->PCR[10]=0x1000; //enable gated clock of GPIO SYSCON->AHBCLKCTRLSET[0]=1<<19; GPIO0->PDDR|=1<<10; GPIO0->PTOR=1<<10; //set break point here GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; } 2.2 Initialize the CTimer register. CTIMER4->CTCR=0x00; CTIMER4->PR=0x00; //set the CTimet4 mode and enable interrupt for match0 CTIMER4->MCR=0x03; CTIMER4->PWMC=0x00; //set the CTimer4 cycle time CTIMER4->MR[0]=2000000; CTIMER4->MSR[0]=2000000; //Start up CTimer4 CTIMER4->TCR=0x01; 2.3 Initialize the NVIC The IRQ number of CTimer4 is 56, so you have to set the bit 24 of both NVIC->ISER[1]|=1<<24; NVIC->ICPR[1]|=1<<24; and set the priority of NVIC->IPR[56] with 0x00; NVIC->IPR[56]=0x00;   //CTimer4 IRQ 56, 56-32=24 void cTimer0Init(void) { //CLOCK_SetClkDiv(kCLOCK_DivCtimer4Clk, 1u); //CLOCK_AttachClk(kFRO_HF_to_CTIMER4); //enable Ctimer4 gated clock SYSCON->AHBCLKCTRLSET[2]=1<<22; SYSCON->PRESETCTRLSET[2]=1<<22; SYSCON->PRESETCTRLCLR[2]=1<<22; SYSCON->CTIMERGLOBALSTARTEN|=1<<4; //select CTimer4 clock source SYSCON->CTIMERCLKSEL[4]=0x04; SYSCON->CTIMERCLKDIV[4]=0x02; //init the CTimer0 CTIMER4->CTCR=0x00; CTIMER4->PR=0x00; CTIMER4->MCR=0x03; CTIMER4->PWMC=0x00; CTIMER4->MR[0]=2000000; CTIMER4->MSR[0]=2000000; //CTIMER0->IR=0x01; CTIMER4->TCR=0x01; NVIC->ISER[1]|=1<<24; NVIC->ICPR[1]|=1<<24; NVIC->IPR[56]=0x00; } 2.3 Each interrupt source has unique interrupt service routine in the file startup_mcxn947_cm33_core0.c For the CTimer4 ISR, it is called: CTIMER4_IRQHandler So it is okay to fill the function: void CTIMER4_IRQHandler(void) { //clear flag CTIMER4->IR|=0x01; //toggle LED GPIO0->PTOR=1<<10; } In conclusion, the doc gives a snippet which can toggle a LED by writing the register directly. It also give the code to configure CTimer4 so that it can generate interrupt, in the ISR, toggle a LED. Appendix This is the entire source code:   /* * Copyright 2019 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ #include "pin_mux.h" #include "peripherals.h" #include "board.h" /******************************************************************************* * Definitions ******************************************************************************/ void clockOUTInit(void); void GPIOInit(void); void cTimer0Init(void); void MRTInit(void); /******************************************************************************* * Prototypes ******************************************************************************/ /******************************************************************************* * Variables ******************************************************************************/ /******************************************************************************* * Code ******************************************************************************/ /*! * @brief Main function */ int main(void) { /* Board pin init */ CLOCK_EnableClock(kCLOCK_Gpio0); BOARD_InitPins(); BOARD_BootClockFRO12M(); //FlexPWMPinInit(); GPIOInit(); cTimer0Init(); //MRTInit(); __asm("nop"); while (1) { } } //P0_10 is LED red void GPIOInit(void) { SYSCON->AHBCLKCTRLSET[0]=1<<13; PORT0->PCR[10]=0x1000; //enable gated clock of GPIO SYSCON->AHBCLKCTRLSET[0]=1<<19; GPIO0->PDDR|=1<<10; //set a break point here and run step by step GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; GPIO0->PTOR=1<<10; } //CTimer4 IRQ 56, 56-32=24 void cTimer0Init(void) { // CLOCK_SetClkDiv(kCLOCK_DivCtimer4Clk, 1u); // CLOCK_AttachClk(kFRO_HF_to_CTIMER4); //enable Ctimer4 gated clock SYSCON->AHBCLKCTRLSET[2]=1<<22; SYSCON->PRESETCTRLSET[2]=1<<22; SYSCON->PRESETCTRLCLR[2]=1<<22; SYSCON->CTIMERGLOBALSTARTEN|=1<<4; //select CTimer4 clock source SYSCON->CTIMERCLKSEL[4]=0x04; SYSCON->CTIMERCLKDIV[4]=0x02; //init the CTimer0 CTIMER4->CTCR=0x00; CTIMER4->PR=0x00; CTIMER4->MCR=0x03; CTIMER4->PWMC=0x00; CTIMER4->MR[0]=2000000; CTIMER4->MSR[0]=2000000; //CTIMER0->IR=0x01; CTIMER4->TCR=0x01; NVIC->ISER[1]|=1<<24; NVIC->ICPR[1]|=1<<24; NVIC->IPR[56]=0x00; } void CTIMER4_IRQHandler(void) { //clear flag CTIMER4->IR|=0x01; //toggle LED GPIO0->PTOR=1<<10; } //MRT0 interrupt IRQ is 30 void MRTInit(void) { SYSCON->AHBCLKCTRLSET[1]=1<<0; SYSCON->PRESETCTRLSET[1]=1<<0; SYSCON->PRESETCTRLCLR[1]=1<<0; MRT0->CHANNEL[0].INTVAL=6000000; MRT0->CHANNEL[0].INTVAL|=1<<31; MRT0->CHANNEL[0].CTRL=0x01; NVIC->ISER[0]|=1<<30; NVIC->ICPR[0]|=1<<30; NVIC->IPR[30]=0x00; } void MRT0_IRQHandler(void) { if(MRT0->CHANNEL[0].STAT&0x01) { MRT0->CHANNEL[0].STAT|=0x01; } //toggle LED GPIO0->PTOR=1<<10; }

  This guide helps you to: Get familiar with NPU inside the MCX Know eIQ ML examples included in SDK. Summarize related application notes and demo projects on GitHub Prerequisites: Windows 10 development PC. FRDM-MCXN947 board NXP’s  MCUXpresso IDE is installed on the development PC Generate and download FRDM-MCXN947 SDK package from the web-based MCUXpresso SDK builder. Introduction to NPU The MCXN94x and MCXN54x are based on dual high-performance Arm® Cortex®-M33 cores running at up to 150 MHz, it has 2MB of on-chip Flash with optional full ECC RAM and an integrated proprietary NPU. The integrated NPU delivers up to 40x faster machine learning (ML) throughput compared to a CPU core, enabling it to spend less time awake and reducing overall power consumption. The architecture provides power and performance-optimized NPUs integrated with NXP's very wide portfolio of microcontrollers and applications processors. The eIQ Neutron NPUs offer support for a wide variety of neural network types such as CNN, RNN, TCN, and Transformer networks and more. ML application development with the eIQ Neutron NPU is fully supported by the eIQ machine learning software development environment. The NPU used in MCXN94 is Neutron N1-16, its block diagram is shown in the below figure. The eIQ Neutron N1-16 NPU found inside the MCXN94 has 4 compute pipes and each compute pipe contains 4 INT8 MAC (Multiply Accumulate) blocks for a total of 16 MAC blocks. This means that MCXN94 could execute 4.8G(150MHz * 4 * 4 * 2) INT8 operations per second. The MCUXpresso Software Development Kit (MCUXpresso SDK) provides a comprehensive software package with a pre-integrated TensorFlow Lite for Microcontrollers (TFLM). The Neutron library is integrated into TFLM as well. The following table shows the operators which are supported by the NPU. Operator Operator input type MCXN947/MCXN548 NPU ADD Float No Uint8(PTQ) No Int8(PCQ) Yes AVERAGE_POOL_2D Float No Uint8(PTQ) No Int8(PCQ) Yes CONV_2D Float No Uint8(PTQ) No Int8(PCQ) Yes DEPTHWISE_CONV_2D Float No Uint8(PTQ) No Int8(PCQ) Yes FULLY_CONNECTED Float No Uint8(PTQ) No Int8(PCQ) Yes UNIDIRECTIONAL_SEQUENCE_ LSTM Float No Uint8(PTQ) No Int8(PCQ) No LOGISTIC (Sigmoid) Float No Uint8(PTQ) No Int8(PCQ) Yes MAX_POOL_2D Float No Uint8(PTQ) No Int8(PCQ) Yes MUL Float No Uint8(PTQ) No Int8(PCQ) No SOFTMAX Float No Uint8(PTQ) No Int8(PCQ) No SVDF Float No Uint8(PTQ) No Int8(PCQ) No Note: PTQ — Per-tensor quantized (asymmetric 8-bit quantization). PCQ — Per-channel quantized (symmetric 8-bit quantization). For more information please refer to eIQ TensorFlow Lite User's Guide.pdf in middleware/eiq/doc of SDK. eIQ ML examples included in SDK. Download SDK and select FRDM-MCXN947 in MCUxpresso SDK Builder, Remember to select eIQ middleware. Then open MCUXpresso, it’s convenient to install the SDK by dragging and dropping the file into the SDK installation window of the MCUXpresso IDE. Import SDK examples into the workspace: There are 7 ML examples included in SDK: Here are the descriptions of the eIQ examples: eIQ example Description Hardware requirements tflm_cifar10 CIFAR10 example based on TensorFlow Lite Micro, recognizes a static image FRDM-MCXN947 USB type-c cable tflm_kws Keyword spotting example based on TensorFlow Lite Micro recognizes a static WAV audio FRDM-MCXN947 USB type-c cable tflm_label_image Label 1000 classes of images based on TensorFlow Lite Micro FRDM-MCXN947 USB type-c cable mpp_camera_mobilenet_view_tflm Label camera images based on TensorFlow Lite Micro FRDM-MCXN947 LCD: MikroElektronika TFT Proto 5" OV7670 module USB type-c cable mpp_camera_ultraface_view_tflm Face detection using the camera as the source, based on TensorFlow Lite Micro FRDM-MCXN947 LCD: MikroElektronika TFT Proto 5" OV7670 module USB type-c cable mpp_camera_view A simple camera preview pipeline. FRDM-MCXN947 LCD: MikroElektronika TFT Proto 5" OV7670 module USB type-c cable tflm_modelrunner TFLite Model Benchmark example for Microcontrollers. FRDM-MCXN947 RJ45 Network cable For additional information and guidance, kindly refer to the README file located in the doc folder that accompanies each example. Summary of related application notes There are two application notes available that provide information on advanced usage of NPU. How to Integrate Customer ML Model to NPU on MCXN94x Face Detection demo with NPU accelerated on MCXN947. Please find the notes on the NXP website Summary of demo projects on GitHub There are five demos on nxp-appcodehub from GitHub: Multiple Face detection on FRDM-MCXN947 Multiple person detection on FRDM-MCXN947 Label CIFAR10 images on FRDM-MCXN947 Fashion-MNIST recognition on FRDM-MCXN947 NPU vs TensorFLM benchmark on MCX  

In order to recover your board, you need to accomplish the following: Ensure that your PC successfully enumerates the LinkServer debugger under the COM ports. Confirm that you can attach to the running code on the board. When attempting to program the board, the following error appears:   The device stops during initialization because the value of SIM_CHIPCTL is not set to its default after reset. This happens because SRAMU and SRAML are retained across resets, which causes a flash initialization error. To resolve this issue, modify the debug script to override the SIM_CHIPCTL register with its default value: 0x0030_0000. Locate the file MCXE24x_connect.scp. If you are using the default installation path, it should be located at: C:\NXP\LinkServer_YourVersion\binaries\Scripts   Open the file and add the line "Poke32 this 0x40048004 0x00300000" I recommend do it after the "Release NRESET" message.     Note: You need to add a number to each line of code    After making this change, you should be able to program your MCX E24x board as usual.

Overview NXP FRDM-MCXN947 board is a low-cost design and evaluation board based on the MCXN947 device. NXP provides tools and software support for the MCXN947 device, including hardware evaluation boards, software development integrated development environment (IDE), sample applications, and drivers. The board is equipped with Ethernet PHY, and also supports camera modules and NXP's low-cost LCD module PAR-LCD-S035.   In this article, we will explore how to simultaneously implement Ethernet connection transmission and image acquisition using a camera on the MCXN947 board. Hardware Environment Development Board: FRDM-MCXN947 Display: 3.5" TFT LCD (P/N PAR-LCD-S035) Camera: OV7670 Network Cable: RJ45 Software Environment IDE: MCUXpresso IDE v11.9.0 SDK: MCUXpresso SDK Builder (nxp.com) Pin Configuration and Multiplexing When designing circuits, attention must be paid to avoiding pin conflicts, that is, ensuring that the same pin is not configured to perform conflicting functions at different times. When configuring pin functions, it is necessary to consider whether their electrical characteristics (such as voltage range, current drive capability, etc.) meet the requirements of the peripherals. When writing software, it is necessary to consider the support for pin multiplexing in different versions of MCU firmware or library files to ensure software compatibility and stability. Import the " lwip_examples " -> " lwip_ping_bm " project from the FDRM-MCXN947 SDK, open the board -> pin_mux.c file, and you can see the pin configuration for Ethernet connection as shown in the table below: Pin Name Pinmux Assignment P1_4 ALT9 - ENET0_TX_CLK P1_5 ALT9 - ENET0_TXEN P1_6 ALT9 - ENET0_TXD0 P1_7 ALT9 - ENET0_TXD1 P1_8 ALT9 - ENET0_TXD2 P1_9 ALT9 - ENET0_TXD3 P1_13 ALT9 - ENET0_RXDV P1_14 ALT9 - ENET0_RXD0 P1_15 ALT9 - ENET0_RXD1 P1_20 ALT9 - ENET0_MDC P1_21 ALT9 - ENET0_MDIO   Download the schematic of the MCXN947 board from NXP's official website, and find the modules corresponding to Camera and FlexIO LCD, as shown below:   FlexIO is a flexible input/output (I/O) technology developed by NXP, used to provide high-speed, programmable communication capabilities between microcontrollers (MCU) and external devices. It allows developers to configure the FlexIO module inside the microcontroller to simulate various communication protocols and develop custom protocols. Note: This LCD only supports 3V I/O voltage, so when configuring all pins on this connector, you must ensure they are all set to 3V3 operation mode. The following diagram shows the working principle of the SDK example, where the camera collects images and transmits them to the LCD display: It can be seen that the LCD module does not have any pin conflicts with the pins required for Ethernet and Camera functions, while the pins required for configuring the Camera module are duplicated with Ethernet. The pin reuse can be found in the datasheet provided on the NXP official website as shown in the following table: Pin Name Pinmux Assignment P0_4 ALT0 - P0_4 P0_5 ALT0 - P0_5 P1_4 ALT7 - SmartDMA_PIO0 P1_5 ALT7 - SmartDMA_PIO1 P1_6 ALT7 - SmartDMA_PIO2 P1_7 ALT7 - SmartDMA_PIO3 P1_10 ALT7 - SmartDMA_PIO6 P1_11 ALT7 - SmartDMA_PIO7 P1_18 Default-PIO-Low P1_19 Default-PIO-High P2_2 ALT1 - CLKOUT P3_2 ALT2 - FC7_P0 P3_3 ALT2 - FC7_P1 P3_4 ALT7 - SmartDMA_PIO4 P3_5 ALT7 - SmartDMA_PIO5 As seen above, pins P1_4, P1_5, P1_6, and P1_7 conflict directly with Ethernet pins. Since Ethernet pins are fixed to the RJ45 PHY, the Camera interface must be reassigned to alternate pins. From the datasheet, P3_0, P3_1, P3_2, and P3_3 can serve as alternatives. However, P3_2 and P3_3 are already used for I²C. To resolve this, they are reassigned to P3_8 and P3_7 respectively (using kPORT_MuxAlt3). The updated pin mapping is shown below: Previous Pin Current Pin Pinmux Assignment P1_4 P3_0 ALT7 - SmartDMA_PIO0 P1_5 P3_1 ALT7 - SmartDMA_PIO1 P1_6 P3_2 ALT7 - SmartDMA_PIO2 P1_7 P3_3 ALT7 - SmartDMA_PIO3 P3_2 P3_8 ALT3 - FC7_P0 P3_3 P3_7 ALT3 - FC7_P1   Implementation The reassigned pins (P3_0, P3_1, P3_7, P3_8) are not exposed on the board’s headers, but the schematic shows that they are connected to test pads TP12, TP31, TP18, and TP16. The camera can be wired to these pads directly.   Pin Name Solder Pad P3_0 TP12 P3_1 TP31 P3_7 TP18 P3_8 TP16     Integrate the smartdma_camera_flexio_mculcd example from display_examples into the lwip_ping_bm project. Merge .c and .h files from board , drivers , component , and source folders. Add these folders to the include path under Project -> Properties -> C/C++ Build -> Settings -> Includes .   After integration, compile and flash the project to the board. The output is shown in the images.   Conclusion The Ethernet and Camera functions can be simultaneously implemented on the MCX N947 board. The lwip_ping_bm demo showcases ICMP-based Ping functionality using the lwIP TCP/IP stack. It periodically sends ICMP echo requests to a PC and processes the replies. The smartdma_camera_flexio_mculcd demo demonstrates how to use SmartDMA to capture image data frame-by-frame from the OV7670 camera and display it on the ST7796S LCD panel via FlexIO. By reconfiguring and multiplexing pins, simultaneous use of Ethernet and Camera on the MCX N947 is achievable.  

1. Introduction During recent customer technical support, we have find that power supply design issues frequently occur when using MCXN94X/MCXN54X products with HLQFP 100-pin packaging. To address this, we have developed this design guide specifically for 100-pin packaged chips, based on the power supply design diagrams provided in the MCX Nx4x Power Management User Guide (UG10101). Description of Package Types The MCXNx4x series currently includes three package types: VFBGA 184-pin HDQFP 172-pin HLQFP 100-pin The power supply design solutions in the User Guide(UG10101) primarily target the 172-pin and 184-pin packages. 2. Special Design Requirements for HLQFP 100-Pin Packages 2.1 Power Supply Design Solution for HLQFP 100-Pin Packages (LDO_CORE Mode) When using a 100-pin MCXNx4x chip and selecting the LDO_CORE mode (with DCDC_CORE disabled), the power supply design shall comply with the following specifications: Key Design Differences 1)Shared Power Pin Characteristics In the 100-pin package, VDD_DCDC and VDD_LDO_SYS share the same pin. When DCDC_CORE is turned off, DCDC_LX must be left floating, and the DCDC function must be disabled through software configuration. 2) Port Power Supply Design The power supply pin Vdd_p2 for PORT2 shares a single pin with VDD. The 100-pin packaged chip cannot provide independent power supply to PORT2; instead, it must be uniformly powered by VDD, consistent with the power supply configuration for PORT0/PORT1. 2.2 Power Supply Design Solution for 100-Pin Packages (DCDC_CORE Mode) If the DCDC_CORE mode is used (with LDO_CORE turned off), the 100-pin chip can directly refer to the MCX Nx4x Power Management User Guide (UG10101). However, special attention must be paid to the following: PORT2 still cannot be supplied with independent power and must adhere to the port power supply design requirements specified above. 3.Technical Support If you have any issues during the power supply design of MCXNx4x series chips, please feel free to leave a message for communication at any time.   Thanks for Yang Zhang's help with the review.