Introduction Standard Trusted Firmware‑M (TF‑M) targets in Zephyr, including RW61x‑based platforms, assume the presence of BL2 (MCUboot) as the second-stage bootloader. BL2 is responsible for image authentication, upgrade handling, and flash layout enforcement. However, many NXP devices provide a ROM‑based secure boot / dual‑boot mechanism capable of authenticating firmware and directly transferring control to a secure image. In such cases, BL2 is redundant and can be disabled to reduce boot time and flash usage. This article describes how to disable BL2 in TF‑M and configure Zephyr to boot directly from ROM into the TF‑M Secure image, followed by the Non‑Secure application.   Typical TF‑M Boot Flow (With BL2) The default Zephyr TF‑M boot chain is: BootROM → BL2 (MCUboot) → TF‑M Secure → Non‑Secure application BL2: Owns the flash layout (primary/secondary slots) Performs image authentication Manages firmware upgrades Example with samples/tfm_integration/config_build   Target Boot Flow (ROM Boot, No BL2) When using the ROM bootloader: BootROM → TF‑M Secure → Non‑Secure application In this scenario: ROM performs authentication and version checks TF‑M Secure becomes the first executable stage No firmware swapping or secondary slots are required Example with samples/tfm_integration/config_build   Disable BL2 in TF‑M Kconfig Changes Disable BL2 explicitly in the project configurations and update the base address: CONFIG_TFM_BL2=n CONFIG_FLASH_BASE_ADDRESS=0x80A0000   This removes MCUboot from the build and prevents generation of BL2 artifacts.   Secure Image Entry Requirements When BL2 is removed, the ROM must jump directly to the TF‑M Secure vector table. Ensure that: The Secure image is linked at the ROM‑expected address The Secure vector table is valid The Secure reset handler init No BL2 handoff logic is required.   Non‑Secure Image Considerations The TF‑M Secure image will transfer control after initialization. Built as a direct‑boot Zephyr application No MCUboot headers Linked at the Non‑Secure offset defined in the partition layout   Dual Boot Enablement (ROM‑Managed A/B Images) On RW61x‑class devices, the ROM expects the Secure image to start at offset 0x1000 within a bootable slot, with the Non‑Secure image located at offset 0xA0000 . Each boot slot therefore contains a complete Secure + Non‑Secure pair at fixed offsets. The ROM authenticates the slot, jumps to the Secure offset, and TF‑M later transfers control to the Non‑Secure image. BootROM ├─ Authenticate Slot 0 → Secure@+0x1000 → Non‑Secure@+0xA0000 └─ Authenticate Slot 1 → Secure@+0x1000 → Non‑Secure@+0xA0000 No BL2 or runtime image swapping is involved.     Example Flash Layout (Corrected) Slot 0 Slot 0 Base : 0x08000000 Secure Image (0) : 0x08001000  Non‑Secure Image 0 : 0x080A0000    Slot 1 Slot 1 Base : 0x08200000 Secure Image (1) : 0x08201000  Non‑Secure Image 1 : 0x082A0000   Each slot is independently bootable and contains no shared state with the other slot.     ROM Boot Expectations For each slot, the ROM expects: Slot authentication data (signature / manifest) A valid Secure vector table at slot_base + 0x1000 A valid Secure reset handler The ROM never jumps to Non‑Secure directly.     Using the SEC tool to enable dual boot  First we'll create two images one for slot 0 and one for slot 1. The difference will be noted in the text of the non-secure image.  1. Build Zephyr Images (Slot‑A and Slot‑B) For each slot, build: TF‑M Secure image (linked at +0x1000 ) Zephyr Non‑Secure image (linked at +0xA0000 ) Slot 0, I modified the non-secure image to print a quick message identifying the slot it was programmed in.  Slot 1, I modified the non-secure image to print a quick message identifying the slot it was programmed in.  Using the SEC tool, we will use the "Merge Tool" to merge the secure and non-secure binaries with the appropriate offset. 2. Merge Secure + Non‑Secure Images ROM expects one contiguous image per slot, not two independent binaries. In SEC Tool: Open Merge Tool Select: Secure binary(without boot header) → offset 0x1000 Non‑Secure binary → offset 0xA0000 Output a single merged image * If you are using the kconfig options as described above, the FCB will be attached to the secure binary, therefore please ensure that your offset for secure binary considers the FCB location which is offset 0x400 Do this for both slot images. In this example I created merged_imaged_slot_0 and merged_image_slot_1.   3. Assigning Version Metadata Dual‑boot selection is driven entirely by ROM metadata. For each merged image: Set Image Version Example: Slot A version: 1 Slot B version: 2 ROM rules are typically: Boot highest valid version Use fallback slot if authentication fails   Select the merged image for the slot you would like to program first. Select the version that will be used with that slot.    Next, open "Dual Image Boot"   For Slot 0, select "Image 0" and select the offset you would like to use for the slot division. For Slot 1, select "Image 1".   4. Program Slot 0 (Initial Boot) Program Slot 0 only Reset device Expected behavior: ROM authenticates Slot 0 ROM jumps to slot 0 + 0x1000 TF‑M Secure initializes Non‑Secure app runs ✅ Confirms your Secure → Non‑Secure chain works without BL2   5. Program Slot 1 (Upgrade Test) Program Slot 1 Update slot metadata (version > Slot 0) Reset device Expected behavior: ROM selects Slot 1 Slot 1 Secure executes Slot 1 Non‑Secure message appears   Common Mistakes to Avoid Merging images at wrong offsets ( 0x0 instead of 0x1000 ) Forgetting to bump the version for Slot B Leaving MCUboot headers enabled Assuming TF‑M controls slot selection   Conclusion Disabling BL2 in TF‑M and booting directly from ROM is a valid, efficient, and production‑ready configuration when the device ROM already provides secure boot and dual‑boot services. In this architecture, the ROM is the authority for authentication, version selection, and rollback, while TF‑M Secure becomes the first executable firmware stage. When combined with ROM‑managed A/B dual boot, this approach provides: Independent, fully self‑contained Slot A and Slot B images Deterministic boot behavior based on ROM policy (version or fallback) Secure rollback without runtime image swapping No dependency on MCUboot or BL2 infrastructure The key requirements for success are: Explicitly disable BL2 in TF‑M Link the Secure image at the ROM‑required offset ( +0x1000 ) Link the Non‑Secure application at the fixed Non‑Secure offset ( +0xA0000 ) Merge Secure and Non‑Secure binaries into a single slot image Use the SEC tool to: Assign image versions Enable dual‑boot policy Authenticate and sign each slot image In this model, TF‑M and Zephyr are slot‑agnostic: they do not manage upgrades, slot selection, or rollback. All boot decisions are made before execution begins, by the ROM, based on SEC‑provided metadata. This design reduces boot time, simplifies flash layouts, removes firmware‑swap complexity, and aligns well with high‑reliability production systems where firmware updates are performed out‑of‑band and enforced by ROM‑level security.

This attachment includes the presentation content and hands-on lab guides for this session, used at trainings including the NXP Technology Days.  The labs are also available at this MCUXpresso documentation lab. Return to Zephyr Knowledge Hub

If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. Custom board The Zephyr repository includes support for dozens of NXP development boards.  When creating a custom board, it is best to start with the closest development board using an SOC from the same family, clone that board folder, rename as the new board, and modify to match the hardware.  More resources for custom boards include: See NXP's application example with custom board create-zephyr-app-repo Zephyr Project Board Porting Guide NXP blog: Creating a Custom Zephyr Board for the i.MX RT685 See section "Generating a board pinctrl" on this page If changing memory settings from the cloned development board, see Memory details with Zephyr. Clock Configuration in Zephyr With MCUXpresso for VS Code and custom boards, see Using Out-of-Tree Boards. Unsupported SOC part number A common challenge when creating a custom board is that not every SOC part number sold by NXP is supported in Zephyr today. Support in Zephyr is based on boards, not directly by SOCs.  A board name must be specified when building a Zephyr application.  Then the board files include the SOC used on that board.  These are the NXP boards supported in Zephyr.  The Zephyr documentation framework does not have similar pages for SOCs. NXP contributes Zephyr support for development boards.  One development board usually supports a family of SOCs.  The development board usually has the superset SOC on the board, which offers the most features/memory of that family.  For example, MIMXRT1060-EVK board is used to develop with the i.MX RT106x family, and uses the superset RT1062 part number.  Other part numbers in a family are very similar to the superset, but may lack some features, have less memory, or less pins in a smaller package. Since Zephyr support is based on boards, and the SOCs on the boards are supported, today there are many other similar SOC part numbers that are not directly supported in Zephyr.  Here are some options to manage this when creating a custom board: Base the custom board on the development board supported in Zephyr, and use the same SOC part number on the custom board.  That SOC is already available in Zephyr to enable the development board. Use an SOC in the same family on the circuit board, but configure the Zephyr custom board to use the superset SOC on the development board.  For example, the circuit board uses an RT1061 part number, but the custom board files use the same RT1062 part number from the MIMXRT1060-EVK.  The advantage of this option is Zephyr does not require any additional SOC support.  The superset likely has all the features and memory available for the SOC on the circuit board.  Then the custom board files can modify the devicetree and Kconfig by disabling peripherals that are not available, and reducing memory sizes as needed.  SOC pinctrl files are available for most SOCs in supported families, found in the HAL_NXP repo.  Usually the custom board can include the SOC pinctrl file for the exact part number used. Use an SOC in the same family, but contribute all the SOC files needed in Zephyr.  For example, the circuit board uses an RT1061 part number, so the developer adds the RT1061 part number option to the Zephyr repo, and configures the custom board to use that RT1061 part number.  This option requires more effort and some comfort with the Zephyr repo, but some Zephyr users may prefer this option.  And if a new SOC is enabled like this, it can be contributed upstream to the Zephyr repo. The SOC options discussed above assume a board for the SOC family is already supported in Zephyr, which enables at least one SOC in that family.  If trying to port Zephyr to a new family of SOCs with no board support, that can take significantly more effort.  To minimize porting effort, it is best to start with a family of SOCs already supported on a board. Pinctrl Zephyr uses pinctrl to configure the pins and pinmux settings of an SOC.  Typically, each board has a pinctrl file with the default pinctrl settings for that board.  For example, this is the mimxrt1060_evk-pinctrl.dtsi.  NXP also has pinctrl files for each SOC, like mimxrt1062dvl6a-pinctrl.dtsi.  The SOC pinctrl files are located in the HAL_NXP repo and provide all the pinmux options for each pin, which makes it easier and more readable to select the pinmux option in the board pinctrl file.  For the NXP boards, the board pinctrl file includes the SOC pinctrl file like this: #include <nxp/nxp_imx/rt/mimxrt1062dvl6a-pinctrl.dtsi> Generating a board pinctrl New board pinctrl files are usually created when creating a new board.  Board pinctrl files can always be created by hand.  But generating the file can be convenient, especially since NXP offers the Pins Tool included in the MCUXpresso Config Tool.  The Pins Tool has a GUI to help select all the desired signals used by the application, and configure the pinmux and pin settings.  Starting with release v25.03, the Config Tool can generate Zephyr board pinctrl files for the i.MX RT1xxx and MCX devices.  More devices supported in Zephyr will be added in later releases.  To learn how to generating a board pinctrl file, see the Config Tool User Guide. For other devices not yet supported in the Config Tool, NXP has a Python script to help generate a board pinctrl file.  These scripts will eventually be replaced by the Config Tool and deprecated.  The script uses the same Config Tool above to configure the pins of a board, and then extracts the pin information from a file and generates the board pinctrl file.  The scripts are included in the HAL_NXP repo and documented with this Readme. If generation is not an option, then the board pinctrl must be hand written.  The best option is to find a board pinctrl file for a similar SOC, and modify as needed. New out-of-tree application The Zephyr repository is full of samples and tests applications, which are helpful to learn how to use a driver, subsystem, or module.  When creating a new application, a new Git repo can be created for the app, and West can be used to pull in the Zephyr repo as a module.  Applications frequently use West’s T2 Star topology with Zephyr.  These example repos are a good reference when creating your application repo See NXP's application example create-zephyr-app-repo Zephyr Project’s example-application repo, includes an out-of-tree board and driver NXP repository of Zephyr demos and examples NXP Pro Support repository of Zephyr examples   Return to Zephyr Knowledge Hub

Here are some resources to learn more about Zephyr: Taking you through all the Zephyr environment setup steps with MCUXpresso for VS Code and the MCUXpresso Installer, this NXP Getting Started with Zephyr beginner's tutorial will take you through to building and running your first Zephyr application.  This step-by-step lab guide (from NXP Tech Day trainings) starts with "Hello, World" then walks you through helpful tutorials on Kconfig, Device Tree and debug methods:  Hands-On Workshop: Developing with Zephyr™ OS in Visual Studio Code This tutorial shows the power of the portability that Zephyr brings. Simple steps are shown to port an LVGL demo from FRDM-MCXN947 to the FRDM-RW612:  NXP Zephyr display portability demo Looking for more? Visit the Training section of our Zephyr landing page to find NXP webinars and online training - just click the “Training” tab at top of the page Return to Zephyr Knowledge Hub

The Zephyr SDK is a set of build tools for building Zephyr applications. It includes GCC and CMake, and each Zephyr release is tied to a specific Zephyr SDK version. This version is noted in the SDK_VERSION file in the Zephyr repository. Using the recommended Zephyr SDK version is important—mismatched versions can cause build errors. For example, Zephyr v4.1 specifies Zephyr SDK v0.17.0. If you use Zephyr SDK v0.17.2 (meant for Zephyr v4.2) with Zephyr v4.1, you’ll encounter build errors. If you need to build apps for Zephyr v4.1, install Zephyr SDK v0.17.0. You can install multiple Zephyr SDK versions and switch between them at build time (see instructions below). Full vs. Minimal Install Full Install: Includes all toolchains for every supported SoC architecture. Recommended for beginners but requires more disk space and download time. Minimal Install: Lets you choose only the toolchains you need. Saves space and time. For Minimal install, run the setup.cmd script to select which tools to install.  On NXP boards, select: Register Zephyr SDK CMake package Install host tools aarch64-zephyr-elf (64-bit ARM) arm-zephyr-eabi (32-bit ARM, including NXP MCUs) optional  xtensa-nxp… (Cadence Tensilica DSP cores) Installing Zephyr SDK These steps cover installing the Zephyr SDK using the MCUXpresso Installer, West from CLI, or manual download. Installing with MCUXpresso Installer The MCUXpresso Installer started supporting packs for Zephyr with Zephyr v4.2.  Each pack installs the matching Zephyr SDK version (e.g., v4.2 pack installs SDK v0.17.2).  This option Installs a minimal set of tools for NXP development.   The MCUXpresso Installer does not support older Zephyr SDK versions. For v0.17.1 or earlier, use West or manual install. Installing with West CLI Zephyr Project added Zephyr SDK installation to West. For CLI, Activate your Python Virtual Environment, then run: west sdk install --version 0.17.0   If --version is omitted, West uses the version in the SDK_VERSION file of the Zephyr repo. By default, installs the Full package. For minimal, add -i . Installing by Manual Download Download the Zephyr SDK from the https://github.com/zephyrproject-rtos/sdk-ng/releases. Choose Full or Minimal for your host OS. Extract to your user folder (default location for West and MCUXpresso): Windows: C:\Users\<username>\zephyr-sdk-0.17.0 Ubuntu: /home/<username>/zephyr-sdk-0.17.0 Selecting Zephyr SDK Version Multiple Zephyr SDK versions can coexist. West uses the latest by default, but you can override it: VS Code: When importing examples, select the Zephyr SDK version in the wizard. CLI: Set the environment variable ZEPHYR_SDK_INSTALL_DIR  before building.  This command sets that variable in Ubuntu: export ZEPHYR_SDK_INSTALL_DIR="/home/<username>/zephyr-sdk-0.17.0" Or in Windows: set ZEPHYR_SDK_INSTALL_DIR= C:\Users\<username>\ zephyr-sdk-0.17.0   Return to Zephyr Knowledge Hub    

Recently some Windows users started reporting issues installing the Zephyr SDK, required for building Zephyr applications.  Users first ran into this issue using NXP's MCUXpresso Installer, but had the same issue trying to manually install the Zephyr SDK. The root cause is that setup.cmd and these other tools use wget to download the individual toolchain packages.  And apparently recent changes in Windows or security settings interpret this wget download as unsecure, and wget is blocked. Context The Zephyr SDK is a package of multiple toolchains that support all the hardware platforms and CPU architectures available in Zephyr.  The binary bundle releases for download are available in two options: Minimal and Full.  For example, these bundles can be downloaded here for v0.17.4, currently the latest release. The Full bundle is a large download and includes all the toolchains and other tools in that download package.  The Minimal bundle is much smaller and does not contain any toolchains and allows users to choose the toolchains to download and install.  Minimal has an extra step after download to run the setup script and the user selects the tools to download.  In Windows, this script is setup.cmd. If installing the Minimal bundle and wget downloads are blocked for setup.cmd, then the Zephyr SDK install fails.  MCUXpresso Installer v25.12 and other install options use the Minimal bundle, and can be blocked by this issue. Workaround NXP is working on improving the MCUXpresso Installer to address this issue.  But in the meantime, downloading and installing the Full bundle avoids using wget and avoids this issue.   Download the Full bundle, here for v0.17.4, and extract the bundle in your user folder.  After extracting, the full Windows path will be  C:\Users\<username>\zephyr-sdk-0.17.4 .  West and other build tools will find this folder during the build.  The Zephyr SDK can also be installed elsewhere using an environment variable, see the Zephyr SDK documentation.  After extracting, run the setup.cmd to finish setup.  But with the Full install, setup.cmd will not need to download with wget. Be aware, this article was written when v0.17.4 was the latest release of the Zephyr SDK.  Check here for the latest release. Return to Zephyr Knowledge Hub

This page is a summary of helpful resources that are frequently referenced by those learning and developing with Zephyr on NXP platforms.  If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. Installing Zephyr and Getting Started NXP provides the MCUXpresso extension for Visual Studio code, and this is the quickest option to learn and use Zephyr on NXP platforms.  Get started with this MCUXpresso for VS Code documentation, and the Zephyr lab guide for Installation and Preparation.  These guides leverage the MCUXpresso Installer, which can install all the tools and dependencies needed to develop and debug Zephyr applications.  For issues installing the tools and setting up the build environment, see this Installation and Troubleshooting FAQ.  Once installed, more Zephyr lab guides show the basics with VS Code to import examples, build and debug applications. VS Code or the MCUXpresso extension are not required to develop with Zephyr, and many users prefer using command line.  See Zephyr Project’s Getting Started guide for that option. NXP also provides a downstream ecosystem called the Zephyr Software Developement Kit (ZSDK).  To learn more, see Introduction to ZSDK Downstream and ZSDK Getting Started. Links to other Knowledge articles: Zephyr Project documentation Development Tools Device support in Zephyr Training Build and Configuration System, like Devicetree and Kconfig NXP Application Notes – click the “Documentation” tab at top of the page Getting Support / asking for Help: MCUXpresso for VS Code community forum Zephyr NXP Support community forum NXP Application Code Hub Custom boards and applications, and pinctrl Memory Peripherals and drivers Zephyr modules, subsystems and features Contributing to Zephyr

Anyone can Contribute to Zephyr, but all contributions must comply with the Coding Style Guidelines.  This list includes some resources for contributing: Configuring VS Code editor for Zephyr coding style guidelines To contribute, propose changes by submitting a Pull Request (PR), see Contributor Expectations (more to come) Return to Zephyr Knowledge Hub

Anyone can Contribute to Zephyr, but all contributions must comply with the Coding Style Guidelines.  The editor in Visual Studio Code can be configured to help with these style guidelines.  This article details how to configure the editor. In VS Code, go to File→Preferences→Settings (or use CTRL + , to open them directly). Note that these setting changes can also be restricted to the Zephyr workspace by switching the Settings tab selection from "User" to "Workspace" if desired. The following settings help with Zephyr's style guidelines: Editor: Tab Size: set to 8 Editor: Insert Spaces: turn off Files: Trim Final Newlines: turn on Files: Trim Trailing Whitespace: turn on C_Cpp: Dim Inactive Regions: turn off Return to Zephyr Knowledge Hub

If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. Bootloaders Zephyr includes the open-source MCUboot bootloader as a module, and makes it easy to use as a bootloader for Zephyr applications. MCUboot and Zephyr on NXP i.MX RT series Building a sample with MCUboot and Sysbuild, and  Zephyr app with MCUboot in VS Code.  More advanced MCUboot RAM Loading with Zephyr. Zephyr MCUBoot + TF-M Inter-Processor Communication (IPC) and Multicore Zephyr includes an IPC subsystem.  Zephyr also integrates the open-source OpenAMP framework for communication between cores using the RPMsg protocol. Zephyr OpenAMP multicore sample RT1170 Building a dual-core image Zephyr networking stack on i.MX RT1170 Cortex-M4 secondary core Multicore performance LVGL graphics Zephyr integrates LVGL as a module, provides samples, and makes it easy to use LVGL in a Zephyr app. LVGL sample apps in the Zephyr repo List of NXP and other display shields in Zephyr Adding a display shield as a Cmake argument in MCUXpresso for VS Code GUI Guider example with Zephyr and MCUXpresso for VS Code Networking stack Zephyr includes a native networking stack. Networking IP over USB CDC NCM   Power Management (PM) Zephyr includes a Power Management subsystem, supported on many NXP SOCs. Webinar: Accelerate Development with Zephyr OS Features and Modules NXP SmartWatch demo and webinar: minimizes power consumption on the i.MX RT500 PSA and Trusted Firmware (TF-M) Example TF-M PSA crypto on FRDM-RW612 Zephyr MCUBoot + TF-M Adding a non-secure region in TF-M based in Zephyr on FRDM-RW612 Startup code and process For portability, Zephyr manages startup code that is not included in the application.  The SOC, memory, device drivers, and some subsystems are initialized before main(). Webinar: Application Portability Made Easy With Zephyr OS and NXP Adding custom startup code   Return to Zephyr Knowledge Hub

If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. One of the popular reasons developers choose Zephyr is the large offering of drivers and peripheral support.  The best place to look for the latest drivers and features supported on a hardware platform, is on the board’s documentation page.  For example, this Supported Features table lists the latest support for the FRDM-MCXN947 board.  Here are the links to these pages for all the boards with Zephyr support. NXP’s Hardware Abstraction Layer (HAL) is based on the MCUXpresso SDK drivers.  To learn more, see the blog Zephyr Software Code Reuse with NXP MCUXpresso SDK.  Most users want to use the Zephyr driver APIs in their application for portability.  But if a Zephyr driver is not supported on a platform, or if there is no Zephyr driver for a hardware peripheral, another option is Using MCUXpresso SDK drivers in Zephyr app. Peripheral Clocks: Most peripheral clocks are enabled in SOC or board source files, see Clock Configuration in Zephyr.  One common issue Zephyr users have when enabling or adding a peripheral instance on their board, is that instance is not clocked properly.  Below are some helpful resources for specific peripherals and drivers: Accelerators and Coprocessors PowerQuad Appnote AN13970 Running Zephyr RTOS on Cadence Tensilica HiFi 4 DSP Analog to Digital Converter (ADC) Zephyr sample die_temp_polling to measure temperature Displays Most displays are enabled in Zephyr as shields, which are add-on hardware modules.  See Zephyr’s list of shields. Typically a board page will document a display shield it has been tested with.  For example, the FRDM-MCXN947 board page includes the LCD_PAR_S035 display shield. The shield page gives instructions how to include that shield in the build, and add to the application.  For example, see the LCD_PAR_S035 shield page.  If building with VS Code, see the CMake wiki.  Zephyr has a couple samples that use displays, including the display driver sample and the LVGL demo. Direct Memory Access (DMA) When using a DMA, be aware of cache coherency, and make sure buffers accessed by DMA are not in cacheable memory.  This includes when using other drivers that use DMA, like I2S, SPI, UART, etc..  A good reference for placing buffers in non-cacheable memory is the spi_loopback test. Inter-Integrated Circuit (I2C) The Zephyr repo has a couple I2C sample applications, but because these depend on I2C targets in hardware, these samples are enabled on a small number of boards.  Here is a list of other I2C references: i2c_target_api test – this is the primary test NXP uses to test I2C on the supported boards.  This is a loopback test using two I2C peripherals.  One is configured as a controller, and the other as a target which emulates an EEPROM.  For this test to pass, usually the I2C signals must be shorted to connect the two I2Cs.  For the list of supported boards, see the testcase.yaml. Sensor samples – many NXP evaluation boards include sensors on the I2C bus.  Depending on the board, there may be some sensor sample apps.  For example, the accelerometer trigger and accelerometer polling samples are supported on many NXP boards.  For the list of supported boards, see the accel_trig/boards folder or the accel_polling sample.yaml. I2c_shell – this is not a sample app, but a shell feature that is easy to add to an app.  If there is no driver or example available to communicate with an I2C target, this feature can be helpful to test out the communication.  Through the shell, I2C controllers can scan for targets and send read/write commands to them.  Golioth shared this great blog on i2c_shell with all the details.  Inter-Integrated Circuit Sound (I2S) The I2S drivers are tested using Zephyr’s i2s_speed test.  That is a loopback test, and some boards require changes to connect the signals for the test to pass, see the readme. Networking includes Ethernet MIMXRT1170-EVK Zephyr Network Performance Zephyr networking stack on i.MX RT1170 Cortex-M4 secondary core Serial Peripheral Interface (SPI) The SPI driver is tested with Zephyr’s spi_loopback test.  This test is also a good reference for the options to place DMA buffers in non-cacheable memory, see DMA above. With Zephyr’s SPI driver, the SPI Controller can drive the chip select signal using the hardware peripheral or by software in the driver using a GPIO.  To learn more, see Hardware chip select vs GPIO.  There are some simple SPI examples showing this, see the LPSPI hardware chip select example, and the LPSPI GPIO chip select example. The SPI timing parameters can be configured in devicetree, see the LPSPI timing parameter example. Universal Serial Bus (USB) USB Host As of 12/19/2025: USB Host support in Zephyr is very limited, and there is on-going work to enable more.  This tracker ticket details the current status and plans for USB Host support.   USB Device is supported, and Zephyr provides several sample applications Networking IP over USB CDC NCM   Return to Zephyr Knowledge Hub

If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. When learning Zephyr, there are lots of questions about memory.  Where does the linker place code and data?  How does the application configure to use other memories? The default memory sections used by the linker are configured in the devicetree.  Typically the devicetree uses chosen nodes to configure these sections.  Here is an example from the board MIMXRT1060-EVK: chosen { zephyr,flash = &is25wp064; zephyr,sram = &sdram0; };   The names of these chosen nodes can be misleading.  zephyr,flash points to the node the linker uses for all the code (.text) and read-only data sections.  Typically this points to physical flash memory, like on this board it places in external QSPI flash, but it can be in memory that is not flash.  zephyr,sram points to the node the linker uses for all the .data and .bss sections.  This should be in RAM, but is not required to be in SRAM.  This board places in the external SDRAM.  The application can point these nodes to other memories that are best for that app.  Other common memory nodes used are &dtcm , &itcm , or &ocram .  Typically, these chosen nodes are set in the board devicetree file.  But when learning Zephyr and working with devicetree, it is best to confirm the devicetree settings in the generated devicetree files created during the build of the application, see Lab Guide: Devicetree and VS Code Devicetree Viewer.   i.MX RT memory Most memory questions come from those using the i.MX RT devices.  These MCUs are high-performance flashless devices with multiple internal and external memory options to maximize performance and flexibility for the application.  Some helpful resources specific to the i.MX RT devices: i.MX RT application notes: AN12437 i.MX RT Series Performance Optimization AN12077 Using the i.MX RT FlexRAM AN13970 RT Series Memory Relocation in Zephyr The bootloader in ROM requires the Flash Configuration Block (FCB) when booting.  And optionally the Device Configuration Data (DCD) or eXternal Memory Configuration Data (XMCD) can be added, typically used to enable SDRAM.  This post has more details about where to find these structures, and how they are included with the board. No SDRAM: the Zephyr support for RT development boards with external SDRAM typically place data in the SDRAM.  And the ROM bootloader will configure the SDRAM interface before the Zephyr app executes using the DCD or XMCD.  This post discusses removing the SDRAM for a custom board. Configuring FlexRAM, resizing ITCM, DTCM, or OCRAM, see AN13970 RT Series Memory Relocation in Zephyr   Relocating code to RAM Relocating code to RAM is a common requirement, like to maximize performance, or reduce power consumption.  With Zephyr, applications can relocate all the code, or part of the code to RAM.  Some helpful resources for relocation: AN13970 RT Series Memory Relocation in Zephyr Zephyr Code And Data Relocation APIs Example applications that relocate code: Simple example SDRAM_hello_world.zip that moves the entire app to SDRAM, and uses the ROM bootloader to load the RAM at boot, before the app executes. Zperf sample: this networking sample in Zephyr relocates the networking stack and Ethernet driver code to ITCM to improve performance when built for the MIMXRT1170-EVK.  The rest of code remains in the default external QSPI flash. NXP SmartWatch demo and webinar: relocates most code to internal SRAM to reduce power consumption, but leaves graphical assets in flash. Locating data to RAM With Zephyr, the default placement of all data, variables, and stacks go in the zephyr,sram node.  But some applications want some specific data to be placed elsewhere.  Like placing data in DTCM to maximize performance, placing a DMA buffer in non-cacheable memory, or moving large frame buffers for a display to external RAM.  Some helpful resources for specifying data placement include: The declaration of static variables can include linker section tags to place them in specific sections.  A reference showing this is the dma_mcux_edma.c driver, which place the dma_tcdpool structures in the __dtcm_noinit_section or __nocache sections. Another option for static variables is to use devicetree nodes in the variable declaration to place in a specific section.  One example to reference is NXP's Facial Detection demo.  This demo adds the chosen node zephyr,modelbuf in the devicetree, which points to the memory section node sramx .  To use this method, the memory section node requires the property zephyr,memory-region .  In the source code, the  model_input_buf buffer is declared with the zephyr_modelbuf node.  Then the linker places model_input_buf in the sramx section. The data and bss sections of entire source files or libraries can be relocated to other RAMs, see Zephyr Code And Data Relocation APIs. Zephyr can use a special pinned section to place the interrupt and main stacks in a different RAM section.  The simple example pinned_hello_world.zip pins the interrupt and main stacks in DTCM.   Other memory resources Example resizing memory nodes, leverages all SRAM in NXP LPC5500   Return to Zephyr Knowledge Hub

Zephyr Project Build and Configuration System Devicetree Zephyr Project Devicetree Webinar: Application Portability Made Easy With Zephyr OS and NXP VS Code Lab Guide: Devicetree and Devicetree Viewer Golioth blog: Zephyr for Hardware Engineers: GPIO Zephyr Project Devicetree HOWTOs Kconfig Zephyr Project Kconfig Webinar: Application Portability Made Easy With Zephyr OS and NXP VS Code Lab Guide: Kconfig and compiler optimizations   Return to Zephyr Knowledge Hub

If you have any questions or issues related to these resources, please Ask a new question, and the NXP support team can address it there. Some resources to help with developing and debugging Zephyr applications: MCUXpresso extension for Visual Studio Code VS Code Lab Guides: Building the Hello World sample Kconfig and compiler optimizations Debugging and Thread Awareness Devicetree and VS Code Devicetree Viewer Installing a Zephyr SDK version Segger Tools: Webinar NXP and SEGGER: Debug, Visualize and Analyze Zephyr OS Applications with Ease Ozone debugger SystemView real-time analysis tool If RTT control block address is not automatically found, see Using Segger SystemView and RTT Golioth blog: Debugging with SEGGER Ozone and SystemView on Zephyr J-Link debug probe: Using J-Link with MIMXRT1060 or MIMXRT1064 Using J-Link with MIMXRT1060-EVKB or MIMXRT1040-EVK Using J-Link with MIMXRT1160-EVK or MIMXRT1170-EVK Using J-Link with MIMXRT1170-EVKB Percepio View for Zephyr RTOS and Tracealyzer for Zephyr MCUXpresso Config Tools, can generate board pinctrl files. FreeMASTER Run-Time Debugging Tool FreeMASTER Zephyr Sample Applications Return to Zephyr Knowledge Hub

This simple demo shows the portability of Zephyr with LVGL by running the same application on different hardware platforms.  Leveraging Zephyr's Hardware Abstraction Layer (HAL), applications can be written without hardware dependencies in the source code.  And without changing source, the same app can be built for different hardware. The demo steps use the following hardware and tools, but can easily run on other hardware with displays using the same general steps: FRDM-MCXN947 board FRDM-RW612 board LCD-PAR-S035 display shield NXP's MCUXpresso extension for VS Code The attached presentation gives a brief overview of Zephyr and the HAL portability.  This video shows all the steps to build the example, prepare the hardware, and program the boards. Return to Zephyr Knowledge Hub

Introduction Trusted Firmware-M (TF-M) divides memory into secure and non-secure regions. This guide explains how to add a custom non-secure flash region for data import purposes. This is useful for testing or extending TF-M functionality on platforms like FRDM-RW612. This guide is using el2go_import_blob on frdmrw612//ns as a base example. You may use any TFM based example.  Imported as a freestanding application using VSCode.  The initial two steps add a macro in order to easily add a #ifdef statement in the code in case you'd like to toggle the region on/off. TFM does not use the traditional Zephyr kConfig, so it is necessary to follow the steps to ensure the macro is defined correctly. If you want to add the region without the #if statement, skip steps 1-2. Make sure to remove #ifdef TFM_CUSTOM_DATA_IMPORT_REGION #endif from steps 3-5. 1. Enable the Feature via Configuration File: el2go_import_blob/Kconfig config TFM_CUSTOM_DATA_IMPORT_REGION bool "Enable custom flash area for testing" help Validate non-secure region in flash. File: el2go_import_blob/prj.conf CONFIG_TFM_CUSTOM_DATA_IMPORT_REGION=y 2. Update Build System to Pass the Flag File: el2go_import_blob/CMakeLists.txt Append the CMake option: if(CONFIG_TFM_CUSTOM_DATA_IMPORT_REGION) set_property(TARGET zephyr_property_target APPEND PROPERTY TFM_CMAKE_OPTIONS -DUSE_TFM_CUSTOM_DATA_IMPORT_REGION=ON ) endif() File: platform/ext/target/nxp/frdmrw612/config.cmake Add the flag: set(USE_TFM_CUSTOM_DATA_IMPORT_REGION OFF CACHE BOOL "") File: platform/ext/target/nxp/frdmrw612/CMakeLists.txt Add compile definition: if (USE_TFM_CUSTOM_DATA_IMPORT_REGION) set(TFM_CUSTOM_DATA_IMPORT_REGION_COMPILE_DEFINITION "TFM_CUSTOM_DATA_IMPORT_REGION") endif() target_compile_definitions(psa_interface INTERFACE ${TFM_CUSTOM_DATA_IMPORT_REGION_COMPILE_DEFINITION} ) 3. Define the Flash Region File: platform/ext/target/nxp/frdmrw612/partition/flash_layout.h Define address and size: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION #define TFM_CUSTOM_NS_REGION_ADDR (0x08500000) #define TFM_CUSTOM_NS_REGION_SIZE (0x00001000) // 4KB #endif File: platform/ext/target/nxp/frdmrw612/partition/region_defs.h Map the region: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION #define CUSTOM_NS_DATA_REGION_START (TFM_CUSTOM_NS_REGION_ADDR) #define CUSTOM_NS_DATA_REGION_SIZE (TFM_CUSTOM_NS_REGION_SIZE) #endif 4. Update Linker Script File: platform/ext/target/nxp/common/gcc/tfm_common_s.ld Add region base declaration: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION Load$$LR$$LR_CUSTOM_DATA_IMPORT_REGION$$Base = CUSTOM_NS_DATA_REGION_START; #endif   5. Declare and Initialize Region in Code File: platform/ext/target/nxp/common/target_cfg_common.h Add to memory region struct: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION uint32_t custom_ns_data_region_base; uint32_t custom_ns_data_region_limit; #endif File: platform/ext/target/nxp/common/tfm_hal_platform.c Initialize region limits: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION REGION_DECLARE(Load$$LR$$, LR_CUSTOM_DATA_IMPORT_REGION, $$Base); #endif // TFM_CUSTOM_DATA_IMPORT_REGION #ifdef TFM_CUSTOM_DATA_IMPORT_REGION .custom_ns_data_region_base = (uint32_t)&REGION_NAME(Load$$LR$$, LR_CUSTOM_DATA_IMPORT_REGION, $$Base), .custom_ns_data_region_limit = (uint32_t)&REGION_NAME(Load$$LR$$, LR_CUSTOM_DATA_IMPORT_REGION, $$Base) + CUSTOM_NS_DATA_REGION_SIZE - 1, #endif // TFM_CUSTOM_DATA_IMPORT_REGION File: platform/ext/target/nxp/common/tfm_hal_isolation.c Configure SAU: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION SECURE_WRITE_REGISTER(&(SAU->RNR), 7U); SAU->RBAR = (memory_regions.custom_ns_data_region_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.custom_ns_data_region_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; #endif File: platform/ext/target/nxp/frdmrw612/target_cfg.c Configure MPC: #ifdef TFM_CUSTOM_DATA_IMPORT_REGION enable_mem_rule_for_partition(memory_regions.custom_ns_data_region_base, memory_regions.custom_ns_data_region_limit); #endif 6. Update Device Tree Overlay File: zephyr/samples/el2go_import_blob/frdm_rw612_rw612_ns.overlay Add partition: custom_ns_data: partition@500000 { label = "custom_ns_data"; reg = <0x500000 0x1000>; };     Let's test the region by erasing, writing and reading.   1. Enable the Zephyr flash File: el2go_import_blob/prj.conf   CONFIG_FLASH=y   2. Add some test code to the main source file of the project.  #include <zephyr/drivers/flash.h> const struct device *flash_dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_flash_controller)); static int test_flash_region(void) { uint32_t offset = 0x500000; uint32_t test_data = 0xDEADBEEF; uint32_t read_data; // 1. Erase flash (required before write) flash_erase(flash_dev, offset, 4096); // 2. Write data flash_write(flash_dev, offset, &test_data, sizeof(test_data)); // 3. Read data (this can use memcpy function) memcpy(&read_data, (void *)0x08500000, sizeof(read_data)); if (read_data == test_data) { LOG("✓ Flash test passed with memcpy: 0x%08x\n", read_data); } else { LOG("✗ Flash test failed\n"); } //Flash read operation will have fix to correctly calculate address next release /*flash_read(flash_dev, offset, &read_data, sizeof(read_data)); if (read_data == test_data) { LOG("✓ Flash test passed with flash_read: 0x%08x\n", read_data); } else { LOG("✗ Flash test failed\n"); } */ return 0; }   3. Call the  test_flash_region() function from the main() .  

If you have any questions or issues, please Ask a new question, and the NXP support team can address it there. This article is an example using Zephyr's Networking stack over USB on the MCXN microcontroller family.  Although similar steps should also work on other boards with USB support.  This article provides 2 examples and patches: Single network interface over USB NCM Two network interfaces in same app: USB NCM plus Ethernet USB Background Zephyr added a new USB Device stack which was called USB Next during development. After the Zephyr v4.2 release, this USB Next stack is the default stack and is recommended for new applications.  The original USB stack has been deprecated, see the USB doc.  The latest stack is included using the Kconfig CONFIG_USB_DEVICE_STACK_NEXT. Networking support over USB is supported.  According to USB device next follow-up, the USB maintainer wrote "The support for networking functions RNDIS and CDC EEM is not available in the new stack. Instead, the CDC NCM and CDC ECM implementations should be used."  And the USB samples page says "USB CDC ECM and USB CDC NCM implementations are covered by the networking samples zperf: Network Traffic Generator or HTTP Server". To enable networking over USB, these samples include overlay files like usbd_cdc_ncm.overlay and overlay-usbd.conf . This article builds the HTTP Server sample with USB CDC NCM for the MCXN products. Example: USB NCM only The http_server sample using a single network interface through USB. Requirements The requirements to use the ncm_mcxn.patch and follow these steps include: After the Zephyr v4.2 release and before v4.3 was released, the default USB stack was changed and these samples were updated.  This patch was based on commit 67f2464 The patch supports the following MCXN boards: FRDM-MCXN947 - the board referenced in the steps below MCX-N9XX-EVK MCX-N5XX-EVK - at the time this article was published, the support for this board was not yet merged in the Zephyr repo.  There was an open Pull Request adding the MCX-N5XX-EVK board used to test this board Steps for http_server sample By default, the http_server runs over Ethernet on these boards.  The attached patch adds overlays for these boards to that sample to run over USB.  Build the sample with CLI using the command below for the FRDM-MCXN947 board.  The MCUXpresso extension for VS Code can also be used to build these samples west build -b frdm_mcxn947//cpu0 samples/net/sockets/http_server/ --pristine   Attach both USB Type-C cables to the FRDM-MCXN947.  Flash the http_server app to the board and run. The USB port J11 will enumerate in the host computer as a network adapter.  Assign that adapter a fixed IP address of 192.0.2.2.  Open a web browser and browse to 192.0.2.1.  The browser will show a web page served from the FRDM-MCXN947 board. This is the console output printed to the terminal after the web client browses from the server: *** Booting Zephyr OS build v4.2.0-3840-g62212512547a *** [00:00:00.001,000] <inf> net_config: Initializing network [00:00:00.001,000] <inf> net_config: IPv4 address: 192.0.2.1 [00:00:00.101,000] <inf> net_config: IPv6 address: 2001:db8::1 [00:00:00.101,000] <inf> net_config: IPv6 address: 2001:db8::1 [00:00:00.614,000] <inf> cdc_ncm: Enabled cdc_ncm_0 [00:00:00.615,000] <inf> cdc_ncm: New configuration, interface 1 alternate 1 [00:00:00.617,000] <inf> cdc_ncm: New configuration, interface 1 alternate 0 [00:00:00.617,000] <err> usbd_core: UDC error event [00:00:00.617,000] <err> usbd_core: UDC error event [00:00:00.638,000] <inf> cdc_ncm: New configuration, interface 1 alternate 1 [00:00:00.738,000] <inf> cdc_ncm: Speed change submitted [00:00:00.739,000] <inf> cdc_ncm: Speed change sent [00:00:00.740,000] <inf> cdc_ncm: Connected status submitted [00:00:00.747,000] <inf> cdc_ncm: Connection status sent [00:00:00.840,000] <inf> cdc_ncm: Connected status done [00:04:52.217,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler1 [00:04:53.216,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler1 [00:04:53.641,000] <inf> net_http_server_sample: Accepted websocket connection s [00:04:53.884,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler1 [00:04:54.883,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler1 uart:~$   Example: USB NCM plus Ethernet Similar to the example above, but this example leaves the Ethernet device enabled, and modifies the http_server source to enable both networking interfaces. Requirements The requirements to use the ncm_plus_ethernet.patch and follow these steps include: Like the example above, this patch was based on commit 67f2464 The patch supports the FRDM-MCXN947 board Connect the board to the host computer as described in the previous example.  In addition, connect an Ethernet cable to J16 on the board to the host computer. Networking setup This example configures 2 network interfaces in the http_server example, both with static IPv4 addresses.  The host computer will also connect through two network interfaces: one through USB and one using Ethernet.  Using Ubuntu as the host, I found I had to set the two interfaces on separate subnets for Ubuntu to communicate with both interfaces.  This is the setup used to test this example using all static IP addresses: USB NCM interface: http_server eth1 interface with address 192.0.3.1 host computer enx00005e005301 interface with address 192.0.3.2 Ethernet interface: http_server eth0 interface with address 192.0.2.1 host computer wired Ethernet interface with address 192.0.2.2 Steps for http_server sample Build the sample with CLI using the command below for the FRDM-MCXN947 board.  The MCUXpresso extension for VS Code can also be used to build these samples west build -b frdm_mcxn947//cpu0 samples/net/sockets/http_server/ --pristine   Open a web browser and browse to 192.0.2.1.  The browser will show a web page served from the Ethernet interface of the FRDM-MCXN947 board.  Open a second tab or browser, and browse to 192.0.3.1 for the USB interface.  Both web pages are updated using the two interfaces. This is the console output printed to the terminal after the web client browses from the server: [00:00:00.050,000] <inf> phy_mii: PHY (0) ID 7C121 [00:00:00.051,000] <inf> eth_nxp_enet_qos_mac: Link is down *** Booting Zephyr OS build v4.2.0-3649-g4006a48b4040 *** [00:00:00.052,000] <inf> net_config: Initializing network [00:00:00.052,000] <inf> net_config: Waiting interface 1 (0x30002190) to be up... [00:00:00.530,000] <inf> cdc_ncm: Enabled cdc_ncm_0 [00:00:00.531,000] <inf> cdc_ncm: New configuration, interface 1 alternate 1 [00:00:00.533,000] <inf> cdc_ncm: New configuration, interface 1 alternate 0 [00:00:00.533,000] <err> usbd_core: UDC error event [00:00:00.533,000] <err> usbd_core: UDC error event [00:00:00.554,000] <inf> cdc_ncm: New configuration, interface 1 alternate 1 [00:00:00.654,000] <inf> cdc_ncm: Speed change submitted [00:00:00.657,000] <inf> cdc_ncm: Speed change sent [00:00:00.658,000] <inf> cdc_ncm: Connected status submitted [00:00:00.665,000] <inf> cdc_ncm: Connection status sent [00:00:00.758,000] <inf> cdc_ncm: Connected status done [00:00:02.152,000] <inf> phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:00:02.152,000] <inf> eth_nxp_enet_qos_mac: Link is up [00:00:02.153,000] <inf> net_config: Interface 1 (0x30002190) coming up [00:00:02.153,000] <inf> net_config: IPv4 address: 192.0.2.1 [00:00:02.253,000] <inf> net_config: IPv6 address: 2001:db8::1 [00:00:02.253,000] <inf> net_config: IPv6 address: 2001:db8::1 [00:00:06.548,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler status 1 [00:00:07.650,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler status 1 [00:00:07.652,000] <inf> net_http_server_sample: Accepted websocket connection for net stats [00:00:08.581,000] <dbg> net_http_server_sample: uptime_handler: Uptime handler status 1   The http_server includes the shell with some networking commands.  Enter the command "help" in the debug console to learn more.  This is the output from the shell command "net iface": uart:~$ net iface Hostname: zephyr Default interface: 1 Interface eth0 (0x30002190) (Ethernet) [1] =================================== Link addr : AE:9A:22:0C:E0:F3 MTU : 1500 Flags : AUTO_START,IPv4,IPv6 Device : ethernet (0x10037d08) Status : oper=UP, admin=UP, carrier=ON Ethernet capabilities supported: 10 Mbits 100 Mbits Ethernet PHY device: ethernet-phy@0 (0x10037cc0) Ethernet link speed: 100 Mbits full-duplex IPv6 unicast addresses (max 3): fe80::ac9a:22ff:fe0c:e0f3 autoconf preferred infinite 2001:db8::1 manual preferred infinite IPv6 multicast addresses (max 4): ff02::1 ff02::1:ff0c:e0f3 ff02::1:ff00:1 IPv6 prefixes (max 2): <none> IPv6 hop limit : 64 IPv6 base reachable time : 30000 IPv6 reachable time : 23045 IPv6 retransmit timer : 0 IPv4 unicast addresses (max 1): 192.0.2.1/255.255.255.0 manual preferred infinite IPv4 multicast addresses (max 2): 224.0.0.1 IPv4 gateway : 192.0.2.2 Interface eth1 (0x300022b0) (Ethernet) [2] =================================== Link addr : 02:00:00:F1:34:7C MTU : 1500 Flags : AUTO_START,IPv4,IPv6 Device : cdc_ncm_eth0 (0x10037ce4) Status : oper=UP, admin=UP, carrier=ON Ethernet capabilities supported: 10 Mbits Ethernet PHY device: <none> (0) IPv6 unicast addresses (max 3): fe80::ff:fef1:347c autoconf preferred infinite IPv6 multicast addresses (max 4): ff02::1 ff02::1:fff1:347c IPv6 prefixes (max 2): <none> IPv6 hop limit : 64 IPv6 base reachable time : 30000 IPv6 reachable time : 36584 IPv6 retransmit timer : 0 IPv4 unicast addresses (max 1): 192.0.3.1/255.255.255.0 manual preferred infinite IPv4 multicast addresses (max 2): 224.0.0.1 IPv4 gateway : 0.0.0.0 Return to Zephyr Knowledge Hub

GUI Guider is a user-friendly graphical user interface development tool from NXP that enables the rapid development of high quality displays with the open-source LVGL graphics library.  GUI Guider can also export projects using Zephyr.  The document GUIGuider_User_Manual installed with GUI Guider has a section working with Zephyr, and provides steps using Command Line Interface (CLI).  This article is an example using NXP's MCUXpresso extension for VS Code to import the generated project, build and download to a board. Requirements The steps in this article are based on these requirements: Software: GUI Guider v1.10.0-GA Zephyr v4.0.0 - the GUI Guider release notes say support is based on "Zephyr v4.0 support for LVGL v8.3.10" Zephyr SDK v0.17.0 - the Zephyr SDK version tested with Zephyr v4.0.0 MCUXpresso extension for VS Code v25.9.49 Hardware:   MIMXRT595-EVK evaluation board for the i.MX RT500 G1120B0MIPI display shield  Zephyr Pre-Requisites This GUI Guider release requires an older version of Zephyr v4.0.0.  If the Zephyr repo is already imported in VS Code, the MCUXpresso extension can checkout the required version. Click the MCUXpresso extension, right-click the Zephyr repo to update, and click "Update Repository or Index"   A pop-up appears in the lower right corner.  Click the Custom button to select the release tag    A pull-down appears at the top center.  Select the v4.0.0 release tag.  This will take some time for the extension to checkout this version, and run "west update" to sync all the module repositories.    If the Zephyr repo needs to be imported for the first time, the v4.0.0 version can be selected during the import.  Use the Quickstart Panel in the extension to "Import Repository".  For more help getting started with the MCUXpresso extension and importing Zephyr, see the NXP Zephyr Knowledge Hub. Repository: Zephyr Revision: select v4.0.0   Create and Export GUI Guider project Open GUI Guider and start a new project.  Select LVGL8.3.10 because the GUI Guider release notes say this is the LVGL version supported with Zephyr v4.0.0.   Select the board MIMXRT595-EVK Select the application SmartWatch Create the project   Generate the C code for the project:    Export the code for Zephyr:   Exporting the project into the Zephyr repository is the easiest option to import that project into VS Code.  In this example, the Zephyr workspace was setup in C:\z\zephyrproject.  The project folder name we will export is gui_guider_demo, and place in the samples folder Then the full path for this exported project is C:\z\zephyrproject\zephyr\samples\gui_guider_demo Import GUI Guider project into VS Code Back in VS Code, in the MCUXpresso extension, refresh the repository to find the newly generated sample project:   In the Quickstart Panel, "Import Example from Repository" with these settings: Repository: your Zephyr v4.0.0 workspace Board: mimxrt595_evk//cm33 Template: search "gui", and select the exported gui_guider_demo App type: Repository application Zephyr SDK: since this is an older Zephyr release, be sure to use the older Zephyr SDK v0.17.0, otherwise the app may not build   After importing, we also need to add the display shield to the project.  This is done by adding a Cmake variable, see the MCUXpresso Cmake wiki for more details.  In the gui_guider_demo project, click the Edit button for the debug build configuration.   Add the shield name to the CMake Extra arguments using this line, and click the Save button: SHIELD="g1120b0mipi"    Apply GUI Guider patches GUI Guider includes git patches in the exported project, and GUIGuider_User_Manual provides steps for apply these patches to the Zephyr and LVGL repositories.  Applying these patches uses CLI, and this article leverages a CLI feature in the MCUXpresso extension. Right-click the gui_guider_demo project, and select "Open in Integrated Terminal".  This opens the CLI terminal in the project folder, and activates the Python virtual environment.   Enter these CLI commands to apply the patches: cd ../.. git apply samples\gui_guider_demo\patches\0001-zephyr-Add-build-support-for-new-lvgl-widgets-develo.patch cd ..\modules\lib\gui\lvgl git apply ..\..\..\..\zephyr\samples\gui_guider_demo\patches\0001-lvgl-Add-new-widgets-developed-by-NXP.patch   Update Kconfig settings  Some of the Kconfig settings in the exported project do not work for this board and application, and the sizes must be increased.  The sizes used here come from the LVGL demo in the Zephyr repo from the file samples/modules/lvgl/demos/prj.conf.  For an introduction to Kconfig, see the NXP Zephyr Lab MCXN947 Kconfig. In the exported gui_guider_demo project, open the project file prj.conf.   Update the first two Kconfig settings with these sizes: CONFIG_LV_Z_MEM_POOL_SIZE=49152 CONFIG_MAIN_STACK_SIZE=4096 Build and flash the project  The project is now ready to build.  Right-click the project and do a Pristine Build   When the build completes, click the debug icon to program the image to flash.  The app is a very large image and will take some time to program.   Now the LVGL application generated by GUI Guider runs on the target board. Return to Zephyr Knowledge Hub

If you have any questions or issues, please Ask a new question, and the NXP support team can address it there. Long term, NXP hopes clocks will be enabled and configured using the Clock Management Subsystem, but this is not adopted yet.  For now, most clocks at the SOC level are configured by source code in the startup code.  Newer boards configure these clocks in the board.c file.  For example, frdm_mcxn947_init() enables these clocks for FRDM-MCXN947 board.  Clock configuration is specific to the board and the application.  For a custom board, it is expected the board owner will review all the clock configuration in these files, and configure as needed for that board.   Some older SOCs enable the clocks in soc.c.  For example, clock_init() enables these clocks for the i.MX RT10xx SOCs.  When clock_init() is included in the SOC file, it is declared as weak so it can be overridden without needing to modify soc.c.  Custom boards can add a custom clock_init() in their board files to override this function. Peripheral Clocks NXP has a large portfolio of boards supported for different SOCs with many peripheral options and multiple instance of peripherals.  Many of these instances cannot easily be tested when Zephyr support is added for a board.  Most peripheral clocks are enabled in clock_init() in soc.c or board source files discussed above.  One common issue Zephyr users have when enabling or adding a peripheral instance on their board, is that instance is not clocked properly.  Typically enabling the peripheral clock is simple once this is known.   Return to Zephyr Knowledge Hub

Zephyr is enabled on the MIMXRT1170-EVK board and can run on both the primary Cortex-M7 and secondary Cortex-M4 cores.  This example shows how to run an Ethernet networking sample on the M4 core, using the dhcpv4_client sample.  By default for the M4 on this board, the code (.text) and data sections are linked to the Tightly Coupled Memories (TCMs) RAM_L and RAM_U (called sram0 and sram1 in the Zephyr devicetree).  But one of these TCMs is not large enough to place all of the code of a networking sample.  This example moves the M4 code to the internal 512 KB OCRAM1 using a devicetree overlay. This example also leverages Sysbuild and the M4 launcher feature.  Sysbuild builds both images for the M7 and M4.  The M7 boots first from flash, and runs a simple cm4_launcher app.  That app copies the M4 image from flash to RAM (OCRAM1 in this case) and then starts the M4.  This cm4_launcher app simplifies booting and testing apps on the M4. Requirements This example is enabled and tested with the following: MIMXRT1170-EVKB board Zephyr v4.2.0 Zephyr SDK v0.17.2 Connect an Ethernet cable to J32 for the 10/100M PHY DHCP example app Apply the attached patch to the Zephyr repository.  Some details about this patch: The mimxrt1170_evk Kconfig.defconfig is modified to define CONFIG_NET_L2_ETHERNET when building the the M4.  This improvement will be submitted to upstream Zephyr. Adds the sysbuild folder to the dhcp sample with the cm4_launcher to run on the M7 Modifies the M7 devicetree and Kconfig to prevent using resources that are used by the M4. Modifies the M4 linker settings to place the code (.text)  zephyr,flash  node in  ocram1 , and the data  zephyr,sram  node in  sram1  (RAM_U). Build and flash the app with CLI using these commands: west build -b mimxrt1170_evk//cm4 samples/net/dhcpv4_client/ --sysbuild --pristine west flash Reset the board after flashing. To build the app with NXP's MCUXpresso extension for VS Code, see the Sysbuild wiki.  You will also need to flash the cm4_launcher domain to the flash.  This MCUboot article has similar steps to enable sysbuild and flash the other domain. When both images are flashed, the RT1170 will boot and print this to the console: [00:00:00.051,000] <inf> phy_mii: PHY (0) ID 1CC816 [00:00:00.053,000] <inf> eth_nxp_enet_mac: Link is down *** Booting Zephyr OS build v4.2.0-1-g692f19148321 *** [00:00:00.053,000] <inf> net_dhcpv4_client_sample: Run dhcpv4 client [00:00:00.053,000] <inf> net_dhcpv4_client_sample: Start on ethernet: index=1 [00:00:03.153,000] <inf> phy_mii: PHY (0) Link speed 100 Mb, full duplex [00:00:03.153,000] <inf> eth_nxp_enet_mac: Link is up [00:00:03.170,000] <inf> net_dhcpv4: Received: 192.168.86.159 [00:00:03.170,000] <inf> net_dhcpv4_client_sample: Address[1]: 192.168.86.159 [00:00:03.170,000] <inf> net_dhcpv4_client_sample: Subnet[1]: 255.255.255.0 [00:00:03.170,000] <inf> net_dhcpv4_client_sample: Router[1]: 192.168.86.1 [00:00:03.170,000] <inf> net_dhcpv4_client_sample: Lease time[1]: 86400 seconds uart:~$ For more articles, see NXP's Zephyr Knowledge Hub.