i.MX RT Crossover MCUs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT Crossover MCUs Knowledge Base

Discussions

Sort by:
1 Introduction    With the quick development of science and technology, the Internet of Things(IoT) is widely used in various areas, such as industry, agriculture, environment, transportation, logistics, security, and other infrastructure. IoT usage makes our lives more colorful and intelligent. The explosive development of the IoT cannot be separated from the cloud platform. At present, there are many types of cloud services on the market, such as Amazon's AWS, Microsoft's Azure, google cloud, China's Alibaba Cloud, Baidu Cloud, OneNet, etc.    Amazon AWS Cloud is a professional cloud computing service that is provided by Amazon. It provides a complete set of infrastructure and cloud solutions for customers in various countries and regions around the world. It is currently a cloud computing with a large number of users. AWS IoT is a managed cloud platform that allows connected devices to easily and securely interact with cloud applications and other devices.    NXP crossover MCU RT product has launched a series of AWS sample codes. This article mainly explains the remote_control_wifi_nxp code in the official MIMXRT1060-EVK SDK as an example to realize the data interaction with AWS IoT cloud, Android mobile APP, and MQTTfx client. The cloud topology of this article is as follows: Fig.1-1 2 AWS cloud operation 2.1 Create an AWS account Prepare a credit card, and then go to the below amazon link to create an AWS account:    https://console.aws.amazon.com/console/home   2.2 Create a Thing    Open the AWS IOT link: https://console.aws.amazon.com/iot    Choose the Things item under manage, if it is the first time usage, customer can choose “register a thing” to create the thing. If it is used in the previous time, customers can click the “create” button in the right corner to create the thing. Choose “create a single thing” to create the new thing, more details check the following picture. Fig. 2-1 Fig.2-2 Fig.2-3 2.3 Create certificate    Create a certificate for the newly created thing, click the “create certificate” button under the following picture: Fig.2-4    After the certificate is built, it will have the information about the certificate created, it means the certificate is generated and can be used. Fig. 2-5 Please note, download files: certificate for this thing, public key, private key. It will be used in the mqttfx tool configuration. Click “A root CA for AWS for Download”, download the root CA for AWS IoT, the mqttfx tool setting will also use it. Open the root CA download link, can download the CA certificate. RSA 2048 bit key: VeriSign Class 3 Public Primary G5 root CA certificate Fig. 2-6 At last, we can get these files: 7abfd7a350-certificate.pem.crt 7abfd7a350-private.pem.key 7abfd7a350-public.pem.key AmazonRootCA1.pem Save it, it will be used later. Click “active” button to active the certificate, and click “Done” button. The policy will be attached later.   2.4 Create Policies     Back to the iot view page: https://console.aws.amazon.com/iot/     Select the policies under Secure item, to create the new policies.  Fig. 2-7 Input the policy name, in the action area, fill: iot:*, Resource ARN area fill: * Check Allow item, click the create button to finish the new policy creation. Fig. 2-8 2.5 Things attach relationship     After the thing, certificate, policies creation, then will attach the policy to the certificate, and attach the certificate to the Things. Fig. 2-9 Choose the certificates under Secure item, in the related certificate item, choose “…”, you will find the down list, click “attach policy”, and choose the newly created policy. Then click attach thing, choose the newly created thing. Fig. 2-10 Fig. 2-11 Fig. 2-12 Now, open the Things under Mange item, check the detail things related information. Fig.2-13 Double click the thing, in the Interact item, we can find the Rest API Endpoint, the RT code and the mqttfx tool will use this endpoint to realize the cloud connection. Fig. 2-14 Check the security, you will find the previously created certificate, it means this thing already attach the new certificates: Fig. 2-15 Until now, we already finish the Things related configuration, then it will be used for the MQTT fx, Android app, RT EVK board connections, and testing, we also can check the communication information through the AWS shadow in the webpage directly.       3 Android related configuration 3.1 AWS cognito configuration    If use the Android app to communicate with the AWS IoT clould, the AWS side still needs to use the cognito service to authorize the AWS IoT, then access the device shadows. Create a new identity pools at first from the following link: https://console.aws.amazon.com/cognitohttps://console.aws.amazon.com/cognito Fig. 3-1 Click “manage Identity pools”, after enter it, then click “create new identity pool” Fig. 3-2 Fig. 3-3 Fig. 3-4 Here, it will generate two Roles: Cognito_PoolNameAuth_Role Cognito_PoolNameUnauth_Role Click Allow, to finish the identity pool creation. Fig. 3-5 Please record the related Identity pool ID, it will be used in the Android app .properties configuration files. 3.2 Create plicies in IAM for cognito   Open https://console.aws.amazon.com/iam   Click the “policies” item under “access management” Fig. 3-6 Choose “create policy”, create a IAM policies, in the Policy JSON area, write the following content: Fig. 3-7 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:Connect" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "iot:Publish" ], "Resource": [ "arn:aws:iot:us-east-1:965396684474:topic/$aws/things/RTAWSThing/shadow/update", "arn:aws:iot:us-east-1:965396684474:topic/$aws/things/RTAWSThing/shadow/get" ] }, { "Effect": "Allow", "Action": [ "iot:Subscribe", "iot:Receive" ], "Resource": [ "*" ] } ] }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Please note, in the JSON content: "arn:aws:iot:<REGION>:<ACCOUNT ID>:topic/$aws/things/<THING NAME>/shadow/update", "arn:aws:iot:<REGION>:<ACCOUNT ID>:topic/$aws/things/<THING NAME>/shadow/get" Region:the us-east-1 inFig. 3-5 ACCOUNT ID, it can be found in the upper right corner my account side. Fig 3-8 Fig 3-9 After finished the IAM policy creation, then back to IAM policies page, choose Filter policies as customer managed, we can find the new created customer’s policy. Fig. 3-10 3.3 Attach policy for the cognito role in IAM   In IAM, choose roles item: Fig. 3-11 Double click the cognito_PoolNameUnauth_Role which is generated when creating the pool in cognito, click attach policies, select the new created policy. Fig. 3-12 Fig. 3-13 Until now, we already finish the AWS cognito configuration.   3.4  Android properties file configuration Create a file with .properties, the content is:     customer_specific_endpoint=<REST API ENDPOINT>     cognito_pool_id=<COGNITO POOL ID>     thing_name=<THING NAME>     region=<REGION> Please fill the correct content: REST API ENDPOINT:Fig 2-14 COGNITO POOL ID:fig 3-5 THING NAME:fig 2-14,upper left corner REGION:Fig 3-5, the region data in COGNITO POOL ID Take an example, my properties file content is:  customer_specific_endpoint=a215vehc5uw107-ats.iot.us-east-1.amazonaws.com  cognito_pool_id=us-east-1:c5ca6d11-f069-416c-81f9-fc1ec8fd8de5  thing_name=RTAWSThing  region=us-east-1 In the real usage, please use your own configured data, otherwise, it will connect to my cloud endpoint. 4. MQTTfx configuration and testing MQTT.fx is an MQTT client tool which is based on EclipsePaho and written in Java language. It supports subscribe and publish of messages through Topic. You can download this tool from the following link:   http://mqttfx.jensd.de/index.php/download    The new version is:1.7.1.   4.1 MQTT.fx configuration     Choose connect configuration button, then enter the connection configuration page: Fig. 4-1 Profile Name: Enter the configuration name Broker Address: it is REST API ENDPOINT。 Broker Port:8883 Client ID: generate it freely CA file: it is the downloaded CA certificate file Client Certificate File: related certificate file Client key File: private key file Check PEM formatted。 Click apply and OK to finish the configuration. 4.2 Use the AWS cloud to test connection   In order to test whether it can be connected to the event cloud, a preliminary connection test can be performed. Open the aws page: https://console.aws.amazon.com/iot here is a Test button under this interface, which can be tested by other clients or by itself.Both AWS cloud and MQTTfx subscribe topic: $aws/things/RTAWSThing/shadow/update MQTTfx publishes data to the topic: $aws/things/RTAWSThing/shadow/update It can be found that both the cloud test port and the MQTTfx subscribe can receive data: Fig. 4-2 Below, the Publish data is tested by the cloud, and then you can see that both the MQTTFX subscribe and the cloud subscribe can receive data: Fig. 4-3 Until now, the AWS cloud can transfer the data between the AWS iot cloud and the client. 5 RT1060 and wifi module configuration   We mainly use the RT1060 SDK2.8.0 remote_control_wifi_nxp as the RT test code: SDK_2.8.0_EVK-MIMXRT1060\boards\evkmimxrt1060\aws_examples\remote_control_wifi_nxp Test platform is:MIMXRT1060-EVK Panasonic PAN9026 SDIO ADAPTER + SD to uSD adapter The project is using Panasonic PAN9026 SDIO ADAPTER in default. 5.1 WIFI and the AWS code configuration    The project need the working WIFI SSID and the password, so prepare a working WIFI for it. Then add the SSID and the password in the aws_clientcredential.h #define clientcredentialWIFI_SSID       "Paste WiFi SSID here." #define clientcredentialWIFI_PASSWORD   "Paste WiFi password here." The connection for AWS also in file: aws_clientcredential.h #define clientcredentialMQTT_BROKER_ENDPOINT "a215vehc5uw107-ats.iot.us-east-1.amazonaws.com" #define clientcredentialIOT_THING_NAME       "RTAWSThing" #define clientcredentialMQTT_BROKER_PORT      8883   5.2 certificate and the key configuration Open the SDK following link: SDK_2.8.0_EVK-MIMXRT1060\rtos\freertos\tools\certificate_configuration\CertificateConfigurator.html Fig. 5-1 Generate the new aws_clientcredential_keys.h, and replace the old one. Take the MCUXPresso IDE project as an example, the file location is: Fig. 5-2 Build the project and download it to the MIMXRT1060-EVK board. 6 Test result Androd mobile phone download and install the APK under this folder: SDK_2.8.0_EVK-MIMXRT1060\boards\evkmimxrt1060\aws_examples\remote_control_android\AwsRemoteControl.apk SDK can be downloaded from this link: Welcome | MCUXpresso SDK Builder  Then, we can use the Android app to remote control the RT EVK on board LED, the test result is 6.1 APP and EVK test result MIMXRT1060-EVK printf information: Fig. 6-1 Turn on and turn off the led:   Fig. 6-2                                        Fig. 6-3 6.2 MQTTfx subscribe result MQTTfx subscribe data Turn on the led, we can subscribe two messages: Fig. 6-4 Fig. 6-5   Turn off the led, we also can subscribe two messages: Fig. 6-6 Fig. 6-7 In the two message, the first one is used to set the led status. The second one is the EVK used to report the EVK led information. MQTTfx also can use the publish page, publish this data: {"state":{"desired":{"LEDstate":1}}} or {"state":{"desired":{"LEDstate":0}}} To topic: $aws/things/RTAWSThing/shadow/update It also can realize the on board LED turn on or off. 6.3 AWS cloud shadows display result Turn on the led: Fig. 6-8 Turn off the led: Fig. 6-9 In conclusion, after the above configuration and testing, it can finish the Android mobile phone to remote control the RT EVK on board LED and get the information. Also can use the MQTTFX client tool and the AWS shadow page to check the communication data.
View full article
Slides from webinar hosted by NXP on Dec 10, 2019.
View full article
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.      
View full article
This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.
View full article
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. 
View full article
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: OV7670 parallel camera (with optional wide-angle lens) USB Camera with USB A to micro-B converter The AI/ML demos currently available use the USB camera but an AI/ML example using the parallel camera is under development. 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. 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. Also note that there are multiple alternative names for the LCD panel and all these names 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 The Media Processing Pipeline (MPP) interference examples in the i.MX RT700 MCUXpresso SDK only support inferencing on static images. USB and FlexIO camera support for those examples are under development. These projects are also only available for command line GCC and VS Code. However the camera_view MPP example, which simply shows the camera data on a LCD display but does not inference a model, does support a USB camera and can be enabled by adding a USE_USB_CAMERA declaration in \mcuxsdk\examples\_boards\mimxrt700evk\eiq_examples\mpp\examples\camera_view\reconfig.cmake by editing the following macro:   mcux_add_macro(     CC "-DRTOS_HEAP_SIZE=2000 \     -DconfigGENERATE_RUN_TIME_STATS=1 \     -DUSE_USB_CAMERA"     CX "DconfigGENERATE_RUN_TIME_STATS=1\     -DUSE_USB_CAMERA" )  
View full article
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. 
View full article
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 Manually Update SDK Libraries To Use Latest Version   eIQ Neutron SDK 3.1.2   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/  
View full article
目录 一、概述 二、环境准备   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(端推理为主)的前置补充,本文不涉及到端侧部署与优化。
View full article
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帧/秒。 另外,这些优化方法和思路并不局限在该场景应用,对于常规的系统级的性能提升亦可作为参考。
View full article
  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.
View full article
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 June 2026 for eIQ Neutron SDK 3.1.2
View full article
This is a guide line to run both the master core and slave core projects as XIP targets from one flash.
View full article
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. 
View full article
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.
View full article
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       
View full article
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 full article
​​迁移重点​​: ​​检查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
View full article