INTRODUCTION REQUIREMENTS INTEGRATION     1. INTRODUCTION   This document provides an step-by-step guide to migrate the webcam application explained on AN12103 "Developing a simple UVC device based on i.MX RT1050" to EVKB-MIMXRT1050. The goal is getting the application working on rev. B silicon, using the current SDK components (v2.4.2) and with MCUXpresso IDE (v10.2.1), because the original implementation from the application note is using rev. A silicon and is developed on IAR IDE.   2. REQUIREMENTS   A) Download and install MCUXpresso IDE v10.2.1. B) Build an MCUXpresso SDK v2.4.2 for EVKB-MIMXRT1050 from the "SDK Builder web page", ensuring that CSI and USB components are included, and MCUXpresso IDE is selected, and install it. For A) and B) steps, you could refer to the following Community document: https://community.nxp.com/docs/DOC-341985  C) Download the source code related to AN12103. D) Having the EVKB-MIMXRT1050 board, with MT9M1114 camera module. 3. INTEGRATION   a) Open MCUXpresso IDE, and click on "Import SDK example" shortcut, select the "evkbimxrt1050" board and click on "Next" button. b) Select the "driver_examples->csi->csi_rgb565" and "usb_examples->dev_video_virtual_camera_bm" examples, and click on "Finish" button. c) Copy the "fsl_csi.h", "fsl_csi.c", "fsl_lpi2c.h" and "fsl_lpi2c.c" files from the "drivers" folder of CSI project, to the "drivers" folder of the Virtual_Camera project. d) Copy the "pin_mux.h" and "pin_mux.c" files from the "board" folder of CSI project, to the "board->src" folder of the Virtual_Camera project, replacing the already included files. e) Copy the "camera" folder from AN12103 software package from the path below, to the Virtual_Camera project: <AN12103SW\boards\evkmimxrt1050\user_apps\uvc_demo\src\camera> Also copy the "main.c" file from AN12103 software package to the "sources" folder of the Virtual_Camera project. Ensure selecting the option "Copy files and folders" when copying folders/files. f) Right click on the recently added "camera" folder, and select "Properties". Then, on the "C/C++ Build" menu, remove the checkbox "Exclude resource from build" option, and then click on "Apply and Close" button. g) Right click on the Virtual_Camera project, and select "Properties". Then, select the "C/C++ Build -> Settings -> MCU C Compiler -> Preprocessor" menu, and click on the "+" button to add the following value: "SDK_I2C_BASED_COMPONENT_USED=1", and click on "OK" button. h) Now, move to the "Includes" menu of the same window, and click on the "+" button to add the following value: "../camera". Repeat the same procedure on "MCU Assembler -> General" menu, and then, click on "Apply and Close" button. i) Refer to "usb" folder from AN12103 software package from the path below, and copy "video_camera.h", "video_camera.c", "usb_device_descriptor.h" and "usb_device_descriptor.c" files to the "sources" folder of Virtual_Camera project, ensuring selecting the option "Copy files and folders" and overwriting the already included files: <AN12103SW\boards\evkmimxrt1050\user_apps\uvc_demo\src\usb> j) Select "video_data.h", "video_data.c", "virtual_camera.h" and "virtual_camera.c" files and "doc" folder, then right click and select "Delete". Click on "OK" button of the confirmation window to remove these resources from the Virtual_Camera project. k) Refer to "fsl_mt9m114.c" file from "camera" folder of Virtual_Camera project, and delete the "static" definition from functions "MT9M114_Init", "MT9M114_Deinit", "MT9M114_Start", "MT9M114_Stop", "MT9M114_Control" and "MT9M114_InitExt". l) Refer to "main.c" file from "sources" folder of Virtual_Camera project, and comment out the call to the function "BOARD_InitLPI2C1Pins". Also, refer to "board.c" file from "board->src" folder of Virtual_Camera project, and comment out the call to the function "SCB_EnableDCache". m) Refer to "camera_device.c" file from "camera" folder of Virtual_Camera project, and comment out the line "AT_NONCACHEABLE_SECTION_ALIGN(static uint16_t s_cameraFrameBuffer[CAMERA_FRAME_BUFFER_COUNT][CAMERA_VERTICAL_POINTS * CAMERA_HORIZONTAL_POINTS + 32u], FRAME_BUFFER_ALIGN);" and add the following line: static uint16_t __attribute__((section (".noinit.$BOARD_SDRAM"))) s_cameraFrameBuffer[CAMERA_FRAME_BUFFER_COUNT][CAMERA_VERTICAL_POINTS * CAMERA_HORIZONTAL_POINTS + 32u] __attribute__ ((aligned (FRAME_BUFFER_ALIGN))); n) Compile and download the application into the EVKB-MIMXRT1050 board. The memory usage is shown below: o) When running the application, if you also have the serial terminal connected, you should see the print message. Additionally, if connected to Windows OS, you could find it as "CSI Camera Device" under the "Imaging devices" category. p) Optionally, you could rename the Virtual_Camera project to any other desired name, with rigth click on Project, and selecting "Rename" option, and finally, click on "OK" button. It is also attached the migrated MCUXpresso IDE project including all the steps mentioned on the present document. Hope this will be useful for you. Best regards! Some additional references: https://community.nxp.com/thread/321587  Defining Variables at Absolute Addresses with gcc | MCU on Eclipse   

In the i.MXRT 1050 EVK web page, there is a very nice "Getting Started" page to show the videos and steps how to use the board. 1. Connect the board to your PC by a USB cable. 2. Build and download the SDK. a. In the SDK Builder web page, you can customize and download the specific SDK of your board. b. On the next page, you can select different OS and different IDE. Select "MCUpresso IDE" for Windows here. c. You can add the software component that you wanted. d. Request to build the SDK. e. When the build request has completed, the SDK is available for download under the SDK Dashboard page. - Download icon : Download the SDK - Rebuild icon : Rebuild the SDK with different setting - Share icon : Share the SDK to others - MCUConfigTool icon : Run the MCU Configuration Tool to configure the pinmux and clocks for your own design board. - Remove icon : Remove the SDK from the Dashboard. 3. Install the MCUXpresso IDE. a. Go to the MCUXpresso IDE weg page to download the IDE and then install it. 4. Build and run the example on EVK. a. Open the MCUXpresso IDE. Simply drag & drop the SDK zip file to "Installed SDKs" view. b. Import the SDK examples and then click "Next". c. Select the "hello_world" under the demo_apps. d. Click "Build" to build the demo. e. Execute the terminal software (e.g. PuTTY). The COM port of the console output can be found in "devices manager". The COM setting is 115200,8,N,1. f. Click the "bug" icon to start the debugging. g. Click "Resume All Debug Sessions" icon to run the demo. h. "hello world" print out in console. Reference: i.MXRT1050 web page ( Contain the datasheet, reference manual of the i.MXRT1050 processor) i.MXRT1050EVK web page ( Contain the user's guides of the i.MXRT1050 EVK) MCUXpresso IDE web page ( Contain the user's guides of the MCUXpresso IDE )

Testing Boot times – Generating a bootable image Bootable Image Structure: The bootable image consists of: FlexSPI Configuration Block (FCB) Image Vector Table (IVT) Boot Data Device Configuration Data (DCD) Program image CSF, Certificates, and signatures (this stuff is optional and only comes with high-assurance boot I’ll briefly explain each below: FlexSPI Configuration Block (FCB) The FCB will configure the settings of the FlexSPI communication. It will establish how many ports will be used, what clock speed to run the FlexSPI controller at, etc. This is the first thing that happens, as everything else is stored in Flash memory. In order to read anything else, the flash must first be configured.  Image Vector Table (IVT)  The IVT is a table that tells the memory the addresses of where everything is stored. Boot Data The Boot Data contains pointers to the start address of the Memory. Device Configuration Data (DCD) The DCD contains configuration data to configure any peripherals. Program image The program image contains the code you write to go into the application. CSF, Certificates, and signatures These things are optional. They come with high-assurance boot sequence and will not be covered in this writeup. Below is a rough table outlining these different parts of the boot image: Bootable Image generation software / tools: MCUXpresso – download the MCUXpresso IDE Flash Loader – download from RT1050 page > software and tools > flashloader This entire folder will include the MFGTool, elftosb tool, and more documentation. DCD.bin file: I found mine included in this document: https://community.nxp.com/docs/DOC-340655 Bootable Image Generation Overview MCUXpresso can generate bootable images for Hyperflash and QSPI XiP, but if trying to boot and execute in place of SDRAM or intern SRAM, or from your own memory module, then you must generate a bootable image by through a combination of generating an s record or elf image on MCUXpresso, and then using the flashloader tool suite (elftosb and mfgtool) to create a bootable image and then a bootable program to upload to the board. The entire general process is described below. In subsequent sections, a more detailed step-by-step guide is provided for Hyperflash XiP, SDRAM, and SRAM, each. MCUXpresso Configurations and output: Begin with your application code in MCUXpresso. Change memory allocation in the memory configuration editor of the MCU Settings part of MCUXpresso according to where you would like to boot from. If applicable, be sure to specify in the preprocessor settings if you would like to enable the dcd in the boot image. Generate an s-record (.s19) file from MCUXpresso using binary utilities. Elftosb tool – .bin file generation You can find this tool in the flashloader. Call an imx command to it which will take as input the s-record file containing the program image, a dcd.bin file (may or may not be in the s-record), a FCB?, and a bd_file (given to you, specific to your memory configuration). The elftosb tool will generate as an output a .bin file. Elftosb tool – Bootable image generation Then call the elftosb tool again with a kinetis command. This will take the .bin file and convert it to a boot_image.sb file. MFG tool Then we can use the mfg tool to generate the program image for the board, and upload it. In order to do this, the board SW7 must be set to OFF-ON-OFF-ON, and switch the jumper from J1  (5-6) to J1 (3-4). Connect the USB cable to J9 to power the board. Then connect the board to your computer and run the Mfg tool. Click start and the image will be uploaded.      After this the bootable image will be uploaded to the board and you’ll be good to go! Remember to switch the pin headers back, so the board can boot normally. J1 (5-6) and SW7 to OFF-ON -ON -OFF to boot from Hyperflash. Now in the following sections I’ll break down specific examples of what to do depending on the specific memory location you’d like to boot from. Bootable Image Generation – XiP Hyperflash Please note that this can also be done in MCUXpresso, but In order to use my own dcd file, I did this project using the traditional flashloader tools.   MCUXpresso Configurations and output: Begin by changing memory allocation in the memory configuration editor (edit project settings >> C/C++ Build >> MCU settings >>edit. It should look like the one below. Then go to C/C++ Build >>settings > MCU C compiler > preprocessor and set the XIP_boot_header enable and and XIP_boot_header_DCD_enable both to 0 if you have a dcd.bin file to use. Otherwise set these fields to 1. Hit apply and close. Go to the debug portion and click on binary utilities, then generate an s-record (.s19) file from MCUXpresso.  Click build to re-build the project. Copy this .s19 file. Elftosb tool – .bin file generation In the flashloader tool, go to Tools > elftosb > Win, and drop the .s19 file in this folder, as well as the dcd.bin file. Fire up command prompt in administrator mode, and use command cd [elftosb directory] to get to this folder To generate the .bin file, call the command:   elftosb.exe -f imx -V -c ../../bd_file/imx10xx/imx-flexspinor-normal-unsigned-dcd.bd -o ivt_flexspi_nor_led_blinky.bin HYPERFLASH_led_blinky.s19   This command essentially uses the imx-flexspinor bd linker file to generate a .bin file that will include the dcd.bin header inside. Note that HYPERFLASH_led_blinky.s19 should be renamed to your actual file name acquired from MCUXpresso   Elftosb tool – Bootable image generation Then we must generate the boot_image.sb Then call the elftosb tool again with a kinetis command. This will take the .bin file and convert it to a boot_image.sb file. The command is:   elftosb.exe -f kinetis -V -c ../../bd_file/imx10xx/program_flexspinor_image_hyperflash.bd -o boot_image.sb ivt_flexspi_nor_led_blinky_nopadding.bin   Note: The output of the first imx command we made must match the input of this one (ivt_flexspi_nor_led_blinky_nopadding.bin). Also, the output must remain named boot_image.sb, otherwise it will not work. MFG tool Then we can use the mfg tool to generate the program image for the board, and upload it. In order to do this, the board SW7 must be set to OFF-ON-OFF-ON, and switch the jumper from J1  (5-6) to J1 (3-4). Connect the USB cable to J9 to power the board. Then connect the board to your computer and run the Mfg tool. Click start and the image will be uploaded.        Copy the boot_image.sb file that we created in the last step. Move it to the directory Tools > mfgtools-rel > Profiles > MXRT105X > OS Firmware, and drop it in here. Next, set SW7 on the board to OFF-ON-OFF-ON, and switch the jumper at the bottom to power the board. Then connect the USB cable to J9. This will allow you to program the board. Go back to the folder mfgtools-rel and Open the Mfg Tool. It should say HID- compliant vendor-defined device. Otherwise double check SW7 and the power pin at the bottom right.   Click start and if successful it should look like: Please note that this success only means that it was able to upload the bootable image to the board. This usually works well. However, if you find later that the board doesn’t do what it’s supposed to, then there might be a problem in the other steps of the processor. Check to make sure you used the right linker file, and that the settings in MCUXpresso are configured correctly. Press stop and exit Remember to switch the pin headers back, so the board can boot normally. J1 (5-6) and SW7 to OFF-ON -ON -OFF to boot from Hyperflash.   Bootable Image Generation – SDRAM The guide is based off this link: https://community.nxp.com/docs/DOC-340655 . Download the files provided there, and unzip. Everything is good except the first step of that pdf document is a little unclear. MCUXpresso Configurations and output: Begin by changing memory allocation in the memory configuration editor of the MCU Settings part of MCUXpresso. It should look like the one below. Then go to settings > MCU C compiler > preprocessor and set the XIP_boot_header enable and and XIP_boot_header_DCD_enable both to 0 Hit apply and close. Go to C/C++ Build >> Settings >> MCU Linker >> Manage linker script, and check the box Link application to RAM. Go to the debug portion and click on binary utilities, then generate an s-record (.s19) file from MCUXpresso.  Click build to re-build the project. You can check the console to verify the correct allocations of memory: Copy this .s19 file. Elftosb tool – .bin file generation In the flashloader tool, go to Tools > elftosb > Win, and drop the .s19 file in this folder, as well as the dcd.bin file. There’s another step for booting from SDRAM. Take the file imx-sdram-normal-unsigned-dcd.bd (included in the link posted) and drag it into Tools > bd_file > imx10xx Fire up command prompt in administrator mode, and use command cd [elftosb directory] to get to this folder To generate the .bin file, call the command:   elftosb.exe -f imx -V -c ../../bd_file/imx10xx/imx-sdram-normal-unsigned-dcd.bd -o evkbimxrt1050_led_blinky.bin SDRAM1_led_blinky.s19   This command essentially uses the imx-flexspinor bd linker file to generate a .bin file that will include the dcd.bin header inside. Note that HYPERFLASH_led_blinky.s19 should be renamed to your actual file name acquired from MCUXpresso   Elftosb tool – Bootable image generation Then we must generate the boot_image.sb Then call the elftosb tool again with a kinetis command. This will take the .bin file and convert it to a boot_image.sb file. The command is:   elftosb.exe -f kinetis -V -c ../../bd_file/imx10xx/program_flexspinor_image_hyperflash.bd -o boot_image.sb evkbimxrt1050_led_blinky_nopadding.bin   The output of the first imx command we made must match the input of this one. Also, the output must remain named boot_image.sb, otherwise it will not work. Also note that this says flexspinor image hyperflash, but that is correct since we are still technically needing to boot from Hyperflash initially before we copy everything over to SDRAM. Copy the boot_image.sb file. MFG tool Then we can use the mfg tool to generate the program image for the board, and upload it. In order to do this, the board SW7 must be set to OFF-ON-OFF-ON, and switch the jumper from J1  (5-6) to J1 (3-4). Connect the USB cable to J9 to power the board. Then connect the board to your computer and run the Mfg tool. Click start and the image will be uploaded.        Copy the boot_image.sb file that we created in the last step. Move it to the directory Tools > mfgtools-rel > Profiles > MXRT105X > OS Firmware, and drop it in here. Next, set SW7 on the board to OFF-ON-OFF-ON, and switch the jumper at the bottom to power the board. Then connect the USB cable to J9. This will allow you to program the board. Go back to the folder mfgtools-rel and Open the Mfg Tool. It should say HID- compliant vendor-defined device. Otherwise double check SW7 and the power pin at the bottom right.   Click start and if successful it should look like: Please note that this success only means that it was able to upload the bootable image to the board. This usually works well. However, if you find later that the board doesn’t do what it’s supposed to, then there might be a problem in the other steps of the processor. Check to make sure you used the right linker file, and that the settings in MCUXpresso are configured correctly. Press stop and exit Remember to switch the pin headers back, so the board can boot normally. J1 (5-6) and SW7 to OFF-ON -ON -OFF to boot from Hyperflash.   Bootable Image Generation – SRAM This one was a little trickier as there was no appnote, but not too bad. MCUXpresso Configurations and output: Begin by changing memory allocation in the memory configuration editor of the MCU Settings part of MCUXpresso. It should look like the one below. We are linking to copy everything to dtc RAM Then go to settings > MCU C compiler > preprocessor and set the XIP_boot_header enable and and XIP_boot_header_DCD_enable both to 0 Hit apply and close. Go to C/C++ Build >> Settings >> MCU Linker >> Manage linker script, and check the box Link application to RAM.   Go to the debug portion and click on binary utilities, then generate an s-record (.s19) file from MCUXpresso.  Click build to re-build the project. You can verify that application is linked to SRAM in the console: Copy this .s19 file. Elftosb tool – .bin file generation In the flashloader tool, go to Tools > elftosb > Win, and drop the .s19 file in this folder, as well as the dcd.bin file Fire up command prompt in administrator mode, and use command cd [elftosb directory] to get to this folder This step is specific to dtcm ram: Go to Tools >>bd_file >> imx10xx, and open up the imx-dtcm-unsigned-dcd.bd file and change the ivtOffset address to 0x1000. 0x400 is the default for SDCARD booting. To be clear, the bd file should look as below: To generate the .bin file, call the command:   elftosb.exe -f imx -V -c ../../bd_file/imx10xx/imx-dtcm-unsigned-dcd.bd -o evkbimxrt1050_led_blinky.bin SRAM1_led_blinky.s19   This command essentially uses the imx-flexspinor bd linker file to generate a .bin file that will include the dcd.bin header inside. Note that SRAM_led_blinky.s19 should be renamed to your actual file name acquired from MCUXpresso. Elftosb tool – Bootable image generation Then we must generate the boot_image.sb Then call the elftosb tool again with a kinetis command. This will take the .bin file and convert it to a boot_image.sb file. The command is:   elftosb.exe -f kinetis -V -c ../../bd_file/imx10xx/program_flexspinor_image_hyperflash.bd -o boot_image.sb evkbimxrt1050_led_blinky_nopadding.bin   The output of the first imx command we made must match the input of this one. Also, the output must remain named boot_image.sb, otherwise it will not work. Also note that this says flexspinor image hyperflash, but that is correct since we are still technically needing to boot from Hyperflash initially before we copy everything over to SDRAM. MFG tool Then we can use the mfg tool to generate the program image for the board, and upload it. In order to do this, the board SW7 must be set to OFF-ON-OFF-ON, and switch the jumper from J1  (5-6) to J1 (3-4). Connect the USB cable to J9 to power the board. Then connect the board to your computer and run the Mfg tool. Click start and the image will be uploaded.    Copy the boot_image.sb file that we created in the last step. Move it to the directory Tools > mfgtools-rel > Profiles > MXRT105X > OS Firmware, and drop it in here. Next, set SW7 on the board to OFF-ON-OFF-ON, and switch the jumper at the bottom to power the board. Then connect the USB cable to J9. This will allow you to program the board. Go back to the folder mfgtools-rel and Open the Mfg Tool. It should say HID- compliant vendor-defined device. Otherwise double check SW7 and the power pin at the bottom right.   Click start and if successful it should look like: Please note that this success only means that it was able to upload the bootable image to the board. This usually works well. However, if you find later that the board doesn’t do what it’s supposed to, then there might be a problem in the other steps of the processor. Check to make sure you used the right linker file, and that the settings in MCUXpresso are configured correctly. Press stop and exit Remember to switch the pin headers back, so the board can boot normally. J1 (5-6) and SW7 to OFF-ON -ON -OFF to boot from Hyperflash. Please note that this success only means that it was able to upload the bootable image to the board. This usually works well. However, if you find later that the board doesn’t do what it’s supposed to, then there might be a problem with the other steps of the processor. Check to make sure you used the right linker file, and that the settings in MCUXpresso are configured correctly. After this the bootable image will be uploaded to the board and you’ll be good to go!

A small project I worked on was to understand how RT1050 boot-up performs from different memory types. I used the LED_blinky code from the SDK as a baseline, and ran some tests on the EVKB board. The data I gathered is described below, as well as more detailed testing procedures. Testing Procedure The boot-up time will be defined as the time from which the processor first receives power, to when it executes the first line of code from the main() function. Time was measured using an oscilloscope (Tektronix TDS 2014) between the rising edge of the POR_B* signal to the following two points: FlexSPI_CS asserted (first read of the FlexSPI by the ROM)** GPIO Toggle in application code (signals beginning of code execution).*** *The POR_B signal was available to scope through header J26-1 **The FlexSPI_CS signal is available through a small pull-up resistor on the board, R356. A small wire was soldered alongside this resistor, and was probed on the oscilloscope. ***The GPIO pin that was used was the same one that connected to USER_LED (Active low). This pin could be scoped through header J22-5. TP 2, 3, 4, and 5 are used to ground the probe of the oscilloscope. This was all done in the EVKB evaluation board. Here are a couple of noteworthy points about the test ran: This report mostly emphasizes the time between the rise of the POR_B signal, and the first line of execution of code. However, there is a time between when power is first provided to the board and the POR_B system goes up. This is a matter of power electronics and can vary depending on the user application and design. Because of this, this report will not place a huge emphasis on this. The first actual lines of code of the application is actually configuring several pins of the processor. Only after these pins are executed, does the GPIO toggle low and the time is taken on the oscilloscope. However, these lines of configuration code are executed so rapidly, that the time is ignored for the test.   Clock Configurations The bootable image was flashed to the RT1050 in all three cases. Afterwards, in MCUXpresso, the debugger was configured with “Attach Only” set to true. A debug session was then launched, and after the processor finished executing code, it was paused and the register values were read according to the RT1050 Reference Manual, chapter 18, CCM Block Diagram.  Boot Configuration: Core Clock (MHz) * FlexSPI Clock (MHz) SEMC Clock (MHz) FlexSPI 130 99 SDRAM 396 130 99 SRAM 396 130 99 *The Core Clock speed was also verified by configuring clko1 as an output with the clock speed divided by 8. This frequency was measured using an oscilloscope and verified to be 396 MHz. Results The time to chip select pin represents the moment when the first flash read happens from the RT1050 processor. The time to GPIO output represents the boot-up time.   As expected, XiP Hyperflash boots faster than other memories. SRAM and SDRAM memories must copy to executable memory before executing which will take more time and therefore boot slower. In the sections below, a more thorough explanation is provided of how these tests were ran and why Hyperflash XiP is expected to be the fastest. Hyperflash XiP Boot Up Below is an outline of the steps of what we expect the Hyperflash XiP boot-up process to look like: Power On Reset (J26-1) Begin access to Flash memory (FlexSPI_SS0) Execute in place in flash (XiP) First line of code is exectuted (USER_LED) In MCUXpresso, the map file showed the following: The oscilloscope image is below:   SDRAM Boot Up The processor will bootup from ROM, which will be told to copy an application image from the serial NOR flash memory to SDRAM (serial NOR flash uses Hyperflash communication). The RT flashloader tool will let me load up the application to the flash to be configured to copy over memory to the SDRAM and execute to it.   It is expected that copying to SDRAM will be slower than executing in place from Hyperflash since an entire copying action must take place.   The SDRAM boot-up process looks like the following: Power On Reset (J26-1) Begin access to Flash memory (FlexSPI_SS0) Copy code to SDRAM Execute in place in SDRAM (FlexSPI_SS0) First line of code is executed (USER_LED)   In MCUXpresso, the map file showed the following:   In order to run this test, I followed these instructions: https://community.nxp.com/docs/DOC-340655. SRAM Boot Up For SRAM, a similar process to that of SDRAM is expected. The processor will first boot from internal ROM, and then go to Hyperflash. It will then copy over everything from Hyperflash to internal SRAM DTC memory and then execute from there.  The SRAM Boot Up Process follows as such: Power On Reset (J26-1) Begin access to Flash memory (FlexSPI_SS0) Copy code to SRAM Execute in place in SRAM (FlexSPI_SS0) First line of code is executed (USER_LED)   In MCUXpresso, the map file showed the following:   This document was generated from the following discussion: javascript:;

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

The path of SDRAM Clock in Clock Tree                 According CCM clock tree in i.MXRT1050 reference manual, we can abstract part of SDRAM clock, and draw it’s diagram below.   Descriptions for Diagram 1 (1) PLL2 PFD2                 ① Registers related to PLL2 PFD2 ---CCM_ANALOG_PLL_SYSn (page 767, in reference manual) Address: 0x400D_8030h important bits: bit[15:14]---- select clock source. Bit[13] ----- Enable PLL output Bit[0]------- This field controls the PLL loop divider. 0 - Fout=Fref*20; 1 - Fout=Fref*22. ---CCM_ANALOG_PLL_SYS_NUM(page 768, in reference manual) Address: 0x400D_8050h important bits: bit[29:0]--- 30 bit numerator (A) of fractional loop divider (signed integer) ---CCM_ANALOG_PLL_SYS_DENOM (page 769, in reference manual) Address: 0x400D_8060h important bits: bit[29:0]---- 30 bit Denominator (B) of fractional loop divider (unsigned integer).   ---CCM_ANALOG_PFD_528n (page 769, in reference manual) Address: 0x400D_8100h important bits: bit[21:16]----- This field controls the fractional divide value. The resulting frequency shall be 528*18/PFD2_FRAC where PFD2_FRAC is in the range 12-35.   ② Computational formula PLL2_PFD2_OUT=(External 24MHz)*(Fout + A/B) * 18/ PFD2_FRAC   ③ Example for PLL2_PFD2_OUT computation CCM_ANALOG_PLL_SYSn[0] = 1  // Fout=Fref*22 CCM_ANALOG_PLL_SYS_NUM[29:0] = 56  // A = 56 CCM_ANALOG_PLL_SYS_DENOM[29:0] = 256  // B=256 CCM_ANALOG_PFD_528n[21:16] = 29                       // PFD2_FRAC=29   PLL2_PFD2_OUT = 24 * (22 + 56/256)*18/29 = 331MHz (330.98MHz)   (2) Clock Select Register : CCM_CBCDR Address: 0x 400F_C014h important bits: SEMC_ALT_CLK_SEL & SEMC_CLK_SEL & SEMC_PODF bit[7] --- bit[SEMC_ALT_CLK_SEL] 0---PLL2 PFD2 will be selected as alternative clock for SEMC root clock 1---PLL3 PFD1 will be selected as alternative clock for SEMC root clock Bit[6] --- bit[SEMC_CLK_SEL] 0----Periph_clk output will be used as SEMC clock root 1----SEMC alternative clock will be used as SEMC clock root Bit[18:16] --- bit[SEMC_PODF] Post divider for SEMC clock. NOTE: Any change of this divider might involve handshake with EMI. See CDHIPR register for the handshake busy bits. 000 divide by 1 001 divide by 2 010 divide by 3 011 divide by 4 100 divide by 5 101 divide by 6 110 divide by 7 111 divide by 8 Example for configuration of SDRAM Clock   Example : 166MHz SDRAM Clock   ---- 0x400D8030 = 0x00002001 // wirte  0x00002001 to CCM_ANALOG_PLL_SYSn ---- 0x400D8050 = 0x00000038 // write 0x00000038 to CCM_ANALOG_PLL_SYS_NUM ---- 0x400D8060 = 0x00000100 // write 0x00000100 to CCM_ANALOG_PLL_SYS_DENOM ---- 0x400D8100 = 0x001d0000 // write 0x001d0000 to CCM_ANALOG_PFD_528n ---- 0x400FC014 = 0x00010D40 // write 0x00010D40 to CCM_CBCDR, divided by 2         NXP TIC team Weidong Sun 2018-06-01

The iMX RT1050 ROM will allow you to copy an application image from a serial NOR flash memory on the FlexSPI controller to SDRAM at boot time. If you want to run your application from SDRAM, then when debugging and developing your application you should use an initialization script for the debugger to setup the SDRAM so the application can be downloaded directly to the SDRAM for debugging. When you are ready to have your application boot without the debugger, then you'll need to use the RT flashloader tools to program the application to the flash and configure it to copy to the SDRAM. The attached document contains instructions on how to program a boot image to serial NOR flash (in this case the hyperflash that is on the EVK) that will be copied to the SDRAM at boot time.

The MIMXRT1050-EVK includes a CMSIS-DAP/DAP-Link interface that includes MSD drag and drop functionality for the HyperFlash on the board. The drag and drop programming functionality can be used to program applications compiled to execute-in-place (XIP) from the HyperFlash memory. In the early SDK versions for RT1050, the projects did not include the flash configuration block and IVT required to make a bootable image across all toolchains. Starting with the SDK 2.3.1 release, projects include XIP files that add this information to the project. This allows for programming a bootable application to the external flash memory directly from the debugger, so many customers might not even need to use the drag-and-drop programming feature any more. Because of the SDK changes, the DAP-Link application has also had changes: Early versions of the DAPLink firmware were setup to work with a raw application binary like those generated by the SDK 2.3.0 for toolchains other than the MCUXpresso IDE. These versions will take the raw application binary and prepend the flash configuration block for the HyperFlash/QSPI and an IVT to make a bootable image. Newer version of the DAPLink firmware are setup to work with a complete bootable binary like those generated by SDK 2.3.1 and later. These versions will not attempt to prepend a flash configuration block and IVT to the application, because these are assumed to already be present. The following table describes the versions of the DAPLink application that have been released. NOTE: the firmware can be updated on the board, so the version on a given board might not match what was originally programmed at manufacture time. The latest version of firmware can be downloaded from www.nxp.com/opensda Board Rev DAPLink MCU GIT SHA from details.txt file NOTE EVK_A2 MK20 34182e2cce4ca99073443ef29fbcfaab9e18caec DAPLink will add FCB and IVT EVK_A3-EVK-A5 MK20 853df431d81359e822f49363891f877f17d31efb DAPLink will add FCB and IVT EVKB_A MK20 853df431d81359e822f49363891f877f17d31efb DAPLink will add FCB and IVT EVKB_A1 MK20 853df431d81359e822f49363891f877f17d31efb DAPLink will add FCB and IVT EVKB_A1 MK20 b3435dbed0ba4f09680e49d2fcfdaab32c7a4c71 DAPLink will NOT add FCB and IVT To use the drag and drop programming: 1. Configure the board for serial downloader mode by setting SW7 to OFF-ON-OFF-ON.  2. Press SW3 to reset the processor. 3. Drag the application binary to the RT1050-EVK drive.  4. Put the board back in internal boot mode by setting SW7 to OFF-ON-ON-OFF. 5. Press SW3 to reset the processor and your application should boot.  There are some limitations to the drag and drop programming to keep in mind: - Only works for Hyperflash/QSPI XIP applications. Doesn't support copying the code from HyperFlash to another memory (like ITCM) for execution - Application initial stack pointer must be located in DTCM - Doesn't support DCD files The flashloader and ROM tools offer a second external memory programming method where the limitations above do not apply: https://www.nxp.com/downloads/en/initialization-boot-device-driver-code-generation/Flashloader_i.MXRT1050_1.0_GA.zip  Refer to AN12107 for more information: https://www.nxp.com/docs/en/application-note/AN12107.pdf?fsrch=1&sr=2&pageNum=1