There are two version of the i.MX RT1170 Evaluation Kit:  MIMXRT1170-EVK (no longer available for purchase) MIMXRT1170-EVKB   The key differences between the two versions of are laid out in the MIMXRT1170-EVKB Board Hardware User Guide:    One important change is the QuadSPI flash used on each board. This means that if you attempt to use SDK projects created for the RT1170-EVKB, it will not run properly on an older RT1170-EVK board due to using the mismatched QSPI configuration data. And new releases of MCUXpresso SDK only support the newer EVKB board.  However there is a simple fix to get those newer i.MX RT1170 EVKB MCUXpresso SDK projects to run on the older i.MX RT1170 EVK hardware. Simply download the MCUXpresso SDK 2.16.00 for the original RT1170-EVK board, unzip the archive file, and then copy the evkmimxrt1170_flexspi_nor_config.h and evkmimxrt1170_flexspi_nor_config.c files found in \SDK_2_16_000_MIMXRT1170-EVK\boards\evkmimxrt1170\xip into your EVKB project's xip folder. Then either delete/rename the EVKB version of the evkbmimxrt1170_flexspi_nor_config.c and evkbmimxrt1170_flexspi_nor_config.h files from the project to avoid compiler conflicts. This will update the QSPI configuration for that project to be compatible with the QSPI hardware on the original EVK. As an exmaple, here is the RT1170 Hello World project with that change - the EVKB files were renamed with a .orig extension so they would not be included in the compilation:    Note that due to the new hardware features found on the EVKB board there are some EVKB SDK projects that simply can't be supported on the original EVK board. But this work-around will provide support for many MCUXpresso SDK projects that don't require those new EVKB board features.    VSCode: For VSCode projects the repo\mimxrt1170_evkb\boards\xip\board_boot_header.make file will need to be modified to comment out the evkbmimxrt1170_flexspi_nor_config.c file and add the evkmimxrt1170_flexspi_nor_config.c   

View Webinar Recording

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345190  

There are two main methods for importing a project from GUI Guider to MCUXpresso: Linking the whole GUI Guider project into MCUXpresso. Copying and replacing the GUI on a pre-built LVGL project on MCUXpresso (like the "lvgl_guider" SDK example code). Although the first method is quite convenient, there are times when a user might have a GUI already on an established project. In this case, the second method might be very useful. However, when trying to add lottie widgets to a GUI of an already established project (like the "lvgl_guider" SDK example code), extra steps are required, as this widget uses a proprietary library from Samsung which requires extra steps to add and enable. This document describes the steps needed to add rlottie widgets to a project that is already established in MCUXpresso. GUI Guider 1.8.0, MCUXpresso v11.10.0 and SDK 2.16.000 were used for this document, although the process should be the same for future versions.   Once the Lottie widget has been added to the GUI on GUI Guider, you will want to follow the common steps to import this GUI into the MCUXPresso project. Replace the "custom" and "generated" folders on the MCUXpresso project with the GUI Guider folders: <GUI Guider Project Installation>\custom. <GUI Guider Project Installation>\generated.   TIP: You can open the default location of the MCUXpresso project on the file explorer by selecting the project, opening the "Show In" window by pressing Alt + Shift + W, and selecting "System Explorer":   TIP: You can open the default location of the GUI Guider project on the file explorer by clicking on the green folder icon on the top menu bar:   Copy the "lib" folder from: <GUI Guider Project Installation>\lib into the MCUXpresso project.   Copy the "rlottie" folder from: <GUI Guider Project Installation>\sdk\core\rlottie into the MCUXpresso project.   That’s it for file management. Now, in MCUXpresso: Include the "lib" and "rlottie" folders as source folders by adding their path under: Project properties > C/C++ General > Paths and Symbols > Source Location.   Include the rlottie folder as include path by adding its path under the following two compilers' include paths: Project properties > C/C++ Build > Settings > MCU C++ Compiler > Includes > Include Paths.   Project properties > C/C++ Build > Settings > MCU C Compiler > Includes > Include Paths.   As mentioned on the LVGL documentation for "Rlottie player", we need to add the "-rlottie" flag to the linker, but also link the rlottie library (librlottie.a) to the project. This is done by setting the following on Project Properties > C/C++ Build > Settings > MCU C++ Linker > Libraries:   Finally, enable the macro definition: #define LV_USE_RLOTTIE 1 under the "lv_conf.h" file on "source" to tell LVGL that we are using the rlottie library.   With these steps, the rlottie application was imported, along with its headers and libraries, and this rlottie feature was enabled by linking them to the build configuration. Because of this, the application compiles without any errors. Great! Note: There's a possibility that the following error shows up when compiling: If this is the case, simply change the following macro in "source" > "lv_conf.h" from '0' to '1' to enable user data in the lv_font_t variable type:   However, when executing the application, the screen goes black. Turns out, as soon as the application tries to execute the first rlottie instruction from the ".a" archived library, it is unable to execute anything, which causes the application to halt and get stuck on a black screen. This happens as soon as the application calls line 113 of the "lv_rlottie.c" file to construct the rlottie widget: (This file is under <project folder>\lvgl\lvgl\src\extra\libs\rlottie)   But there was no issue when building the application, so what gives? Well, the Rlottie library is quite memory heavy, so we also need to provide it with memory according to its requirements. We can do this by increasing the heap and stack size from their "default" state to something like 0x800000 for the stack and 0x1000 for the heap. These values are what GUI Guider provides to its projects when using Rlottie widgets.   With this, the MCUXpresso project will now have the rlottie libraries enabled, and also have enough memory to successfully debug/run the project on the i.MX RT board.       Happy "Lottie-ing"!   Edwin.

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 QDC Incorrect Input Filter Register (FILT) configuration.  FILT_PRSC bitfield is not implemented in Design. 22 May 2025 ​ ​

This article uses i.MXRT1170 as an example, but the rules apply to the i.MX RT series. 1. Backgroud and Questions DataSheets (e.g, RT1170A , RT1170B) show the 'NON JEDEC'  Package as following, but the Product quality page (e.g MIMXRT1172AVM8A) is marked as WSL 3 (Moisture Sensitivity Level 3), which is one of the moisture sensitivity levels defined in JEDEC-STD-020. Is there a contradiction? Does the product comply with JEDEC-STD-020?  2. What is JEDEC-STD-020? JEDEC-STD-020 is a standard that defines the moisture sensitivity level (MSL) and preconditioning requirements for surface-mount devices (SMDs) during the reflow soldering process. Compliance with this standard means that the device's storage and handling before reflow soldering meet industry specifications, making it suitable for automated manufacturing environments. 3. WSL 3 and JEDEC-STD-020 Compliance  On NXP’s product quality page, some i.MX RT1170 variants are marked as WSL 3 (Moisture Sensitivity Level 3), which is one of the levels defined in JEDEC-STD-020. This means: The device can be exposed to ambient conditions for 168 hours before reflow soldering;  It must be stored in dry-pack packaging; It complies with JEDEC-STD-020 handling and processing requirements. This indicates that i.MX RT1170 series have been tested and qualified according to JEDEC-STD-020. Key parameters from NXP Product pages： MSL (Moisture Sensitivity Level): 3 Peak Package Body Temperature: 260°C Time at Peak: 40 seconds 4. “NON JEDEC” Packge in the Datasheet In the i.MX RT1170 datasheet, some package types are labeled as “NON JEDEC”, which typically means: The package dimensions or layout do not strictly follow JEDEC standard outlines; The device has not undergone the formal JEDEC-STD-020 certification process. For example, the IMXRT1170BCEC Rev.1 datasheet states: Package Information: Plastic Package 289-pin MAPBGA, 14 x 14 mm, 0.8 mm pitch Package Type: NON JEDEC [1] This indicates that the package is not a JEDEC-standard mechanical outline. However, it does not necessarily mean the device fails to meet the moisture sensitivity requirements defined in JEDEC-STD-020. 5. In summary 'NON JEDEC' refers only to mechanical form, not to reliability standards. The "NON JEDEC" marking on a datasheet refers to the ​​physical package outline​​, while the MSL 3 rating on the product quality page is a ​​reliability and handling specification​​ determined through JEDEC test methods. JEDEC-STD-020 is a moisture sensitivity level testing standard for non-hermetic surface-mount devices. i.MX RT explicitly states that its MSL rating is based on the JEDEC-STD-020 testing process. Whether a package conforms to a JEDEC standard (such as MO-220) has no direct bearing on whether it can be tested under JEDEC-STD-020. ‘NON JEDEC’是指物理封装中的机械形式，不是可靠性标准。 JEDEC-STD-020 是针对非气密性表面贴装器件的湿敏等级测试标准； NXP 明确表示i.MX RT产品 MSL 等级是依据 JEDEC-STD-020 测试流程； 封装是否为 JEDEC 标准（如 MO-220）与是否能进行 JEDEC-STD-020 测试无直接关系。 6. Reference NXP i.MX RT1170 Product Page: https://www.nxp.com/part/MIMXRT1172AVM8A  i.MX RT1170 Datasheet: https://www.nxp.com/docs/en/data-sheet/IMXRT1170CEC.pdf  JEDEC-STD-020 Standard: https://www.jedec.org/document_search/field_doc_type/151?search_api_views_fulltext=%E2%80%8BJ-STD-020&order=title&sort=asc       

​ 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 System Boot Incorrect encoding for BOOT_CFG[9] - ECC Selection The encoding for the boot configuration bit for the ECC selection is incorrect. Device ECC should be 0 and Software ECC should be 1. Before:    After:    - ​

The RT1170 supports the ability to trigger dual ADC’s in SyncMode or AsyncMode via the ADC External Trigger Control (ADC_ETC): In SyncMode, ADC1 and ADC2 are controlled by the same trigger source. In AsyncMode, ADC1 and ADC2 are controlled by separate trigger source. In AsyncMode (TRIGa_CTRL[SYNC_MODE]==0), the ADC conversion clock frequency maximum is 88 MHz, but in SyncMode (TRIGa_CTRL[SYNC_MODE]==1), the ADC conversion clock frequency must be constraint to a lower frequency due to switching noise inherent to its design architecture.  Reducing the conversion clock frequency reduces the switching noise that is observed. NXP is currently conducting further characterization in order to specify the maximum frequency of conversion in SyncMode across process, voltage, and temperature.  However, on typical samples at room temperature 60 MHz is the maximum frequency.

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342717 

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-342954

Issue: 802.11 IEEE station Power Save mode is not working as expected with the latest SDK 2.11.1, supporting NXP wireless solutions 88W8987/88W8977/IW416.   Solution: Modify the structure in file : middleware/wifi/wifidriver/incl/mlan_fw.h, Replace  “ENH_PS_MODES action” to “uint16_t action”.    Note: This fix will officially be part of SDK: 2.12.0

NXP Updated the Hardware Development Guide for the MIMXRT1160/1170 Processor (MIMXRT1170HDUG) The main difference is： Updated capacitance value of VDDA_1P8_IN in Table 1 and Table 2 From 0.1uF to 1uF     This will help improve the robustness of the circuit at low temperatures.

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-341316

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-341985

The i.MX RT600 MCU includes a Cadence® Tensilica® HiFi 4 DSP running at frequencies of up to 600 MHz.The XOS embedded kernel from Cadence is designed for efficient operation on embedded system built using the Xtensa architecture. Although various parts of XOS continue to be tuned for efficient performance on the Xtensa hardware, most of the code is written in standard C and is not Xtensa-specific. Click here to access the full application note.

This application note describes how to develop an audio player with NXP i.MX RT600 crossover MCU family. Click here to access the full application note.

This article will describe how to use the HiFi modules found on certain NXP microcontrollers as an optional method for inferencing a model.  There are several ways of running a TFLite neural network model on NXP microcontrollers: Inference a model only using the main core of the device (CM33 or M7) MCX N i.MX RT1050 i.MX RT1060 i.MX RT1170 i.MX RT1180 i.MX RT595 i.MX RT685 i.MX RT700   Inference a model directly on the HiFi4 or HiFi1 core (on supported platforms) i.MX RT595 i.MX RT685 i.MX RT700 Use the Neutron NPU to accelerate inference of a model - with the CM33 controlling the NPU and acting as a fallback for any non-NPU supported layers i.MX RT700 MCX N   Use the Neutron NPU to accelerate inference of a model - with the HiFi4 controlling the NPU and acting as a fallback for any non-NPU supported layers i.MX RT700     This article will cover options #2 and #4 which make use of the HiFi DSP module. Running a model on the HiFi4 (option #2) will be much faster than running a model just on the CM33/M7 (option #1).   However using the NPU (options #3 and #4) will be significantly faster than only using the DSP due to the hardware optimizations that an NPU provides for neural network calculations. The exact performance gains will be model specific, and also depend on the layer(s) that may not have been converted to use the NPU as NeutronGraph nodes. The accuracy should remain the very similar regardless of method being used. Any type of TFLite neural network model can be ran on the HiFi1/HiFi4 as those DSP modules are just being used accelerate the neural network math that the model uses. CIFAR10 on i.MX RT700 using default MCUXpresso SDK projects: CM33: 105.925ms HiFi1*: 148.487ms HiFi4: 12.312ms NPU w/ CM33 Fallback: 1.048ms NPU w/ HiFi4 Fallback: 0.983ms *HiFi1 runs at 32MHz     Software requirements: Go to the Cadence i.MX RT700 or Cadence i.MX RT685 pages to download the following software. Xtensa Xplorer IDE License Key HIFI DSP Configuration File (NEWLIB) If using a HiFi4 example then download the HiFi4 license and DSP configuration files. Likewise, if using a HiFi1, then will need the HiFi1 license and DSP configuration files. Also you will need to download the Windows or Linux version of these files depending on which host OS you are using on your PC. Finally add the following global system variables which should be set based on the location that Xtensa Explorer was installed (assuming RT700 with HiFi4): XCC_DIR=<install_dir>\XtDevTools\install\tools\RI-2023.11-win32\XtensaTools XTENSA_CORE= rt700_hifi4_RI23_11_nlib   MCUXpresso SDK HiFi ML Examples: There are several HiFi related examples in MCUXpresso SDK for i.MX RT700: tflm_cifar10 – Uses Neutron NPU to inference the CIFAR10 model and uses the CM33 as the fallback for any non-NPU operators. tflm_cifar10_hifi1 – Uses HiFi1 to inference the CIFAR10 model. Does not use the Neutron NPU tflm_cifar10_hifi4 – Uses HiFi4 to inference the CIFAR10 model. Does not use the Neutron NPU tflm_cifar10_hifi4_neutron – Uses Neutron NPU to inference the CIFAR10 model and uses the HiFi4 as the fallback for any non-NPU operators.   tflm_label_image – Uses Neutron NPU to inference the CIFAR10 model and uses the CM33 as the fallback for any non-NPU operators. tflm_label_image_hifi4 - Uses HiFi4 to inference the Mobilenet model. Does not use the Neutron NPU   When using the HiFi eIQ projects provided in MCUXpresso SDK, ensure that the SDK is: Located in a short filename path (ie C:\nxp\RT700), as an excessively long filename path can cause compile issues Directory path contains no spaces If using VS Code import as a Repository project instead of Free Standing. Ensure using at least MCUXPresso SDK 26.03 as there are several important fixes in the 26.03 release for HiFi4 projects   Extending Memory Area in HiFi4 Examples for Larger Models: Open:  \boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4_neutron\linker\hifi4\min-rt\ldscripts\elf32xtensa.x  And make modifications below to extend the memory used for models.  dsp_core_seg :  org = 20200000, len = 0x200000  dsp_core_ncache_seg :  org = 0x20400000, len = 0x180000        _memmap_mem_dsp_core_start = 0x20200000;  _memmap_mem_dsp_core_end   = 0x20580000;  _memmap_seg_dsp_core_start = 0x20200000;  _memmap_seg_dsp_core_max   = 0x20580000;         Ensure that the stack heap is at 0x2058_0000:    PROVIDE(__stack = 0x20580000);    _heap_sentry = 0x20580000;          Now larger models will compile successfully in Xtensa.    Then after copying in the compiled HiFi4 binary files into the MCUXpresso IDE project, modify source/dsp_config.h file to update the DSP_SRAM_ADDRESS:       Then clean and build the project.   HiFi Lab: See the attached lab document for more details on using the HiFi DSP modules to inference models.      

4-TX Line Audio Playback via SAI1 on MIMXRT1170 and CS42448 1. Introduction This document focuses on utilizing the MIMXRT1170-EVKB development board and the CS42448 audio expansion board to achieve specific audio playback functionality through four TX data lines of the SAI1 module. With its real-time performance and high integration, the i.MX RT1170 is widely used in automotive, industrial, and IoT fields. The Arm Cortex-M7 core runs at up to 1GHz, features 2MB on-chip RAM, and offers various memory and connectivity interfaces. It supports multiple audio interfaces, including SAI-1, SAI-2, SAI-3, SAI-4, PDM, ASRC, SPDIF, and MQS. This document details the implementation of 8-channel audio output using the RT1170 EVKB development board and CS42448 Audio Card via four TX data lines of the SAI1 module. It also explains how to generate 8-channel audio data compatible with SDK example requirements. The CS42448 Audio Card can be directly connected to the RT1170 EVKB board, enabling developers to build more complex audio applications. The NXP SDK provides the example 'evkbmimxrt1170_sai_edma_multi_channel_transfer_cm7,' which by default enables two transmission channels (TX_DATA0 and TX_DATA1). When running, 1kHz sine wave audio signals can be heard from the J6 and J7 interfaces of the CS42448 Audio Card. However, when customer requirements demand four TX data lines (TX_DATA0 to TX_DATA3), each transmitting different audio, how can this be achieved? This document explores and validates this scenario in depth. 2. SAI Overview (1) RT1170 Chip SAI Module Features According to the IMXRT1170RM datasheet, SAI2, SAI3, and SAI4 modules each have only one data line for input/output, while SAI1 has four, making it the only module supporting multi-line communication. (2) Configuration Highlights To implement the four TX data line solution, it is crucial to configure the Transmit Configuration 3 (TCR3) TCE register correctly. According to IMXRT1170RM Table 54-2, Option0 should be selected for pin configuration. To enable TX_DATA0 to TX_DATA3, set bits 16–19 of the SAI1 TCR3 register to '1111'. Similarly, for multiple Rx data lines, configure bits 16–19 of the SAI1 RCR3 register (RCE).   3. Hardware Preparation (1) Required Hardware - Mini/micro USB cable - MIMXRT1170-EVKB development board - Personal computer - Headphones (OMTP standard) - CS42448 Audio Card (2) Hardware Modifications on MIMXRT1170-EVKB Solder Resistors: R2008, R2022, R2011, R2021, R2009, R2010, R2012, R2016, R1998, R2013, R2014, R2018, R2017, R2000 Remove Resistors: R2001, R2002, R2003, R2004, R2005, R2006, R2007 After completing the hardware modifications, connect the CS42448 Audio Card to the J76 interface of the MIMXRT1170-EVKB board. 4. Audio Source Preparation The free and powerful audio editing software Audacity is used to convert MP3 files to .wav format. Since each TX data line transmits two audio channels, a total of 8 channels are needed. (1) Audio Channel Allocation Strategy Using Audacity, multiple audio channels were generated. 'HelloWorld' is mono and reused. Allocation is as follows: - TX_DATA0: HelloWorld → Channel 1 & Channel 5 - TX_DATA1: Audio1 → Left: Channel 2, Right: Channel 6 - TX_DATA2: Audio2 → Left: Channel 3, Right: Channel 7 - TX_DATA3: Audio3 → Left: Channel 4, Right: Channel 8 On the CS42448 Audio Card: - J6 plays TX_DATA0 (HelloWorld) - J7 plays  TX_DATA1(Audio1) - J8 plays TX_DATA2(Audio2) - J9 plays TX_DATA3(Audio3) (2) Audio Format Requirements The converted .wav files must match the format used in the NXP SDK example: 48kHz sampling rate and 16-bit width. Ensure these parameters are correctly set in Audacity during conversion. (3) Audio Data Processing To convert the generated HelloWorld-8-channel.wav file into a C language array using WinHex, you need to remove the first 44 bytes, which constitute the standard WAV file header. This step is crucial because the SDK example utilizes raw audio data. For those interested, examining the structure of a WAV file can provide deeper insight into this process. Alternatively, this conversion from WAV format to a C array can also be accomplished using other tools or methods. 5. Software Modifications (1) Configure SAI1 Module Registers To enable four TX data lines, set the TCE bits in the SAI1 TCR3 register. In the NXP SDK code, modify the macro DEMO_SAI_CHANNEL_MASK and configure saiConfig in I2S mode. The function SAI_TransferSendEDMA will set the TCR3 TCE register accordingly. (2) Replace Audio Data and Modify Macros Replace the uint8_t music[] array in the SDK example’s music.h file with the C array generated earlier. Also, update the macro MUSIC_LEN to match the byte length of the new array, ensuring it is a multiple of 1600. After completing all steps, compile and flash the program to the MIMXRT1170-EVKB board. Connect headphones to the CS42448 Audio Card’s J6,J7,J8,J9 interfaces to hear the respective audio outputs.   6. Conclusion This project successfully implements the transmission of four TX data lines via the SAI1 module using the CS42448 Audio Card and MIMXRT1170-EVKB development board. Experimental validation confirms support for multi-channel independent audio output. Each TX data line can output distinct audio content through the CS42448’s physical interfaces (J6–J9), meeting the needs of complex audio scenarios.

This document describes how to program a bootable image into the recovery Flash device using i.MX RT600 MCUs. Click here to access the full application note.