i.MX RT Crossover MCUs Knowledge Base

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

i.MX RT Crossover MCUs Knowledge Base

讨论

排序依据:
Realize a panoramic video layer with OpenGL
查看全文
When design a project, sometimes CCM_CLKO1 needs to output different clocks to meet customer needs. This customer does not need to buy a separate crystal, which can reduce costs。The document describe how to make CCM_CLKO1 output different clock on I.MXRT1050. According to  selection of the clock to be generated on CCM_CLKO1(CLKO1_SEL) and setting the divider of CCM_CLKO1(CLKO1_DIV) in I.MXRT1050reference manual. CCM_CLKO1 can output different clock. If CCM_CLKO1 output different clock via SYS PLL clock. We can get the different clock for the application. CLKO1_DIV 000 001 010 011 100 101 110 111 Freq(MHz) 264 132 88 66 52.8 44 37.714 33 For example we want to get 88Mhz output via SYS PLL clock. We can follow the steps as the below(led_blinky project in SDK 😞       1. PINMUX GPIO_SD_B0_04 as CCM_CLKO1 signal.       IOMUXC_SetPinConfig(       IOMUXC_GPIO_SD_B0_04_CCM_CLKO1,              0x10B0u; 2.Enable CCM_CLKO1 signal. CCM->CCOSR |= CCM_CCOSR_CLKO1_EN_MASK; 3.Set CLKO1_DIV to get 88MHZ the clock for the application. CCM->CCOSR = (CCM->CCOSR & (~CCM_CCOSR_CLKO1_DIV_MASK)) | CCM_CCOSR_CLKO1_DIV(2); CCM->CCOSR = (CCM->CCOSR & (~CCM_CCOSR_CLKO1_SEL_MASK)) | CCM_CCOSR_CLKO1_SEL(1); 4 We will get the clock as the below. Note: In principle, it is not recommended to output CLOCK in CCM_CLKO1, if necessary, Please connect an 8-10pf capacitor to GPIO_SD_B0_04, and connect a 22 ohm resistor in series to prevent interference.
查看全文
[中文翻译版] 见附件 原文链接: https://community.nxp.com/docs/DOC-340813
查看全文
Using a different Flash with the RT1050 In IAR/Keil environment , when you change to other flash(not default flash on EVK board), please refer to below AN to modify the code for it. https://www.nxp.com/docs/en/nxp/application-notes/AN12183.pdf
查看全文
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 anthony_huereca_0-1767760539733.png   anthony_huereca_1-1767760621035.png     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. 
查看全文
​​迁移重点​​: ​​检查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
查看全文
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. It's recommended to also go through the basic i.MX RT700 NPU Lab to learn more about eIQ enablement on RT700. The rest of this post will cover using vision models with camera+LCD on i.MX RT700.    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. anthony_huereca_0-1777502759149.png 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: anthony_huereca_0-1782156759078.png     anthony_huereca_0-1782154106527.png   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.  anthony_huereca_0-1782155634010.png   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.   
查看全文
RT600 ROM API example for w25q128fw support.
查看全文
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: anthony_huereca_6-1777522539156.png   The s_tensorArena buffer is declared in the eIQ MCUXpresso SDK projects in the model.cpp file anthony_huereca_11-1777523751769.png   Size of TensorArena for a model is based on the input, output, and scratch memory of the largest operator in the model: anthony_huereca_12-1777523941900.png     It is estimated during Neutron Conversion in the last Total Data field. However it’s always slightly smaller than actual amount required. anthony_huereca_3-1777522368724.png     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: anthony_huereca_4-1777522368767.png   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.  anthony_huereca_1-1777524241590.png     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. anthony_huereca_8-1777523112268.png 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.  anthony_huereca_0-1777524225514.png     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: anthony_huereca_9-1777523311282.png   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"))); anthony_huereca_5-1777522368775.png   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. 
查看全文
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. mayliu1_1-1760596577697.png 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.   mayliu1_2-1760596693245.png mayliu1_3-1760596700476.png 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. mayliu1_4-1760596785475.png   Modify Project Settings: Make two key configuration changes to ensure successful image generation. mayliu1_5-1760596800335.png mayliu1_6-1760596804637.png Generate Hex File: After configuration, build the project to generate a Hex file for use with SEC TOOL. mayliu1_7-1760596831665.png 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. mayliu1_8-1760596890883.png mayliu1_9-1760596894590.png Configure Flash Type and Test: Select the default external NOR Flash for MIMXRT685-AUD-EVK, apply settings, and run a test. mayliu1_10-1760596916554.png Build Image: Use the previously generated App image and click “Build Image.”  mayliu1_11-1760596979292.png  Program Image: Flash the image to the RT685 chip. mayliu1_12-1760596995145.png   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. mayliu1_13-1760597057591.png 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. mayliu1_14-1760597088841.png mayliu1_15-1760597093145.png Flash Program: Load the Hex file and flash it to the board.   mayliu1_16-1760597109388.png 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. mayliu1_0-1760597371876.png   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 is a guide line to run both the master core and slave core projects as XIP targets from one flash.
查看全文
This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.
查看全文
1. Abstract The GenAVB/TSN Stack FreeRTOS Evaluation User's Guide (version:8.0 Release) covers multiple hardware platforms, software configurations, and evaluation use cases. While comprehensive, the document can be challenging for first-time users to follow due to the large amount of information and the variety of supported scenarios. This article focuses on a specific use case from the User's Guide and provides a detailed, step-by-step walkthrough with screenshots, configuration examples, expected results, and troubleshooting tips. The goal is to help users better understand the setup process and successfully evaluate the GenAVB/TSN stack on NXP platforms. This article walks through Section 4.4, TSN Network Only with TSN Bridge and Standalone Endpoint i.MX RT1180, from the GenAVB/TSN Stack FreeRTOS Evaluation User's Guide. It explains the required hardware setup, firmware build and flashing procedure, board configuration, TSN configuration, execution steps, expected results, and basic troubleshooting tips. 2. Setup 2.1 Hardware Preparation Two i.MX RT1180 boards A PC with a serial terminal emulator. MobaXterm Portable is recommended. At least two USB cables and three Ethernet cables ShellyZhang_0-1783325043864.jpeg   2.2 Firmware Preparation 2.2.1 Setup IDE and SDK Refer to the NXP GenAVB/TSN MCUXpresso User's Guide to install the required software environment for the selected platform and project. A successful project build confirms that the build environment has been installed and configured correctly. VS Code and MCUXpresso for Visual Studio Code are recommended. 2.2.2 Build Image Note:  The specific operating procedures should still be based on GenAVB/TSN MCUXpresso User's Guide . The explanation below is intended only as a supplement to the original document. For GenAVB_TSN-rtos-apps version 8.0, the CM7 Kconfig file needs to be fixed manually before building the image. Kconfig file path: ShellyZhang_0-1783326438663.png   Add two lines like the following: ShellyZhang_2-1783325043922.png Set the Build Configurations of the CM33 project to release_no_enetc0, and then build the project. ShellyZhang_3-1783325043942.png Set the Build Configurations of the CM7 project to release_enetc0, and then build the project. ShellyZhang_4-1783325043961.png Note: If you are using MCUXpresso for VS Code, you may not be able to import both the CM33 and CM7 projects of the TSN application into the same workspace at the same time, like the following: ShellyZhang_5-1783325044093.png If this occurs, remove the existing project from the workspace before importing the project for the other core. This issue is expected to be fixed in a future release. ShellyZhang_6-1783325044123.png After both the CM33 and CM7 projects are built successfully, the generated .bin files and .elf files can be found in the corresponding output directories: ShellyZhang_7-1783325044157.png ShellyZhang_8-1783325044188.png   2.2.3 Flash Image Make sure the board's boot configuration switch is set to Serial Downloader mode. For SDP mode, SW5[1..4] should be set to 0001. Set jumper J1 to position 7–8 so that the evaluation board can be powered through the Debug USB port. Connect one USB cable between the PC and the USB_OTG1 port , which is used for firmware downloading. Connect another USB cable between the PC and the Debug USB port, which is used for power supply and serial communication. Then reset the board. Refer to Chapter 10, "Multi core (Cortex-M33 + Cortex-M7) images flashing" in the GenAVB/TSN MCUXpresso User's Guide. Flash the following generated binaries to the target device: genavb_tsn_rtos_apps\...\release_no_enetc0\evkmimxrt1180_tsn_app_cm33_cm33.bin genavb_tsn_rtos_apps\...\release_enetc0\evkmimxrt1180_tsn_app_cm7_cm7.bin 2.3 Check the Status of the Boards After the flashing operation is completed on both boards, restore the boot configuration switch on each board to Quad SPI mode. For QSPI mode, SW5[1..4] should be set to 0100. Then reset both boards. Remove the jumper on JP7 so that the debug port on each board can enumerate two serial ports. The CM33 and CM7 serial terminal interfaces are provided through the two serial ports enumerated by the debug port. After the boards restart, the red LED D7 should blink, indicating that the TSN application is running. Then, check the hardware connection: ShellyZhang_14-1783325045000.png   ShellyZhang_15-1783325045041.jpeg   2.4 TSN Configuration and Evaluation   i.MX RT1180 Controller i.MX RT1180 IO Device 1 Step 1. Configure the Controller Standalone TSN Endpoint and IO Device Standalone TSN Endpoint respectively. CM33 shell: Press INSERT key mkdir -p /m7/tsn_app write /m7/boot 1 write /m7/tsn_app/role 0 write /m7/tsn_app/mode 2 write /m7/tsn_app/port_id 1 write /m7/tsn_app/num_io_devices 1 write /m7/tsn_app/period_ns 250000 CM33 shell: Press INSERT key mkdir -p /m7/tsn_app write /m7/boot 1 write /m7/tsn_app/role 1 write /m7/tsn_app/mode 2 write /m7/tsn_app/port_id 1 write /m7/tsn_app/period_ns 250000   Step 2. Reset the boards Reset Reset Step 3. Set hardware address CM33 shell: mkdir -p port0 mkdir -p port1 mkdir -p port2 mkdir -p port3 mkdir -p port4 mkdir -p port5 write port0/hw_addr 54:27:8D:00:00:00 write port1/hw_addr 54:27:8D:00:00:01 write port2/hw_addr 54:27:8D:00:00:02 write port3/hw_addr 54:27:8D:00:00:03 write port4/hw_addr 54:27:8D:00:00:04 write port5/hw_addr 54:27:8D:00:00:05 CM33 shell: mkdir -p port0 mkdir -p port1 mkdir -p port2 mkdir -p port3 mkdir -p port4 mkdir -p port5 write port0/hw_addr 54:27:8D:00:01:00 write port1/hw_addr 54:27:8D:00:01:01 write port2/hw_addr 54:27:8D:00:01:02 write port3/hw_addr 54:27:8D:00:01:03 write port4/hw_addr 54:27:8D:00:01:04 write port5/hw_addr 54:27:8D:00:01:05 Step 4. Set gPTP / (Devices without this command configured remain GM devices.)   CM33 shell: mkdir -p fgptp write fgptp/priority1 248   Step 5. VLAN and FDB entry settings BRIDGE>> vlan_update 2 3 -c 1 -p BRIDGE>> vlan_update 2 4 -c 1 -p BRIDGE>> fdb_update 91:e0:f0:00:fe:70 2 4 -c 1 -p BRIDGE>> fdb_update 91:e0:f0:00:fe:71 2 3 -c 1 -p /   Step 6. Scheduled Traffic settings CM33 shell:   BRIDGE>> cd / BRIDGE>> qbv_set 4 -b 35000 -c 250000 -C 0 -l 08,80000 -l f7,170000 -p BRIDGE>> qbv_set 3 -b 160000 -c 250000 -C 0 -l 08,80000 -l f7,170000 -p   CM7 shell:   CONTROLLER>> qbv_set 1 -b 35000 -c 250000 -C 0 -l 02,80000 -l fd,170000 CM7 shell:   IO_DEVICE_0>> qbv_set 1 -b 160000 -c 250000 -C 0 -l 02,80000 -l fd,170000 Step 7. Reset the boards and evaluate Scheduled Traffic / ShellyZhang_16-1783325045104.png   Step 8. Configure Time-Specific Departure (TSD) CM33 shell: Press INSERT key   write /m7/tsn_app/tx_time_enabled 1 write /m7/tsn_app/tx_time_offset_ns 38000 CM33 shell: Press INSERT key   write /m7/tsn_app/tx_time_enabled 1 write /m7/tsn_app/tx_time_offset_ns 38000 Step 9. Reset the boards and evaluate Time-Specific Departure (TSD) / ShellyZhang_17-1783325045170.png   Note: All use cases require the hardware address and gPTP configurations. The original User's Guide does not fully describe this part, so these steps are explicitly included in this article for clarity. 3. Conclusion This guide summarizes the complete workflow for evaluating the GenAVB/TSN Stack FreeRTOS use case on the i.MX RT1180 platform. It covers the required hardware preparation, firmware build process, image flashing procedure, board boot configuration, serial port verification, and TSN configuration steps. By following the configuration sequence in this document, users can set up the Controller and IO Device roles, configure gPTP, VLAN, FDB entries, Scheduled Traffic, and Time-Specific Departure, and then verify the expected TSN behavior between the two i.MX RT1180 boards.
查看全文
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 anthony_huereca_0-1782845821454.png   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. anthony_huereca_1-1782845403033.png   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. anthony_huereca_2-1782845420922.png   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: anthony_huereca_3-1782845441830.png 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 Compiler 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 Compiler 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
查看全文
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.   
查看全文