i.MX RT Crossover MCUs Knowledge Base

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX RT Crossover MCUs Knowledge Base

ディスカッション

ソート順:
1.1 Introduction   RT-Flash is a GUI tool specially designed for i.MX RT production. Its feature is similar to MfgTool2, but it solves below limitaions of MfgTool2: The .sb file can only be specified in xml file; USB port is the only choice to download .sb file; Sometimes USB Hub is required to connect;   With RT-Flash, you can easily get started with NXP MCU secure boot. The main features of RT-Flash include: Support i.MXRT1015, i.MXRT1021, i.MXRT1051/1052, i.MXRT1061/1062, i.MXRT1064 SIP Support both UART and USB-HID serial downloader modes Support for loading .sb image file into boot device 1.2 Download   RT-Flash is developed in Python, and it is open source. The development environment is Python 2.7.15 (32bit), wxPython 4.0.3, pySerial 3.4, pywinusb 0.4.2, PyInstaller 3.3.1 (or higher). Source code: https://github.com/JayHeng/RT-Flash   RT-Flash is packaged by PyInstaller, all Python dependencies have been packaged into an executable file (\RT-Flash\bin\RT-Flash.exe), so if you do not want to develop RT-Flash for new feature, there is no need to install any Python software or related libraries. Note1: The RT-Flash.exe in the source code package is packaged in the Windows 10 x64 environment and has only been tested in this environment. If it cannot be used directly for system environment reasons, you need to install Python2.7.15 x86 version (Confirm that the directory "\Python27" and "\Python27\Scripts" are in the system environment variable path after the installation is completed), then click on "do_setup_by_pip.bat" in the "\RT-Flash\env" directory to install the Python library on which RT-Flash depends. Finally, click "do_pack_by_pyinstaller.bat" to regenerate the RT-Flash.exe. Note2: You must use Python2 x86 version, because RT-Flash uses the pywinusb library, which cannot be packaged by PyInstaller in Python2 x64 version. The pywinusb author has no plan to fix the problem. 1.3 Installation   RT-Flash is a pure green free installation tool. After downloading the source code package, double-click "\RT-Flash\bin\RT-Flash.exe" to use it. No additional software is required.   Before the RT-Flash.exe graphical interface is displayed, a console window will pop up first. The console will work along with the RT-Flash.exe graphical interface. The console is mainly for the purpose of showing error information of RT-Flash.exe. At present, RT-Flash is still in development stage, and the console will be removed when the RT-Flash is fully validated. 1.4 Interface
記事全体を表示
One-stop secure boot tool: NXP-MCUBootUtility v1.0.0 is released Source code: https://github.com/JayHeng/NXP-MCUBootUtility 【v1.1.0】 Feature:   1. Support i.MXRT1015   2. Add Language option in Menu/View and support Chinese Improvement:   1. USB device auto-detection can be disabled   2. Original image can be a bootable image (with IVT&BootData/DCD)   3. Show boot sequence page dynamically according to action Interest:   1. Add sound effect (Mario) 【v1.2.0】 Feature:   1. Can generate .sb file for MfgTool and RT-Flash   2. Can show cost time along with gauge Improvement:   1. Non-XIP image can also be supported for BEE Encryption case   2. Display guage in real time Bug:   1. Region count cannot be set more than 1 for Fixed OTPMK Key case   2. Option1 field is not implemented for FlexSPI NOR configuration
記事全体を表示
The document will introduce how to configure LPSPI clock on I.MXRT1050. The purpose is to help IMXRT customers better understand the clock tree and configure LPSPI clock in SDK.    Customer can configure LPSPI clock according to the following steps: 1 Select Source according to the clock tree. 2   Set LPSPI_CKL_SEL according to the register CCM_CBCMR. 3 Enable LPSPIn clock according to the register CCM_CCGR1. 4 Set clock gate according to register CCM_ANALOG_PFD_480n[PFDn_CLKGATE]. 5 Set LPSPI_PODF according to register CCM_CBCMR. 6 Set TCR[PRESCALE] according to LPSPIx module. 7  Set CCR[SCKDIV] according to LPSPIx module. The customer can get the value LPSPI_CLK according to the above steps
記事全体を表示
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 )
記事全体を表示
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 
記事全体を表示
INTRODUCTION REQUIREMENTS UTILITY USAGE INTEGRATION FUNCTIONAL DEMONSTRATION     1. INTRODUCTION   This document explains how to create an emWin application using as reference the emwin_temperature_control demo included on MCUXpresso SDK, and the emWin Utilities. The custom application for this example, is a Tic-Tac-Toe game, using the emWin GUI as user input, adding the proper logic for game implementation on the emWin generated code, and running on a MIMXRT1060-EVK board. 2. REQUIREMENTS   For the demonstration of this demo, the following material is required: MIMXRT1060-EVK board with the RK043FN02H-CT 4.3" LCD Panel. MCUXpresso IDE v11.0. MCUXpresso SDK v2.6.2 for EVK-MIMXRT1060, including the emWin middleware. Segger emWin 5.38b Libraries and Utilities. emWin 5.30 documentation. 3. UTILITY USAGE   For this demo, just GUIBuilder utility is used, and from this utility, just four widget elements are implemented on the application: Window, Text, Button and Image. At the beginning, one Window is added, configuring its xSize and ySize to 480 x 272, matching with screen's resolution. Over this Window, all the other elements are placed. Each Widget have proprieties that could be added/modified with the right click menu. The overall number of used widgets elements are the following: Three Text widgets, one for the title, other to indicate the next turn, and a third that is empty, because it will be dynamically updated to indicate the winner of the game (or indicating a Draw). Two Image widgets, on where BPM files are loaded and converted to constant arrays, to have the Cross/Circle icons indicating the current turn of the game. Ten Button widgets, one to reinitialize the game, and the other nine to build the 3x3 array used for the game. The complete application layout is shown on the following figure: Then, click on "File->Save" menu, and a file named "WindowDLG.c" file should be created on the same folder on where GUIBuilder utility is located. The "WindowDLG.c" file of this demo, as well as the BMP files for the cross/circle icons could be found on the attachments of this document. Additionally, you could also click on "File->Open" to open the downloaded "WindowDLG.c" file and modify it by your own. 4. INTEGRATION   1) First of all, it is required to import the "emwin_temperature_control" demo included on MCUXpresso SDK for MIMXRT1060-EVK board: Import SDK example(s) -> evkmimxrt1060 -> emwin_examples -> emwin_temperature_control 2) Just after importing the demo, by convenience we have renamed the project and the "source->emwin_temperature_control.c" to "evkmimxrt1060_emwin_tictactoe" and "emwin_tictactoe.c" (right click -> rename). After applying these changes, the demo should be able to be compiled and downloaded without errors and running without issues: 3) Then, open the "WindowDLG.c" file generated by the GUIBuilder and locate the "Defines" section. Copy all of them and replace the Definitions for Widgets IDs already included on the "emwin_tictactoe.c" file. 4) Also remove the "Some dimension defines" and "Colors" sections of the "emwin_tictactoe.c" file, and also the content of "Structures", "Static data". From the same file, also remove the sections for "_aGradient", "_GetSelectedRoom", "_SetFanButtonState", "_cbButton", "_cbButtonFan", "_cbKnob", "_DrawKnob", "_OnRelease". 5) Add the "_acImage_0" and "_acImage_1" arrays from the "WindowDLG.c" file to the "Static data" section of "emwin_tictactoe.c" file. 6) Replace all the elements from the "_aDialogCreate" array from the "emwin_tictactoe.c" with the ones from the "WindowDLG.c" file. 7) Add the function "_GetImageById" and replace the function "_cbDialog" from the "WindowDLG.c" file to the "emwin_tictactoe.c" file. 😎 Until here, the application should be compiled and downloaded without issues, although there is not included any functionality to perform the match. The downloaded layout is shown on the following image: 9) Now, for the implementation of the game itself, the following variables are added to the "Static data" section of "emwin_tictactoe.c" file. "player_turn" indicates who is the current player on move ("X" or "O"). "slots_free" is a counter to know how many remaining slots are free. "winner_player" stores who is the winner, or if the game is a Draw. "slot_status" array is in charge to store the current statusof each slot U8 i, player_turn=0, slots_free=9, winner_player=0; const U32 player_colors[] = {GUI_RED, GUI_BLUE}; enum {SLOT_FREE, SLOT_X, SLOT_O, SLOT_LOCK}; U8 slot_status[] = {SLOT_FREE, SLOT_FREE, SLOT_FREE,                               SLOT_FREE, SLOT_FREE, SLOT_FREE,                               SLOT_FREE, SLOT_FREE, SLOT_FREE}; 10) It was also implemented a function that checks all the possible Slot combinations to define the winner or if the match is a draw. It is the function "CheckWinner" and could be ckeched in the "emwin_tictactoe.c" file of the attachments, that already have all the required changes to have the Tic-Tac-Toe demo running. It is also required adding its function prototype to the "Prototypes" section of "emwin_tictactoe.c" file. 11) Basically, almost all of the game mechanics are defined by the "WM_NOTIFICATION_CLICKED" event of the 9x9 Buttons widgets, so, it is implemented inside the "_cbDialog" function. Below you could find the code for "ID_BUTTON_0"; the red highlights are what change for each Button event:     case ID_BUTTON_0: // Notifications sent by 'Button'       switch(NCode) {       case WM_NOTIFICATION_CLICKED:         // USER START (Optionally insert code for reacting on notification message)         if (slot_status[0] == SLOT_FREE){             hItem = WM_GetDialogItem(pMsg->hWin, ID_BUTTON_0);             BUTTON_SetTextColor(hItem, 0, player_colors[player_turn]);             if (!player_turn){                 BUTTON_SetText(hItem, "X");                 slot_status[0] = SLOT_X;             }             else{                 BUTTON_SetText(hItem, "O");                 slot_status[0] = SLOT_O;             }             player_turn ^= 1;             slots_free--;         }         // USER END         break; 12) For the Restart Button, the implemented logic is in charge of revert back all the Slots status to "Free", erase the content of all the Slots, and also restart the counter of free Slots to nine. 13) After polling all the GUI widgets events, the "CheckWinner" function is called, and then, the winner is defined, indicating it on the "Text_Winner" widget (on the upper-left corner of the screen) that was originally empty. 14) It is also implemented a functionality to directly draw a green rectangle (using emWin Draw functions) around the Cross/Circle icons, depending who is the player on move (also implemented inside the "_cbDialog" function, at the end).   //Draw green rectangle to indicate the player on move   if (!player_turn)   {     GUI_SetColor(GUI_GREEN);     GUI_DrawRoundedFrame(6, 106, 83, 183, 0, 4);     GUI_SetColor(GUI_BLACK);     GUI_DrawRoundedFrame(6, 186, 83, 263, 0, 4);   }   else   {       GUI_SetColor(GUI_GREEN);       GUI_DrawRoundedFrame(6, 186, 83, 263, 0, 4);       GUI_SetColor(GUI_BLACK);       GUI_DrawRoundedFrame(6, 106, 83, 183, 0, 4);   } 15) Finally, a printf with a welcome message was added to "main" function, just before initializing the GUI.     PRINTF("Tic-Tac-Toe demo on i.MXRT1060.\r\n"); 5. FUNCTIONAL DEMONSTRATION   Below are shown captures of the application running, when Cross wins, when Circle wins, and when the match is a draw.  
記事全体を表示
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
記事全体を表示
i.MX RT1050 is the first set of processors in NXP's crossover processor family, combining the high-performance and high level of integration on an applications processors with the ease of use and real-time functionality of a microcontroller. As the first device in a new family, we have had some learning and improvements that have come along the way. There have been some changes and improvements to the processor and also our enablement for the device. This can result in some revisions of hardware and software not being directly compatible with each other out of the box. In particular, some software that has been released for the A0 silicon revision (found on EVK boards) doesn't run on the A1 silicon revision (EVKB boards). In order to minimize the risk of compatibility issues, we recommend that all customers move to SDK 2.3.1 or higher. The SDK 2.3.1 is listed as supporting the EVKB hardware specifically, but the SDK is compatible with the EVK (non-B) hardware. We also recommend that customers using the DAPLink firmware for the OpenSDA debugging circuit built into the EVK/EVKB update to the latest version available on the www.nxp.com/opensda site. The flashloader package has also been updated. Rev 1.1 or later should be used (Flashloader i.MX-RT1050). There are many application notes available for RT1050. Many of these application notes were written based on the original silicon revision and early releases of enablement software. We are in the process of reviewing the published application notes and application note software to prioritize updating them where needed based on the latest enablement and recommendations. If you are in a situation where you need to use SDK 2.3.0 on A1 silicon, the most likely problem area involves some new clock gate bits that were added on the A1 silicon revision. These bits weren't present on the A0 silicon, so SDK 2.3.0 will clear them which disables external memory interfaces. If you comment out  the call to BOARD_BootClockGate() that is in the BOARD_BootClockRUN function (found in the clock_config.c file), that should allow the SDK 2.3.0 software to run on an A1 silicon/EVKB. For more information: MCUXpresso SDK RT1050 migration app note  i.MX RT1050 CMSIS-DAP drag-and-drop programming 
記事全体を表示
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 
記事全体を表示
RT1170 flexSPI1 secondary QSPI flash debug flashdriver 1. Abstract RT1170 has two groups of flexSPI: FlexSPI1, FlexSPI2. Each group of flexSPI is also divided into primary option group and secondary pin group. For specific chip connections, please refer to the following article: https://www.cnblogs.com/henjay724/p/15139381.html NXP provided burning algorithms are started from the flexSPI1 primary group for RT1170. However, in actual use, some customers need to start from the flash of the FlexSPI1 secondary pin group and use the debugger to program the chip. How to prepare the corresponding flash algorithm? Moreover, different debuggers correspond to different program algorithms. This article will take RT1170 flexSPI1 secondary pin group flash boot as an example to explain how to use CMSIS DAP and JLINK as debugger to prepare the corresponding burning algorithm and do debug, as well as the necessary conditions for booting from the secondary port, and provide modified flash algorithm which can be directly used to debug and programming. Here, I would like to thank the customer who are providing the test platform, because the official MIMXRT1170-EVK is an external QSPI flash connected from the FlexSPI1 primary interface and does not provide a secondary group interface. 2 Related prepare To test the FlexSPI1 Secondary pin group, you must first prepare a board that connects the QSPI flash to the Secondary pin, and then configure the FlexSPI_PIN_GROUP_SEL fuse to 1. Since the FlexSPI1 secondary pin group is already connected to the GPIO_AD port, the maximum speed limit is 104Mhz.    Fig 1 2.1 Hardware prepare Fig 2 2.2 fuse FLEXSPI_PIN_GROUP_SEL burn   FLEXSPI_PIN_GROUP_SEL fuse address is 0X9A0[10]: Fig 3 To burn fuse, let the chip to enter serial download mode and connect through MCUBootutility. When connecting, you need to select the FlexSPI1 secondary option, as follows:   Fig 4 Burn fuse result is:   Fig 5 After the fuse is burned successfully, change the board boot mode to internal boot mode, then we can program the app and boot from the flash which is connecting to the FlexSPI1 secondary pin group. 3 Flash algorithm modification and debug test Regarding the flash algorithm of RT1170 FlexSPI1 for secondary pin group, this article mainly focuses on the preparation and testing of MCUxpresso IDE, two debuggers: CMSIS DAP's .cfx, and JLINK's RT-UFL flash algorithm. Here is a brief explanation of the principle of modifying the flash algorithm. It is actually based on the ROM API. Therefore, the main modification point is : option0 =0xc1000005, option1=0x00010000.   Fig 6 3.1 CMSIS DAP .cfx flash algorithm prepare and test The algorithm source code of RT1170 CMSIS DAP can be found in the path of MCUXpressoIDE: C:\nxp\MCUXpressoIDE_11.8.0_1165\ide\Examples\Flashdrivers\NXP\iMXRT\iMXRT117x_FlexSPI_SFDP.zip To the new MCUXpresso IDE 11.10, use this path: C:\NXP\MCUXpressoIDE_11.10.0_3148\ide\LinkServer\Examples\Flashdrivers\NXP\iMXRT\iMXRT117x_FlexSPI_SFDP.zip After importing the algorithm source code, first compile the LPCXFlashDriverLib<Release_SectorHashing> version to get the lib that needs to be called. For iMXRTt117x_FlexSPI_SFDP, select the MIMXRT1170_SFDP_QSPI (FlexSPI1 Port A QSPI) version, and modify Imxrt117xFlexSPI_SFDP, FlashConfig.h: #define CONFIG_OPTION0 0xc1 000005 #define CONFIG_OPTION1 0x00010000     Then compile the lib and compile Imxrt117xFlexSPI_SFDP to generate .cfx,    Fig 7 After build, the .cfx file can be found in project folder: iMXRT117x_FlexSPI_SFDP\builds Rename it: MIMXRT1170_SFDP_QSPI1_Secondary.cfx, and copy it to the IDE installation directory: C:\nxp\MCUXpressoIDE_11.8.0_1165\ide\binaries\Flash    This is done for the later app, you can directly select the corresponding .cfx in the list.    For details on how to compile the algorithm source code to obtain .cfx, you can refer to the article: https://www.cnblogs.com/henjay724/p/14190485.html    After preparing the APP and CMSIS DAP debugger, select compiled .cfx flash algorithm in the app project:   Fig 8 To the app, it should be noted that the serialClkFreq in the FCB is configured as 100MHz, and the LUT commander matches the flash command used. The FCB of W25Q128 is as follows: const flexspi_nor_config_t qspiflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_LoopbackFromDqsPad, .csHoldTime = 3u, .csSetupTime = 3u, // Enable DDR mode, Wordaddassable, Safe configuration, Differential clock .controllerMiscOption = 0x10, .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_4Pads, .serialClkFreq = kFlexSpiSerialClk_100MHz,//kFlexSpiSerialClk_133MHz, .sflashA1Size = 16u * 1024u * 1024u, .lookupTable = { // Read LUTs [0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xEC, RADDR_SDR, FLEXSPI_4PAD, 0x20), [1] = FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06, READ_SDR, FLEXSPI_4PAD, 0x04), // Read Status LUTs [4 * 1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x04), // Write Enable LUTs [4 * 3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06, STOP, FLEXSPI_1PAD, 0x0), // Erase Sector LUTs [4 * 5 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x21, RADDR_SDR, FLEXSPI_1PAD, 0x20), // Erase Block LUTs [4 * 8 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD8, RADDR_SDR, FLEXSPI_1PAD, 0x18), // Pape Program LUTs [4 * 9 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x12, RADDR_SDR, FLEXSPI_1PAD, 0x20), [4 * 9 + 1] = FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), // Erase Chip LUTs [4 * 11 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x60, STOP, FLEXSPI_1PAD, 0x0), }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .ipcmdSerialClkFreq = 0x1, .blockSize = 64u * 1024u, .isUniformBlockSize = false, }; Debug result is:   Fig 9 It can be seen that the modified flexSPI1 secondary group flash algorithm has been successfully called, the downloading is successful, and the app function runs normally. 3.2 JLINK RT-UFL flash algorithm prepare and test Some customers like to use JLINK, but the Segger JLINK driver algorithm source code are not open, so you can use the RT-UFL algorithm, modify it to match the option of RT1170 FlexSPI1 secondray group, and then call it.     For information on the RT-UFL algorithm, please see the following link:    https://www.cnblogs.com/henjay724/p/13951686.html https://www.cnblogs.com/henjay724/p/14942574.html https://www.cnblogs.com/henjay724/p/15430619.html    To the RT UFL modification points: ufl_main.c case kChipId_RT116x: case kChipId_RT117x: uflTargetDesc->flexspiInstance = MIMXRT117X_1st_FLEXSPI_INSTANCE; uflTargetDesc->flexspiBaseAddr = MIMXRT117X_1st_FLEXSPI_BASE; uflTargetDesc->flashBaseAddr = MIMXRT117X_1st_FLEXSPI_AMBA_BASE; uflTargetDesc->configOption.option0.U = 0xc1000005; uflTargetDesc->configOption.option1.U = 0x00010000; Build the code, generate: MIMXRT_FLEXSPI_UV5_UFL_Flexspi1secondary_qspi.FLM,copy To: C:\Program Files\SEGGER\JLINKV768B\Devices\NXP\iMXRT_UFL Please note, to the SEGGER DRIVER path, it determined by your own JLINK driver version install path. In file C:\Program Files\SEGGER\JLINKV768B\JLinkDevices.xml, add the new flash algorithm file calling code: <!------------------------> <Device> <ChipInfo Vendor="NXP" Name="MIMXRT1170_UFL_flexspi1_2nd" WorkRAMAddr="0x20240000" WorkRAMSize="0x00040000" Core="JLINK_CORE_CORTEX_M7" JLinkScriptFile="Devices/NXP/iMXRT_UFL/iMXRT117x_CortexM7.JLinkScript" Aliases="MIMXRT1176xxx8_M7; MIMXRT1176xxxA_M7" /> <FlashBankInfo Name="QSPI Flash" BaseAddr="0x30000000" MaxSize="0x01000000" Loader="Devices/NXP/iMXRT_UFL/MIMXRT_FLEXSPI_UV5_UFL_Flexspi1secondary_qspi.FLM" LoaderType="FLASH_ALGO_TYPE_OPEN" /> </Device> <!------------------------> In the app project, debug configuration,configure the JLINK device as: MIMXRT1170_UFL_flexspi1_2nd   Note: uncheck “reset before running”, otherwise, it will be stopped in ROM after entering the debug mode.   Fig 10 Test the debug result is:   Fig 11 We can see, when use the modified RT-UFL, the JLINK debug also works OK. 4. summarize This article mainly provides the algorithm modification of RT1170 FlexSPI1 secondary group. The algorithm modification of other Flash interfaces and port is similar. The main attention is paid to fuse and algorithm matching. This article provides two modified FlexSPI1 secondary group burning algorithms: MIMXRT1170_SFDP_QSPI1_Secondary.cfx RT-UFL modified MIMXRT_FLEXSPI_UV5_UFL_Flexspi1secondary_qspi.FLM attachments: CMSIS DAP: RT117X FlexSPI1 2nd flashalgo->CMSIS DAP->MIMXRT1170_SFDP_QSPI1_Secondary.cfx JLINK RT-UFL: RT117X FlexSPI1 2nd flashalgo\JLINK RT-UFL Copy JLINK RT-UFL folder to Segger JLINK install path: C:\Program Files\SEGGER\JLINKV768B In this way, the relevant flash algorithm can be called according to the above content.    
記事全体を表示
1. Abstract     When the customer uses the NXP RT board to debug the code, sometimes, the board   suddenly meets debug connect issues when using the IDE and the debugger to download the code. Especially to the customer who is using the NXP RT EVK board with the onboard default CMSIS-DAP debugger. They even suspect the board is broken after trying a lot of times.     The debugger connects issues that normally happen when using the wrong FDCB, the download process is ended abnormally, the wrong flash loader, or the abnormal app code in the flash, .etc.     The reported issue result will be similar to the following pictures: Fig.1 Fig.2     The connect log maybe:       No connection to chip’s debug port       Error: Wire Ack Wait Fault     This document will give some methods to recover the board when meeting the debugger issues with the typical MIMXRT1060-EVK board +MCUXpresso IDE as the test platform. Other platform is also similar, the recovery method also can be used. 2. RT board recovery method     The main method is to change the RT board to the serial download mode, bring the core to a known state, then do the mass erase in IDE or with the MCUXpresso Secure Provisioning Tool(SPT).     First, let the board enter the serial download mode: Fig.3     Enter serial download mode:     1) SW7: 1-OFF,2-OFF,3-OFF,4-ON     2) Power off and power on again, or Press Reset button 2.1 IDE Mass Erase     MCUXpresso IDE, choose the related debugger interface, then choose “erase flash action”.     Here take the MIMXRT1060-EVK on board default debugger CMSIS DAP as an example: Fig.4 Fig.5    After this operation, when the Board is back to the internal boot again, the debugger can download to the flash again. 2.2 SPT Mass Erase     Customers also can use the NXP MCUXpresso Secure Provisioning Tool to do the code download or the mass erase in the serial download mode, this method also can recover the board, in fact, just let the core in the known status.     SPT tool download link: https://www.nxp.com/design/software/development-software/mcuxpresso-secure-provisioning-tool:MCUXPRESSO-SECURE-PROVISIONING     After installing the SPT tool, open it.     1) Create one RT1060 workspace Fig.6     2) Connect the board with USB or the UART     Here, take USB interface as an example. Fig.7 Fig. 8 Fig.9 Fig.10 Fig.11       Until now, the external flash is erased!     In the SPT, the customer also can double check the memory, especially whether the FDCB area is erased or not, just like in the following picture: Fig.12     The customer can go back to the internal boot mode and use the debugger to download the code again.       Internal boot mode:           SW7:1-OFF,2-OFF,3-ON,4-OFF      Press reset or power off and power on again to enter the internal boot mode, then use the debugger to test it again, this is the result: Fig.13     We can see, the MIMXRT1060-EVK debugger interface is recovered! 3. Conclusion     When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core.     So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation.
記事全体を表示