i.MX RT Crossover MCUs Knowledge Base

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX RT Crossover MCUs Knowledge Base

ディスカッション

ソート順:
ModelRunner is a benchmarking tool for running TensorFlow Lite models on NXP microcontrollers. It supports both HTTP and UART communication modes and provides detailed latency profiling for each model layer. The model profiling information is in JSON format and can be uploaded to the upcoming eIQ AI Toolkit and eIQ AI Hub tools for more detailed analysis.  ModelRunner is available on the following MCU devices: FRDM-MCXN947 MCX-N5XX-EVK MCX-N9XX-EVK MIMXRT700-EVK MIMXRT595-EVK MIMXRT685-EVK MIMXRT1060-EVK MIMXRT1170-EVK There are two methods for using ModelRunner: Via an Ethernet connection to the board Via UART using an emulated network connection  - useful for devices without Ethernet like i.MX RT700   The attached guide walks through how to use both methods. A Windows Powershell or Linux prompt should be used for this lab as a normal Windows command prompt will not parse the commands correctly.   
記事全体を表示
eIQ Neutron SDK is a new software package that includes the Neutron Converter tool and eIQ Neutron libraries to run Neutron converted neural network models on devices that have an eIQ Neutron NPU like MCX N, i.MX RT700, or i.MX95 Previously the Neutron Converter tool was part of eIQ Toolkit. However going forward, new versions of the Neutron Converter tool will be released as part of the eIQ Neutron SDK. This change will allow for more frequent updates to provide better performance and additional operator support. MCUXpresso SDK and Linux BSP use Neutron libraries as part of the eIQ examples included in those software releases. However to use the latest Neutron Converter, an eIQ project will need to be updated to use the latest Neutron software libraries. This post walks through where to place the updated Neutron libraries and header files.    If the version of the Neutron Converter tool that was used to convert a model does not match the Neutron libraries used by the eIQ project, then during inference you will see the following error(s) printed on the serial terminal and may get incorrect results: Microcode version mismatch Or Internal Neutron NPU driver error 281b in model prepare Or Incompatible Neutron NPU microcode and driver versions The version of the Neutron Converter tool that was used to convert a model can be found by either viewing the converted model in Netron or by looking at the generated header file:     Here is a table showing where you can find the matching version of the Neutron Converter tool for the default Neutron libraries found in different versions of MCUXpresso SDK: MCUXpresso SDK Default Neutron Library Version in MCUXpresso SDK Default Compatible Neutron Converter Can Be Found In 24.12 1.2.0+0x6f710a6d eIQ Toolkit 1.17 25.03 1.2.0+0X1b86b19d eIQ Toolkit 1.17 25.06 2.0.2 eIQ Toolkit 1.17 25.09 2.1.3 eIQ Toolkit 1.17 25.12 2.2.2 eIQ Neutron SDK 2.2.2 26.03 3.0.0 eIQ Neutron SDK 3.0.0 26.06 3.1.1 eIQ Neutron SDK 3.1.1 Manually Update SDK Libraries To Use Latest Version   eIQ Neutron SDK 3.1.3   It is highly recommend to always use the latest Neutron Converter tool and to update the libraries in your eIQ project to match the latest Neutron Converter tool. The libraries can be updated by overwriting the original files. You may wish to make a backup first though as the default eIQ examples in that SDK will use models that were converted to match those original Neutron libraries. The Neutron file structure in eIQ Neutron SDK and MCUXpresso SDK are now the same so that the entire Neutron folder can be overwritten directly.    Updating Neutron Libraries in MCUXpresso SDK 25.12 and later: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\neutron\common\include\   Note: The target\imxrt700\driver\include\NeutronEnvConfig.h and the libraries in target\imxrt700\cmodel are used by the ExecuTorch inference engine and so are not needed for TFLM eIQ projects.  Note: In MCUXpresso SDK 26.03 there are two sets of Neutron libraries in imported projects. It's the files in the /middleware/eiq folder that need to be updated.      Updating Neutron Libraries in MCUXpresso SDK 25.09 or before: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\common\include\   Updating Neutron Libraries for MCUXpresso SDK 2.16 or before: Replace the entire middleware\eiq directory from MCUXpresso SDK 26.03 into your project, and then the Neutron libraries can be updated per the instructions above. In these older MCUXpresso SDK releases there were additional eIQ changes beyond just the four files above, so the easiest method to update those older projects is just to replace the entire eIQ middleware directory.        Updating Neutron Libraries for i.MX devices: To update the neutron runtime on a target device, upload the files to their designated directories, as follows:   File Target Directory NeutronFirmware.elf /lib/firmware libNeutronDriver.so /lib/ libneutron_delegate.so /lib/  
記事全体を表示
The i.MX RT700 microcontroller family includes an eIQ Neutron N3-64 NPU for accelerating neural network models. The i.MX RT700 EVK can be combined with a camera and LCD screen to showcase running TinyML vision models on a microcontroller.    i.MX RT700 Camera Hardware Setup: The following hardware is used: i.MX RT700 EVK RK055HDMIPI4MA0 LCD panel Camera Options: USB Camera with USB A to micro-B converter OV7670 parallel camera (with optional wide-angle lens) The USB camera should be attached to the i.MX RT700 EVK on USB OTG port J40. The parallel camera interface is available on J53 and uses FlexIO with eDMA to read in the camera data. AN14836 describes the details. Note that the links in that app note for the demo software do not work but the demo code is in the process of being posted on NXP’s Application Code Hub.  When inserting the parallel camera align it to the left most side, as shown in the image below:       Directions for attaching the LCD panel to the J52 connector on the underside of the i.MX RT700 EVK can be found on this Community post.  Note that there are multiple names used for the LCD panel and all these part numbers refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG i.MX RT700 Vision ML Examples: There are two vision AI/ML examples for i.MX RT700 available today: Object Detection (part of AN14718) Hand Gesture Recognition Both of these examples use a USB camera.  i.MX RT700 Vision MPP Examples:  The Media Processing Pipeline (MPP) interference examples in i.MX RT700 MCUXpresso SDK 26.06 and later support both parallel and USB camera interfaces. These SDK examples are only available for command line GCC and VS Code MCUXpresso SDK layouts. They are not available for MCUXpresso IDE, IAR, or Keil.    A parallel camera is used by default in the RT700 MPP projects. A USB camera can be enabled by adding a USE_USB_CAMERA declaration in the project's CMakeLists.txt file by adding the following macro:   mcux_add_macro(     CC "-DUSE_USB_CAMERA"     CX "-DUSE_USB_CAMERA" ) However it's important to note that the camera_usb_final_fr_app_view project is setup to use USB camera by default, but it only works with a very specific HM2131 camera. All other MPP demos can work with most generic USB cameras.   
記事全体を表示
Zephyr now supports the eIQ Neutron NPU on MCX N and i.MX RT700. This article will describe how to get Zephyr and use the eIQ Neutron NPU libraries and examples.  Some previous experience with eIQ Neutron NPU enablement is assumed, so ensure you're familiar with the eIQ Neutron SDK, converting models for eIQ Neutron NPU, and basic ML concepts by going through the MCX N or i.MX RT700  NPU bare-metal lab guides for VS Code before continuing on below.  Install Software Run the MCUXpresso Installer tool and install three key components: Zephyr Developer Arm GNU Toolchain Zephyr SDK LinkServer   Install LinkServer and add LinkServer to the PATH Install VS Code and MCUxpresso VS Code plugin   Download Zephyr Open VSCode Go to the MCUXpresso for VSCode plugin and click on Import Repository Go to the Remote tab and select the Zephyr repository. Choose it a directory name and location to download the repository to, and then click on Import.   It will take approximately 30 minutes to download the repository. Near the end of the download there will be several prompts in the terminal asking to accept licenses. Type “y” to accept and hit enter. There will be about 10 of these prompts at the end. Open the MCUXpresso Venv Terminal which has a Python virtual environment with all the paths preconfigured that were installed by MCUXpresso Installer.   In the terminal that pops up, type “1” to select the default environment. Then navigate to the directory you downloaded Zephyr into Run the following commands to get TensorFlow: west config manifest.project-filter -- +tflite-micro west update Go into the zephyr subdirectory folder cd zephyr Now need to explicitly download the Pull Request (PR) that enables eIQ Neutron. This eventually won’t be necessary when Zephyr 4.5 is released in October, but until then will need to type the following In the command prompt to get it:   git remote -v git remote add upstream https://github.com/zephyrproject-rtos/zephyr.git git remote -v   git stash git fetch upstream pull/108834/head:pr-108834 git checkout pr-108834   After this command you should see there’s now a folder at <zephyr_location>\ \zephyr\samples\boards\nxp\tflm_neutron with example source code.   Compile and Run a Zephyr eIQ Neutron NPU example Compile the project with west:  For MCX N: west build -p auto -b frdm_mcxn947/mcxn947/cpu0 samples/boards/nxp/tflm_neutron   For RT700: west build -p auto -b mimxrt700_evk/mimxrt798s/cm33_cpu0 samples/boards/nxp/tflm_neutron Open TeraTerm or other serial terminal program, and connect to the virtual COM port that board enumerated as when you plugged in the USB cable. Use 115200 baud, 1 stop bit, no parity. Flash the resulting code with west flash The serial terminal should show the following: Can debug with west debug      Run your own NPU accelerated ML model in Zephyr Make sure you've gone through the MCX N or i.MX RT700  hands-on labs so you're familiar with the enablement. The same steps for converting a model with the Neutron Converter tool inside eIQ Neutron SDK, updating the eIQ Neutron libraries, modfiying the operator list, and adding a new model are relevant when using Zephyr, but the file locations will be Zephyr specific. Also note that the header file generated by the Neutron Converter tool will need to be updated to match the header of the model.hpp file.  Also note that the README.rst file in the Zephyr Neutron example mentions using eIQ Toolkit but that information is outdated and been superseded by eIQ Neutron SDK.  eIQ Neutron example is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron Neutron libraries are at <zephyr_location>\modules\hal\nxp\zephyr\blobs\neutron\ Model data is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\models\mcxn\model.hpp Labels file is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\labels.h kTensorArenaSize variable is set in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 40) and is set to 60KB by default OpResolver is set in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 65) The model is selected in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 11)   Additional References: Blog post on west which Zephyr uses. Zephyr on FRDM-MCXN947 Zephyr on i.MX RT700 Zephyr TensorFlow
記事全体を表示
These lab guides provide step-by-step instructions on how to take a quantized TensorFlow Lite model and use the Neutron Conversion Tool found in eIQ Neutron SDK to convert the model to run on the eIQ Neutron NPU found on i.MX RT700 devices.  The eIQ Neutron NPU for i.MX RT700 Lab Guide documents focus on using the Neutron Converter tool found inside eIQ Neutron SDK  to convert a model and then import that converted model into an eIQ MCUXpresso SDK example. There are labs for VSCode, GCC, and MCUXpresso IDE.    The labs were designed to run on the i.MX RT700 EVK, but the same concepts can be applied to MCX N boards as well and are similar to the MCX N eIQ Neutron NPU labs. You can also explore the TFLM Getting Started Guide for information on how to use your own model and data for inference.  Also be sure to check out AN14700 - i.MX RT700 eIQ Neutron NPU Enablement and Performance which goes into more details on the eIQ Neutron N3-64 NPU found on i.MX RT700.  --- Updated July 2026 for MCUXpresso SDK 26.06
記事全体を表示
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: 1.048ms NPU w/ HiFi4: 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.   MCUXpresso SDK 26.03 Known Issue:  In MCUXpresso SDK 26.03 an additional compile option named -mlongcalls needs to be used to avoid issues when adding additional operators the ops list. For VS Code, inside \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4\hifi4 edit the reconfig.cmake file in the mcux_add_xtensa_configuration options:   mcux_add_xtensa_configuration( CC "-DXOS_CLOCK_FREQ=237500000 -std=c99 -mlongcalls" CX "-stdlib=libc++ \ -mlongcalls \ -std=c++17" ) If using Xtensa Explorer: Then in the Addl compiler tab, under Additional options, add -mlongcalls and click OK to save. HiFi4 Neutron Example:  The HiFi4 Neutron example may not execute in MCUXpresso SDK 26.03. Please either upgrade the Neutron libraries to the latest version, or else use the default HiFi4 Neutron example in MCUXpresso SDK 25.12 in the meantime. This will be fixed in MCUXpresso SDK 26.06.   HiFi Lab: See the attached lab document for more details on using the HiFi DSP modules to inference models.      
記事全体を表示
There are some items to be aware of when using eIQ projects in VSCode with MCUXpresso SDK 26.03   Debugger hangs when debugging eIQ examples on i.MX RT700 in VSCode There are two work-arounds available: 1) Use a JLink to debug the project instead of the default CMSIS-DAP interface. To do this: Install LinkServer Put a jumper on JP20 on the i.MX RT700 EVK, Update the MCULink firmware to use JLink by running C:\NXP\LinkServer_25.12.83\MCU-LINK_installer\scripts\program_JLINK.cmd Take off the jumper on JP20.    2) Alternatively update the linker file in the eIQ project:  Open the MIMXRT798Sxxxx_cm33_core0_flash.ld linker file in Repository->mcusdk->examples->_boards->mimxrt700evk->eiq_examples->tflm_label_image->cm33_core0->gcc  (use the path based on the eIQ project name that you are trying to use) In that linker file go to line 198 to 203 and replace the .ncache section with the code below:   .npu_ncache (NOLOAD) :   {       KEEP(*(.npu_ncache_data))       KEEP(*(.npu_ncache_data*))   } > m_ncache   ASSERT(. < 0x20580000, "Error: .npu_ncache cannot go beyond SRAM P18")   .ncache (NOLOAD) :   {     *(NonCacheable)     . = ALIGN(4);     __noncachedata_end__ = .;     /* define a global symbol at ncache data end */   } > m_ncache       i.MX RT700 eIQ HiFi4 and HiFi1 projects cannot be imported or compiled in VSCode or command line GCC. In VSCode use the "Repository" import option. To compile the projects you must install Xtensa Xplorer, the RT700 license, and RT700 NewLib DSP Configuration file. Then add the following environmental variables: XCC_DIR=/<Xtensa Install Path>/XtDevTools/install/tools/RI-2023.11-win32/XtensaTools XTENSA_CORE=rt700_hifi4_RI23_11_nlib The project can then be compiled with command-line GCC with: west build -p always --sysbuild examples/eiq_examples/tflm_cifar10_hifi4/cm --toolchain armgcc --config flash_debug -b mimxrt700evk -Dcore_id=cm33_core0 Note that if using HiFi1 projects then XTENSA_CORE should be set to rt700_hifi1_RI23_11_nlib   Also an additional compile option called -mlongcalls needs to be used to avoid issues when adding additional operators the ops list. Inside \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\tflm_cifar10_hifi4\hifi4 edit the reconfig.cmake file in the mcux_add_xtensa_configuration options:   mcux_add_xtensa_configuration( CC "-DXOS_CLOCK_FREQ=237500000 -std=c99 -mlongcalls" CX "-stdlib=libc++ \ -mlongcalls \ -std=c++17" ) A warning message comes up in eIQ Neutron SDK 3.1.2 If using eIQ Neutron SDK 3.1.2 then the follow warning will appear on the serial terminal during the model initialization: Unable to save model handle, call neutronModelUnprepare() when done This warning is not relevant for Neutron C devices like RT700 and MCX N and can be ignored as it does not impact inference time or accuracy. It will be fixed in the next eIQ Neutron SDK release. Some eIQ files that are commonly modified are shared among all eIQ examples For example, the Neutron libraries are shared among all eIQ examples. This can cause version compatibility issues with the default eIQ examples if the eIQ Neutron libraries are updated with eIQ Neutron SDK. This is because the eIQ projects in MCUXPresso SDK were converted using Neutron Converter 3.0.0 and the Neutron libraries in the SDK are shared among all eIQ projects.  To work around this, either revert the Neutron libraries back to version 3.0.0 or else download a separate repository to use the default eIQ examples. 
記事全体を表示
This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.
記事全体を表示
There are two important memory locations used during eIQ inferencing on microcontrollers: modeldata: Location of the model in memory. Can be located in RAM or Flash. Inference time will be faster if it is located in RAM. s_tensorArena: Memory area that is used for input, output, and intermediate arrays. Must be located in RAM. The MCUXpresso SDK eIQ projects create a s_tensorArena buffer that is placed in RAM and used by the model. In the MCUXpresso SDK projects, the default size for this buffer is 256 KB in size and the size is set by the kTensorArenaSize variable, which is declared in the model_data.h header file in the MCUXpresso SDK examples:   The s_tensorArena buffer is declared in the eIQ MCUXpresso SDK projects in the model.cpp file   Size of TensorArena for a model is based on the input, output, and scratch memory of the largest operator in the model:     It is estimated during Neutron Conversion in the last Total Data field. However it’s always slightly smaller than actual amount required.     The actual buffer size used is printed out during inference by using the s_interpreter- >arena_used_bytes(); API call after model initialization. This is automatically done in the MCUXpresso SDK eIQ examples:   Thus the tensorArena buffer size can be optimized in a project for the particular model by running the project at least once and then the kTensorArenaSize variable can be set to the actual used size as it will remain constant for a particular model. Buffer size requirements are model-specific and will depend on the structure and complexity of each model.   The TensorArena size required is often the same regardless of using the original unconverted model or a NPU converted model, but sometimes the NPU reduces the required size. And occasionally the buffer size must be larger for an NPU converted model so it is quite model dependent. Beyond the model inferencing specific memory requirements, there will also be RAM and Flash required for generating the input data for a model (camera, sensor, etc) and any output handling (LCD, notification, etc).  MCX N Specific Memory Details for Neutron NPU: By default the model is placed into the internal flash because in model_data.h it is declared with: static const uint8_t model_data[] __ALIGNED(16) __PLACEMENT = {   By removing the const keyword, then the model will be placed into RAM during runtime and slightly improve the inference time. static uint8_t model_data[] __ALIGNED(16) __PLACEMENT = { As an example, doing this in the CIFAR10 MCUXpresso SDK example improves the inference time from 7.032ms to 5.524ms. Note that the kTensorArena variable must also be reduced from the default 256,000 bytes to 44,848 in order to fit in the internal RAM. The inference time improvement is model specific. However putting the model into RAM could not be done for the Label Image MCUXpresso SDK example because that model is too big and there is not enough RAM available for the model plus the tesnorArena buffer (which must be in internal RAM).  i.MX RT700 Specific Memory Details for Neutron NPU: See the i.MX RT700 eIQ Neutron NPU Enablement and Performance app note (AN14700) for more details about using eIQ Neutron NPU on i.MX RT700.  On i.MX RT700 the NPU has access to 5.5 MB of internal RAM from address 0x2000_0000 to 0x2058_0000 which consists of partitions SRAM P0 to SRAM P17. The model should be located inside this RAM area if it is placed in internal RAM. If using external memory, then the eIQ libraries will automatically copy the necessary model data to that internal memory location (see section below). The s_tensorArena buffer must also be within this 5.5MB RAM memory area. If the tensorArena buffer is located outside this 5.5MB area the model will still run but the inference results will be incorrect.      For i.MX RT700 eIQ projects, by default the model is placed at location 0x2040_0000 in RAM using the modeldata location name. For larger models, the RAM allocated by default in the eIQ SDK example projects for the s_tensorArena buffer or modeldata area may not be sufficient. In such case, the NCACHE_REGION size (where the s_tensorArena buffer is located) and modeldata size can be increased in the SDK project settings by modifying the linker file. The tensorArena buffer for RT700 internal memory models that use the NPU must also be in noncachable memory space. The model will still run if it is in cachable memory space but the results may be incorrect.  As a side note, for non-converted models that only run on the CM33 Core0 and do not use the NPU at all (mostly only done for benchmarking comparisons) then the tensorArena can be in cachable RAM and will see better performance if it's in that cachable RAM and is located between 0x2000_0000 and 0x2058_0000 since that RAM is the main System RAM for Core0.    i.MX RT700 eIQ Neutron NPU with External Memory For large models, or in cases where RAM is limited due to other uses in the application, the model can be stored in external flash memory via XSPI0. Placing the model in the external memory has an impact on performance, however. An example of this can be found in the tflm_label_image_ext_mem example in the MCUXpresso SDK where the model is at address 0x2820_0000. When the model is in external flash, then during inference a fragmented copy of the model is done to bring in chunks of the model into the internal RAM. This does have an impact on performance of the model and an example is given in the app note. Note: If placed in external memory then the --fetch_constants_to_sram option must be used during NPU conversion of the model to let the Neutron library know that it needs to do this fragmented copy during inference.      The scratch_weights buffer size required for this operation is printed out in the Scratch field during the model conversion when using the required --fetch-constants-to-sram argument:   And the scratchWeightsBuffer is created in the \eiq\tensorflow-lite\tensorflow\lite\micro\kernels\neutron\neutron.cpp file and the size can be modified by editing: #define SCRATCH_WEIGHTS_SRAM_SIZE  1200*1024 static uint8_t scratchWeightsBuffer[SCRATCH_WEIGHTS_SRAM_SIZE] __attribute__((aligned(16))) __attribute__((section("NonCacheable")));   If the scratch memory buffer size is too small for the model then there will not be an error message but the model output may be incorrect.  Also note that the Scratch Memory buffer is only needed when running a Neutron enabled model in external memory on i.MX RT700. If using a non-Neutron enabled model that only uses the CM33 core to run, then it is not needed. 
記事全体を表示
There are two new LCD panels that are now available for i.MX RT EVKs: The original RK043FN02H-CT panel is being replaced with the newer RK043FN66HS-CTG panel, which will affect the following EVKs: i.MX RT1050 i.MX RT1060 i.MX RT1064   The original RK055HDMIPI4M panel is being replaced with the newer RK055HDMIPI4MA0 panel, which will affect the following EVKs: i.MX RT595 i.MX RT1160 i.MX RT1170   These changes are due to the previous panels being EOL by the LCD panel manufacturer. These new LCDs have the same dimensions and screen size as their original versions (4.3” 480x272 and 5.5” 720x1280 respectively) and the physical connections are the same. The version name can be found on the back of the LCD. Some of these panels have multiple names that are used interchangeably across different documents.  The old i.MX RT1170 panel has multiple names and all these names refer to the exact same panel: RK055HDMIPI4M RK055AHD091 RK055AHD091‑CTG The new i.MX RT1170 panel has multiple names and all these names refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG There are modifications to the software that may need to be made or else the LCD panel will be dark or blank when running MCUXpresso SDK demos on i.MXRT EVKs. This updated code is already available in the latest MCUXpresso SDK and SDK demos are configured by default to use the new panels.   For the i.MX RT1050/1060/1064 panel RK043FN66HS-CTG: The touch controller has changed and the SDK software has been modified to support the new touch controller. The LCD panel also has slightly different specs but the same code used for the original LCD panel will also work with the new LCD panel, so no change is necessary for display-only demos.  LCD demos are configured to support the new panel by default in the latest MCUXpresso SDK. So if you have the original panel you will need to change in the SDK code from      #define DEMO_PANEL  DEMO_PANEL_RK043FN66HS    //new panel (default SDK setting)           to       #define DEMO_PANEL  DEMO_PANEL_RK043FN02H     //older panel   For the i.MX RT595/RT1160/RT1170 panel RK055HDMIPI4MA0: Both the touch and display SDK software had to be updated to support this new panel. LCD demos are configured to support the new panel by default in the latest MCUXpresso SDK. So if you have the original panel you will need to change in the SDK code from:       #define DEMO_PANEL DEMO_PANEL_RK055MHD091    //new panel (default SDK setting)           to       #define DEMO_PANEL DEMO_PANEL_RK055AHD091    //older panel
記事全体を表示
This guide will walk through how to do connect the camera and LCD modules to i.MX RT boards and how to test to ensure the camera and LCD are connected properly. Update May 2022: There are now updated versions of these LCD panels that have an impact on software. See this post for more details. The physical connections are the same for both the original and new panels however so there are no changes to this guide.   This first part of this guide is for the i.MX RT1050, i.MX RT1060, i.MX RT1064 EVKs. The second part of this guide is for i.MX RT595, i.MX RT1160 and i.MX RT1170 EVKs.      Part 1: Camera and LCD for i.MX RT1050, i.MX RT1060, and i.MX RT1064:  The camera used by the RT1050, RT1060, and RT1064 EVKs are the same. However this camera only comes with the RT1060 and RT1064 EVKs. There are alternatives available for the RT1050 as discussed in this blog post.    The LCD screen compatible with these boards is the RK043FN66HS-CTG    Camera:  1) The camera connector is on the front of the board. Flip the black connector up so it's 90 degrees from its original position.  2) Then slide in the flat ribbon connector of the camera 3) Flip the black connector back down. It should keep the ribbon cable snug.   LCD: 1) On the back of the board, slide the black connector for the LCD ribbon forward. 2) Then slide in the flat LCD ribbon cable underneath the black connector. 3) Slide the black connector back to its original position. The cable should be snug. 4) Do the same for the touch controller connector and slide the black connector forward Then insert the cable between the black connector and the white top so that the cable is in the middle. It might take a few tries as its somewhat difficult. You could also use needle nose pliers to help guide in the cable but be careful about damaging the cable. 5) Then slide the black connector back to the original position. The cable should be snug. 6) It should look like the following when complete.   Testing: 1) To test the camera and LCD, use the CSI driver examples in the MCUXpresso SDK.  2) The camera will likely be out of focus the first time you use it. Adjust it by rotating the lens clockwise until the image is in focus. You can use your fingers or some needle nose pliers. It could take up to two rotations and it should turn easily. Also remove the plastic cover.    3) To test the touch controller, use the emwin temperature control example in the MCUXpresso SDK   Tape: 1) Once the LCD has been confirmed to work, you can use two layers of thick double sided foam tape to securely attach it to the board.      Part 2: Camera and LCD for i.MX 700, i.MX RT595, i.MX RT1160 and i.MX RT1170 EVKs:  The i.MX RT1160 and i.MX RT1170 EVKs both come with a OV5640 MIPI camera module in the box.    The LCD screen compatible with the i.MX RT1160, i.MX RT1170, i.MX RT595, and i.MX RT700 is the RK055HDMIPI4MA0 and it can be found here.  There are multiple alternative names for this panel and all these names refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG   Instructions for i.MX RT1170 are below: i.MX RT1170-EVK Camera:  1) The camera connector is on the front of the board at J2. It connects by simply pressing the camera down onto the connector. It takes a bit of force but should not be too difficult.    i.MX RT1170-EVK LCD: 1) On the back of the board, slide the black connector (J40) for the LCD ribbon forward towards the edge of the board.    2) Then carefully slide in the flat LCD ribbon cable into the connector. The blue writing should be facing up like in the photo. It should go above the black part of the connector that you just slid out, and under the white part of the connector.  3) Slide the black plastic connector back to its original position. The cable should be snug if pulled. It should look like the following:    i.MX RT1170-EVK Power: 1) If using the LCD, then the external power adapter must be used with the board. Connect the barrel connector to J43 on the board. 2) Also change the jumper on J38 to be on pins 1-2 so that it uses the external power.  3) Connect a micro-USB cable to J11, which will cause the board to enumerate as a COM port and as a debug interface for downloading and debugging code   i.MX RT1170-EVK Camera and LCD Testing: 1) To test the camera and LCD, use the csi_mipi_rgb_cm7 driver example that can be found in the MCUXpresso SDK for i.MX RT1170. The camera input should be displayed on the LCD screen if everything is connected properly.          
記事全体を表示
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   
記事全体を表示
目录 一、概述 二、环境准备   2.1 虚拟环境   2.2 使用Google Colab 三、核心步骤   3.1 CIFAR10数据集   3.2 模型创建   3.3 模型训练   3.4 模型转换   3.5 推理验证   3.6 benchmark性能   3.7 完整实现   3.7 简化版本(Colab) 四、TFLite Micro部署 五、快速验证 六、应用示例 七、结论 八、参考 more details, please see the attachment. 一、概述 CIFAR-10: 多伦多大学Alex Krizhevsky CIFAR-10公开数据集,也是计算机视觉领域最经典、最常用的入门级基准数据集之一,包含10个类别的6万张32x32彩色图像(5万训练,1万测试),例如飞机、汽车、鸟、猫等。 tflm_cifar10:演示了如何在恩智浦的微控制器上使用TensorFlow Lite Micro框架,实时运行CIFAR-10图像分类模型。即将一个预先训练好的、针对CIFAR-10数据集的卷积神经网络模型部署到MCU上,让其具备了识别10类常见物体(飞机、汽车、鸟、猫等)的能力。 模型:一个轻量级CNN模型,包含3个卷积层、ReLU激活层、池化层和一个全连接层。 输入: 32x32像素的彩色图像。 输出:图像属于CIFAR-10中10个类别的概率。 本文档:提供针对CIFAR10数据集搭建的完整流程,从数据集、模型训练转换、部署推理的快速实现方案,可作为示例tflm_cifar10(推理为主)的前置补充,本文不涉及到端侧的部署与优化。  ... """ CIFAR10 快速训练、测试、部署与推理完整流程 """ import os os.environ['TF_CPP_MIN_LOG_LEVEL'] = '2' # 减少TensorFlow日志 import tensorflow as tf import numpy as np import time import matplotlib.pyplot as plt print(f"TensorFlow版本: {tf.__version__}") print(f"NumPy版本: {np.__version__}") class CIFAR10QuickPipeline: def __init__(self): """初始化管道""" self.model = None self.tflite_model = None def load_data(self, sample_size=1000): """加载简化数据集""" print("\n1. 加载CIFAR10数据集...") (x_train, y_train), (x_test, y_test) = tf.keras.datasets.cifar10.load_data() # 预处理 x_train = x_train.astype('float32') / 255.0 x_test = x_test.astype('float32') / 255.0 # 使用少量数据(快速训练) x_train_small = x_train[:sample_size] y_train_small = y_train[:sample_size] x_test_small = x_test[:200] y_test_small = y_test[:200] # 转换为独热编码 y_train_onehot = tf.keras.utils.to_categorical(y_train_small, 10) y_test_onehot = tf.keras.utils.to_categorical(y_test_small, 10) print(f"训练数据: {x_train_small.shape}") print(f"测试数据: {x_test_small.shape}") return (x_train_small, y_train_onehot), (x_test_small, y_test_onehot) def create_simple_model(self): """创建简化CNN模型""" print("\n2. 创建简单CNN模型...") model = tf.keras.Sequential([ # 输入层 tf.keras.layers.Input(shape=(32, 32, 3)), # 卷积层1 tf.keras.layers.Conv2D(8, (3, 3), padding='same', activation='relu'), tf.keras.layers.MaxPooling2D((2, 2)), # 卷积层2 tf.keras.layers.Conv2D(16, (3, 3), padding='same', activation='relu'), tf.keras.layers.MaxPooling2D((2, 2)), # 全连接层 tf.keras.layers.Flatten(), tf.keras.layers.Dense(32, activation='relu'), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10, activation='softmax') ]) model.compile( optimizer='adam', loss='categorical_crossentropy', metrics=['accuracy'] ) model.summary() self.model = model return model def train_model(self, x_train, y_train, x_test, y_test, epochs=10): """训练模型""" print("\n3. 训练模型...") # 回调函数:早停 callbacks = [ tf.keras.callbacks.EarlyStopping( monitor='val_loss', patience=3, restore_best_weights=True ) ] history = self.model.fit( x_train, y_train, epochs=epochs, batch_size=32, validation_data=(x_test, y_test), callbacks=callbacks, verbose=1 ) # 评估模型 test_loss, test_acc = self.model.evaluate(x_test, y_test, verbose=0) print(f"\n测试准确率: {test_acc:.4f}") return history def convert_to_tflite(self): """转换为TFLite格式""" print("\n4. 转换为TFLite格式...") # 转换为TFLite converter = tf.lite.TFLiteConverter.from_keras_model(self.model) # 优化配置 converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_types = [tf.float32] # 转换 tflite_model = converter.convert() # 保存模型 with open('cifar10_model.tflite', 'wb') as f: f.write(tflite_model) # 保存为字节数组(用于嵌入式部署) self.save_as_c_array(tflite_model) self.tflite_model = tflite_model model_size = len(tflite_model) / 1024 print(f"模型大小: {model_size:.1f} KB") return tflite_model def save_as_c_array(self, tflite_model): """保存为C数组格式""" c_array = '// 自动生成的CIFAR10模型数组\n' c_array += '#include <stdint.h>\n\n' c_array += 'const unsigned char cifar10_model_tflite[] = {\n' # 每行显示12个字节 for i in range(0, len(tflite_model), 12): line_bytes = tflite_model[i:i+12] c_array += ' ' + ', '.join(f'0x{b:02x}' for b in line_bytes) + ',\n' c_array += '};\n\n' c_array += f'const unsigned int cifar10_model_tflite_len = {len(tflite_model)};\n' with open('cifar10_model_array.h', 'w') as f: f.write(c_array) print("C数组已保存: cifar10_model_array.h") def test_tflite_inference(self, x_test, y_test, num_tests=10): """测试TFLite推理""" print(f"\n5. 测试TFLite推理 ({num_tests}个样本)...") if self.tflite_model is None: with open('cifar10_model.tflite', 'rb') as f: self.tflite_model = f.read() # 加载TFLite模型 interpreter = tf.lite.Interpreter(model_content=self.tflite_model) interpreter.allocate_tensors() input_details = interpreter.get_input_details() output_details = interpreter.get_output_details() # 类别名称 class_names = ['飞机', '汽车', '鸟', '猫', '鹿', '狗', '青蛙', '马', '船', '卡车'] correct = 0 times = [] for i in range(min(num_tests, len(x_test))): # 准备输入 input_data = x_test[i:i+1] # 推理 start_time = time.perf_counter() interpreter.set_tensor(input_details[0]['index'], input_data) interpreter.invoke() inference_time = time.perf_counter() - start_time times.append(inference_time) # 获取输出 output = interpreter.get_tensor(output_details[0]['index']) predicted_class = np.argmax(output[0]) actual_class = np.argmax(y_test[i]) # 检查是否正确 if predicted_class == actual_class: correct += 1 print(f"样本 {i+1}: 预测={class_names[predicted_class]:<5} " f"实际={class_names[actual_class]:<5} " f"时间={inference_time*1000:.1f}ms " f"{'✓' if predicted_class == actual_class else '✗'}") accuracy = correct / num_tests avg_time = np.mean(times) * 1000 print(f"\n推理统计:") print(f" 准确率: {accuracy:.1%} ({correct}/{num_tests})") print(f" 平均推理时间: {avg_time:.1f}ms") print(f" 推理速度: {1000/avg_time:.0f} FPS") return accuracy, avg_time def benchmark_performance(self, x_test): """性能基准测试""" print("\n6. 性能基准测试...") interpreter = tf.lite.Interpreter(model_content=self.tflite_model) interpreter.allocate_tensors() input_details = interpreter.get_input_details() # 预热 test_input = x_test[0:1] for _ in range(10): interpreter.set_tensor(input_details[0]['index'], test_input) interpreter.invoke() # 基准测试 num_runs = 100 start_time = time.perf_counter() for _ in range(num_runs): interpreter.invoke() total_time = time.perf_counter() - start_time avg_time = total_time / num_runs * 1000 print(f"基准测试结果:") print(f" 总推理次数: {num_runs}") print(f" 总时间: {total_time*1000:.1f}ms") print(f" 平均推理时间: {avg_time:.1f}ms") print(f" 推理速度: {1000/avg_time:.0f} FPS") return avg_time def save_model_summary(self): """保存模型摘要""" summary = [] self.model.summary(print_fn=lambda x: summary.append(x)) with open('model_summary.txt', 'w') as f: f.write('\n'.join(summary)) f.write(f"\n\n模型信息:") f.write(f"\n参数数量: {self.model.count_params():,}") f.write(f"\n保存时间: {time.ctime()}") print("模型摘要已保存: model_summary.txt") def main(): """主函数""" print("=" * 60) print("CIFAR10 快速训练、测试、部署管道") print("=" * 60) # 创建管道 pipeline = CIFAR10QuickPipeline() # 1. 加载数据 (x_train, y_train), (x_test, y_test) = pipeline.load_data(sample_size=2000) # 2. 创建模型 pipeline.create_simple_model() # 3. 训练模型 history = pipeline.train_model(x_train, y_train, x_test, y_test, epochs=15) # 4. 保存模型摘要 pipeline.save_model_summary() # 5. 转换为TFLite pipeline.convert_to_tflite() # 6. 测试推理 pipeline.test_tflite_inference(x_test, y_test, num_tests=20) # 7. 性能测试 pipeline.benchmark_performance(x_test) print("\n" + "=" * 60) print("流程完成!生成的文件:") print(" 1. cifar10_model.tflite - TFLite模型") print(" 2. cifar10_model_array.h - C数组格式") print(" 3. model_summary.txt - 模型摘要") print("=" * 60) if __name__ == "__main__": main() ... 七、结论 本文旨在以常见图像分类场景(CIFAR10)为例,让读者快速了解从数据搭建、模型创建、训练、推理和验证的完整流程,可作为示例tflm_cifar10(端推理为主)的前置补充,本文不涉及到端侧部署与优化。
記事全体を表示
1 背景 2 开发搭建    2.1 软件    2.2 硬件 3 性能优化    3.1 原始性能    3.2 优化1:编译优化    3.3 优化2:外部SDRAM    3.4 优化3:VGLite加速    3.5 优化对比 4 结论 5 参考       1 背景 LVGL (Light and Versatile Graphics Library)是一款高性能、低资源占用的轻量级嵌入式图形库,凭借其强大的开源生态与广泛的操作系统适配支持,能够覆盖从低功耗的ARM Cortex-M系列微控制器(主频可低至100MHz)到运行Linux的高性能MPU等多种硬件平台,已成为嵌入式开源方案中的首选。许多芯片厂商已为其提供“开箱即用”级支持。 恩智浦(NXP)为其主流平台(如MCX、i.MX RT和LPC系列)提供了配套的软硬件示例,并在MCUXpresso SDK中集成了LVGL示例,这些示例对各类场景进行基准指标量化。然而,在实际应用中,因软、硬件配置与规格差异,性能表现往往存在波动,需结合具体场景进行针对性优化。 本文基于i.MX RT1170相关实践案例,旨在帮助NXP用户快速理解并选用适当的优化策略,以达成LVGL应用性能提升的目标。     4    结论 本文档针对NXP官方示例LVGL的 benchmark性能进行逐步优化,如CPU Usage, FPS, Render时间,Flush时间等,并提供了各个优化方案的量化数据对比以’Widgets demo’为例,其CPU使用率由原始的97%逐步降低至17%,而FPS帧率则由原始的2帧/秒提升至59帧/秒。 另外,这些优化方法和思路并不局限在该场景应用,对于常规的系统级的性能提升亦可作为参考。
記事全体を表示
  1 Background 2 Development Setup   2.1 Software   2.2 Hardware 3 Performance Optimization   3.1 Baseline Performance   3.2 Optimization 1: Compiler Optimization   3.3 Optimization 2: External SDRAM   3.4 Optimization 3: VGLite Acceleration   3.5 Optimization Comparison 4 Conclusion 5 References 1. Background LVGL (Light and Versatile Graphics Library) is a high-performance, low-resource embedded graphics library. Thanks to its robust open-source ecosystem and broad OS compatibility, it supports a wide range of hardware platforms—from low-power ARM Cortex-M microcontrollers (with clock speeds as low as 100 MHz) to high-performance MPUs running Linux—making it a preferred choice in embedded open-source solutions. Many silicon vendors now offer “out-of-the-box” support for LVGL.   NXP provides ready-to-use software and hardware examples for its mainstream platforms—including MCX, i.MX RT, and LPC series—and integrates LVGL examples into the MCUXpresso SDK. These examples include quantified benchmark metrics for various scenarios. However, due to differences in software/hardware configurations and specifications, actual performance may vary significantly and often requires scenario-specific tuning.   This document, based on practical experience with the i.MX RT1170 platform, aims to help NXP users quickly understand and apply appropriate optimization strategies to enhance LVGL application performance.         4. Conclusion This document presents a step-by-step optimization of NXP’s official LVGL benchmark example, with quantified improvements in CPU usage, FPS, render time, and flush time. Taking the Widgets demo as an example: CPU usage dropped from 96% → 12% FPS increased from 2 → 59 These optimization techniques—not limited to LVGL—are broadly applicable to system-level performance tuning on i.MX RT platforms.
記事全体を表示
This is a guide line to run both the master core and slave core projects as XIP targets from one flash.
記事全体を表示
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.
記事全体を表示
Recovery Methods for RT595 and RT685 Development Boards When Programming Fails During the development and use of RT595 and RT685 development boards, developers often encounter a common issue reported by users: persistent errors during programming via a debugger, making it impossible to reprogram the board and effectively rendering it “bricked.” These issues can arise from various causes, such as incorrect FCB writing, interruptions during the download process, or other unknown anomalies. This article introduces two effective recovery methods: Using the SEC TOOL utility. Using an external J-Link programmer. Note: Both methods require setting the RT595 and RT685 boards to Serial ISP mode beforehand. NXP has released two RT685-based development boards (MIMXRT685-AUD-EVK and MIMXRT685-EVK) and one RT595 board. Since the RT595 board operates similarly to the RT685 boards, this article uses the MIMXRT685-AUD-EVK board for demonstration. Ensure the SDK version is correct during the process. 1. Preparation: Entering Serial ISP Mode Using the MIMXRT685-AUD-EVK board as an example, set switches SW5[1-3] to “ON OFF OFF” to enter Serial ISP mode. This corresponds to the following pin levels: PIO1_17: High PIO1_16: High PIO1_15: Low Refer to the RT600 User Manual for detailed mappings between ISP pins and boot modes.   2. Method 1: Recovery Using SEC TOOL  1. Preparation: Generate APP Image Import SDK Demo: Open MCUXpresso IDE and import the demo project mimxrt685audevk_lpc_gpio_led_output_cm33.   Modify Project Settings: Make two key configuration changes to ensure successful image generation. Generate Hex File: After configuration, build the project to generate a Hex file for use with SEC TOOL. 2. Using SEC TOOL Download SEC TOOL: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-secure-provisioning-tool:MCUXPRESSO-SECURE-PROVISIONING Create Workspace: Launch SEC TOOL and create a new workspace for MIMXRT685S. Select Connection Method: RT500 and RT600 support USB, UART, SPI, and I2C. Choose one (e.g., UART via J5 or USB via J7). Only one protocol can be used at a time. If switching, power cycle the board. Configure Flash Type and Test: Select the default external NOR Flash for MIMXRT685-AUD-EVK, apply settings, and run a test. Build Image: Use the previously generated App image and click “Build Image.”    Program Image: Flash the image to the RT685 chip.   Switch Boot Mode: Power off the board and set Boot mode to FlexSPI Boot from PortB: PIO1_17: Low PIO1_16: High PIO1_15: Low SW5[1-3]: “ON OFF ON” Power on the board again. It should now operate normally and run the program successfully. 3. Method 2: Recovery Using J-Link Programmer 1. Preparation: Generate Flashable File Import the same demo project into MCUXpresso IDE and compile it without modifications to generate a Hex or S19 file. Download and install SEGGER J-Flash from SEGGER Official Website. 2. Hardware Setup Board Modifications: Connect pins 2 and 3 of JP2. Remove jumpers JP17, JP18, JP19 (ensure p3 is disconnected). Set SW5 to “ON OFF OFF”. Device Connection: Connect J-Link Plus to J19 on the board. Connect J6 to the PC to power the board. 3. Programming with J-Flash Create New Project: Open J-Flash and create a new project for MIMXRT685S. Note: RT685 supports only SWD, not JTAG. Flash Program: Load the Hex file and flash it to the board.   Switch Boot Mode: After flashing, power off the board and set Boot mode to FlexSPI Boot from PortB: PIO1_17: Low PIO1_16: High PIO1_15: Low SW5[1-3]: “ON OFF ON” Power on the board again. It should now function normally and run the program successfully.   Conclusion By following either of the two methods described above, developers can effectively recover RT595 and RT685 development boards from programming failures and restore normal operation. Choose the method that best suits your specific situation. 
記事全体を表示
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       
記事全体を表示
​​迁移重点​​: ​​检查GPIO配置​​:利用新时序建议优化设计。 ​​更新SDK至25.06+​​:确保芯片版本识别和ROM API兼容。 ​​验证SEMC设计​​:若使用CSX1/2/3,需按ERR052401调整时序。 ​​工具链升级​​:J-Link v8.38+和MCUXpresso脚本更新。   0. 本文目的    若您并未遇到RT1170 FSGPIO漂移老化问题,请忽略本文档。 若您遇到RT1170A的ERR052351(输出电压>1.98V时参数漂移)和ERR050643(上电瞬间误触发上拉脉冲)问题,并想通过迁移到新硅片RT1170B,请查看本文完成迁移。 ​ 1. 硅片变更 (Silicon Changes)​ ​ ​​GPIO修复​​: 解决了RT1170A的ERR052351(输出电压>1.98V时参数漂移)和ERR050643(上电瞬间误触发上拉脉冲)问题。 影响范围:GPIO_AD/GPIO_LPSR/GPIO_DISP_B2 bank。 ​​ROM更新​​: 清理ROM补丁(不影响开放API)。 ​​HAB API向量表地址​​:从 0x0021_1C0C (A版)改为 0x0021_1C14 (B版)。 ROM_FLEXSPI_NorFlash_ClearCache() 入口地址变更(详见第6节)。 ​​芯片ID变更​​: MISC_DIFPROG 寄存器的 CHIPID 复位值变化: A版: 0x001170A0 B版: 0x001170B0 (需通过bit[7:4]区分:A版= 1011 ,B版= 1100 )。 ​​2. 数据手册变更 (Data Sheet Changes)​ ​ ​​型号命名​​:所有型号后缀从 A 改为 B (例: MIMXRT117xxxxxB )。 ​​GPIO电气规范​​: ​​表37​​:GPIO_AD/LPSR/DISP_B2的驱动电流调整(如DSE=1时IOH从-10mA→-9mA)。 ​​表40​​: 新增 Vpead 参数。 上升/下降时间调整(如DSE=0/SRE=1时从6ns→7.5ns)。 ​​关键建议​​: 3.3V模式:≥25MHz用连续范围模式(Continuous Range),<25MHz用高范围模式(High Range)。 1.8V模式:推荐低范围模式(Low Range)。 ​​其他更新​​: 存储温度范围:-40℃ → ​​-55℃​​。 SDR50/SDR104时序:输入建立时间从2.5ns→2.0ns。 FlexSPI时序:TDVO最大值从4→1,TDHO最小值从2→0。 ​​3. 参考手册变更 (Reference Manual Changes)​ ​ ​​芯片ID识别​​: MISC_DIFPROG[7:4] 复位值从固定值改为​​芯片版本标识​​(A版= 1011 ,B版= 1100 )。 ​​4. 勘误变更 (Errata Changes)​   参考资料:i.MX RT1170A Errata,  i.MX RT1170B Errata​ ​​修复问题​​: 移除ERR052351(GPIO参数漂移)和ERR050643(上电脉冲问题)。 ​​新增问题​​: ​​ERR052401​​:SEMC_CSX1/2/3信号时序退化(SYNC模式最大延迟增加2.4ns)。 ​​规避方案​​: SYNC模式:优先使用SEMC_CSX0或SEMC_RDY作为片选。 Async模式:调整SEMC配置寄存器(SRAMCR1/NORCR1的CES位)。 ​​5. SDK代码变更 (SDK Code Changes)​ ​ ​​SDK 25.06​​(2025年6月底发布)支持B版。 ​​关键代码调整​​: ChipID 和  ROM_API bootloader入口地址  变更 /*! * @brief ROM API init. */ void ROM_API_Init(void) { if (ANADIG_MISC->MISC_DIFPROG == 0x001170a0U) // A版 { g_bootloaderTree = ((bootloader_api_entry_t *)*(uint32_t *)0x0020001cU); } else // B版 { g_bootloaderTree = ((bootloader_api_entry_t *)*(uint32_t *)0x0021001cU); } } FlexSPI缓存清除函数入口地址变更 :ROM_FLEXSPI_NorFlash_ClearCache /*! @brief Software reset for the FLEXSPI logic. */ void ROM_FLEXSPI_NorFlash_ClearCache(uint32_t instance) { uint32_t clearCacheFunctionAddress; if (ANADIG_MISC->MISC_DIFPROG == 0x001170a0U) { clearCacheFunctionAddress = 0x0020426bU; } else if (ANADIG_MISC->MISC_DIFPROG == 0x001170b0U) { clearCacheFunctionAddress = 0x0021a3b7U; } else { clearCacheFunctionAddress = 0x0021a3bfU; } HAB API vector table addresses变更 :从0x0021_1C0C(i.MX RT1170A) to 0x0021_1C14(i.MX RT1170B). SDK无影响,SBL github已经解决。 ​​6. 工具变更 (Tool Changes)​ ​ ​​J-Link​​:需升级至​​v8.38或更高版本​​。 ​​MCUXpresso​​:v24.12及更早版本需更新 RT1170_reset.scp 脚本中的芯片ID检测逻辑。 ​​7. 通用数据手册更新 (Appendix A)​ ​ ​​电压范围​​: NVCC_GPIO重命名为​​NVCC_AD​​(后续版本将恢复原名)。 NVCC_AD/DISP2/LPSR最大值从1.95V→​​1.98V​​。 ​​GPIO模式定义​​: 统一命名:​​连续范围模式​​(原Normal/Derated)、​​低范围模式​​(原Low)、​​高范围模式​​(原High)。 ​​时序优化​​: LPSPI主模式频率上限从30MHz→​​60MHz​​,建立时间从10ns→3ns。 ​​新增警告​​: GPIO_AD/LPSR/DISP_B2的NVCC不可悬空,否则可能漏电​​500μA/每Bank​​。 ​​8. 其他信息​ ​ ​​文档版权​​:示例代码遵循​​BSD-3-Clause许可证​​。 ​​参考文档​: AN14716 MCUXPresso SDK i.MX RT
記事全体を表示