飞思卡尔 iMX6 处理器 - Garz & Fricke SANTARO 10.4 盒装 PCT/电阻 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Garz & Fricke 产品 SANTARO 将在即将于纽伦堡举行的嵌入式世界展会期间在飞思卡尔展位上展出。 SANTARO 使用飞思卡尔 iMX6 处理器。单核、双核和四核。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Garz & Fricke 产品 SANTARO 将在即将于纽伦堡举行的嵌入式世界展会期间在飞思卡尔展位上展出。 SANTARO 使用飞思卡尔 iMX6 处理器。单核、双核和四核。

Garz & Fricke - 适用于 iMX 6 产品的 Bootloader Flash N Go <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

i.MX25 参考手册 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这是当前发布的 i.MX25 参考手册的副本，用于输入社区评论。请随意在此参考手册中添加内嵌注释。您可以指出哪里需要更多信息或者哪里现有信息不正确。您还可以根据您使用该设备的经验，在评论中输入扩展文档中现有信息的信息。如果您指出某个段落或章节需要更多信息，请具体说明，而不是“需要更多信息”。您在本手册中的评论可能会对其他成员有所帮助，并将推动本文档和未来文档的改进。 注意：文档查看器不支持直接转到指定页面。您无需手动逐页翻阅，而是可以搜索页面上的字符串（例如“重置类型”），或者转到内联注释中列出的章节链接。为此，请向下翻页到文档视图下方的注释，选择“内联注释”，按“页面”对注释进行排序，然后选择要查看的章节。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 这是当前发布的 i.MX25 参考手册的副本，用于输入社区评论。请随意在此参考手册中添加内嵌注释。您可以指出哪里需要更多信息或者哪里现有信息不正确。您还可以根据您使用该设备的经验，在评论中输入扩展文档中现有信息的信息。如果您指出某个段落或章节需要更多信息，请具体说明，而不是“需要更多信息”。您在本手册中的评论可能会对其他成员有所帮助，并将推动本文档和未来文档的改进。 注意：文档查看器不支持直接转到指定页面。您无需手动逐页翻阅，而是可以搜索页面上的字符串（例如“重置类型”），或者转到内联注释中列出的章节链接。为此，请向下翻页到文档视图下方的注释，选择“内联注释”，按“页面”对注释进行排序，然后选择要查看的章节。 回复：i.MX25参考手册 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 应该是 表 23-26 中的“写入水印级别的最大合法值为 128” 反而 msgstr "写入 水印 级别 的 最大 合法 值为 127 " . 突发长度字段（WR_BRST_LEN 和 RD_BRST_LEN）的默认/重置值为 0b00100 是正确的（而不是 0b01000）

i.MX27 ADS 添加 USB Host2 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在 i.MX27ADS 上添加对 USB 主机高速的支持 首先，确保已应用以下补丁： usbh2_cspi1_ss2.补丁 usbh2_set_ulpi_xcvr.补丁 取消选择SPI2： 设备驱动程序 ---> SPI支持---> [ ] CSPI2 选择 USB 主机 2： USB支持---> EHCI HCD（USB 2.0）支持 [*] 支持飞思卡尔控制器上的 Host2 端口 i.MX2x

Kinetis K53 Medical Teaching Lab from the University of Brasov The Technical University in Brasov (Romania) has set up a Medical Teaching lab featuring the Freescale Tower Kit K53 with Oximeter MED-SPO2 and 2 electrode system EKG MED-EKG. Find below the material associated to this lab led by Prof. Sorin-Aurel Moraru from the Faculty of Engineering. He can be contacted at [email protected] The course is in Romanian and include an overview of the hardware and exercises

IMX27 PDK NAND Flashing RedBoot Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs -e 0x20000 -s 0x800 –n -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: Format the flash redboot> fis init -f Make a Bad Block Table redboot> nand scan Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: redboot> load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x100000, for IMX27PDK) redboot> fis create -f 0x100000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: redboot> load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX27PDK) redboot> fis create -f 0x600000 root Testing This step can be omitted! You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -c "noinitrd console=ttymxc0,115200 root=nfs nfsroot= : ip=dhcp" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock4 /mnt ls /mnt List the /mnt contents. The output must be the right file system. For testing root file system on NAND, type exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp" Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable. i.MX2x

Adeneo Embeddedは、i.MX53上のLinuxとWEC7のベンチマーク比較をリリース <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 多くのお客様が特定のプラットフォームで次の製品のオペレーティングシステムを選択するのが難しいと感じているため、Adeneo Embeddedは、i.MX53プラットフォーム上のLinuxとWEC7の非常に詳細な比較をまとめました。この比較では、プラットフォームのセットアップ、最初のビルドの作成にかかる時間から、パフォーマンスと消費電力のベンチマークまで、すべてを文書化しています。以下は、ドキュメントの内容のスナップショットです。   完全なドキュメントにアクセスするには、Adeneo Embedded([email protected])にお問い合わせください 全般

Adeneo Embedded releases a benchmark comparison of Linux and WEC7 on i.MX53 As many customers find it difficult selecting an Operating system for their next product on a given platform Adeneo Embedded put together a very detailed comparison between Linux and WEC7 on the i.MX53 platform. This comparison documents everything from the time it takes to setup the platform, create the first builds to performance and power consumption benchmarks. Below is a snapshot of the contents of the document.   To get access to the complete document, please contact Adeneo Embedded at [email protected] General

P2010/P2020 计时常见问题解答 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> P2010/P2020 H/W 规格描述最大 SYSCLK 频率为 100MHz。一般情况下当用户输入100MHz时钟时，实际时钟速度会变得更快。我认为只要我使用高达 100MHz 的振荡器，P2010/P2020 就有足够的余量来实现更快的 SYSCLK。我的理解正确吗？ 是的，你的理解是正确的。只要您使用 100MHz 振荡器就没问题。 QorIQ P2设备

All Boards TFTP on Ubuntu For Debian and Based Systems Users: To install tftpboot service first install tftp server: $sudo apt-get install tftpd Choose an Internet super server to install Install xinetd OR inetd. Notice openbsd-inetd is alread installed on Ubuntu. INET Open a terminal as root If inetd is not installed, install it typing $sudo apt-get install openbsd-inetd create tftpboot folder and set permissions:    $sudo mkdir /tftpboot $sudo chmod a+x /tftpboot Edit tftp file    $sudo gedit /etc/inetd.conf Add this line: tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /tftpboot After restart the inetd server:    $ sudo /etc/init.d/openbsd-inetd restart XINET Open a terminal as root If xinetd is not installed, install it typing: $sudo apt-get install xinetd create tftpboot folder and set permissions: $sudo mkdir /tftpboot $sudo chmod a+x /tftpboot Edit file tftp:    $sudo gedit /etc/xinetd.d/tftp Add these lines    service tftp {   socket_type = dgram   protocol = udp   wait = yes   user = root   server = /usr/sbin/in.tftpd   server_args = /tftpboot   disable = no   per_source = 100 2   flags = IPv4 } After restart the inetd server: $ sudo /etc/init.d/xinetd restart

Q&A: Does VIN have to be valid before programming PMIC over i2c? Q: Does VIN have to be valid before we can talk to the PMIC over i2c? Can a valid voltage on LICELL and VDDIO work instead? The PF0100 datasheet says: ---------------------------------------------- To communicate with I2C, VIN must be valid and VDDIO, to which SDA and SCL are pulled up, must be powered by a 1.7 to 3.6V supply. VIN, or the coin cell voltage must be valid to maintain the contents of the registers. -------------------------------- A: VIN and VDDIO must be valid for communicating to the I2C block. Having LICELL and VDDIO will not work since a portion of the digital circuitry needed for accessing the registers is powered through VIN. This document was generated from the following discussion: Programming PMIC over i2c

Adeneo Embedded Sabre SDP Androidの専門知識 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Adeneo Embeddedの専門知識をご覧ください! 詳細については、当社のWebサイトをご覧ください (マイビデオで視聴)

Open-CMSIS-Packs 文档 Open-CMSIS-Pack 项目 这是 Open-CMSIS-Pack 项目网站的链接。该资源提供了 CMSIS-Packs 背后的所有技术细节。 使用 Open-CMSIS-Packs 这是 VS Code 的 MCUXpresso 文档链接，向用户展示如何开始使用 Open-CMSIS-Packs。 打开 CMSIS 包

Resources for Zephyr’s Build and Configuration System Zephyr Project Build and Configuration System Devicetree Zephyr Project Devicetree Webinar: Application Portability Made Easy With Zephyr OS and NXP VS Code Lab Guide: Devicetree and Devicetree Viewer Golioth blog: Zephyr for Hardware Engineers: GPIO Zephyr Project Devicetree HOWTOs Kconfig Zephyr Project Kconfig Webinar: Application Portability Made Easy With Zephyr OS and NXP VS Code Lab Guide: Kconfig and compiler optimizations Return to Zephyr Knowledge Hub

HOWTO: Program Serial RCON using S32 Debug Probe This document details the steps to program external EEPROM with the 32 reset configuration bits in support of the 'Boot from serial RCON' method detailed in the device reference manual. The Python scripts used for this task are designed and tested to work on the EVBs, where EEPROM hardware is connected via I2C.(Serial EEPROM is not implemented on all boards). The RCON can be set by the following:  Fuses (internal to the device)  Parallel (GPIO pins/DIP Switches on EVB)  Serial (EEPROM connected via I2C)  The Serial option can be programmed using a debug probe connected via JTAG. This enables the RCON to be controlled remotely, assuming the debug probe is setup to allow remote connections.  The images shown throughout this document are of the S32G274A device implementation and are provided for illustration purposes.               Preparation  Install S32 Design Studio IDE  Use the S32DS Extensions and Updates menu to install the Development Package for the device subject to debugging. This is important as the Development Packages add the S32 Debugger support which provides access to the EEPROM programming capabilities via I2C of the S32 Debug Probe.  Connect the S32 Debug Probe to the EVB and the host PC containing S32 Design Studio installation.  Set BOOTMOD pins to boot from RCON  Set BOOT_CFG[8]=1 on the EVB, for serial RCON mode Procedure    Depending on the way the device used and how the {device name}_i2c_RCON.py is edited, user must use the old procedure on the new one. Both detailed below. To choose between the Old procedure and the new procedure, you must check in the {device_name}_i2c_RCON.py if variables like “INTERACTIVE_MODE” and “RCON_DATA” exist. The {device_name}_i2c_RCON.py can be found in: {INSTALL_DIR}…S32DS/tools/S32Debugger/Debugger/scripts/{device_name}/ {device_name_part_name}_i2c_RCON.py If the variables exist, please use the old procedure. If the variables were removed, please use the new procedure. I.  Old procedure ( If “INTERACTIVE_MODE” variable still exists)   Open cmd window to the S32 Debugger folder where the device-specific scripts are located. ../S32Debugger/Debugger/Scripts/{device_name/part_number} Set Python path so correct version is used (if not already set in env vars)   set PYTHONPATH=C:\NXP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7;C:\N XP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Edit the python script to adjust the value to be programmed to RCON, {device_name}_i2c_RCON.py. Note: The listed examples show only the minimum values required to configure each of the external memory types. Additional settings may be required for your specific application. Adjust RCON_DATA for the configuration you wish to program. Do not adjust RCON_ADDR. Adjust S32DBG_IP for the IP address of your S32 Debug Probe. Adjust INTERACTIVE_MODE i. Set True, if desired to be prompted in the command window to enter RCON_DATA      ii. Set False, if desried to have script automatically enter RCON_DATA, based on the value set     within the file. Adjust _SOC_NAME as appropriate for the specific device you are using. The valid options are defined in {device_name}_context.py Enter the command to start GDB, passing in the RCON Python script: Windows OS: ../ S32DS\tools\gdb-arm\arm32-eabi\bin/arm-none-eabi-gdb-py.exe -x {device_name}_i2c_RCON.py OR ../ S32DS\tools\gdb-arm\arm64-eabi\bin/arm-none-eabi-gdb-py.exe -x {device_name}_i2c_RCON.py Linux OS: arm-none-eabi-gdb-py -x {device_name}_i2c_RCON.py If everything worked properly, then the value you programmed will be displated to the screen. To exit GDB, enter ‘quit’. II.  New Procedure ( If “INTERACTIVE_MODE” variable was deleted) Set Python path so correct version is used (if not already set in env vars)  set PYTHONPATH=C:\NXP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7;C:\N XP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages  Start GDB Server. (…\S32Debugger\Debugger\Server\gta\gta.exe) Start Command Prompt and enter the command to start GDB with python: Example:   C:\NXP\S32DS.3.5_230912_devpck\S32DS\tools\gdb-arm\arm32eabi\bin\arm-none-eabi-gdb-py.exe Linux OS: arm-none-eabi-gdb-py   In s32rcon.py ( C:\NXP\S32DS.3.5_230912_devpck\S32DS\tools\S32Debugger\Deb ugger\scripts\gdb_extensions\rcon\s32rcon.py😞 Edit connection parameters (Probe IP, GDB server port, JTAG speed, etc.) Edit _RCON_SCRIPT parameter with absolute path to the desired I2C RCON script for the desired board: Example: _RCON_SCRIPT = " C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Deb ugger/scripts/s32g2xx/ s32g274a_i2c_RCON.py"      c. Source s32rcon.py in GDB. Example: source C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Deb ugger/scripts/gdb_extensions/rcon/s32rcon.py     d. Run command py rcon() in GDB. OBS:  Steps a, b can be done after c directly from GDB, using GDB py commands: Examples:  py _GDB_SERVER_PORT=45000  py _RCON_SCRIPT="C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Debu gger/scripts/s32g2xx/ s32g274a_i2c_RCON.py" User can now use the available commands, like rcon_help, rcon_read, rcon_write to interact with the EEPROM. User can write [command] -h for more information and mandatory parameters of the command. User can write ‘quit’ to exit the S32 RCON services.

Introduction to RW61x and FRDM-RW612 Step by Step video: (view in My Videos) FRDM-RW612 FRDM-Training Wireless

RW61xおよびFRDM-RW612の紹介 ステップバイステップのビデオ: (マイビデオで視聴) FRDM-RW612 FRDMトレーニング ワイヤレス

[RT1170]How to debug a dual core project within SDRAM     Compared with the RT10xx series, the i.MX RT117x has an additional M4 core, which makes multi-core collaboration possible. The general practice of multi-core operation is to run in independent program data space and communicate through a shared memory space. For example, in the official SDK routine, the M7 code runs in Flash, while the M4 code runs in SRAM, and they communicate from each other via a shared SRAM space, which can ensure the maximum performance. However, during the development stage, customers may need to put both the M7 and M4 codes in external SDRAM for debugging. Although this will affect some performance, it will not perform too many erase and write operations on the flash, which also has certain practical significance.     The following is a detailed explanation of how to load a dual core project to SDRAM for debugging. The following example comes from the official SDK dual core demo -  rpmsg_lite_pingpong .     Because the default system boots from the M7 core, the usual practice is to load the M4 code by the M7, and then kick off the M4 core by M7 as well. Therefore, most of the changes are in the M7 project settings. The specific steps are as follows: M7 project settings: Add two memory space definitions, BOARD_SDRAM and SDRAM. BOARD_SDRAM section is used for M7 to store the data, while SDRAM section is used for M4's code. It should be noted that the location of BOARD_SDRAM should be next to BOARD_FLASH where is the default data section of the project.  Add macro definition to enable SDRAM initialization code  Select the following option to move the application code originally placed in BOARD_FLASH into BOARD_SDRAM.  In the multi-core setup, set the M4 code location to the SDRAM space defined previously.   Replace the startup script in the debugger configuration with the version with SDRAM initialization support.   And add the following debug option:   --cachelib libm7_cache.so   Finally, update the M4 core startup address in the M7 code to the starting address of the SDRAM section defined previously:  The changes to the M4 project are much simpler.  Add SDRAM memory space definition. The starting address and size should be consistent with the SDRAM space definition in the M7 project.   With the above steps, you can debug the code of M7 and M4 in SDRAM at the same time!   Compared with the RT10xx series, the i.MX RT117x has an additional M4 core, which makes multi-core collaboration possible. The general practice of multi-core operation is to run in independent program data space and communicate through a shared memory space. For example, in the official SDK routine, the M7 code runs in Flash, while the M4 code runs in SRAM, and they communicate from each other via a shared SRAM space, which can ensure the maximum performance. However, during the development stage, customers may need to put both the M7 and M4 codes in external SDRAM for debugging. Although this will affect some performance, it will not perform too many erase and write operations on the flash, which also has certain practical significance.

MCUXpresso for VS Code: Importing Projects from the MCUXpresso SDK MCUXpresso SDK The MCUXpresso SDK has been reengineered to make use of CMake and Kconfig. This article will demonstrate how to use the SDK in VS Code. *Note: The SDK has switched to CalVer versioning convention. *Note: The SDK will contain previews of possible changes for a later release. The previews are available for early evaluation but are not intended to substitute a release. Importing the SDK Navigate to the QUICKSTART PANEL in the MCUXpresso for VS Code extension. Click on Import Repository. Select the REMOTE option if you have not yet obtained the SDK. Designate a destination to save locally in the Location field. Select the latest release of the MCUXpresso SDK in the Repository field. The latest version for this walkthrough is MCUXpresso SDK - 24.12.00. Select the main revision in the Revision field.  Note: The SDK can be cloned directly from GitHub. Select the Local option to import if you've already obtained the SDK. Importing an example project The process of importing a project into MCUXpresso for VS Code does not vary from previous versions. To do so, simply use the Import Example from Repository option. Exploring the CMake format You will notice several folders when navigating the SDK directory. To examine the CMake project format, let's take a look at the led_blinky_peripheral project. This project is found in examples/demo_apps/led_blinky_peripheral. In this directory, you will find generic project files including the CMakeLists file. For example, the file that holds the main function in this example project can reference different board files and their respective peripherals. The files are generic to allow reusability and support for many other devices. This reduces the overall size of the SDK. The CMakeLists file is used to specify the device and project options for the build. In another article, we will cover how the variables in the CMakeLists files are referenced when a build for a specific device is initiated. For now, let's take a look at structure of the file. You'll notice that the variables in this file are generic and will be referenced later for the build. For example, the following two variables are needed for the build system to know which board to build for and where to reference the files. SdkRootDirPath - This specifies the root path to the SDK. board - This specifies the board name. Once the build is initiated all the necessary files will be drawn in to the project. MCUXpresso for VS Code

How to load MDK RAM app to the RT1170 external flash How to load MDK RAM app to the RT1170 external flash 1. Abstract This guide is requested by our end customer, he wants to realize the MDK project RAM code download to the MIMXRT1170 external QSPI flash. So, based on the NXP RT1170 SDK, and the MIMXRT1170-EVK board, generate the MDK project, reallocate the app image, generate the image, and use the tool to download the code to the external flash. 2. App image prepare 2.1 Generate one SDK MDK standalone project Open the SDK_2_15_000_MIMXRT1170-EVK webpage: https://mcuxpresso.nxp.com/en/builder?hw=MIMXRT1170-EVK Download the SDK, and generate one MDK standalone project: Fig 1 Fig 2 After downloading, we will get the MIMXRT1170-EVK-iled_blinky_cm7.zip, which is the MDK project. 2.2 MDK project image reallocation As the RAM image is the none-xip image, normally to the IDE, can’t download to the flash directly, as the debug is in the RAM. If want to download to the flash, we can generate the app image, then use the tool to program it to the external flash. Normally, none-xip image, the IVT offset is 0X400, so we need to reallocate the image start address, here, we can use 0X2000 as the app entry address. Fig 3 ITCM default size is 256K=0X4000, so modify the linker file-> scf file like this: Fig 4 Now, to generate the hex and bin image file, which is used for the tool downloading. Fig 5 To build the bin file command: $K\ARM\ARMCC\bin\fromelf.exe --bin --output=debug\@L.bin !L Fig 6   Building, you can find the file in the folder: MIMXRT1170-EVK-iled_blinky_cm7\iled_blinky_cm7\debug Fig 7 2.3 MDK project debug after reallocation After the image reallocation, some customer may still need the MDK RAM project can do the debugging, here, also need to modify the debug .ini file. The Setup also need to change the SP, PC and Vector table offset register address. Fig 8 Then build and debug the code, we can find it can enter the ram image debug mode: Fig 9 3. App image download We can use the MCUBootUtility Tool to download the code: https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v6.1.0 the related user manual is: https://github.com/JayHeng/NXP-MCUBootUtility Download the tool. MIMXRT1170-EVK enter the serial download mode by changing SW1: 1-OFF,2-OFF,3-OFF,4-ON Power off and power on the board again, find another USB cable to connect the J20 USB1 interface. Then, use the MCUBootutility to connect the board: Fig 10 After connection, select the MDK project generated .hex file: Fig 11 Press the All-in-One-Action button, to download the code, this is the downloaded result: Fig 12 Press the “Reset device” button to exit the tool. Then MIMXRT1170-EVK board change SW1: 1-OFF, 2-OFF, 3-ON,4-OFF Press the EVK on board reset button, SW4, you will find the LED is blinking, it means the MDK RAM project already download to the external QSPI flash, and boot OK.