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.  Note: The Neutron Converter tool has been renamed to the Neutron Compiler tool.    “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 Compiler Tool with the --dump-header-file-output option at the top of the resulting header file.  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 for the model 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 The size of this buffer can be estimated when running the Neutron Compiler tool in the "Total data" field but this estimate is often slightly smaller than the actual amount used. The actual TensorArenaSize buffer required can be determined when running the model by calling s_interpreter->arena_used_bytes(); which is printed out to the serial terminal in the eIQ MCUXpresso SDK examples. The recommendation is to use the estimation but increase by ~10%, run the model, and then use the arena_used_bytes API to determine the true amount of scratch memory required.   “Internal Neutron NPU driver error 281b in model prepare!” or “Incompatible Neutron NPU microcode and driver versions!” Ensure the version of the eIQ Neutron Compiler Tool used to convert the model is the correct one that is compatible with the NPU libraries used by the SDK project.  See this Community Post for how to update the eIQ Neutron libraries.     Camera colors are incorrect on FRDM-MCXN947 board See this Community post for more details on using a camera with the FRDM-MCXN947 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.             anthony_huereca_0-1709071420874.png 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.            anthony_huereca_1-1709071421059.png                

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-MCXN947-Case-base.png   FRDM-MCXA153 case step files are here FRDM-MCXA153-Case.png   FRDM-MCXW71 case step files are here FRDM-MCXW71-Case.png

The MCX N microcontroller family includes an eIQ Neutron N1-16 NPU for accelerating neural network models. The FRDM-MCXN947 development board can be combined with a camera and LCD screen to showcase running TinyML vision models on a microcontroller.   MCX N Camera Hardware Setup: The following hardware is used: MCX N FRDM Development Board - FRDM-MCXN947 OV7670 camera (with optional wide-angle lens) NXP LCD-PAR-S035  There are three small modifications needed for the FRDM-MCXN947 board for camera support. Without this modification the camera colors will be incorrect and tinted red.   Change SJ16, SJ26, and SJ27 found on the back of the Rev B board to connect pin 3 (the dashed side) so that it looks like the following:          anthony_huereca_0-1770329042521.png Then connect the camera and LCD to the FRDM-MCXN947: Plug in the OV7670 camera into J11. It should line up with the orange box.         anthony_huereca_1-1770329080269.png                   anthony_huereca_2-1770329086311.png     Connect the LCD-PAR-S035 LCD into J12. It should be flush with the bottom so that the top 2 rows of pins are left hanging off the edge. Also note that on some LCD-PAR-S035 boards those top two rows of pins are not installed.          anthony_huereca_3-1770329095085.png   It should look like the following when complete           anthony_huereca_4-1770329100729.png   Also as the camera and Ethernet pins are shared, if you need to use the Ethernet+Camera at the same time please see this NXP Community post. MCX N Vision ML Examples: The NXP Application Code Hub contains several vision AI/ML examples: Face Detect Face Detect with Zephyr Multiple Person Detection  CIFAR10 Fashion MNIST There are also Multimedia Processing Pipeline (MPP) examples inside the MCX N MCUXpresso SDK that demonstrate more examples of using vision AI/ML on MCX N. These examples are only available for VSCode/GCC in the Repository-Layout SDK package. Note: It is recommended to use MCUXpresso SDK 25.09 for these examples. The MPP issues in the 25.12 and 26.03 MCUXpresso SDK releases should be fixed in the upcoming MCUXpresso SDK 26.06.  anthony_huereca_5-1770329951165.png   MCX N ML Vision Lab: The attached eIQ Neutron NPU for MCX N Lab Guide - Face Detect.pdf lab document walks through the steps to download an example Face Detect ML project from the NXP Application Code Hub and use the eIQ Neutron Compiler tool to convert a model. It also describes how to update the eIQ and Neutron software libraries in an older MCUXpresso SDK project to work with the latest eIQ Neutron SDK libraries. It is recommended to go through the general MCX N NPU Lab Guide first and then do the attached Face Detect lab second.  The lab is also included below: 1  Lab Overview This document will demonstrate the acceleration provided by the eIQ Neutron NPU using the Multiple Face Detection demo for the FRDM-MCXN947 found on the NXP App Code Hub. The demo will run with the non-NPU optimized model and then the performance can be compared to the NPU optimized version of that same model. It also demonstrates how the NPU optimized version of the face detect model was generated. This lab is written for MCUXPresso IDE but the same basic steps can be used for VSCode or GCC.   This lab will also cover how to update the Neutron NPU libraries in the project, as the original Face Detect example uses an older Neutron library version.   It is highly recommended to complete the eIQ Neutron NPU for MCX N Lab Guide before starting this lab. 2  Software and Hardware Installation This section will cover the hardware and software needed for this lab. 2.1 Hardware The following hardware is required for this lab: MCX N FRDM Development Board - FRDM-MCXN947 OV7670 camera (with optional wide-angle lens) NXP LCD-PAR-S035 2.2 NXP Software Installation          Install MCUXpresso IDE v25.6 or later. Download the latest eIQ Neutron SDK Download and unzip the latest MCUXpresso SDK for FRDM-MCXN947 using MCUXpresso SDK builder Search for the FRDM-MCXN947 board anthony_huereca_0-1779252823521.png     Then click on Others anthony_huereca_1-1779252835626.png   On the SDK builder page, make sure to select the “eIQ” middleware and that the MCUXpresso IDE toolchain is selected. Then click on Build SDK.   anthony_huereca_2-1779252845567.png   Then click on the Download button and accept the license agreement to download the zip file. anthony_huereca_3-1779252852536.png     3   Face Detection Example 3.1 Download Face Detect Demo from App Code Hub The code for this lab can be found on the NXP Application Code Hub hosted on Github, and we can use MCUXpresso IDE to directly import the Face Detection example from App Code Hub.   Drag-and-drop the FRDM-MCXN947 SDK zip file into the Installed SDKs window, located on a tab at the bottom of the screen named “Installed SDKs”. You will get the following pop-up, so hit OK. anthony_huereca_4-1779252865811.png   Once imported, the Installed SDK tab will look something like this:  anthony_huereca_5-1779252872648.png   In the Quickstart Panel found in the lower left corner, click on Import from Application Code Hub.. anthony_huereca_6-1779252877943.png   In the dialog box that pops up there are many filters available to filter for different devices and types of demos. But since the name of the demo we are interested in is already known, the search box will be faster. Select the AI/ML category and then type in “face detection” and then click on the “Multiple face detection on mcxn947” demo. Make sure you don’t accidently click on the “Multiple Person Detection” demo. anthony_huereca_7-1779252885931.png   On the popup that comes up, click on GitHub link at the top. At that point the Next button at the bottom will become clickable so click on that. anthony_huereca_8-1779252891875.png     The next screen displays the possible branches. In this case there is only main so just click on the Next button at the bottom to go with the default. anthony_huereca_9-1779252899673.png   The next dialog box determines the location on your computer where the code will be downloaded to. You can leave it at the default location if desired or click on Browse to pick your own location. Then click on Next. anthony_huereca_10-1779252906645.png   The next screen will download the code and ask about importing the project. Click on Next to go with the default Import existing Eclipse projects option. anthony_huereca_11-1779252913518.png   Then finally on the last screen click on Finish to import the project into your MCUXPresso IDE workspace. anthony_huereca_12-1779252920739.png   You may get the following warning due to the project being made on an older version of the SDK. Then hit OK to accept the using the newest version. anthony_huereca_13-1779252927267.png  15. It should look like the following when done: anthony_huereca_14-1779252934804.png     3.2 Convert Model The demo is already using a model that was converted to take advantage of the eIQ Neutron NPU. This purpose of this section of the lab is to teach new NXP users how that model was converted. Unzip the eIQ Neutron SDK package in a directory of your choosing.   Optionally add <unzip_location>\eIQ_NeutronSDK_<version>\bin to your executable path so that the neutron-compiler utility can be directly called from the command line. Back in MCUXpresso IDE, find the location of the original non-converted model used for this demo by right clicking on the face_detect.tflite file in source/model/ and going to Utilities->Open directory browser here. anthony_huereca_15-1779252951720.png   Copy the directory location as it will be used in the next step anthony_huereca_16-1779252958805.png   Open a Windows Command prompt and navigate to the directory where the model was at from the previous step             anthony_huereca_17-1779252967083.png   Use the Neutron Compiler to convert the Face Detection model: neutron-compiler --input face_detect.tflite --output face_npu.tflite --target mcxn94x anthony_huereca_18-1779252973705.png     3.3 Update eIQ Neutron Libraries The Face Detect ACH example uses an older version of the eIQ Neutron libraries, and so it needs to be updated to match the Neutron libraries in newest eIQ Neutron SDK since the model was converted with that version of the Neutron Compiler tool.   In the frdmmcxn947_multi_face_detection project, right click on the eiq folder and go to Utilities->Open directory browser here anthony_huereca_19-1779252981696.png   Overwrite the Neutron files from the eIQ Neutron SDK folder into your project to update the Neutron libraries to the latest version: File Name Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\mcxn94x\board\ eiq\neutron\mcxn\cm33 libNeutronFirmware.a target\mcxn94x\board\ eiq\neutron\mcxn\cm33 NeutronDriver.h target\mcxn94x\driver\include\ eiq\neutron\driver\include NeutronErrors.h target\mcxn94x\common\include\ eiq\neutron\common\include After the new Neutron libraries are copied over, clean the project to ensure the new libraries will be used anthony_huereca_20-1779252988773.png     3.4 Board modifcations There are some hardware modifications to the MCX FRDM board required for this demo since the camera pins are muxed with the Ethernet pins and the Ethernet functionality is the default.   The board version can be determined by scanning the QR code on the back of the MCX FRDM board with your phone. Most people will have Rev B boards. anthony_huereca_21-1779252995826.png   Rev A: Remove the R157, R158, and R159 resistors from the back of the Rev A board so that it looks like the following: anthony_huereca_22-1779253003945.png   Rev B: Change SJ16, SJ26, and SJ27 found on the back of the Rev B board to connect pin 3 (the dashed side) so that it looks like the following: anthony_huereca_23-1779253007749.png       3.5 Connect the camera and LCD Plug in the OV7670 camera into J11. It should line up with the orange box. anthony_huereca_24-1779253014542.png anthony_huereca_25-1779253017946.png   Connect the LCD-PAR-S035 LCD into J12. Note that some older LCD-PAR-S035 LCDs may have an extra set of pins soldered on, and in that case the extra 2 rows of pins should be hanging off the edge like in the photo below.             anthony_huereca_26-1779253024933.png   It should look like the following when complete anthony_huereca_27-1779253031139.png     3.6 Run Models Now open up model_data.s by double clicking on it, and then modify line 43 to point to the original (non NPU converted) model file named face_detect.tflite. This particular project uses the .tflite file directly. anthony_huereca_28-1779253042408.png   Build the project by clicking on the Build icon in the Quickstart Panel anthony_huereca_29-1779253048317.png   Then download and run the project by clicking on the Debug icon in the Quickstart Panel anthony_huereca_30-1779253054552.png     You should see the demo working with an inference time of 817ms printed on the LCD display. Note: The default camera on the OV7670 is not very wide angle so you have to hold it fairly far back. There are wide-angle lenses that can be purchased to make it easier to demonstrate. Note: After POR there may be some glitching on the camera due to the fact the camera is expecting 2.8V but the board is at 3.3V and the initial HSYNC signal was missed. Press the reset button (SW1) and it should fix any camera issue.  Now let’s use the Neutron optimized model by opening model_data.s again and this time selecting the NPU converted model face_npu.tflite anthony_huereca_31-1779253063971.png   Recompile and reprogram the board. You’ll see it is significantly faster with a 22ms inference time, a 37x improvement!   4  Conclusion This lab demonstrated how the eIQ Neutron NPU on MCX N devices can significantly decrease inference time on quantized models and the steps to generate a NPU optimized model using the command line tools. Also explore the other App Code Hub ML examples available online.

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. Harry_Zhang_0-1757560073724.png   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: Harry_Zhang_1-1757560397299.png Harry_Zhang_2-1757560410963.png   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: Harry_Zhang_3-1757562668813.png 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. Harry_Zhang_0-1757564251929.png   Pin Name Solder Pad P3_0 TP12 P3_1 TP31 P3_7 TP18 P3_8 TP16   Harry_Zhang_2-1757564416860.png   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 . Harry_Zhang_3-1757564453620.png   After integration, compile and flash the project to the board. The output is shown in the images. Harry_Zhang_4-1757564465243.png Harry_Zhang_5-1757564478135.png   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.  

Introduction This article describes the method to update the Boot ROM patch on MCX N94x / N54x devices to patch version T1.1.5.   Before beginning, note that this process can only be performed via ISP mode of the device and can only be performed using a command line method.  The NXP Secure Provisioning tool uses command line operations in its backend and does make these available to the user.  For directions on how to access the command line interface through the Secure Provisioning tool, consult your Secure Provisioning Tool documentation.  Command line blhost method ISP Pin Method 1) With the device powered off, assert the ISP pin (GPIO P0_6) by pulling this pin low. 2) With ISP pin still asserted, power on the device.   3) After the device has fully powered on (at least as long as the t_POR time quoted in the Power mode transition operating behaviors table of the MCX N94x / N54x datasheet), release the ISP pin.  4) Open a command prompt and set the working directory to your blhost installation. 5) Verify that the current version of ROM patch is not T1.1.5 using this command: blhost <interface> <parameters> -- get-property 24.  a) Where <interface> should be replaced with the code for the interface type and <parameters> should be replaced with the parameters of that interface.  For more information on this syntax, refer to the blhost User's Guide.   6) Execute this command:  blhost <interface> <parameters> receive-sb-file <path_to_file_location>/mcx_n10_a1_prov_fw_rp_v5.0.sb3.  7) Repeat steps 1 - 5 to verify that the ROM version is T1.1.5.  ISP Pin Unavailable - SWD Method 1) Connect to target via SWD 2) Open the secure provisioning tool 3) Select the serial interface window and select the command line button 4) Send the following command: nxpdebugmbox -i pyocd ispmode -m 0 5) Verify that the current version of ROM patch is not T1.1.5 using this command: blhost <interface> <parameters> -- get-property 24.  a) Where <interface> should be replaced with the code for the interface type and <parameters> should be replaced with the parameters of that interface.  For more information on this syntax, refer to the blhost User's Guide.   6) Execute this command:  blhost <interface> <parameters> receive-sb-file <path_to_file_location>/mcx_n10_a1_prov_fw_rp_v5.0.sb3 7) Repeat steps 1 - 5 to verify that the ROM version is T1.1.5.         

Porting an ST Application   This section outlines the process of migrating an application developed in the STM32Cube IDE to the NXP MCUXpresso IDE, using a compatible SDK for the target NXP MCU. For users familiar with STM32Cube IDE, maintaining a similar development environment can ease the transition and reduce the learning curve. In this example, an I2C-based application originally developed for an STM32 device will be recreated and adapted for an NXP MCU.   The migration begins by creating a minimal project in MCUXpresso IDE that includes the necessary I2C drivers. The original ST application utilizes two I2C instances for communication between components on the same board. To replicate this functionality, two sets of I2C pins must be initialized. Additionally, the application uses a push-button input and an LED output to demonstrate behavior changes, requiring the configuration of corresponding GPIOs using the MCUXpresso pin configuration tools.   To begin the migration, the main source file from the original ST project—as well as any custom source files not part of the standard ST driver set—should be incorporated into the new NXP project.   The following steps outline the initial project setup in MCUXpresso IDE: Select Create a new C/C++ project. Choose the target MCU (e.g., MCXA156). Click Next. Expand the Drivers section. Select I2C. Click Next. Click Finish.   Upon creation, the project includes a basic "Hello World" example. This template can be used as a starting point. All content within the main source file—except for the initial macro definitions—can be replaced incrementally to integrate the application logic, allowing for a modular and controlled migration process. Sabina_Bruce_1-1763569353713.png The next step involves transferring the main source file from the original ST project into the newly created MCUXpresso project. During this process, standard ST includes, and driver references are excluded, unless custom header files are required. In this case, no custom headers are used, so only the core application logic is migrated.   Many of the function calls within the ST source file rely on STM32-specific HAL APIs. These will be reviewed and systematically replaced with equivalent functions from the NXP SDK. The approach involves analyzing each function within the main() routine to understand its purpose and then substituting it with the corresponding implementation in the NXP environment.   Sabina_Bruce_2-1763569353730.png Functions quick summary from ST project: Interrupt Priority Configuration Configures the microcontroller’s interrupt system to manage priority levels when multiple interrupts occur simultaneously. Power Peripheral Clock Enablement Activates the clock for the Power (PWR) peripheral, a prerequisite for configuring power management settings. Power Management Setup Initializes power management features of the STM32U5xx microcontroller to optimize energy efficiency and performance across internal components. System Clock Configuration Sets up the timing system of the microcontroller, configuring it to operate at a frequency of 160 MHz. Peripheral Initialization Establishes pin configurations and functional settings for peripherals. In this application, I2C1 is configured as the follower and I2C3 as the leader. LED Initialization Configures the LED to start in a low-active state, turning it on to indicate initial status or communication feedback. GPIO Polling for Button Press Continuously monitors the status of a GPIO input pin. If the button is not pressed, the LED blinks rapidly. Once pressed, the loop exits, and the LED remains on. I2C Communication Start Initiates the I2C communication process from the master side, triggering data transfer between the two I2C interfaces.   How is this handled in the NXP SDK? Interrupt Priority Configuration This functionality is supported through CMSIS core NVIC functions and can be reused directly. It requires defining macros to establish the desired pre-emption priority levels. Clock and Power Configuration These aspects are consolidated within the BOARD_InitBootClocks function, located in clock_config.c under the board folder. This function initializes both the system clock and power settings for the NXP MCU. Peripheral and Pin Initialization Peripheral setup is divided across two functions: BOARD_InitBootPins (in pin_mux.c) handles pin configuration for I2C and GPIO. BOARD_InitBootPeripherals (in peripherals.c) manages I2C peripheral initialization and GPIO interrupt setup. LED Initialization GPIO pins can be configured as output high or low depending on the desired initial state. The LED can be toggled or set using GPIO_PinWrite. GPIO Polling for Button Press This behavior can be replicated using a custom polling function that utilizes GPIO_PinRead to monitor the button state. I2C Communication Start The I2C master communication is initiated using LPI2C_MasterStart, which begins the data transfer process with the designated slave device.     Tackling Clock Initialization using Clock Config Tool The MCUXpresso IDE includes integrated configuration tools, which can be accessed via the Project Explorer by selecting the appropriate option from the drop-down menu located in the upper-right corner of the interface. Sabina_Bruce_3-1763569353733.png To configure the system clocks, open the Clocks tool within MCUXpresso IDE. The clock diagram displays the supported configurations for the selected MCU. In this example, the device has a maximum core clock frequency of 96 MHz. As this meets the application's requirements, no modifications to the default clock settings are necessary. Sabina_Bruce_4-1763569353743.png To enable the peripheral clocks for the I2C instances, navigate to the clock configuration diagram within the MCUXpresso Config Tools. Scroll through the diagram to locate the available peripherals and activate the I2C modules by selecting the appropriate clock sources. Sabina_Bruce_5-1763569353757.png To configure the clock source for the I2C0 and I2C3 peripherals, double-click on the CLKSEL field associated with each instance in the clock configuration diagram. For this setup, select FRO_HF_DIV as the clock source for both I2C0 and I2C3. Sabina_Bruce_6-1763569353761.png Next, configure the clock divider by selecting the corresponding field in the clock configuration diagram. The details will appear in the top-right panel of the interface. To enable the clock path to the I2C peripheral, ensure the option “Divider clock is running” is selected. Sabina_Bruce_7-1763569353764.png At this stage, the I2C peripheral clocks have been successfully enabled. Sabina_Bruce_8-1763569353777.png     To apply and integrate the configuration changes into the project, click “Update Code.” This action will generate the corresponding source files and ensure the new settings are reflected in the project structure.   Tackling Pin Initialization using Pins Config Tool The MCUXpresso IDE includes integrated configuration tools, which can be accessed from the Project Explorer by selecting the appropriate option from the drop-down menu located in the upper-right corner of the interface. Sabina_Bruce_9-1763569353780.png To begin configuring the I2C pins, select “Open Pins” from the configuration tool menu within MCUXpresso IDE. Using the filter functionality, search for available pins compatible with I2C instance 0. After reviewing the board schematic, pins P0_16 and P0_17 were selected, as they are accessible via a header. Assign the appropriate I2C functionality to these pins by selecting LPI2C0:SDA and LPI2C0:SCL from the configuration options. Sabina_Bruce_10-1763569353815.png Repeat the configuration process for I2C instance 3. Based on the board schematic, pins P3_27 and P3_28 are selected for this instance. Assign the appropriate functionality by selecting LPI2C3:SDA and LPI2C3:SCL within the pin configuration tool. Sabina_Bruce_11-1763569353825.png Once the pin selections are made, a configuration table is generated displaying the routing and settings for each pin. Within this table, use the routing details to configure the pins as required. For the I2C pins, enable internal pull-up resistors to ensure proper signal integrity during communication. Sabina_Bruce_12-1763569353838.png In addition to configuring the I2C pins, it is necessary to set up two GPIO pins—one for input and one for output. On this board, SW2 (P1_7) is designated for button input functionality, while P3_0 is assigned for LED output. Sabina_Bruce_13-1763569353842.png Sabina_Bruce_14-1763569353845.png Within the routing details of the pin configuration table, define the behavior for both input and output GPIOs. Based on the application requirements, the output pin should be initialized to a logical low state (select Logical 0) to activate the LED. For the input pin, enable interrupt detection on a falling edge to register button presses accurately. Sabina_Bruce_15-1763569353848.png To finalize the configuration and integrate the changes into your project, click “Update Code.” This will generate the necessary source files and apply the selected settings to the project structure. Tackling Peripheral Initialization using Peripheral Config Tool The MCUXpresso IDE features integrated configuration tools, accessible via the Project Explorer. To launch these tools, use the drop-down menu located in the upper-right corner of the interface. Sabina_Bruce_16-1763569353851.png   To begin peripheral configuration, select “Open Peripherals” from the configuration tool menu within MCUXpresso IDE. In this view, focus on initializing the GPIO and I2C settings for each instance. To proceed, select “Peripheral Drivers” to access the list of supported drivers available for the target device Sabina_Bruce_17-1763569353857.png   GPIO1 Configuration To filter the available peripheral options, enter “GPIO” in the search field within the Peripheral Drivers view. Once the relevant options are displayed, click “OK” to proceed with the GPIO configuration. Sabina_Bruce_18-1763569353865.png To enable the interrupt functionality for P1_7, which is assigned to the button input, begin by selecting a new peripheral driver. Use the filter to search for GPIO, then choose the appropriate driver to activate the GPIO1 interrupt handler. Sabina_Bruce_19-1763569353875.png I2C3 Leader/Master Configuration To configure the I2C peripheral, filter the available options by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one for your application and click “OK” to proceed. Sabina_Bruce_20-1763569353885.png Configure I2C3 as the master (leader) device and enable interrupt-driven data transfer. This setup allows the I2C3 instance to initiate communication and handle data transmission using interrupt mechanisms for improved responsiveness and efficiency. Sabina_Bruce_21-1763569353900.png Additionally, enable the interrupt handler for the I2C3 peripheral. Configure the appropriate priority level and activate the Transmit Data Ready flag to support interrupt-driven data transmission. Sabina_Bruce_22-1763569353910.png I2C0 Follower/Slave Configuration To configure the I2C0 follower peripheral, filter the available drivers by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one and click “OK” to proceed with the configuration. Sabina_Bruce_23-1763569353920.png Configure I2C0 as the slave (follower) device. Enable the interrupt-driven transfer method and specify the slave address to be used for communication. This setup allows the I2C0 instance to respond to master requests and handle data reception via interrupts. Sabina_Bruce_24-1763569353944.png Additionally, enable the interrupt handler for the I2C0 peripheral. Configure the appropriate priority level, validate the assigned follower address, and activate the Receive Data Ready flag to support interrupt-driven data reception. Sabina_Bruce_25-1763569353954.png To apply the configured settings and integrate them into the project, click “Update Code.” This action will generate the necessary source files and ensure that all peripheral and pin configurations are reflected in the project structure. Config Tools Generated Files The MCUXpresso configuration tools automatically generate source code based on the selected settings, streamlining integration into the main application. This generated code includes initialization routines for clocks, pins, and peripherals configured in previous steps. All generated files are organized under the board directory within the project structure. Sabina_Bruce_26-1763569353958.png board.c When creating a project using an NXP development board, the default configuration includes initialization of debug UART pins for serial terminal communication. In this case, the UART functionality is not required, and the corresponding function in board.c will not be used. clock_config.c This file contains all system clock configurations. Use the BOARD_InitBootClocks function to initialize the clock frequency and power mode settings. For this application, the system is configured to operate at 96 MHz. peripherals.c This file includes initialization code for peripherals configured via the Config Tools. In this example, it contains setup routines for both I2C instances and the GPIO interrupt. While the BOARD_InitPeripherals function can be used, it is often more effective to selectively integrate the generated code into specific locations within the application to align with the required execution sequence. pin_mux.c This file defines all pin configurations selected for the application, including I2C and GPIO assignments. Although UART pins are included by default, they are not utilized in this project. Use the BOARD_InitBootPins function to apply the pin settings. Additionally, the original ST application includes a cache initialization function (MX_ICACHE_Init). In the NXP SDK, cache configuration is handled within the startup code. This can be reviewed in the SystemInit function located in system_MCU.c under the device folder. Replacing the Initialization Functions Sabina_Bruce_41-1763577157030.png Clock and Pin Initialization In the main function of the NXP-based project, system clocks and pin configurations are initialized using the functions generated by the configuration tools: BOARD_InitBootClocks BOARD_InitBootPins Peripheral Initialization Initialization code for peripherals is sourced from the peripherals.c file generated by the Config Tools. The first block of code sets up the GPIO interrupt handler, including its priority level and NVIC configuration. Following this, the I2C master and slave instances are initialized along with their respective interrupt handlers and priority levels. At this stage, interrupt flags are not yet enabled; they will be activated later within the data transfer function to ensure proper sequencing and avoid premature interrupt triggering. The peripherals.c file includes a code snippet specifically for initializing the LPI2C0 peripheral for slave operations. This code can be selectively integrated into the main function or other appropriate locations within the application to align with the desired execution flow. Sabina_Bruce_28-1763569353988.png While the configuration tools in MCUXpresso IDE effectively generate the necessary initialization code, it remains the developer’s responsibility to determine the most appropriate placement of this code within the application. This decision should be guided by the operational sequence required by the specific protocol or peripheral being implemented. For example, in I2C communication, data transfer is managed through interrupts. If the LPI2C0_Init function is used without consideration for timing, interrupts may trigger prematurely, resulting in incomplete or mismanaged transactions. To ensure proper execution, the recommended sequence is: Initialize the peripheral and its associated interrupt handler. Start the I2C transaction. Enable interrupts for both master and slave operations. In this application, the initialization is performed within the main() function, while the interrupt flags are selectively enabled later within the Handle_I2C_Master function to maintain correct timing and control. Sabina_Bruce_29-1763569353999.png Replacing the Action Functions Sabina_Bruce_43-1763577293016.png   SYSTICK Initialization The SYSTICK timer is configured to support delay operations within the application, such as controlling the LED blinking rate. Detailed instructions for initializing SYSTICK are provided in the following sections. Button Polling and LED Control This functionality is implemented through a custom function that continuously polls the button input. While waiting for user interaction, the LED toggles to indicate readiness. Once the button is pressed, the LED remains steadily lit, signaling progression to the I2C data transfer phase. I2C Master Handling The Handle_I2C_Master function is implemented using the driver APIs provided for the I2C peripheral in the NXP SDK. This function initiates the I2C transaction and manages the communication sequence. Interrupt handlers for both master and slave I2C instances are derived from the peripheral initialization code. At this stage, relevant interrupt flags are selectively enabled to support the specific behaviors required by the application. WaitForUserButtonPress Function To begin customizing the GPIO interrupt handler, open the Peripherals Config Tool within MCUXpresso IDE. From there, you can copy the auto-generated IRQ handler for GPIO, which serves as a reliable starting point. This code can then be modified to suit the specific requirements of your application. Sabina_Bruce_31-1763569354026.png To return to the code editor after configuring peripherals, click the “Develop” button located in the upper-right corner of the MCUXpresso IDE. Once in the development environment, paste the copied IRQ handler code into the main source file—ideally near the top—for easier access and organization. Sabina_Bruce_32-1763569354031.png Modifications were made to include a control variable within a while loop, allowing the application to pause execution until a button press is detected. This ensures that the program proceeds only after user interaction, aligning with the intended flow of the application. Sabina_Bruce_33-1763569354037.png The WaitForUserButtonPress function utilizes GPIO toggle and write operations to control the LED state, along with a delay mechanism to manage the blinking interval during the polling loop. To implement the delay, the SYSTICK timer is initialized and configured accordingly. Additionally, a global counter variable is introduced, along with the corresponding SYSTICK interrupt handler, to support time-based operations within the application. Sabina_Bruce_34-1763569354042.png Within the main() function, the SYSTICK timer initialization should be added prior to the button polling logic. This ensures that the delay mechanism is fully operational before entering the loop that waits for user input. Sabina_Bruce_35-1763569354044.png The finalized WaitForUserButtonPress function will include: GPIO operations to toggle and control the LED state. A while loop that continuously checks the button state and proceeds only upon detection of a press event. Sabina_Bruce_36-1763569354052.png The GPIO_* APIs are part of the NXP GPIO driver library and are used for various operations such as initialization, pin control, and interrupt handling. The macros highlighted in the code—typically shown in pink within the IDE—are generated by the Config Tools and defined in the pin_mux.h header file. The delay functionality used in the application is implemented through a custom SYSTICK-based function, as previously described. To explore the full set of available GPIO APIs, refer to the fsl_gpio.h header file. This file provides comprehensive support for GPIO operations, including port and pin-level control, configuration, and interrupt management. Customizing the I2C Interrupt Handlers To customize the I2C interrupt handlers in a manner similar to the GPIO handler, begin by opening the Peripherals Config Tool in MCUXpresso IDE. From there, locate and copy the auto-generated IRQ handler for I2C0. This serves as a foundational template that can be modified to meet the specific requirements of the application. Sabina_Bruce_37-1763569354056.png To return to the code editor, click the “Develop” button located in the upper-right corner of the MCUXpresso IDE. Once in the development environment, paste the copied I2C interrupt handler code into the main source file—preferably near the top—for better organization and accessibility. Sabina_Bruce_38-1763569354061.png Repeat the same process for I2C3 by copying its auto-generated interrupt handler from the Peripherals Config Tool. This handler can then be used as a base for customization, similar to the approach taken with I2C0. Consolidating I2C Interrupt Handlers In the original ST-based project, each I2C instance utilized two separate interrupt handlers: one for standard operations and another for error handling. However, the NXP MCU used in this migration provides a single interrupt vector per I2C instance, which handles both standard and error conditions. As a result, the functionality of the original four handlers must be consolidated into two—one for each I2C instance. This requires a careful review of the original interrupt logic to ensure that all relevant flags and behaviors are preserved in the merged implementation. For example, the slave handler in the original project checks for an address match flag and, upon detection, verifies readiness to receive data. The equivalent behavior in the NXP environment is implemented by monitoring the appropriate status flags within the unified interrupt handler, ensuring that both address recognition and data reception are handled correctly. Slave Handler Sabina_Bruce_39-1763569354077.png The I2C slave interrupt handler is triggered when the master device addresses the slave at 0x7E. Upon detecting this address match, the slave acknowledges the request and prepares to receive incoming data. The second part of the handler manages the data reception process. It handles each byte transmitted by the master, monitors for a NACK (Not Acknowledge) condition to signal the end of transmission, and stores the received data into a designated buffer. This ensures that the slave processes the communication sequence correctly and terminates the transfer gracefully once all data has been received. Master Handler Sabina_Bruce_40-1763569354092.png The I2C master interrupt handler monitors the Master Transfer Ready flag, which indicates that the peripheral is prepared to transmit the next byte of data. Upon detecting this condition, the handler checks the transmit buffer to determine if additional data remains to be sent. A counter is used to track the progress of the transmission. Using the appropriate Master Send operation, the handler transmits the next byte and advances the buffer pointer. When the final byte is sent, the handler issues a STOP condition to signal the completion of the data transfer sequence. Handle_I2C_Master Function The Handle_I2C_Master function is responsible for initiating and managing the I2C communication process. It begins by issuing a MasterStart command to initiate communication with the slave device at the specified address. Upon successful acknowledgment from the slave, the data transfer is handled through the corresponding interrupt routines. Sabina_Bruce_0-1763577716125.png This function also initializes the interrupt handlers for both the master and slave I2C instances. As previously noted, it is essential to enable interrupts after the master initiates communication to prevent premature interrupt triggering, which could disrupt the transaction sequence. Once the data transfer is complete and the slave has received all expected bytes, the function concludes by setting the LED to a steady state—indicating successful execution and the end of the application flow. Conclusion Migrating an application from the STM32 development environment to the NXP MCX platform using MCUXpresso IDE involves a structured and methodical approach. By leveraging the integrated configuration tools and understanding the functional equivalence between STM32 and NXP SDK components, developers can effectively transition their applications while maintaining performance and functionality. This guide has outlined the key steps involved in replicating an I2C-based application, including project setup, peripheral configuration, pin and clock initialization, and interrupt handling. While the tools provide a strong foundation through auto-generated code, careful consideration must be given to the sequencing and integration of initialization and runtime logic to ensure reliable operation. With a clear understanding of both environments and thoughtful adaptation of application logic, developers can streamline the migration process and take full advantage of the capabilities offered by the NXP MCX platform.    

Install CMSIS Device Pack After the MDK tools are installed, Cortex® Microcontroller Software Interface Standard (CMSIS) device packs must be installed to fully support the device from a debug perspective. These packs include things such as memory map information, register definitions and flash programming algorithms. Follow these steps to install the appropriate CMSIS pack. Please use MDK-Arm Microcontroller Development Kit (Keil)® version 5.38.1 or above. Open the MDK IDE, which is called µVision. Inside the IDE, select the "Pack Installer" icon Sabina_Bruce_0-1767115848769.png In the Pack Installer window, search for "MCXW" to bring up the MCXW71 family. Click on the MCXW7XX name, and then in the right-hand side you'll see the NXP:  MCXW71_DFP  pack. Click on the "Install" button next to the pack. This process requires an internet connection to successfully complete After the installation finishes, close the Pack Installer window and return to the µVision IDE Build the Example Application The following steps will guide you through opening the  hello_world  application. These steps may change slightly for other example applications as some of these applications may have additional layers of folders in their path. If not already done, open the desired demo application workspace in: <install_dir>/boards/<sdk_board_name>/<example_type>/<application_name>/mdk Select Debug configuration Sabina_Bruce_1-1767115880908.png Do right-click on the project and select the project options: Sabina_Bruce_2-1767115902529.png Now, go to the Debug option and select CMSIS-DAP ARMv8-M Debugger. Click on the OK button Sabina_Bruce_3-1767115924146.png To build the demo project, select the "Rebuild" button, highlighted in red Sabina_Bruce_4-1767115960650.png The build will complete without errors

Introduction This article describes the method to update the Boot ROM patch on MCX N23x devices to patch version T1.0.7 Before beginning, note that this process can only be performed via ISP mode of the device and can only be performed using a command line method.  The NXP Secure Provisioning tool uses command line operations in its backend and does make these available to the user.  For directions on how to access the command line interface through the Secure Provisioning tool, consult your Secure Provisioning Tool documentation.    Note: If in development lifecycle, perform a mass erase prior to updating ROM. Mass erase can be done by nxpdebugmbox -i pyocd cmd -f mcxn236 erase command from SPSDK.  Command line blhost method ISP Pin Method 1) With the device powered off, assert the ISP pin (GPIO P0_6) by pulling this pin low. 2) With ISP pin still asserted, power on the device.   3) After the device has fully powered on (at least as long as the t_POR time quoted in the Power mode transition operating behaviors table of the MCX N23x datasheet), release the ISP pin.  4) Open a command prompt and set the working directory to your blhost installation. 5) Verify that the current version of ROM patch is not T1.0.7 using this command: blhost <interface> <parameters> -- get-property 24.  a) Where <interface> should be replaced with the code for the interface type and <parameters> should be replaced with the parameters of that interface.  For more information on this syntax, refer to the blhost User's Guide.   6) Execute this command:  blhost <interface> <parameters> receive-sb-file <path_to_file_location>/mcx_n11_a0_prov_fw_rp_v7.0.sb3.  7) Repeat steps 1 - 5 to verify that the ROM version is T1.0.7.  ISP Pin Unavailable - SWD Method 1) Connect to target via SWD 2) Open the secure provisioning tool 3) Select the serial interface window and select the command line button 4) Send the following command: nxpdebugmbox -i pyocd ispmode -m 0 5) Verify that the current version of ROM patch is not T1.0.7 using this command: blhost <interface> <parameters> -- get-property 24.  a) Where <interface> should be replaced with the code for the interface type and <parameters> should be replaced with the parameters of that interface.  For more information on this syntax, refer to the blhost User's Guide.   6) Execute this command:  blhost <interface> <parameters> receive-sb-file <path_to_file_location>/mcx_n11_a0_prov_fw_rp_v7.0.sb3 7) Repeat steps 1 - 5 to verify that the ROM version is T1.0.7. 

1. RS485 hardware connection RS-485 is a multiple drop communication protocol in which the LPUART transceiver's driver is three-stated unless LPUART is driving. The transmitter can uses the RTS_B signal to enable the driver of a transceiver. The polarity of RTS_B can be configured by firmware to match with the polarity of the transceiver's driver enabling signal. The following figure shows the receiver enabling signal asserted. This connection can also connect RTS_B to both DE and RE_B. The transceiver's receiver is disabled when the uart transmitter is sending char. A pullup can pull RXD to a non-floating value during this time. You can refine this option further by operating LPUART in Single-Wire mode, freeing the RXD pin for other uses.   xiangjun_rong_0-1730685793982.png   When the uart transmits character via TXD pin, the RTS_b signal is asserted automatically, after the RS-485 transceiver, the urat transmitter can drive the differential signals Y/Z. When the uart dose not transmit character, the RTS_b signal is unasserted, so the RS-485 transceiver is in tr-state, the differential signal Y/Z is NOT driven by this RS-485 transceiver. For receiver part of the RS-485 transceiver, if the RTS_b sigbal is connected to the RE_b pin of receiver of RS-485 transceiver directly or via an inverter depending on the required logic of the RS-485 transceiver , when the uart transmits character, the receiver of  RS-485 transceiver is disabled, the RO pin of the RS485 is in tri-state, so a pull-up resistor is required on the RO pin and the RXD pin of LPUart can not receive any character from it’s own transmitter.  The RTS_B signal can function as hardware flow control, but note the application uses RTS_b signal to control RS485 enabling instead of hardware flow control. )   2. RTS_b pin assigmnet.   For the uart module of MCXN family, the FCx_P0 is RXD pin of UARTx module, the FCx_P1 is TXD pin of UARTx module, the FCx_P2 is RTS_b of UARTx module. xiangjun_rong_1-1730686061880.png For MCXN94x family, the P1_8 pin can function as FC4_P0 or RXD pin of UART4; the P1_9 pin can function as FC4_P1 or TXD pin of UART4; the P1_22 pin can function as FC4_P2 or RTS_b pin of UART4 with setting up PORT1_PCR22[MUX] bits as decimal 3; xiangjun_rong_2-1730686303719.png   3)software 3.1 pin assignment void BOARD_InitPins(void) {     /* Enables the clock for PORT1: Enables clock */     CLOCK_EnableClock(kCLOCK_Port1);       const port_pin_config_t port1_8_pinA1_config = {/* Internal pull-up/down resistor is disabled */                                                     kPORT_PullDisable,                                                     /* Low internal pull resistor value is selected. */                                                     kPORT_LowPullResistor,                                                     /* Fast slew rate is configured */                                                     kPORT_FastSlewRate,                                                     /* Passive input filter is disabled */                                                     kPORT_PassiveFilterDisable,                                                     /* Open drain output is disabled */                                                     kPORT_OpenDrainDisable,                                                     /* Low drive strength is configured */                                                     kPORT_LowDriveStrength,                                                     /* Pin is configured as FC4_P0 */                                                     kPORT_MuxAlt2,                                                     /* Digital input enabled */                                                     kPORT_InputBufferEnable,                                                     /* Digital input is not inverted */                                                     kPORT_InputNormal,                                                     /* Pin Control Register fields [15:0] are not locked */                                                     kPORT_UnlockRegister};     /* PORT1_8 (pin A1) is configured as FC4_P0 */     PORT_SetPinConfig(PORT1, 8U, &port1_8_pinA1_config);       const port_pin_config_t port1_9_pinB1_config = {/* Internal pull-up/down resistor is disabled */                                                     kPORT_PullDisable,                                                     /* Low internal pull resistor value is selected. */                                                     kPORT_LowPullResistor,                                                     /* Fast slew rate is configured */                                                     kPORT_FastSlewRate,                                                     /* Passive input filter is disabled */                                                     kPORT_PassiveFilterDisable,                                                     /* Open drain output is disabled */                                                     kPORT_OpenDrainDisable,                                                     /* Low drive strength is configured */                                                     kPORT_LowDriveStrength,                                                     /* Pin is configured as FC4_P1 */                                                     kPORT_MuxAlt2,                                                     /* Digital input enabled */                                                     kPORT_InputBufferEnable,                                                     /* Digital input is not inverted */                                                     kPORT_InputNormal,                                                     /* Pin Control Register fields [15:0] are not locked */                                                     kPORT_UnlockRegister};     /* PORT1_9 (pin B1) is configured as FC4_P1 */     PORT_SetPinConfig(PORT1, 9U, &port1_9_pinB1_config);       //* PORT1_22 (pin L4) is configured as FC4_P2 with ALT3*/       const port_pin_config_t port1_22_pinC3_config = {/* Internal pull-up/down resistor is disabled */                                                        kPORT_PullDisable,                                                        /* Low internal pull resistor value is selected. */                                                        kPORT_LowPullResistor,                                                        /* Fast slew rate is configured */                                                        kPORT_FastSlewRate,                                                        /* Passive input filter is disabled */                                                        kPORT_PassiveFilterDisable,                                                        /* Open drain output is disabled */                                                        kPORT_OpenDrainDisable,                                                        /* Low drive strength is configured */                                                        kPORT_LowDriveStrength,                                                        /* Pin is configured as FC4_P1 */                                                        kPORT_MuxAlt3,                                                        /* Digital input enabled */                                                        kPORT_InputBufferEnable,                                                        /* Digital input is not inverted */                                                        kPORT_InputNormal,                                                        /* Pin Control Register fields [15:0] are not locked */                                                        kPORT_UnlockRegister};        /* PORT1_9 (pin B1) is configured as FC4_P1 */        PORT_SetPinConfig(PORT1, 22U, &port1_22_pinC3_config); }   The   //P1_22 function as RTS_b signal void RTS_b_init(LPUART_Type *base) {  base->MODIR |=LPUART_MODIR_TXRTSE(1); //                   (((uint32_t)(((uint32_t)(x)) << LPUART_MODIR_TXRTSE_SHIFT)) & LPUART_MODIR_TXRTSE_MASK)   }   4)uart timing tested by scope xiangjun_rong_3-1730686359583.png   Conclusion: From the above scope screen shot, you can see that when the uart transmitter sends char, the RTS_b signal becomes low, so it can function as RS485 transceiver enabling signal.  

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   PMOD-Adapter-3Drender.png   This is how it looks connected to a FRDM-RW612 board  FRDM-RW612-PMOD-DisplaySmall.png enjoy!    

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” xiangjun_rong_0-1731589149867.png   1.2 Select the board or processor, then clock “Next” software button xiangjun_rong_1-1731589305914.png   1.3 Name the project and Select the driver. In the menu, it is okay to use default configuration, then clock “Finish” xiangjun_rong_2-1731589334564.png   1.4 A New project called MCXN947_project is created with C language xiangjun_rong_3-1731589357474.png   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” xiangjun_rong_4-1731589387456.png   1.6 Add the main.s as the following Fig and click “Finish” xiangjun_rong_5-1731589442105.png   1.7 The final project is like: xiangjun_rong_6-1731589491099.png   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 xiangjun_rong_7-1731589601652.png   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.

NXP officially launched the MCX C series chips in July 2024. As a Cortex-M0+ MCU with high cost-effectiveness, energy efficiency, and security, it strongly supports the upgrade of traditional 8-bit and 16-bit designs. Since its release, the chip has gained rapid favor among customers, with many projects now entering mass production. In practical applications, more and more customers have inquired about how to enter the ISP mode of MCX C series chips and complete firmware updates. We have previously introduced the method using the blhost tool (see MCX C: How to Enter the ROM Bootloader to Update the Firmware - NXP Community). It is worth noting that the MCUXpresso Secure Provisioning (SEC) tool now supports MCX C series chips starting from version 25.03. The operation process is described in detail below. Refer to the attached PDF file for details.

The table below contains notable updates to the current release of the Reference Manual. The information provided here is preliminary and subject to change without notice. Affected Modules Issue Summary Description  Date MCXNx4x Pinout xlsx Attachment Defeature PF* pins Erroneous pinouts to PF* signals on ALT11 are removed.  Before:  joseph_hernandez_0-1709937861704.png   After:  joseph_hernandez_1-1709937951033.png   01 March 2024 System Boot ROM API Missing Boot Modes sections in ROM API chapter of System Boot New sections added: 15.3 Boot modes 15.3.1 Master boot mode Master boot mode supports the following boot devices: Internal flash memory boot FlexSPI NOR flash memory boot SPI 1-bit NOR recovery boot Secondary bootloader boot Table 229. Image offsets for different boot media   Boot media Image offset Internal flash memory boot 0h FlexSPI NOR flash memory boot 1000h SPI 1-bit NOR recovery boot 0h Secondary bootloader boot 0h   15.3.2 Secondary bootloader mode   The Secondary bootloader mode can be enabled by setting the CMPA[BOOT_SRC] as 2, the image loaded in the Bank1_IFR0 region (0x0100_8000 to 0x0100_FFFF) will be set as primary boot mode, and the secondary boot image will boot first after the device reset. The secondary boot image type can be plain, crc or signed image, but cannot set as the SB file.   Based on the CMPA[OEM_BANK1_IFR0_PROT](0x01004004[5:7]) setting, after the secondary boot image boot, the Bank1_IFR0 region will be configured with different MBC setting:   Lifecycle CMPA[OEM_BANK1_IFR0_PROT] Secondary bootloader mode MBC IFR0 recovery boot MBC Develop (0x3) NA GLABC0 GLBAC0 Develop2 (0x7), In-field (0xF), In-field Locked (0xCF), Field Return OEM (1F) 0 GLBAC4 GLBAC4   1 GLBAC4 2 GLBAC2 3 GLBAC6 4 GLBAC4 5 6 7     01 March 2024 Input Multiplexing (INPUTMUX) Clarification to CMP trigger input registers Update to the CMPx_TRIG Register function description for the following registers: CMP0_TRIG (260h), CMP1_TRIG (4EOh), and CMP2_TRIG (500h)  Before:  Function This register selects the CMPx trigger inputs   After: Function This register selects the CMPx SAMPLE/WINDOW input 01 March 2024  

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.

1.Overview The NXP MCXN947 is a high-performance microcontroller that supports booting from either internal or external Flash memory. For most embedded applications, the on-chip Flash provides sufficient capacity to host both code and resources. However, in domains such as AI, image processing, or speech recognition—especially when deploying large neural network models with the eIQ toolchain—the size of the models can easily exceed the available internal Flash space. Although the MCXN947 supports executing directly from external Flash (XIP), the system typically boots from a fixed entry point in either internal or external Flash. This raises the question: can we combine the best of both worlds by booting from internal Flash while placing large resources or code segments in external Flash for direct execution? This article presents a demo implementation of exactly such a hybrid “internal boot + external XIP execution” scheme. The approach preserves fast and flexible system startup, while significantly expanding available storage capacity—ideal for hosting large AI models. Hardware Environment: Development Board: FRDM-MCXN947 Software Environment: IDE: MCUXpresso IDE v11.9.0 SDK: SDK Builder | MCUXpresso SDK Builder (nxp.com) Base Project: frdmmcxn947_tflm_cifar10 2. External Flash Hardware Configuration and Pin Assignment The FRDM-MCXN947 board integrates an external 8-line Octal Flash, connected to the MCU’s FlexSPI interface. The key pin assignments are as follows: Harry_Zhang_0-1756458008577.png Octal Flash Pin Function MCXN947 Connection HyperRAM Chip Pin Function Connected to MCXN947 CS SPI communication chip select signal P3_0 / FLEXSPI0_A_SS0_b SCK SPI communication clock signal P3_7 / FLEXSPI0_A_SCLK DQS SPI communication data strobe signal P3_6 / FLEXSPI0_A_DQS DQ0 OSPI data signal D0 P3_8 / FLEXSPI0_A_DATA0 DQ1 OSPI data signal D1 P3_9 / FLEXSPI0_A_DATA1 DQ2 OSPI data signal D2 P3_10 / FLEXSPI0_A_DATA2 DQ3 OSPI data signal D3 P3_11 / FLEXSPI0_A_DATA3 DQ4 OSPI data signal D4 P3_12 / FLEXSPI0_A_DATA4 DQ5 OSPI data signal D5 P3_13 / FLEXSPI0_A_DATA5 DQ6 OSPI data signal D6 P3_14 / FLEXSPI0_A_DATA6 DQ7 OSPI data signal D7 P3_15 / FLEXSPI0_A_DATA7 The configuration code begins with  /* Enables the clock for PORT3: Enables clock */ CLOCK_EnableClock(kCLOCK_Port3); const port_pin_config_t port3_0_pinB17_config = {/* Internal pull-up/down resistor is disabled */ kPORT_PullDisable, /* Low internal pull resistor value is selected. */ kPORT_LowPullResistor, /* Fast slew rate is configured */ kPORT_FastSlewRate, /* Passive input filter is disabled */ kPORT_PassiveFilterDisable, /* Open drain output is disabled */ kPORT_OpenDrainDisable, /* Low drive strength is configured */ kPORT_LowDriveStrength, /* Pin is configured as FLEXSPI0_A_SS0_b */ kPORT_MuxAlt8, /* Digital input enabled */ kPORT_InputBufferEnable, /* Digital input is not inverted */ kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ kPORT_UnlockRegister}; /* PORT3_0 (pin B17) is configured as FLEXSPI0_A_SS0_b */ PORT_SetPinConfig(PORT3, 0U, &port3_0_pinB17_config);   The same procedure is repeated for all FlexSPI pins. 3. FlexSPI Module Initialization To enable XIP from external Flash, the FlexSPI peripheral must be properly initialized.   3.1. Configure the FlexSPI clock /* Flexspi frequency 150MHz / 2 = 75MHz */ CLOCK_SetClkDiv(kCLOCK_DivFlexspiClk, 2U); CLOCK_AttachClk(kPLL0_to_FLEXSPI); /*!< Switch FLEXSPI to PLL0 */ 3.2 Initialize the FlexSPI driver Integrate the FlexSPI driver, which is provided in the SDK, into the project, /*Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.rxSampleClock = EXAMPLE_FLEXSPI_RX_SAMPLE_CLOCK; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; FLEXSPI_Init(base, &config); /* Configure flash settings according to serial flash feature. */ FLEXSPI_SetFlashConfig(base, &deviceconfig, FLASH_PORT); #if defined(EXAMPLE_FLASH_RESET_CONFIG) uint32_t TempFastReadSDRLUTCommandSeq[4]; memcpy(TempFastReadSDRLUTCommandSeq, FastReadSDRLUTCommandSeq, sizeof(FastReadSDRLUTCommandSeq)); #endif   4. Configure MCUXpresso Project to Support Octal Flash In MCUXpresso IDE, go to MCU Settings > Memory, and add a new memory region: Name: OSPI_FLASH (or OCTAL_FLASH) Start Address: Set according to the external flash address connected to your chip. According to the user manual, the FLEXSPI start address is 0x80000000. Harry_Zhang_1-1756458846963.png Size: For example, 128MB Next, select the corresponding external flash driver provided by NXP. The FRDM_MCXN947 board is connected to the mt35xu512aba flash, which supports SFDP, so we can choose MCXN9xx_SFDP_FlexSPI.cfx. After adding it, you will see the memory details displayed. Harry_Zhang_2-1756458878141.png 5. Add Linker Script and Migrate Model Data 5.1 Create Linker Script Fragments Add two files to the linkscripts/ folder in your project: text.ldt (for code sections) rodata.ldt (for model read-only data) Contents: <#if memory.name=="OSPI_FLASH"> KEEP (*(.model_data*)) KEEP (*(model.o*)) KEEP(*(.text.OSPI_FLASH*)) *(.text.QSPI_FLASH*) *(.text.${memory.alias}*) *(.text.${memory.name}*) </#if> This ensures that model data (e.g., the .model_data section) is properly retained and placed in the XIP (Execute In Place) region. 5.2 Place Model Data in XIP Region Use the following method to place the model into the .model_data section (in C code): __attribute__((section(".model_data"))) const unsigned char model_data[] = { #include "model_data.inc" }; Harry_Zhang_3-1756459055137.png 6. Build and Verify After building the project, the Image Memory Map Report in MCUXpresso IDE will show that parts of the .text and .rodata sections have been successfully placed into the Octal Flash (OSPI_FLASH) region. For example: Harry_Zhang_4-1756459105739.png OSPI_FLASH:      100144 B    262140 KB      0.04% After downloading and running the program, the system boots from internal Flash and successfully reads model data directly from external Flash, completing the AI inference task. Harry_Zhang_5-1756459182471.png   Conclusion Through the configuration steps introduced in this article, the MCXN947 successfully implements a hybrid storage solution combining internal boot with external XIP execution. This approach retains the advantage of fast boot speed while significantly expanding the available storage capacity for programs and models, providing strong support for deploying complex AI models. For resource-constrained MCU platforms, this architecture is not only a practical and feasible choice, but also represents an optimized strategy that is likely to be widely adopted in future embedded AI applications.

Clone an Example Project from MCUXpresso IDE The following steps will guide you through the manipulation of the general-purpose outputs. The example sets up a CTimer to generate a PWM signal and change between two LEDs. Find the Quickstart Panel in the lower left-hand corner and click on Import SDK example(s) Sabina_Bruce_14-1767120564749.png Click on the FRDM-MCXN947 board to select that you want to import an example that can run on that board, and then click on Next Sabina_Bruce_15-1767120575767.png Use the arrow button to expand the  driver_examples  category, then expand the ctimer examples, click on the check box next to  ctimer_match_interrupt_example  to select it. To use the UART for printing (instead of the default semihosting), Select UART as the SDK Debug Console checkbox under the project options. Then, click on Finish Sabina_Bruce_16-1767120587691.png Click on the  “frdmmcxn947_ctimer_match_interrupt_example”  project in the Project Explorer View and build, compile, and run the demo as described in the previous section Sabina_Bruce_17-1767120603466.png You should see the BLUE and RED LED changing back and forth Terminate the debug session Use MCUXpresso IDE Pins Tools to Modify Example   Note: Previously, you had to clone an SDK project like in the previous step. Open the pins tool by selecting “ConfigTools” on the top right hand of the file explorer window and then select “ Open Pins” Sabina_Bruce_2-1767120490131.png     The pins tool should now display the pin configuration for the ctimer project Sabina_Bruce_3-1767120490074.png     In the Pins view deselect “Show dedicated pins” and “Show no routed pins” checkboxes to see only the routed pins. Routed pins have a check in a green box next to the pin name. The functions selected for each routed pin are highlighted in green Sabina_Bruce_4-1767120490861.png   In the current configuration, PIO3_2 and PIO3_3 are routed as the outputs of the CTimer. Let’s add a third Ctimer Match output and enable the Green LED Select “Show no routed pins” to see the other options. To enable the third Ctimer Match Output, browse the column for Ctimer and select and output. In this example, we will select, Ctimer4 Match 2 on PIO3_6. Select the item in the Ctimer column to enable Sabina_Bruce_5-1767120490102.png   Now, let’s route the Green LED. In the search box type “green” so that the routed pin for this LED is shown. Finally, click the box under the GPIO column. The box will highlight in green, and a check will appear next to the pin Sabina_Bruce_6-1767120489892.png   Next configure the GPIO pin as an output in the “Routing Details” window Sabina_Bruce_7-1767120490064.png   Now it’s time to implement these changes into the project by exporting the new updated pin_mux.c and pin_mux.h files that are generated by the Pins tool. Click on Update Project in the menu bar Sabina_Bruce_8-1767120490018.png   The screen that pops up will show the files that are changing and you can click on “diff” to see the difference between the current file and the new file generated by the Pins tool. Click on “OK” to overwrite the new files into your project Sabina_Bruce_9-1767120490120.png   Let’s add some additional code to the example. Open  simple_match_interrupt.c  file and add the following macros for the third ctimer output. Sabina_Bruce_10-1767120489936.png   Add the Green LED functions as well. Sabina_Bruce_11-1767120491994.png   Some additional code to be implemented will be the third ctimer’s callback, this can be copied from  ctimer_match1_callback  and modify the content to match2. To be able to visually identify the new ctimer, we will remove one of the previous ctimers as shown Sabina_Bruce_12-1767120492171.png     The main function will need to include the initialization of both the Green LED and the Ctimer Sabina_Bruce_13-1767120490811.png   Build and download the project as done in the previous section Run the application. You should now see the Green and Blue LED blinking back and forth Terminate the debug session

Porting an ST Application   This section outlines the process of migrating an application developed in the STM32Cube IDE to the NXP MCUXpresso VSCode extension, using a compatible SDK for the target NXP MCU.   For users familiar with STM32Cube IDE, maintaining a similar development environment can ease the transition and reduce the learning curve. In this example, an I2C-based application originally developed for an STM32 device will be recreated and adapted for an NXP MCU.   The migration begins by creating a minimal project in MCUXpresso that includes the necessary I2C drivers. The original ST application utilizes two I2C instances for communication between components on the same board. To replicate this functionality, two sets of I2C pins must be initialized. Additionally, the application uses a push-button input and an LED output to demonstrate behavior changes, requiring the configuration of corresponding GPIOs using the MCUXpresso pin configuration tools.   MCUXpresso for Visual Studio Code MCUXpresso Installer In addition to the MCUXpresso extension, some extra tools and software are required for the full development flow within VS Code. All these dependencies are managed by the MCUXpresso Installer from QUICKSTART PANEL view. AleGuzman_0-1763583159128.png This launches the Installer UI, where an intuitive interface allows users to select from Software Kits, Debug Probes, Standalone Tools, or ARM components.   Using the MCUXpresso Installer, select MCUXpresso SDK Developer, LinkServer, SEGGGER J-Link, PEmicro, and MCUXpresso Configuration Tools then Click Install. AleGuzman_1-1763583205875.png Once all dependencies have finished installing, you can safely close the MCUXpresso Installer. Import Repository The first step in the MCUXpresso for VS Code development flow is to import an SDK software repository. Go to the MCUXpresso for VS Code extension Click Import Repository in the QUICKSTART PANEL AleGuzman_2-1763583252639.png Select MCUXpresso SDK, main revision, choose your SDK destination folder. When finished, click Import AleGuzman_3-1763583313362.png NOTE this import step takes a long time to clone. VS Code shows a progress bar pop-up with the status of the west tool as it clones all the repos. The repository should be added to the IMPORTED REPOSITORY view one the import is successful AleGuzman_7-1763583847603.png   Importing Example from Repository In the QUICKSTART PANEL click Import Example from Repository. AleGuzman_5-1763583445889.png Choose the following board settings to import a Freestanding application To select the board, type MCXA15 to find FRDM-MCXA156 Type hello to find the demo_apps/hello_world For application type, select Freestanding application Change the Name to frdmmcxa156_i2c Click Import and the example should be added to the PROJECTS view AleGuzman_6-1763583573264.png   In the PROJECTS window open Project Files --> prj.conf and add CONFIG_MCUX_COMPONENT_driver.lpi2c=y to add I2C driver support to your project. AleGuzman_0-1763584062725.png   To begin the migration, the main source file from the original ST project—as well as any custom source files not part of the standard ST driver set—should be incorporated into the new NXP project.   The following steps outline the initial project setup in MCUXpresso for VS Code: Upon creation, the project includes a basic "hello_world" example. This template can be used as a starting point. All content within the main source file—except for the initial macro definitions—can be replaced incrementally to integrate the application logic, allowing for a modular and controlled migration process. AleGuzman_1-1763584179044.png   Functions quick summary from ST project The next step involves transferring the main source file from the original ST project into the newly created MCUXpresso project. During this process, standard ST includes, and driver references are excluded, unless custom header files are required. In this case, no custom headers are used, so only the core application logic is migrated.   Many of the function calls within the ST source file rely on STM32-specific HAL APIs. These will be reviewed and systematically replaced with equivalent functions from the NXP SDK. The approach involves analyzing each function within the main() routine to understand its purpose and then substituting it with the corresponding implementation in the NXP environment. AleGuzman_2-1763584254190.png   Interrupt Priority Configuration Configures the microcontroller’s interrupt system to manage priority levels when multiple interrupts occur simultaneously. Power Peripheral Clock Enablement Activates the clock for the Power (PWR) peripheral, a prerequisite for configuring power management settings. Power Management Setup Initializes power management features of the STM32U5xx microcontroller to optimize energy efficiency and performance across internal components. System Clock Configuration Sets up the timing system of the microcontroller, configuring it to operate at a frequency of 160 MHz. Peripheral Initialization Establishes pin configurations and functional settings for peripherals. In this application, I2C1 is configured as the follower and I2C3 as the leader. LED Initialization Configures the LED to start in a low-active state, turning it on to indicate initial status or communication feedback. GPIO Polling for Button Press Continuously monitors the status of a GPIO input pin. If the button is not pressed, the LED blinks rapidly. Once pressed, the loop exits, and the LED remains on. I2C Communication Start Initiates the I2C communication process from the master side, triggering data transfer between the two I2C interfaces.   How is this handled in the NXP SDK? 1. Interrupt Priority Configuration This functionality is supported through CMSIS core NVIC functions and can be reused directly. It requires defining macros to establish the desired pre-emption priority levels. 2–4. Clock and Power Configuration These aspects are consolidated within the BOARD_InitBootClocks function, located in clock_config.c under the board folder. This function initializes both the system clock and power settings for the NXP MCU. 5. Peripheral and Pin Initialization Peripheral setup is divided across two functions: BOARD_InitBootPins (in pin_mux.c) handles pin configuration for I2C and GPIO. BOARD_InitBootPeripherals (in peripherals.c) manages I2C peripheral initialization and GPIO interrupt setup. 6. LED Initialization GPIO pins can be configured as output high or low depending on the desired initial state. The LED can be toggled or set using GPIO_PinWrite. 7. GPIO Polling for Button Press This behavior can be replicated using a custom polling function that utilizes GPIO_PinRead to monitor the button state. 8. I2C Communication Start The I2C master communication is initiated using LPI2C_MasterStart, which begins the data transfer process with the designated slave device.   Generate Initialization Code with MCUXpresso Config Tools Clocks VS Code extension works with Config Tools standalone. To access and use MCUXpresso Config Tools from the MCUXpresso extension in VS Code. In the PROJECTS view, right click on the project folder then select Open with MCUXpresso Config Tools AleGuzman_3-1763584254194.png   Config Tools will be open in a new window, because this is the first time the project is being open a config tools overview window will appear. Make sure the project has Pins, Clocks and Peripherals enabled; then click Close. AleGuzman_4-1763584254199.png   To configure the system clocks, open the Clocks tool through the menu Tools --> Clocks. AleGuzman_5-1763584254200.png   The clock diagram displays the supported configurations for the selected MCU. In this example, the device has a maximum core clock frequency of 96 MHz. As this meets the application's requirements, no modifications to the default clock settings are necessary. AleGuzman_6-1763584254203.png   To enable the peripheral clocks for the I2C instances, navigate to the clock configuration diagram within the MCUXpresso Config Tools. Scroll through the diagram to locate the available peripherals and activate the I2C modules by selecting the appropriate clock sources. AleGuzman_7-1763584254207.png   To configure the clock source for the I2C0 and I2C3 peripherals, double-click on the CLKSEL field associated with each instance in the clock configuration diagram. For this setup, select FRO_HF_DIV as the clock source for both I2C0 and I2C3. AleGuzman_8-1763584254208.png AleGuzman_9-1763584254209.png   Next, configure the clock divider by selecting the corresponding CLKDIV field in the clock configuration diagram. The details will appear in the top-right panel of the interface. To enable the clock path to the I2C peripheral, ensure the option divider /2 and Divider clock is running are selected. AleGuzman_10-1763584254214.png   At this stage, the I2C peripheral clocks have been successfully enabled. AleGuzman_11-1763584254216.png AleGuzman_12-1763584254218.png   Pins In the standalone MCUXpresso Config Tools go to Tools menu and choose Pins. AleGuzman_13-1763584254219.png   Using the filter functionality, search for available pins compatible with I2C instance 0. After reviewing the board schematic, pins P0_16 and P0_17 were selected, as they are accessible via a header. Assign the appropriate I2C functionality to these pins by selecting LPI2C0:SDA and LPI2C0:SCL from the configuration options. AleGuzman_14-1763584254225.png   Repeat the configuration process for I2C instance 3. Based on the board schematic, pins P3_27 and P3_28 are selected for this instance. Assign the appropriate functionality by selecting LPI2C3:SDA and LPI2C3:SCL within the pin configuration tool. AleGuzman_15-1763584254228.png   Once the pin selections are made, a configuration table is generated displaying the routing and settings for each pin. Within this table, use the routing details to configure the pins as required. For the I2C pins, enable internal pull-up resistors to ensure proper signal integrity during communication. AleGuzman_16-1763584254230.png   In addition to configuring the I2C pins, it is necessary to set up two GPIO pins—one for input and one for output. On this board, SW2 (P1_7) is designated for button input functionality, while P3_0 is assigned for LED output. AleGuzman_17-1763584254232.png AleGuzman_18-1763584254234.png   Within the routing details of the pin configuration table, define the behavior for both input and output GPIOs. Based on the application requirements, the output pin should be initialized to a logical low state (select Logical 0) to activate the LED. For the input pin, enable interrupt detection on a falling edge to register button presses accurately. AleGuzman_19-1763584254236.png Peripherals In the standalone MCUXpresso Config Tools go to Tools menu and choose Peripherals. AleGuzman_20-1763584874087.png   Select “Peripheral Drivers” to access the list of supported drivers available for the target device AleGuzman_21-1763584874088.png   GPIO1 Configuration To filter the available peripheral options, enter “GPIO” in the search field within the Peripheral Drivers view. Once the relevant options are displayed, click “OK” to proceed with the GPIO configuration. AleGuzman_22-1763584874090.png   To enable the interrupt functionality for P1_7, which is assigned to the button input, begin by selecting a new peripheral driver. Use the filter to search for GPIO, then choose the appropriate driver to activate the GPIO1 interrupt handler. AleGuzman_23-1763584874092.png   SYSTICK Select “Peripheral Drivers” to access the list of supported drivers available for the target device. AleGuzman_24-1763584874092.png   To filter the available peripheral options, enter “SYSTICK” in the search field within the Peripheral Drivers view. Once the relevant options are displayed, click “OK” to proceed with the 1ms periodic timer configuration. AleGuzman_25-1763584874095.png   Change the Clock source frequence to 24MHz and the interrupt period to 1ms AleGuzman_26-1763584874098.png   I2C Master and Slave Inside the peripheral configuration panel, look for Functional Group then click on Functional Group Properties AleGuzman_27-1763584874098.png In the Functional group properties window, look for Functional groups or Instances. Click Add a new functional group. AleGuzman_28-1763584874099.png   Change the new peripheral function group name to BOARD_InitLPI2Cs then click OK AleGuzman_29-1763584874100.png   Double check that BOARD_InitLPI2Cs function group is selected AleGuzman_30-1763584874101.png   I2C3 Leader/Master To configure the I2C peripheral, filter the available options by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one for your application and click “OK” to proceed. AleGuzman_31-1763584874103.png   Configure I2C3 as the master (leader) device and enable interrupt-driven data transfer. This setup allows the I2C3 instance to initiate communication and handle data transmission using interrupt mechanisms for improved responsiveness and efficiency. AleGuzman_32-1763584874108.png   Additionally, enable the interrupt handler for the I2C3 peripheral. Configure the appropriate priority level and activate the Transmit Data Ready flag to support interrupt-driven data transmission. AleGuzman_33-1763584874110.png   I2C0 Follower/Slave Configuration To configure the I2C0 follower peripheral, filter the available drivers by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one and click “OK” to proceed with the configuration. AleGuzman_34-1763584874112.png   Configure I2C0 as the slave (follower) device. Enable the interrupt-driven transfer method and specify the slave address to be used for communication. This setup allows the I2C0 instance to respond to master requests and handle data reception via interrupts. AleGuzman_35-1763584874116.png   Additionally, enable the interrupt handler for the I2C0 peripheral. Configure the appropriate priority level, validate the assigned follower address, and activate the Address valid, Receive data flag to support interrupt-driven data reception. AleGuzman_36-1763584874118.png   Apply Changes To apply and integrate the configuration changes into the project, click “Update Code.” AleGuzman_37-1763584874118.png   A new window will open to approve all the changes to the corresponding source files and ensure the new settings are reflected in the project structure. Click OK and go back to VS Code AleGuzman_38-1763584874120.png   File Structure The MCUXpresso configuration tools automatically generate source code based on the selected settings, streamlining integration into the main application. This generated code includes initialization routines for clocks, pins, and peripherals configured in previous steps. All generated files are under board directory within the project structure. AleGuzman_39-1763584874124.png   To add the all the source files under the board folder and make the directory path only visible to this target. Modify CMakeList.txt   AleGuzman_40-1763584874130.png 1. peripherals.c This file includes initialization code for peripherals configured via the Config Tools. In this example, it contains setup routines for both I2C instances and the GPIO interrupt. While the BOARD_InitPeripherals function can be used, it is often more effective to selectively integrate the generated code into specific locations within the application to align with the required execution sequence.   2. board.c When creating a project using an NXP development board, the default configuration includes initialization of debug UART pins for serial terminal communication. In this case, the UART functionality is not required, and the corresponding function in board.c will not be used.   3. clock_config.c This file contains all system clock configurations. Use the BOARD_InitBootClocks function to initialize the clock frequency and power mode settings. For this application, the system is configured to operate at 96 MHz.   4. pin_mux.c This file defines all pin configurations selected for the application, including I2C and GPIO assignments. Although UART pins are included by default, they are not utilized in this project. Use the BOARD_InitBootPins function to apply the pin settings.   Additionally, the original ST application includes a cache initialization function (MX_ICACHE_Init). In the NXP SDK, cache configuration is handled within the startup code. This can be reviewed in the SystemInit function located in system_MCU.c under the device folder. Replace Initialization Functions   AleGuzman_0-1763585600652.png 1. Clock and Pin Initialization In the main function of the NXP-based project, system clocks and pin configurations are initialized in the BOARD_InitHardware using the functions generated by the configuration tools: BOARD_InitBootClocks BOARD_InitBootPins   2. Peripheral Initialization Initialization code for peripherals is sourced from the peripherals.c file generated by the Config Tools. BOARD_InitBootPeripherals sets up the GPIO interrupt handler, including its priority level and NVIC configuration. And setups a 1ms SYSTICK periodic timer.   3. I2C Initialization Following this, the I2C master and slave instances are initialized along with their respective interrupt handlers and priority levels. At this stage, interrupt flags are not yet enabled; they will be activated later within the data transfer function to ensure proper sequencing and avoid premature interrupt triggering.   Source file peripherals.c includes a code snippet specifically for initializing the LPI2C0 peripheral for slave operations. This code can be selectively integrated into the main function or other appropriate locations within the application to align with the desired execution flow. AleGuzman_1-1763585600655.png   While the standalone configuration tools effectively generate the necessary initialization code, it remains the developer’s responsibility to determine the most appropriate placement of this code within the application. This decision should be guided by the operational sequence required by the specific protocol or peripheral being implemented.   For example, in I2C communication, data transfer is managed through interrupts. If the LPI2C0_Init function is used without consideration for timing, interrupts may trigger prematurely, resulting in incomplete or mismanaged transactions.   To ensure proper execution, the recommended sequence is: Initialize the peripheral and its associated interrupt handler. Start the I2C transaction. Enable interrupts for both master and slave operations.   In this application, the initialization is performed within the main() function, while the interrupt flags are selectively enabled later to maintain correct timing and control.   Initialize LPI2C To add LPI2C project settings like the slave address and data transfer length open the Kconfig file and add the following config menu AleGuzman_2-1763585600660.png   Add I2C prototypes and variables, that will be used in the I2C interrupt handlers and action functions AleGuzman_3-1763585600664.png   Replace Action Functions AleGuzman_4-1763585600666.png   4. SYSTICK Initialization The SYSTICK timer is configured to support delay operations within the application, such as controlling the LED blinking rate. Detailed instructions for initializing SYSTICK are provided in the following sections. 5. Button Polling and LED Control This functionality is implemented through a custom function that continuously polls the button input. While waiting for user interaction, the LED toggles to indicate readiness. Once the button is pressed, the LED remains steadily lit, signaling progression to the I2C data transfer phase. 6. I2C Master Handling The Handle_I2C_Master function is implemented using the driver APIs provided for the I2C peripheral in the NXP SDK. This function initiates the I2C transaction and manages the communication sequence. Interrupt handlers for both master and slave I2C instances are derived from the peripheral initialization code. At this stage, relevant interrupt flags are selectively enabled to support the specific behaviors required by the application.   WaitForUserButtonPress To begin customizing the GPIO interrupt handler, open the Peripherals Config Tool. From there, you can copy the auto-generated IRQ handler for GPIO, which serves as a reliable starting point. This code can then be modified to suit the specific requirements of your application. AleGuzman_5-1763585600669.png   In the VS Code development environment, paste the copied IRQ handler code into the main source file—ideally near the top—for easier access and organization.   Modifications were made to include a control variable within a while loop, allowing the application to pause execution until a button press is detected. This ensures that the program proceeds only after user interaction, aligning with the intended flow of the application. AleGuzman_6-1763585600672.png   The WaitForUserButtonPress function utilizes GPIO toggle and write operations to control the LED state, along with a delay mechanism to manage the blinking interval during the polling loop. To implement the delay, the SYSTICK timer is initialized and configured accordingly.   Additionally, a global counter variable is introduced, along with the corresponding SYSTICK interrupt handler, to support time-based operations within the application. AleGuzman_7-1763585600673.png   AleGuzman_8-1763585600674.png   Within the BOARD_InitBootPeripherals() function, the SysTick_init() timer initialization was added prior to the button polling logic. This ensures that the delay mechanism is fully operational before entering the loop that waits for user input. AleGuzman_9-1763585600676.png   The finalized WaitForUserButtonPress function will include: GPIO operations to toggle and control the LED state. A while loop that continuously checks the button state and proceeds only upon detection of a press event. AleGuzman_10-1763585600679.png   The GPIO_* APIs are part of the NXP GPIO driver library and are used for various operations such as initialization, pin control, and interrupt handling. The macros highlighted in the code—typically shown in pink within the IDE—are generated by the Config Tools and defined in the pin_mux.h header file.   The delay functionality used in the application is implemented through a custom SYSTICK-based function, as previously described.   To explore the full set of available GPIO APIs, refer to the fsl_gpio.h header file. This file provides comprehensive support for GPIO operations, including port and pin-level control, configuration, and interrupt management.   Customizing the I2C Interrupt Handlers To customize the I2C interrupt handlers in a manner similar to the GPIO handler, begin by opening the Peripherals Config Tool in MCUXpresso IDE. From there, locate and copy the auto-generated IRQ handler for I2C0. This serves as a foundational template that can be modified to meet the specific requirements of the application. AleGuzman_11-1763585600680.png   Repeat the same process for I2C3 by copying its auto-generated interrupt handler from the Peripherals Config Tool. This handler can then be used as a base for customization, like the approach taken with I2C0.   Consolidating I2C Interrupt Handlers In the original ST-based project, each I2C instance utilized two separate interrupt handlers: one for standard operations and another for error handling. However, the NXP MCU used in this migration provides a single interrupt vector per I2C instance, which handles both standard and error conditions.   As a result, the functionality of the original four handlers must be consolidated into two—one for each I2C instance. This requires a careful review of the original interrupt logic to ensure that all relevant flags and behaviors are preserved in the merged implementation.   For example, the slave handler in the original project checks for an address match flag and, upon detection, verifies readiness to receive data. The equivalent behavior in the NXP environment is implemented by monitoring the appropriate status flags within the unified interrupt handler, ensuring that both address recognition and data reception are handled correctly.   Slave Handler AleGuzman_12-1763585600685.png   The I2C slave interrupt handler is triggered when the master device addresses the slave at 0x7E. Upon detecting this address match, the slave acknowledges the request and prepares to receive incoming data.   The second part of the handler manages the data reception process. It handles each byte transmitted by the master, monitors for a NACK (Not Acknowledge) condition to signal the end of transmission, and stores the received data into a designated buffer. This ensures that the slave processes the communication sequence correctly and terminates the transfer gracefully once all data has been received.   Master Handler AleGuzman_13-1763585600689.png   The I2C master interrupt handler monitors the Master Transfer Ready flag, which indicates that the peripheral is prepared to transmit the next byte of data. Upon detecting this condition, the handler checks the transmit buffer to determine if additional data remains to be sent. A counter is used to track the progress of the transmission.   Using the appropriate Master Send operation, the handler transmits the next byte and advances the buffer pointer. When the final byte is sent, the handler issues a STOP condition to signal the completion of the data transfer sequence.   Error Callback When something goes wrong during the I2C communication, the Error_Callback function serves as an error handler doing two main actions. First, it shuts down the communication system by disabling the interrupts for both I2C instances. Second, it provides a clear visual indication to the user that an error has occur. AleGuzman_14-1763585600690.png   Handle_I2C_Master Function AleGuzman_15-1763585600694.png   The Handle_I2C_Master function is responsible for initiating and managing the I2C communication process. It begins by issuing a MasterStart command to initiate communication with the slave device at the specified address. Upon successful acknowledgment from the slave, the data transfer is handled through the corresponding interrupt routines.   This function also initializes the interrupt handlers for both the master and slave I2C instances. As previously noted, it is essential to enable interrupts after the master initiates communication to prevent premature interrupt triggering, which could disrupt the transaction sequence.   Once the data transfer is complete and the slave has received all expected bytes, the function concludes by setting the LED to a steady state—indicating successful execution and the end of the application flow.   Conclusion Migrating an application from the STM32 development environment to the NXP MCX platform using MCUXpresso involves a structured and methodical approach. By leveraging the integrated configuration tools and understanding the functional equivalence between STM32 and NXP SDK components, developers can effectively transition their applications while maintaining performance and functionality.   This guide has outlined the key steps involved in replicating an I2C-based application, including project setup, peripheral configuration, pin and clock initialization, and interrupt handling. While the tools provide a strong foundation through auto-generated code, careful consideration must be given to the sequencing and integration of initialization and runtime logic to ensure reliable operation.   With a clear understanding of both environments and thoughtful adaptation of application logic, developers can streamline the migration process and take full advantage of the capabilities offered by the NXP MCX platform.

The following steps will guide you through the hello_world demo application using MCUXpresso IDE for the Cortex-M33 application. The MCUXpresso IDE installation and the SDK for the MCXN-Series can be found at the section Get Software of this Getting Started guide. Find the Quickstart Panel in the lower left-hand corner.   Sabina_Bruce_1-1767118880216.png Then click on Import SDK example(s). Sabina_Bruce_2-1767118904196.png Click on the board you are using to select an example that can run on that board, and then click on Next. Sabina_Bruce_3-1767118948399.png   Use the arrow button to expand the demo_apps category, and then click the checkbox next to hello_world to select that project. To use the UART for printing (instead of the default semihosting), select UART as the SDK Debug Console checkbox under the project options. Then, click on Finish Sabina_Bruce_4-1767118968268.png Select the project and build it by either clicking on the “build icon” in the shortcuts provided above or by clicking “Build” in the Quickstart Panel Sabina_Bruce_5-1767118993960.png   The project should build without presenting any errors or warnings in the console Sabina_Bruce_6-1767119004337.png   Connect the board to your computer with the type-C USB cable to ‘MCU-LINK’ port. Check your board's user manual for instructions. Sabina_Bruce_7-1767119052616.png   Download the application to your board by either clicking on the “debug” icon above or clicking on “Debug” in the Quickstart Panel Sabina_Bruce_8-1767119086969.png   Select the MCU-Link CMSIS-DAP debug probe Sabina_Bruce_9-1767119109335.png  Open up a serial terminal to be able to see the application’s output. Select the “Terminal” window and press the “new terminal” icon Sabina_Bruce_10-1767119145379.png   Choose a “Serial Terminal” and then set the UART settings to 115200 baudrate, 8 bit data size, no parity and 1 stop bit. Press OK Sabina_Bruce_11-1767119154921.png   Run the application by pressing the “run” icon. See the output printed on the terminal Sabina_Bruce_12-1767119186546.png  

The following steps will guide you through opening the  hello_world  application. The instructions for compiling and debugging the Cortex M33 core are covered in the instructions below. Build an Example Application Please use IAR Embedded Workbench for Arm version 9.50.1 or above. First, unzip the previously downloaded FRDM-MCXW71 SDK package Open the desired example application workspace. Most example application workspace files can be located using the following path: <install_dir>/boards/<sdk_board_name>/<example_type>/<application_name>/iar Select the desired build target from the drop-down. For this example, select the "hello_world - debug" target Sabina_Bruce_1-1767115322919.png Open the project properties by doing a right-click on the project and selecting "Options" Sabina_Bruce_2-1767115378262.png Now, go to the "Debugger" section and change the debugger driver to CMSIS DAP. Press the OK button Sabina_Bruce_3-1767115394492.png To build the application, click the "Make" button, highlighted in red below Sabina_Bruce_4-1767115408772.png The build will complete without errors Sabina_Bruce_5-1767115443376.png   Note: In case of building errors, make sure that the correct board is selected, right-click in Project → Options → General Options → Target → Device. Select the NXP MCU you are using and is supported by the IAR version you have installed. Sabina_Bruce_6-1767115467787.png   Run an Example Application Connect the development platform to your PC via USB cable to 'MCU-Link' port Sabina_Bruce_7-1767115540901.png Click the "Download and Debug" button to download the application to the target Sabina_Bruce_8-1767115562027.png The application is then downloaded to the target and automatically runs to the main() function Run the code by clicking the "Go" button to start the application Sabina_Bruce_9-1767115576348.png The  hello_world  application is now running on the MCU.

The most recent versions of MCUXpresso IDE count with a terminal emulation application. This tool can be used to display information sent from your NXP development platform's virtual serial port 1. Open the MCUXpresso IDE   Sabina_Bruce_8-1767115105085.png 2. Launch the MCUXpresso IDE terminal by clicking on the "Open a Terminal" button on the top of the IDE or press "Ctrl + Alt + Shift + T" Sabina_Bruce_9-1767115121971.png 3. Select Serial Terminal   Sabina_Bruce_10-1767115141929.png 4. Configure the serial port settings (using the LPC-Link2 COM port number) to 115200 baud rate, 8 data bits, no parity and 1 stop bit, then press the "OK" button   Sabina_Bruce_11-1767115171111.png   5. Verify that the connection is open. If connected, MCUXpresso IDE will look like the figure below at the Terminal view   Sabina_Bruce_12-1767115197699.png   6. You're ready to go