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. 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

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

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