This document describes the different source clocks and the main modules that manage which clock source is used to derive the system clocks that exists on the i.MX RT’s devices. It’s important to know the different clock sources available on our devices, modifying the default clock configuration may have different purposes since increasing the processor performance, achieving specific baud rates for serial communications, power saving, or simply getting a known base reference for a clock timer. The hardware used for this document is the following: i.MX RT: EVK-MIMXRT1060 Keep in mind that the described hardware and management clock modules in this document are a general overview of the different platforms and the devices listed above are used as a reference example, some terms and hardware modules functionality may vary between devices of the same platform. For more detailed information about the device hardware modules, please refer to your specific device Reference Manual. RT platforms The Clock Controller Module(CCM) facilitates the clock generation in the RT platforms, many clocking variations are possible and the maximum clock frequency for the i.MX RT1060 device is @600MHz.The following image shows a block diagram of the CCM, the three marked sub-modules are important to understand all the clock path from the clock generation(oscillators or crystals) to the clock management for all the peripherals of the board.    Figure 1. Clock Controller Module(CCM) Block Diagram        CCM Analog Submodule This submodule contains all the oscillators and several PLL’s that provide a clock source to the principal CMM module. For example, the i.MX RT1060 device supports 2 internal oscillators that combined with suitable external quartz crystal and external load capacitors provide an accurate clock source, another 2 internal oscillators are available for low power modes and as a backup when the system detects a loss of clock. These oscillators provide a fixed frequency for the several PLL’s inside this module. Internal Clock Sources with external components  Crystal Oscillator @24MHz Many of the serial IO modules depend on the fixed frequency of 24 MHz. The reference clock that generates this crystal oscillator provides an accurate clock source for all the PLL inputs.  Crystal Oscillator @32KHz Generally, RTC oscillators are either implemented with 32 kHz or 32.768 kHz crystals. This Oscillator should always be active when the chip is powered on. Internal Clock sources RC Oscillator @24MHz A lower-power RC oscillator module is available on-chip as a possible alternative to the 24 MHz crystal oscillator after a successful power-up sequence. The 24 MHz RC oscillator is a self-tuning circuit that will output the programmed frequency value by using the RTC clock as its reference. While the power consumption of this RC oscillator is much lower than the 24MHz crystal oscillator, one limitation of this RC oscillator module is that its clock frequency is not as accurate. Oscillator @32KHz The internal oscillator is automatically multiplexed in the clocking system when the system detects a loss of clock. The internal oscillator will provide clocks to the same on-chip modules as the external 32kHz oscillator. Also is used to be useful for quicker startup times and tampering prevention. Note. An external 32KHz clock source must be used since the internal oscillator is not precise enough for long term timekeeping. PLLs There are 7 PLLs in the i.MXRT1060 platform, some with specific functions, for example, create a reference clock for the ARM Core, USB peripherals, etc. Below these PLLs are listed. PLL1 - ARM PLL (functional frequency @600 MHz) PLL2 - System PLL (functional frequency @528 MHz)* PLL3 - USB1 PLL (functional frequency @480 MHz)* PLL4 - Audio PLL PLL5 - Video PLL PLL6 - ENET PLL PLL7 - USB2 PLL (functional frequency @480 MHz) * Two of these PLLs are each equipped with four Phase Fractional Dividers (PFDs) in order to generate additional frequencies for many clock roots.  Each PLLs configuration and control functions like Bypass, Output Enable/Disable, and Power Down modes are accessible individually through its PFDs and global configuration and status registers found at the CCM internal memory registers.        Clock Control Module(CCM) The Clock Control Module (CCM) generates and controls clocks to the various modules in the design and manages low power modes. This module uses the available clock sources(PLL reference clocks and PFDs) to generate the clock roots. There are two important sub-blocks inside the CCM listed below. Clock Switcher This sub-block provides the registers that control which PLLs and PFDs outputs are selected as the reference clock for the Clock Root Generator.  Clock Root Generator This sub-block provides the registers that control most of the secondary clock source programming, including both the primary clock source selection and the clock dividers. The clock roots are each individual clocks to the core, system buses, and all other SoC peripherals, among those, are serial clocks, baud clocks, and special function blocks. All of these clock references are delivered to the Low Power Clock Gating unit(LPCG).        Low Power Clock Gating unit(LPCG) The LPCG block receives the root clocks from CCM and splits them to clock branches for each peripheral. The clock branches are individually gated clocks. The following image shows a detailed block diagram of the CMM with the previously described submodules and how they link together. Figure 2. Clock Management System Example: Configure The ARM Core Clock (PLL1) to a different frequency. The Clock tools available in MCUXpresso IDE, allows you to understand and configure the clock source for the peripherals in the platform. The following diagram shows the default PLL1 mode configured @600MHz, the yellow path shows all the internal modules involved in the clock configuration.  Figure 3. Default PLL configuration after reset. From the previous image notice that PLL1 is attached from the 24MHz oscillator, then the PLL1 is configured with a pre-scaler of 50 to achieve a frequency @1.2GHz, finally, a frequency divider by 2 let a final frequency @600MHz. 1.1 Modify the PLL1 frequency For example, you can use the Clock tools to configure the PLL pre-scaler to 30, select the PLL1 block and then edit the pre-scaler value, therefore, the final clock frequency is @360MHz, these modifications are shown in the following figure.  Figure 4. PLL1 @720MHz, final frequency @360MHz    1.2 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. This will include the clock source for specific peripherals. In the previous example, we configured the PLL1 (ARM PLL) to a functional frequency @360MHz; this is translated to the following structure in source code: “armPllConfig_BOARD_BootClockRUN” and it’s used by “CLOCK_InitArmPll();” inside the “BOARD_BootClockPLL150MRUN();” function.     Figure 5. PLL1 configuration struct  Figure 6. PLL configuration function Example: The next steps describe how to select a clock source for a specific peripheral. 1.1 Configure clock for specific peripheral For example, using the GPT(General Purpose Timer) the available clock sources are the following: Clock Source Off Peripheral Clock High-Frequency Reference Clock Clock Source from an external pin Low-Frequency Reference Clock Crystal Oscillator Figure 7. General Purpose Timer Clocks Diagram Using the available SDK example project “evkmimxrt1060_gpt_timer” a configuration struct for the peripheral “gptConfig” is called from the main initialization function inside the gpt_timer.c source file, the default configuration function with the configuration struct as a parameter, is shown in the following figure. Figure 8. Function that returns a GPT default configuration parameters The function loads several parameters to the configuration struct(gptConfig), one of the fields is the Clock Source configuration, modifying this field will let us select an appropriate clock source for our application, the following figure shows the default configuration parameters inside the “GPT_GetDefaultConfig();” function.  Figure 9. Configuration struct In the default GPT configuration struct, the Peripheral Clock(kGPT_CLockSource_Periph) is selected, the SDK comes with several macros located at “fsl_gpt.h” header file, that helps to select an appropriate clock source. The next figure shows an enumerated type of data that contains the possible clock sources for the GPT.  Figure 10. Available clock sources of the GPT. For example, to select the Low-Frequency Reference Clock the source code looks like the following figure.  Figure 11. Low-Frequency Reference Clock attached to GPT Notice that all the peripherals come with a specific configuration struct and from that struct fields the default clocking parameters can be modified to fit with our timing requirements. 1.2 Modify the Peripheral Clock frequency from Clock Tools One of the GPT clock sources is the “Peripheral Clock Source” this clock line can be modified from the Clock Tools, the following figure shows the default frequency configuration from Clock Tools view. Figure 12. GPT Clock Root inside CMM In the previous figure, the GPT clock line is @75MHz, notice that this is sourced from the primary peripheral clock line that is @600MHz attached to the ARM core clocks. For example, modify the PERCLK_PODF divider selecting it and changing the divider value to 4, the resulting frequency is @37.5Mhz, the following figure illustrates these changes.  Figure 13. GPT & PIT clock line @37.5MHz 1.3 Export clock configuration to the project After you complete the clock configuration, the Clock Tool will update the source code in clock_config.c and clock_config.h, including all the clock functional groups that we created with the tool. This will include the clock source for specific peripherals. In the previous example, we configured the GPT clock root divider by a dividing factor of 4 to achieve a 37.5MHz frequency; this is translated to the following instruction in source code: “CLOCK_SetDiv(kCLOCK_PerclkDiv,3);” inside the “BOARD_BootClockRUN();” function.                Figure 14. Frequency divider function References i.MX RT1060 Processor Reference Manual Also visit LPC's System Clocks  Kinetis System Clocks

This is the recording of the Crossover Code challenge Webinar presented on December 10.

The i.MX RT600 crossover MCU combines an ultra-low power MCU with a high performance DSP to enable the next generation of ML/AI, voice and audio applications. Get started today and order your MIMXRT685-EVK.

Get 500 MHz for just $1 with NXP's new i.MX RT1010 crossover MCU.  Targeted for a variety of applications, this video highlights two very popular example use-cases for i.MX RT1010 -audio and motor control.

The newly announced i.MX RT1170 is a dual-core Arm® Cortex®-M based crossover MCU that breaks the gigahertz (GHz) barrier and accelerates advanced Machine Learning (ML) applications at the edge.  Built using advanced 28nm FD-SOI technology for lower active and static power requirements, i.MX RT1170 MCU family integrates a GHz Arm Cortex-M7 and power-efficient Cortex-M4, advanced 2D vector graphics, together with NXP’s signature EdgeLock security solution.  The i.MX RT1170 delivers a total CoreMark score of 6468 and address the growing performance needs of edge computing for industrial, Internet-of-Things (IoT) and automotive applications

RT1050 SDRAM app code boot from SDcard burn with 3 tools Abstract       This document is about the RT series app running on the external SDRAM, but boot from SD card. The content contains SDRAM app code generate with the RT1050 SDK MCUXpresso IDE project, burn the code to the external SD card with flashloader MFG tool, and MCUXPresso Secure Provisioning. The MCUBootUtility method can be found from this post: https://community.nxp.com/docs/DOC-346194       Software and Hardware platform： SDK 2.7.0_EVKB-IMXRT1050 MCUXpresso IDE MXRT1050_GA MCUBootUtility MCUXPresso Secure Provisioning MIMXRT1050-EVKB 2 RT1050 SDRAM app image generation     Porting SDK_2.7.0_EVKB-IMXRT1050 iled_blinky project to the MCUXPresso IDE, to generate the code which is located in SDRAM, the configuration is modified like the following items:       2.1 Copy code to RAM 2.2  Modify memory location to SDRAM address 0X80002000 The code which boots from SD card and running in the SDRAM is the non-xip code, so the IVT offset is 0X400, in our test, we put the image from the SDRAM memory address 0x800002000, the configuration is: 2.3 Modify the symbol 2.4 Generate the .s19 file      After build has no problems, then generate the app.s19 file:   Rename the app.19 image file to evkbimxrt1050_iled_blinky_sdram_0x2000.s19, and copy it to the flashloader folder: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win   3, Flashloader configuration and download    This chapter will use flashloader to configure the image which can download the SDRAM app code to the external SD card with MFGTool.       We need to prepare the following files: SDRAM interface configuration file CFG_DCD.bin imx-sdram-unsigned-dcd.bd program_sdcard_image.bd 3.1 SDRAM DCD file preparation      MIMXRT1050-EVKB on board SDRAM is IS42S16160J, we can use the attached dcd_model\ISSI_IS42S16160J\dcd.cfg and dcdgen.exe tool to generate the CFG_DCD.bin, the commander is: dcdgen -inputfile=dcd.cfg -bout -cout   Copy CFG_DCD.bin file to the flashloader path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win 3.2 imx-sdram-unsigned-dcd.bd file Prepare the imx-sdram-unsigned-dcd.bd file content as: options {     flags = 0x00;     startAddress = 0x80000000;     ivtOffset = 0x400;     initialLoadSize = 0x2000;     DCDFilePath = "CFG_DCD.bin";     # Note: This is required if the default entrypoint is not the Reset_Handler     #       Please set the entryPointAddress to Reset_Handler address     entryPointAddress = 0x800022f1; }   sources {     elfFile = extern(0); }   section (0) { }  The above entrypointAddress data is from the .s19 reset handler(0X80002000+4 address data): Copy imx-sdram-unsigned-dcd.bd file to flashloader path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Open cmd, run the following command: elftosb.exe -f imx -V -c imx-sdram-unsigned-dcd.bd -o ivt_evkbimxrt1050_iled_blinky_sdram_0x2000.bin evkbimxrt1050_iled_blinky_sdram_0x2000.s19 After running the command, two app IVT files will be generated: 3.3 program_sdcard_image.bd file Prepare the program_sdcard_image.bd file content as: # The source block assign file name to identifiers sources {  myBootImageFile = extern (0); }   # The section block specifies the sequence of boot commands to be written to the SB file section (0) {       #1. Prepare SDCard option block     load 0xd0000000 > 0x100;     load 0x00000000 > 0x104;       #2. Configure SDCard     enable sdcard 0x100;       #3. Erase blocks as needed.     erase sdcard 0x400..0x14000;       #4. Program SDCard Image     load sdcard myBootImageFile > 0x400;         #5. Program Efuse for optimal read performance (optional)     # Note: It is just a template, please program the actual Fuse required in the application     # and remove the # to enable the command     #load fuse 0x00000000 > 0x07;   } Copy program_sdcard_image.bd to the flashloader path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Open cmd, run the following command: elftosb.exe -f kinetis -V -c program_sdcard_image.bd -o boot_image.sb ivt_evkbimxrt1050_iled_blinky_sdram_0x2000_nopadding.bin Copy the generated boot_image.sb file to the following flashloader path: \Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\mfgtools-rel\Profiles\MXRT105X\OS Firmware 3.4 MFGTool burn code to SD card    Prepare one SD card, insert it to J20, let the board enter the serial download mode, SW7:1-ON 2-OFF 3-OFF 4-ON. Find two USB cable, one is connected to J28, another is connected to J9, we use the HID to download the image.    Open MFGTool.exe, and click the start button:          Modify the boot mode to internal boot, and boot from the external SD card, SW7:1-ON 2-OFF 3-ON 4-OFF.      Power off and power on the board again, you will find the onboard LED D18 is blinking, it means the external SDRAM APP code is boot from external SD card successfully. 4, MCUBootUtility configuration and code download    Please check this community document: https://community.nxp.com/docs/DOC-346194     Here just give one image readout memory map, it will be useful to understand the image location information:     After download, we can readout the SD card image, from 0X400 is the IVT, BD, DCD data, from 0X1000 is the image which is the same as the app.s19 file.     5, MCUXpresso Secure Provisioning configuration and download   This software is released in the NXP official website, it is also the GUI version, which can realize the normal code and the secure code downloading, it will be more easy to use than the flashloader tool, customer don’t need to input the command, the tool help the customer to do it, the function is similar to the MCUBootUtility, MCUBootUtility tool is the opensource tool which is shared in the github, but is not released in the NXP official website.   Now, we use the new official realized tool to download the SDRAM app code to the external SD card, the board still need to enter the serial download mode, just like the flashloader and the MCUBootUtility too, the detail operation is:  We can find this tool is also very easy to use, customer still need to provide the app.19 and the dcd.bin, then give the related boot device configuration is OK.    After the code is downloaded successfully, modify the boot mode to internal boot, and boot from the external SD card, SW7:1-ON 2-OFF 3-ON 4-OFF.     Power off and power on the board again, you will find the onboard LED D18 is blinking, it means the external SDRAM APP code is boot from external SD card successfully.   Until now, all the three methods to download the SDRAM app code to the SD card is working, flashloader is the command based tool, MCUBootUtility and MCUXPresso Secure Provisioning is the GUI tool, which is more easy to use.        

View Webinar Recording

Introduction The RT1064 is the only Crossover MCU from the RT family that comes with an on-chip flash, it has a 4MB Winbond W25Q32JV memory. It's important to remark that it's not an internal memory but an on-chip flash connected to the RT1064 through the FlexSPI2 interface. Having this flash eliminates the need of an external memory. Although the intended use of the on-chip flash is to store your application and do XiP, there might be cases where you would like to use some space of this memory as NVM. This document will explain how to modify one of the SDK example projects to achieve this.  Prerequisites RT1064-EVK  The latest SDK which you can download from the following link: Welcome | MCUXpresso SDK Builder. In this document, I will use MCUXpresso IDE but you can use the IDE of your preference. The modifications that you need to make are the same despite the IDE that you are using.  Importing the SDK example  The RT1064-EVK comes with two external flash memories, 512 Mb Hyper Flash and 64 Mb QSPI Flash. The RT1064-SDK includes two example projects that demonstrate how to use any of these two external flash memories as NVM. In this document, we will take as a base one of these examples to modify it to use the on-chip flash as NVM. Once you downloaded and imported the SDK into MCUXpresso IDE, you will need to import the example flexspi_nor_polling_transfer into your workspace.    Modifying the SDK example The external NOR Flash memory of the EVK is connected to the RT1064 through the FlexSPI1 interface. Due to this, the example project that we just imported initializes the FlexSPI1 interface pins. In our case, we want to use the on-chip flash that is connected through the FlexSPI2 instance, since we will boot from this memory, the ROM bootloader will configure the pins of this FlexSPI interface. So, in the function BOARD_InitPins we can delete all the pins that were related to the FlexSPI1 interface. At the end your function should look like the following:  void BOARD_InitPins(void) { CLOCK_EnableClock(kCLOCK_Iomuxc); /* iomuxc clock (iomuxc_clk_enable): 0x03u */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B0_12_LPUART1_TX, /* GPIO_AD_B0_12 is configured as LPUART1_TX */ 0U); /* Software Input On Field: Input Path is determined by functionality */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B0_13_LPUART1_RX, /* GPIO_AD_B0_13 is configured as LPUART1_RX */ 0U); /* Software Input On Field: Input Path is determined by functionality */ /* Software Input On Field: Force input path of pad GPIO_SD_B1_11 */ IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B0_12_LPUART1_TX, /* GPIO_AD_B0_12 PAD functional properties : */ 0x10B0u); /* Slew Rate Field: Slow Slew Rate Drive Strength Field: R0/6 Speed Field: medium(100MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B0_13_LPUART1_RX, /* GPIO_AD_B0_13 PAD functional properties : */ 0x10B0u); /* Slew Rate Field: Slow Slew Rate Drive Strength Field: R0/6 Speed Field: medium(100MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Function flexspi_nor_flash_init initializes the FlexSPI interface but in our case, the ROM bootloader already did this for us. So we need to make some modifications to this function as well. The only things that we will need from this function are to update the LUT and to do a software reset of the FlexSPI2 interface. At the end your function should look like the following:  void flexspi_nor_flash_init(FLEXSPI_Type *base) { /* Update LUT table. */ FLEXSPI_UpdateLUT(base, 0, customLUT, CUSTOM_LUT_LENGTH); /* Do software reset. */ FLEXSPI_SoftwareReset(base); } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Inside the file app.h, we need to change some macros since now we will use a different memory and a different FlexSPI interface. The following macros are the ones that you need to modify:  Macro Before After Observations EXAMPLE_FLEXPI FLEXSPI FLEXSPI2 On-chip flash is connected through FlexSPI2 interface  FLASH_SIZE 0x2000 0x200 The size of the on-chip flash is different from the external NOR flash  EXAMPLE_FLEXSPI_AMBA_BASE FlexSPI_AMBA_BASE FlexSPI2_AMBA_BASE On-chip flash is connected through FlexSPI2 interface  EXAMPLE_SECTOR 4 100 The size of the on-chip flash is less than the external NOR flash, hence we will decrease the sector size to avoid erasing our application  Everything else in this file remains the same.  Finally, there are two changes that we need to make in the customLUT. To understand these changes you need to analyze the datasheets of the memories. But in the end, the two modifications are the followings:  Erase sector command of the on-chip flash is 0x20 instead of 0xD7.  Exchange the FLEXSPI command index for NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD and NOR_CMD_LUT_SEQ_IDX_READ_NORMAL to align with XIP settings. At the end your customLUT should look like the following:  const uint32_t customLUT[CUSTOM_LUT_LENGTH] = { /* Fast read quad mode - SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x6B, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST_QUAD + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_SDR, kFLEXSPI_4PAD, 0x08, kFLEXSPI_Command_READ_SDR, kFLEXSPI_4PAD, 0x04), /* Fast read mode - SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x0B, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_READ_FAST + 1] = FLEXSPI_LUT_SEQ( kFLEXSPI_Command_DUMMY_SDR, kFLEXSPI_1PAD, 0x08, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Normal read mode -SDR */ [4 * NOR_CMD_LUT_SEQ_IDX_READ_NORMAL] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x03, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_READ_NORMAL + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Read extend parameters */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUS] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x81, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Write Enable */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x06, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Erase Sector */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x20, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), /* Page Program - single mode */ [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_SINGLE] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x02, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_SINGLE + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Page Program - quad mode */ [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_QUAD] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x32, kFLEXSPI_Command_RADDR_SDR, kFLEXSPI_1PAD, 0x18), [4 * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM_QUAD + 1] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_4PAD, 0x04, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Read ID */ [4 * NOR_CMD_LUT_SEQ_IDX_READID] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x9F, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Enable Quad mode */ [4 * NOR_CMD_LUT_SEQ_IDX_WRITESTATUSREG] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x01, kFLEXSPI_Command_WRITE_SDR, kFLEXSPI_1PAD, 0x04), /* Enter QPI mode */ [4 * NOR_CMD_LUT_SEQ_IDX_ENTERQPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x35, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Exit QPI mode */ [4 * NOR_CMD_LUT_SEQ_IDX_EXITQPI] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_4PAD, 0xF5, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), /* Read status register */ [4 * NOR_CMD_LUT_SEQ_IDX_READSTATUSREG] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0x05, kFLEXSPI_Command_READ_SDR, kFLEXSPI_1PAD, 0x04), /* Erase whole chip */ [4 * NOR_CMD_LUT_SEQ_IDX_ERASECHIP] = FLEXSPI_LUT_SEQ(kFLEXSPI_Command_SDR, kFLEXSPI_1PAD, 0xC7, kFLEXSPI_Command_STOP, kFLEXSPI_1PAD, 0), }; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ These are all the changes that you need to make to the flexspi_nor_polling_transfer to use the on-chip flash as NVM instead of the external NOR flash.  Important notes It's important to mention that you cannot write, erase or read the on-chip flash while making XiP from this memory. So, you need to reallocate all the instructions that read, write and erase the flash to the internal FlexRAM. Fortunately, the example that we use as a base (flexspi_nor_polling_transfer) already does this. This is accomplished thanks to the files located in the linkscritps folder. To learn more about how this works, please refer to section 17.15 of the MCUXpresso IDE User Guide.  Additional resources Datasheet of the on-chip memory (Winbond W25Q32JV).  MCUXpresso IDE User Guide.  I hope that you find this document useful!  Regards,  Victor 

This guide will walk through how to do connect the camera and LCD modules to i.MX RT boards and how to test to ensure the camera and LCD are connected properly. Update May 2022: There are now updated versions of these LCD panels that have an impact on software. See this post for more details. The physical connections are the same for both the original and new panels however so there are no changes to this guide.   This first part of this guide is for the i.MX RT1050, i.MX RT1060, i.MX RT1064 EVKs. The second part of this guide is for i.MX RT595, i.MX RT1160 and i.MX RT1170 EVKs.      Part 1: Camera and LCD for i.MX RT1050, i.MX RT1060, and i.MX RT1064:  The camera used by the RT1050, RT1060, and RT1064 EVKs are the same. However this camera only comes with the RT1060 and RT1064 EVKs. There are alternatives available for the RT1050 as discussed in this blog post.    The LCD screen compatible with these boards is the RK043FN66HS-CTG    Camera:  1) The camera connector is on the front of the board. Flip the black connector up so it's 90 degrees from its original position.  2) Then slide in the flat ribbon connector of the camera 3) Flip the black connector back down. It should keep the ribbon cable snug.   LCD: 1) On the back of the board, slide the black connector for the LCD ribbon forward. 2) Then slide in the flat LCD ribbon cable underneath the black connector. 3) Slide the black connector back to its original position. The cable should be snug. 4) Do the same for the touch controller connector and slide the black connector forward Then insert the cable between the black connector and the white top so that the cable is in the middle. It might take a few tries as its somewhat difficult. You could also use needle nose pliers to help guide in the cable but be careful about damaging the cable. 5) Then slide the black connector back to the original position. The cable should be snug. 6) It should look like the following when complete.   Testing: 1) To test the camera and LCD, use the CSI driver examples in the MCUXpresso SDK.  2) The camera will likely be out of focus the first time you use it. Adjust it by rotating the lens clockwise until the image is in focus. You can use your fingers or some needle nose pliers. It could take up to two rotations and it should turn easily. Also remove the plastic cover.    3) To test the touch controller, use the emwin temperature control example in the MCUXpresso SDK   Tape: 1) Once the LCD has been confirmed to work, you can use two layers of thick double sided foam tape to securely attach it to the board.      Part 2: Camera and LCD for i.MX 700, i.MX RT595, i.MX RT1160 and i.MX RT1170 EVKs:  The i.MX RT1160 and i.MX RT1170 EVKs both come with a OV5640 MIPI camera module in the box.    The LCD screen compatible with the i.MX RT1160, i.MX RT1170, i.MX RT595, and i.MX RT700 is the RK055HDMIPI4MA0 and it can be found here.  There are multiple alternative names for this panel and all these names refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG   Instructions for i.MX RT1170 are below: i.MX RT1170-EVK Camera:  1) The camera connector is on the front of the board at J2. It connects by simply pressing the camera down onto the connector. It takes a bit of force but should not be too difficult.    i.MX RT1170-EVK LCD: 1) On the back of the board, slide the black connector (J40) for the LCD ribbon forward towards the edge of the board.    2) Then carefully slide in the flat LCD ribbon cable into the connector. The blue writing should be facing up like in the photo. It should go above the black part of the connector that you just slid out, and under the white part of the connector.  3) Slide the black plastic connector back to its original position. The cable should be snug if pulled. It should look like the following:    i.MX RT1170-EVK Power: 1) If using the LCD, then the external power adapter must be used with the board. Connect the barrel connector to J43 on the board. 2) Also change the jumper on J38 to be on pins 1-2 so that it uses the external power.  3) Connect a micro-USB cable to J11, which will cause the board to enumerate as a COM port and as a debug interface for downloading and debugging code   i.MX RT1170-EVK Camera and LCD Testing: 1) To test the camera and LCD, use the csi_mipi_rgb_cm7 driver example that can be found in the MCUXpresso SDK for i.MX RT1170. The camera input should be displayed on the LCD screen if everything is connected properly.          

In case you missed our recent webinar, you can check out the slides and comment below with any questions.

Slides from webinar hosted by NXP on Dec 10, 2019.

i.MXRT1050 MCU supports 10M/100M Ethernet MAC. Nowadays, LAN8720A is a very common PHY used in many networking design. In this document, I will show you how to use LAN8720A with i.MXRT1050.  1. Schematic   In this design example,  ENET_RST  is connected to GPIO_AD_B1_04      ENET_INT is connected to GPIO_AD_B0_15      2. Source code modification In the i.MXRT1050 SDK, the source code files of the PHY are fsl_phy.c and fsl_phy.h. The registers of LAN8720A need to be added into the source code. Below is the registers of LAN8720A. The details can be found in the LAN8720A datasheet. ( The modified fsl_phy.c and fsl_phy.h are attached)   In the pinmux.c, modify the GPIO Mux setting of the ENET_INT and ENET_RST.   IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_04_GPIO1_IO20, 0U);                                      IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15, 0U);                                      IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B1_04_GPIO1_IO20, 0xB0A9u);                                  IOMUXC_SetPinConfig(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15, 0xB0A9u);                               This is the part of the source code to reset the PHY in the main() function. gpio_pin_config_t gpio_config = {kGPIO_DigitalOutput, 0, kGPIO_NoIntmode}; GPIO_PinInit(GPIO1, 20, &gpio_config); GPIO_PinInit(GPIO1, 15, &gpio_config); GPIO_WritePinOutput(GPIO1, 15, 1); GPIO_WritePinOutput(GPIO1, 20, 0); delay(); GPIO_WritePinOutput(GPIO1, 20, 1); For more example codes, please refer to the demo_apps/lwip in the i.MXRT SDK package. Reference: i.MXRT1050 web page : i.MX RT1050 MCU/Applications Crossover Processor | Arm® Cortex®-M7 @600 MHz, 512KB SRAM |NXP  MCUXpresso SDK web page : MCUXpresso SDK|NXP 

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   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:   Add two lines like the following: Set the Build Configurations of the CM33 project to release_no_enetc0, and then build the project. Set the Build Configurations of the CM7 project to release_enetc0, and then build the project. 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: 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. 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:   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:     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 /   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) /   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.

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.   

Zephyr now supports the eIQ Neutron NPU on MCX N and i.MX RT700. This article will describe how to get Zephyr and use the eIQ Neutron NPU libraries and examples.  Some previous experience with eIQ Neutron NPU enablement is assumed, so ensure you're familiar with the eIQ Neutron SDK, converting models for eIQ Neutron NPU, and basic ML concepts by going through the MCX N or i.MX RT700  NPU bare-metal lab guides for VS Code before continuing on below.  Install Software Run the MCUXpresso Installer tool and install three key components: Zephyr Developer Arm GNU Toolchain Zephyr SDK LinkServer   Install LinkServer and add LinkServer to the PATH Install VS Code and MCUxpresso VS Code plugin   Download Zephyr Open VSCode Go to the MCUXpresso for VSCode plugin and click on Import Repository Go to the Remote tab and select the Zephyr repository. Choose it a directory name and location to download the repository to, and then click on Import.   It will take approximately 30 minutes to download the repository. Near the end of the download there will be several prompts in the terminal asking to accept licenses. Type “y” to accept and hit enter. There will be about 10 of these prompts at the end. Open the MCUXpresso Venv Terminal which has a Python virtual environment with all the paths preconfigured that were installed by MCUXpresso Installer.   In the terminal that pops up, type “1” to select the default environment. Then navigate to the directory you downloaded Zephyr into Run the following commands to get TensorFlow: west config manifest.project-filter -- +tflite-micro west update Go into the zephyr subdirectory folder cd zephyr Now need to explicitly download the Pull Request (PR) that enables eIQ Neutron. This eventually won’t be necessary when Zephyr 4.5 is released in October, but until then will need to type the following In the command prompt to get it:   git remote -v git remote add upstream https://github.com/zephyrproject-rtos/zephyr.git git remote -v   git stash git fetch upstream pull/108834/head:pr-108834 git checkout pr-108834   After this command you should see there’s now a folder at <zephyr_location>\ \zephyr\samples\boards\nxp\tflm_neutron with example source code.   Compile and Run a Zephyr eIQ Neutron NPU example Compile the project with west:  For MCX N: west build -p auto -b frdm_mcxn947/mcxn947/cpu0 samples/boards/nxp/tflm_neutron   For RT700: west build -p auto -b mimxrt700_evk/mimxrt798s/cm33_cpu0 samples/boards/nxp/tflm_neutron Open TeraTerm or other serial terminal program, and connect to the virtual COM port that board enumerated as when you plugged in the USB cable. Use 115200 baud, 1 stop bit, no parity. Flash the resulting code with west flash The serial terminal should show the following: Can debug with west debug      Run your own NPU accelerated ML model in Zephyr Make sure you've gone through the MCX N or i.MX RT700  hands-on labs so you're familiar with the enablement. The same steps for converting a model with the Neutron Converter tool inside eIQ Neutron SDK, updating the eIQ Neutron libraries, modfiying the operator list, and adding a new model are relevant when using Zephyr, but the file locations will be Zephyr specific. Also note that the header file generated by the Neutron Converter tool will need to be updated to match the header of the model.hpp file.  Also note that the README.rst file in the Zephyr Neutron example mentions using eIQ Toolkit but that information is outdated and been superseded by eIQ Neutron SDK.  eIQ Neutron example is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron Neutron libraries are at <zephyr_location>\modules\hal\nxp\zephyr\blobs\neutron\ Model data is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\models\mcxn\model.hpp Labels file is at <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\labels.h kTensorArenaSize variable is set in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 40) and is set to 60KB by default OpResolver is set in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 65) The model is selected in <zephyr_location>\zephyr\samples\boards\nxp\tflm_neutron\src\main_functions.cpp (line 11)   Additional References: Blog post on west which Zephyr uses. Zephyr on FRDM-MCXN947 Zephyr on i.MX RT700 Zephyr TensorFlow

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

This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.

There are two important memory locations used during eIQ inferencing on microcontrollers: modeldata: Location of the model in memory. Can be located in RAM or Flash. Inference time will be faster if it is located in RAM. s_tensorArena: Memory area that is used for input, output, and intermediate arrays. Must be located in RAM. The MCUXpresso SDK eIQ projects create a s_tensorArena buffer that is placed in RAM and used by the model. In the MCUXpresso SDK projects, the default size for this buffer is 256 KB in size and the size is set by the kTensorArenaSize variable, which is declared in the model_data.h header file in the MCUXpresso SDK examples:   The s_tensorArena buffer is declared in the eIQ MCUXpresso SDK projects in the model.cpp file   Size of TensorArena for a model is based on the input, output, and scratch memory of the largest operator in the model:     It is estimated during Neutron Conversion in the last Total Data field. However it’s always slightly smaller than actual amount required.     The actual buffer size used is printed out during inference by using the s_interpreter- >arena_used_bytes(); API call after model initialization. This is automatically done in the MCUXpresso SDK eIQ examples:   Thus the tensorArena buffer size can be optimized in a project for the particular model by running the project at least once and then the kTensorArenaSize variable can be set to the actual used size as it will remain constant for a particular model. Buffer size requirements are model-specific and will depend on the structure and complexity of each model.   The TensorArena size required is often the same regardless of using the original unconverted model or a NPU converted model, but sometimes the NPU reduces the required size. And occasionally the buffer size must be larger for an NPU converted model so it is quite model dependent. Beyond the model inferencing specific memory requirements, there will also be RAM and Flash required for generating the input data for a model (camera, sensor, etc) and any output handling (LCD, notification, etc).  MCX N Specific Memory Details for Neutron NPU: By default the model is placed into the internal flash because in model_data.h it is declared with: static const uint8_t model_data[] __ALIGNED(16) __PLACEMENT = {   By removing the const keyword, then the model will be placed into RAM during runtime and slightly improve the inference time. static uint8_t model_data[] __ALIGNED(16) __PLACEMENT = { As an example, doing this in the CIFAR10 MCUXpresso SDK example improves the inference time from 7.032ms to 5.524ms. Note that the kTensorArena variable must also be reduced from the default 256,000 bytes to 44,848 in order to fit in the internal RAM. The inference time improvement is model specific. However putting the model into RAM could not be done for the Label Image MCUXpresso SDK example because that model is too big and there is not enough RAM available for the model plus the tesnorArena buffer (which must be in internal RAM).  i.MX RT700 Specific Memory Details for Neutron NPU: See the i.MX RT700 eIQ Neutron NPU Enablement and Performance app note (AN14700) for more details about using eIQ Neutron NPU on i.MX RT700.  On i.MX RT700 the NPU has access to 5.5 MB of internal RAM from address 0x2000_0000 to 0x2058_0000 which consists of partitions SRAM P0 to SRAM P17. The model should be located inside this RAM area if it is placed in internal RAM. If using external memory, then the eIQ libraries will automatically copy the necessary model data to that internal memory location (see section below). The s_tensorArena buffer must also be within this 5.5MB RAM memory area. If the tensorArena buffer is located outside this 5.5MB area the model will still run but the inference results will be incorrect.      For i.MX RT700 eIQ projects, by default the model is placed at location 0x2040_0000 in RAM using the modeldata location name. For larger models, the RAM allocated by default in the eIQ SDK example projects for the s_tensorArena buffer or modeldata area may not be sufficient. In such case, the NCACHE_REGION size (where the s_tensorArena buffer is located) and modeldata size can be increased in the SDK project settings by modifying the linker file. The tensorArena buffer for RT700 internal memory models that use the NPU must also be in noncachable memory space. The model will still run if it is in cachable memory space but the results may be incorrect.  As a side note, for non-converted models that only run on the CM33 Core0 and do not use the NPU at all (mostly only done for benchmarking comparisons) then the tensorArena can be in cachable RAM and will see better performance if it's in that cachable RAM and is located between 0x2000_0000 and 0x2058_0000 since that RAM is the main System RAM for Core0.    i.MX RT700 eIQ Neutron NPU with External Memory For large models, or in cases where RAM is limited due to other uses in the application, the model can be stored in external flash memory via XSPI0. Placing the model in the external memory has an impact on performance, however. An example of this can be found in the tflm_label_image_ext_mem example in the MCUXpresso SDK where the model is at address 0x2820_0000. When the model is in external flash, then during inference a fragmented copy of the model is done to bring in chunks of the model into the internal RAM. This does have an impact on performance of the model and an example is given in the app note. Note: If placed in external memory then the --fetch_constants_to_sram option must be used during NPU conversion of the model to let the Neutron library know that it needs to do this fragmented copy during inference.      The scratch_weights buffer size required for this operation is printed out in the Scratch field during the model conversion when using the required --fetch-constants-to-sram argument:   And the scratchWeightsBuffer is created in the \eiq\tensorflow-lite\tensorflow\lite\micro\kernels\neutron\neutron.cpp file and the size can be modified by editing: #define SCRATCH_WEIGHTS_SRAM_SIZE  1200*1024 static uint8_t scratchWeightsBuffer[SCRATCH_WEIGHTS_SRAM_SIZE] __attribute__((aligned(16))) __attribute__((section("NonCacheable")));   If the scratch memory buffer size is too small for the model then there will not be an error message but the model output may be incorrect.  Also note that the Scratch Memory buffer is only needed when running a Neutron enabled model in external memory on i.MX RT700. If using a non-Neutron enabled model that only uses the CM33 core to run, then it is not needed. 

The i.MX RT700 microcontroller family includes an eIQ Neutron N3-64 NPU for accelerating neural network models. The i.MX RT700 EVK can be combined with a camera and LCD screen to showcase running TinyML vision models on a microcontroller.    i.MX RT700 Camera Hardware Setup: The following hardware is used: i.MX RT700 EVK RK055HDMIPI4MA0 LCD panel Camera Options: USB Camera with USB A to micro-B converter OV7670 parallel camera (with optional wide-angle lens) The USB camera should be attached to the i.MX RT700 EVK on USB OTG port J40. The parallel camera interface is available on J53 and uses FlexIO with eDMA to read in the camera data. AN14836 describes the details. Note that the links in that app note for the demo software do not work but the demo code is in the process of being posted on NXP’s Application Code Hub.  When inserting the parallel camera align it to the left most side, as shown in the image below:       Directions for attaching the LCD panel to the J52 connector on the underside of the i.MX RT700 EVK can be found on this Community post.  Note that there are multiple names used for the LCD panel and all these part numbers refer to the exact same panel: RK055HDMIPI4MA0 RK055MHD091 RK055MHD091-CTG RK055MHD091A0-CTG i.MX RT700 Vision ML Examples: There are two vision AI/ML examples for i.MX RT700 available today: Object Detection (part of AN14718) Hand Gesture Recognition Both of these examples use a USB camera.  i.MX RT700 Vision MPP Examples:  The Media Processing Pipeline (MPP) interference examples in i.MX RT700 MCUXpresso SDK 26.06 and later support both parallel and USB camera interfaces. These SDK examples are only available for command line GCC and VS Code MCUXpresso SDK layouts. They are not available for MCUXpresso IDE, IAR, or Keil.    A parallel camera is used by default in the RT700 MPP projects. A USB camera can be enabled by adding a USE_USB_CAMERA declaration in the project's CMakeLists.txt file by adding the following macro:   mcux_add_macro(     CC "-DUSE_USB_CAMERA"     CX "-DUSE_USB_CAMERA" ) However it's important to note that the camera_usb_final_fr_app_view project is setup to use USB camera by default, but it only works with a very specific HM2131 camera. All other MPP demos can work with most generic USB cameras.   

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.