i.MX RT Crossover MCUs Knowledge Base

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

i.MX RT Crossover MCUs Knowledge Base

讨论

排序依据:
Source code: https://github.com/JayHeng/NXP-MCUBootUtility   【v2.0.0】 Features: > 1. Support i.MXRT5xx A0, i.MXRT6xx A0 >    支持i.MXRT5xx A0, i.MXRT6xx A0 > 2. Support i.MXRT1011, i.MXRT117x A0 >    支持i.MXRT1011, i.MXRT117x A0 > 3. [RTyyyy] Support OTFAD encryption secure boot case (SNVS Key, User Key) >     [RTyyyy] 支持基于OTFAD实现的安全加密启动(唯一SNVS key,用户自定义key) > 4. [RTxxx] Support both UART and USB-HID ISP modes >     [RTxxx] 支持UART和USB-HID两种串行编程方式(COM端口/USB设备自动识别) > 5. [RTxxx] Support for converting bare image into bootable image >     [RTxxx] 支持将裸源image文件自动转换成i.MXRT能启动的Bootable image > 6. [RTxxx] Original image can be a bootable image (with FDCB) >     [RTxxx] 用户输入的源程序文件可以包含i.MXRT启动头 (FDCB) > 7. [RTxxx] Support for loading bootable image into FlexSPI/QuadSPI NOR boot device >     [RTxxx] 支持下载Bootable image进主动启动设备 - FlexSPI/QuadSPI NOR接口Flash > 8. [RTxxx] Support development boot case (Unsigned, CRC) >     [RTxxx] 支持用于开发阶段的非安全加密启动(未签名,CRC校验) > 9. Add Execute action support for Flash Programmer >     在通用Flash编程器模式下增加执行(跳转)操作 > 10. [RTyyyy] Can show FlexRAM info in device status >       [RTyyyy] 支持在device status里显示当前FlexRAM配置情况 Improvements: > 1. [RTyyyy] Improve stability of USB connection of i.MXRT105x board >     [RTyyyy] 提高i.MXRT105x目标板USB连接稳定性 > 2. Can write/read RAM via Flash Programmer >    通用Flash编程器里也支持读写RAM > 3. [RTyyyy] Provide Flashloader resident option to adapt to different FlexRAM configurations >     [RTyyyy] 提供Flashloader执行空间选项以适应不同的FlexRAM配置 Bugfixes: > 1. [RTyyyy] Sometimes tool will report error "xx.bat file cannot be found" >     [RTyyyy] 有时候生成证书时会提示bat文件无法找到,导致证书无法生成 > 2. [RTyyyy] Editing mixed eFuse fields is not working as expected >     [RTyyyy] 可视化方式去编辑混合eFuse区域并没有生效 > 3. [RTyyyy] Cannot support 32MB or larger LPSPI NOR/EEPROM device >     [RTyyyy] 无法支持32MB及以上容量的LPSPI NOR/EEPROM设备 > 4. Cannot erase/read the last two pages of boot device via Flash Programmer >    在通用Flash编程器模式下无法擦除/读取外部启动设备的最后两个Page
查看全文
RT1170 camera CSI Y8 format modification 1.Abstract RT1170's CSI can support YUV format. The so-called YUV is divided into three components: Y represents luminance, that is, grayscale value; UV represents chrominance, which describes chroma and saturation. Similar to RGB, YUV is also a color encoding method, which can separate luminance information Y from chroma information UV. If you want to display black and white, you can have no UV information, only Y information, that is, Y800=Y8, and you can also display the complete image. For RT1170 YUV, the official SDK provides demo based on the YUV444 format, but in actual use, some customers need the function of the Y8 format, so how should they configure it based on the existing YUV SDK? From the reference manual of RT1170, you can see the following information: 1.jpg Fig 1 This description can be understood as requiring the Y8 mode, as long as the configuration: CSI_CR20[BINARY_EN]=0 CSI_CR20[BIG_END]=1 However, in reality, with this configuration, the original YUV code cannot display the camera data. So how should the camera's Y8 configuration be done to display black and white images on the LCD? This article will give a detailed explanation. 2. RT1170 CSI Camera Y8 format configuration and testing 2.1 Hardware and software situation Board:MIMXRT1170-EVK REV C4 LCD:  RK055AHD091 Camera:OV5640 Code:SDK_2_15_000_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\csi\mipi_yuv\cm7 IDE: MCUXPresso IDE v11.9.0 2.2 Y8 formation configuration   In fact, for CSI_CR20 configuration, you also need to enable the Histogram function, which is the following register bits: 2.jpg Fig 2 Here, based on the current SDK demo evkmimxrt1170_csi_mipi_yuv_cm7 demo, modify it to the Y8 format, list the modification points, mainly modify the file:csi_mipi_yuv.c (1) static void DEMO_InitPxp(void) Modify: PXP_SetCsc1Mode(DEMO_PXP, kPXP_Csc1YCbCr2RGB); To: PXP_SetCsc1Mode(DEMO_PXP, kPXP_Csc1YUV2RGB); If this item is not modified, LCD will just display the Green color. (2)static void DEMO_InitCamera(void) Before BOARD_InitMipiCsi(); Add the this code: CSI->CR20 |= CSI_CR20_QRCODE_EN_MASK | CSI_CR20_HISTOGRAM_EN_MASK; Here, didn’t configure CSI_CR20[BINARY_EN]=0, as after reseting, this bit is default to 0. If in the practical usage, this bit is modified to 1, then here, need to modify BINARY_EN to 0, it means the format is Y8, not Y1. The reason that can’t display the correct Y8 previously, is caused by the bit HISTOGRAM_EN is not set. (3) static void DEMO_CSI_MIPI_YUV(void) Modify structure psBufferConfig as follows: pxp_ps_buffer_config_t psBufferConfig = { .pixelFormat = kPXP_PsPixelFormatY8, //kPXP_PsPixelFormatYUV1P444, /* Note: This is 32-bit per pixel */ .swapByte = false, .bufferAddrU = 0U, .bufferAddrV = 0U, .pitchBytes = DEMO_CAMERA_WIDTH,//DEMO_CAMERA_WIDTH * DEMO_CAMERA_BUFFER_BPP,// }; Mainly 2 points: .pixelFormat = kPXP_PsPixelFormatY8, .pitchBytes  = DEMO_CAMERA_WIDTH, If you only change the pixel format to Y8, but pitchBytes is not changed to the camera width, the resulting LCD display will be a small strip on the top, instead of the entire LCD screen showing the camera's Y8 format black and white image. So far, all Y8-related modification projects have been completed. Finally, it should be noted that the default SDK LCD display is not the one selected in this article: RK055AHD091. So you need to modify the DEMO_PANEL macro in display_support.h to the following: #define DEMO_PANEL DEMO_PANEL_RK055AHD091 Then, build the project, and download it to the board MIMXRT1170-EVK. 2.3 Test result after modification Below we use the same color picture to test the YUV and Y8 display effects in front of the camera. here are the pictures:  en.jpg the camera format of the picture on the left is YUV444, and the picture on the right is in Y8 format. You can see that the left one is in color, and the right one is in black and white. The black and white Y8 camera data acquisition and LCD display have been successfully completed.
查看全文
RT1050 FlexIO OV7670 with TFT LCDdisplay 1 Abstract Regarding the RT10XX flexIO collecting OV7670 camera data and displaying it on TFT LCD, in fact, the NXP official website has a very good application note AN12686, but the test is based on RT1010 and not EVK. It may be difficult for actual customers to test directly. When the author was supporting customers, I encountered customers who wanted to implement flexIO on RT1050 EVK to collect parallel port OV7670 data and display it on TFT LCD, which is the LCD with SPI interface, so this article gives the specific test results of the finished product, RT1050 flexIO and There are some differences between RT1010 flexIO. RT1010 flexIO has 8 shifters, but RT1050 only has 4 shifters, so some code modifications need to be made and transplanted to RT1050. Since it is going to run on MIMXRT1050-EVKB, you also need to consider the flexIO pins that can be used, modify the EVKB, and manually weld the relevant pins to configure the corresponding camera signals and LCD display signals. This article mainly comes from problems encountered by customers during testing, so it provides specific hardware connections, software code sharing, test finished product results, etc. 2. Software and hardware prepare Since AN12686 has given the principle in great detail, this article aims to give the differences and the specific conditions of working on RT1050-EVKB. 2.1 Hardware configuration The platform is based on MIMXRT1050-EVKB revA1, OV7670 module, 2.4-inch TFT LCD LCD SPI serial touch TFT color screen ILI9321, with a resolution of 240*320.     For the OV7670 module status and pin status, please check the article:    RT1050 CSI OV7670 camera eLCD display The camera module pins are as follows: 1_1.jpg Fig 1    TFT LCD picture: 2.jpg Fig 2 Pin No Signal Description 1 GND Power ground 2 VCC Power 3.3V 3 CLK SPI clock 4 MOSI SPI data 5 RES LCD reset 6 DC LCD data/commander select pin 7 BLK Backlight control switch, backlight is turned on by default, low level turns off the backlight 8 MISO Touch data reading 9 CS1 Display selection pin 10 CS2 Touch selection pin 11 PEN Touch interrupt signal For LCD, this article only uses the display part and does not use the rough mold part. Considering the pin layout of MIMXRT1050-EVKB, the application note flexIO1 is not used here, but FlexIO2 is selected. The actual RT1050-EVKB and OV7670 module and LCD connection pins are given below. The connection between the LCD signal pin and the MCU MIMXRT1050-EVKB RevA1 signal pin is as follows: LCD signal and pin MIMXRT1050-EVKB revA1 signal and pin GND P1 GND J24_7 3.3V VCC P2 3.3V J24_8 CLK P3 GPIO_AD_B1_15(SPI3_CLK) R98 MOSI P4 GPIO_AD_B1_14(SPI3_MOSI) R99 RES P5 GPIO_AD_B0_02(GPIO1_IO02) J24_2 DC P6 GPIO_AD_B1_10(GPIO01_IO26) J23_1 CS1 P9 GPIO_AD_B1_12(GPIO01_IO28) R100   OV7670 signal pin and MCU MIMXRT1050-EVKB RevA1 signal pin connection situation: 0V7670 signal and pin MIMXRT1050-EVKB revA1 signal and pin OV7670_D0 P3 GPIO_B0_05(FLEXIO2_D05) SW5_1 OV7670_D1 P4 GPIO_B0_06(FLEXIO2_D06) SW5.2 OV7670_D2 P5 GPIO_B0_07(FLEXIO2_D07) SW5_3 OV7670_D3 P6 GPIO_B0_08(FLEXIO2_D08) SW5_4 OV7670_D4 P7 GPIO_B0_09(FLEXIO2_D09) SW6_1 OV7670_D5 P8 GPIO_B0_10(FLEXIO2_D10) SW7_1 OV7670_D6 P9 GPIO_B0_11(FLEXIO2_D11) SW6_2 OV7670_D7 P10 GPIO_B0_12(FLEXIO2_D12) SW6_3 XCLK P11 GPIO_B0_13(FLEXIO2_D13) SW7_2 PCLK P12 GPIO_B0_14(FLEXIO2_D14) SW6_4 HREF(HS) P13 GPIO_B0_15(FLEXIO2_D15) R258/R324 VSYNC P14 GPIO_AD_B0_03(GPIO01_03) J24_1 I2C_SDA P15 GPIO_AD_B1_01(I2C1_SDA) J23_5 I2C_SCL P16 GPIO_AD_B1_00(I2C1_SCLK) J23_6 PWDN P1 GPIO_AD_B1_02(GPIO1_IO18) J22_7 RESET P2 GPIO_AD_B1_03(GPIO1_IO19) J22_8 3.3V P18 3.3V J22_7 GND P17 GND J22_8 In order to reduce the impact of the signal, MIMXRT1050-EVKB removes R323, R316, R309, and D6 on the board. The physical connection situation is as follows: 3.jpg Fig 3 2.2 Software configuration Since the flexIO of RT1050 is different from the 8 shifters of RT1010, the DMA configuration needs to be modified. The difference code of flexio_ov7670 is as follows:   static FLEXIO_CAMERA_Type s_FlexioCameraDevice = { .flexioBase = BOARD_CAMERA_FLEXIO_INST, .datPinStartIdx = BOARD_CAMERA_FLEXIO_DATA_PIN_START_INDEX, .pclkPinIdx = BOARD_CAMERA_FLEXIO_PCLK_PIN_INDEX, .hrefPinIdx = BOARD_CAMERA_FLEXIO_HREF_PIN_INDEX, .shifterStartIdx = 0U, .shifterCount = 4, .timerIdx = 0U, }; static void configDMA(void) { uint32_t soff, smod = 0u, size=0u; while(1u << size < DMA_TRSF_SIZE) /* size = log2(DMA_TRSF_SIZE) */ { size++; } if(DMA_TRSF_SIZE == DMA_MINOR_LOOP_SIZE) { soff = 0u; } else { soff = DMA_TRSF_SIZE; while(1u << smod < DMA_MINOR_LOOP_SIZE) /* smod = log2(DMA_MINOR_LOOP_SIZE) */ { smod++; } } /* Configure DMA TCD */ DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].SADDR = FLEXIO_CAMERA_GetRxBufferAddress(&s_FlexioCameraDevice); DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].SOFF = soff; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].ATTR = DMA_ATTR_SMOD(smod) | DMA_ATTR_SSIZE(size) | DMA_ATTR_DMOD(0u) | DMA_ATTR_DSIZE(size); DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].NBYTES_MLNO = 16; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].SLAST = 0u; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].DADDR = (uint32_t)(*pFlexioCameraFrameBuffer); DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].DOFF = 8; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].CITER_ELINKNO = DMA_MAJOR_LOOP_SIZE; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].DLAST_SGA = -OV7670_FRAME_BYTES; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].CSR = 0u; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].CSR |= DMA_CSR_DREQ_MASK; DMA0->TCD[FLEXIO_CAMERA_DMA_CHN].BITER_ELINKNO = DMA_MAJOR_LOOP_SIZE; /* Configure DMA MUX Source */ DMAMUX->CHCFG[FLEXIO_CAMERA_DMA_CHN] = DMAMUX->CHCFG[FLEXIO_CAMERA_DMA_CHN] & (~DMAMUX_CHCFG_SOURCE_MASK) | DMAMUX_CHCFG_SOURCE(FLEXIO_CAMERA_DMA_MUX_SRC); /* Enable DMA channel. */ DMAMUX->CHCFG[FLEXIO_CAMERA_DMA_CHN] |= DMAMUX_CHCFG_ENBL_MASK; } The code structure adopts: the camera uses flexIO mode to collect DMA transfer. After collecting one frame, DMA stores the data into the buffer, and then displays one frame of data uniformly on the LCD. Since there are many configuration codes for flexIO OV7670 and LCD SPI, we will not explain them one by one here. Please check the attached code source code for details. There is a header file of horsepic.h in the code. This file is a 320*240 RGB565 picture of a horse. It is used to test the LCD display separately. Usually after connecting the LCD, you need to test the LCD display separately. You can use a fixed picture to get the display. , here is the method of converting the picture into a C array: First adjust the picture to the LCD resolution size, and then convert it through the LVGL online conversion tool, select CF_RGB565A8, but the RGB565 generated by this format will have 1 more byte each, you can do it yourself After deletion, it can be called by code: https://lvgl.io/tools/imageconverter Display horse picture code: convert8to16(); ILI9341_FillPic(0, 0, OV7670_FRAME_WIDTH-1u, OV7670_FRAME_HEIGHT-1u, (uint16_t *)(horse16)); Display result: 4.jpg Fig 4 3 Test result and summarize    About RT1050-EVKB, use flexIO to collect OV7670 data and display the situation through TFT LCD. Please check the video for the specific code situation. Check the attached source code. You can see from the video results that the flexIO OV7670 camera data can be successfully displayed and the code can successfully run the function.
查看全文
This is the recording of the Crossover Code challenge Webinar presented on December 10.
查看全文
MIMXRT1010 EVK (Chinese Version)  Design Files and Hardwre User's Guide 
查看全文
  1 Background 2 Development Setup   2.1 Software   2.2 Hardware 3 Performance Optimization   3.1 Baseline Performance   3.2 Optimization 1: Compiler Optimization   3.3 Optimization 2: External SDRAM   3.4 Optimization 3: VGLite Acceleration   3.5 Optimization Comparison 4 Conclusion 5 References 1. Background LVGL (Light and Versatile Graphics Library) is a high-performance, low-resource embedded graphics library. Thanks to its robust open-source ecosystem and broad OS compatibility, it supports a wide range of hardware platforms—from low-power ARM Cortex-M microcontrollers (with clock speeds as low as 100 MHz) to high-performance MPUs running Linux—making it a preferred choice in embedded open-source solutions. Many silicon vendors now offer “out-of-the-box” support for LVGL.   NXP provides ready-to-use software and hardware examples for its mainstream platforms—including MCX, i.MX RT, and LPC series—and integrates LVGL examples into the MCUXpresso SDK. These examples include quantified benchmark metrics for various scenarios. However, due to differences in software/hardware configurations and specifications, actual performance may vary significantly and often requires scenario-specific tuning.   This document, based on practical experience with the i.MX RT1170 platform, aims to help NXP users quickly understand and apply appropriate optimization strategies to enhance LVGL application performance. Sam_Gao_0-1764584255540.png      cpu-usage.png   FPS.png 4. Conclusion This document presents a step-by-step optimization of NXP’s official LVGL benchmark example, with quantified improvements in CPU usage, FPS, render time, and flush time. Taking the Widgets demo as an example: CPU usage dropped from 96% → 12% FPS increased from 2 → 59 These optimization techniques—not limited to LVGL—are broadly applicable to system-level performance tuning on i.MX RT platforms.
查看全文
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-341317
查看全文
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 )
查看全文
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.  
查看全文
RT1170 CMSIS DAP+IDE debug based on ECC enabled 1.    Abstract This article aims to solve the problem that after enabling the ECC function, RT1170 cannot be debugged using CMSIS DAP in the three major IDEs (MCUXpresso, IAR, MDK). ECC is enabled by burning the relevant fuses and enabling ROM preloading, which means that the ROM will help initialize the RAM. However, in actual use, it is found that different debuggers have different appearances on the IDE. For example, Segger JLINK can directly implement debugging, but when CMSIS DAP is combined with the three major IDEs, there will be a problem that the code cannot be debugged after being downloaded to RAM. Here, taking MCUXpresso IDE as an example, after burning the ECC-related fuses on the MIMXRT1170-EVK board, if the project is burned to RAM, it can be debugged directly. However, if the project is burned to flash, there will be problems with flashloader: 1.jpg Fig 1    So is this problem caused by the mismatch of flashloader, or does it require additional operations? This article will give a specific solution! 2. RT1170 ECC basic enable and solution 2.1 RT1170 ECC basic    ECC stands for Error Correcting Code, which can detect and correct memory errors. So what ECC does RT1170 have? They are: MECC64, XECC, FlexRAM ECC. MECC64 MECC64 supports 1-bit error correction and 2-bit error detection,to 2bit, it cannot correct errors, just detect the error. MECC64 is mainly protects OCRAM1 and 2 in the chip. MECC1 protects OCRAM1, and MECC2 protects OCRAM2. OCRAM1 ECC and OCRAM2 ECC are used to store ECC check values. If ECC64 is not enabled, it can be used as a normal OCRAM. An 8-bit ECC check value (8 bits) is calculated for every 64 bits of data. The ECC algorithm is Hsiao Hamming. XECC XECC is External ECC controller, which is used to provide ECC function for external storage space. XECC supports 1-bit error correction and 2-bit error detection. External memory includes XECC_FLEXSPI1, XECC_FLEXSPI2, and XECC+SEMC. XECC can calculate a 4-bit ECC check value for every 4 bits. The XECC check value is immediately following the original value. For example, for a 32-bit data, a 4-bit ECC check value is generated for every 4 bits. 32-bit original data needs to generate 32-bit ECC check data, which requires a total of 64 bits of space. Algorithm: Hsiao Hamming algorithm FlexRAM ECC FlexRAM ECC is used to protect the ITCM, DTCM and OCRAM of FlexRAM. It supports 1-bit error correction and 2-bit error detection. A 7/8-bit ECC check value is calculated for every 4 bytes of DTCM or 8 bytes of ITCM/OCRAM, and the ECC check value is placed in the ECC RAM. 2.2 RT1170 ECC enable    The method used in this article to enable ECC is to directly enable the relevant fuse bit. - MECC_ENABLE (0x840[2]) = 1 - XECC_ENABLE (0x840[3]) = 1 - ROM preloading (0x950[0]) = 1 - FLEXRAMECC_ENABLE (0x840[15]) = 1 For more software configuration information, please refer to the official application note AN13204: https://www.nxp.com/docs/en/application-note/AN13204.pdf The following is the situation after burning the relevant fuses. Burning the fuses can enter the serial download mode and use MCUbootutility to burn: 2.jpg Fig 2 2.3 ECC debug issue solution methods After testing in many ways, such as initializing RAM in the script, because of the characteristics of ECC, RAM needs to be flashed once, but it is found that the general code speed of flashing RAM directly is too slow, resulting in download timeout problems, and then it is changed to use DMA to move data to RAM to ensure that RAM is flashed once, but the result is still not good, so flashing RAM is not the fundamental way to solve the debug problem. Finally, by chance, ECC is turned off in the connection script first, especially FlexRAM ECC, and it is found that the burning algorithm can be called to perform external flash operations at this time. In this way, the code can be successfully downloaded, and then reset to let the ROM turn on the ECC function by itself. The reason why the RAM project can work is that the process of downloading RAM is a process of flashing RAM, so the RAM code can work directly. For the debugger burning and simulation of Flash code, it is still necessary to turn off the ECC module first, mainly the FlexRAM ECC module. Of course, for the sake of insurance, we can directly turn off all MECC and FlexRAM ECC register enable bits, let the flashloader work first, and directly control the register address: 0x40014100=0;0x40018100=0;0x40028108=0; 0x40014100 PIPE_ECC_EN[ECC_EN], control MECC1 0x40018100 PIPE_ECC_EN[ECC_EN], control MECC2 3.jpg Fig 3 0x40028108 FLEXRAM_CTRL ECC_EN, control FlexRAM ECC 4.jpg Fig 4 According to the actual test situation, disabling FlexRAM ECC is effective. The problem should be that the area where the flashloader used is stored is the DTCM of FlexRAM. Check the area of ​​the Flashloader of the burning algorithm as follows: 5.jpg Fig 5 3  Three major IDEs script and testing Here, share the three IDE(MCUXPresso, IAR, MDK)+CMSIS DAP+ECC related modified script file. 3.1 MCUXpresso IDE Script path in the IDE: C:\nxp\MCUXpressoIDE_11.9.0_2144\ide\LinkServer\binaries\Scripts Prepare one script file T1170_connect_M7_wake_M4_ecc.scp,copy it to the above path, and the content is: 1 REM ====================================== 2 REM Copyright 2020-2024 NXP 3 REM All rights reserved. 4 REM SPDX-License-Identifier: BSD-3-Clause 5 REM ====================================== 100 REM ======================================================================= 110 REM RT1170_connect_M7_wake_M4.scp 150 REM ======================================================================= 160 PRINT "RT1170 Connect M7 and Wake M4 Script" 170 REM ======================================================================= 180 REM Uncomment ProbeList for standalone script use (outside the stub) 190 REM ======================================================================= 200 REM ProbeList 210 p% = ProbeFirstFound 220 REM ProbeOpenByIndex p% 230 WireSwdConnect p% 240 SelectProbeCore p% 0 250 CMInitApDp this 252 REM ======================================================================= 254 REM Disable ECC 256 GOSUB 1500 260 REM ======================================================================= 270 REM The M4 AP is not visible while the core is held in reset 280 REM Prepare a spin code in RAM and wake up / reset the M4 to it 290 REM This serves two purposes: 300 REM - enables the M4 AP, required for debug visibility 310 REM - prevents M4 code from interfering with flash programming on M7 320 REM ======================================================================= 330 REM Prepare spin code 340 GOSUB 1000 350 REM ======================================================================= 360 PRINT "Setting M4 clock" 370 REM Set m4_clk_root to OSC_RC_400M / 2: CLOCK_ROOT1 = mux(2), div(1) 380 Poke32 this 0x40CC0080 0x201 390 PRINT "Resetting M4 core" 400 REM Save current reset SRMR and prevent M4 SW reset affecting the system 410 s% = Peek32 this 0x40C04004 420 Poke32 this 0x40C04004 0x00000C00 430 Poke32 this 0x40C04284 0x1 440 Poke32 this 0x40C04004 s% 450 REM ======================================================================= 460 REM Release M4 if needed 500 s% = Peek32 this 0x40c04000 510 IF s% & 1 == 1 THEN GOTO 560 520 PRINT "Releasing M4" 530 s% = s% | 1 540 Poke32 this 0x40c04000 s% 550 REM ======================================================================= 560 PRINT "View cores on the DAP AP" 570 WireSwdConnect p% 580 CoreList p% 590 SelectProbeCore p% 0 600 REM ======================================================================= 610 REM Potentially FlexRAM might need to be set to ensure TCMs are available 620 REM Uncomment next line if needed 630 REM GOSUB 800 640 REM ======================================================================= 650 REM Finished - 0 to select the M7, 1 to select M4 660 d% = 0 670 REM ======================================================================= 680 REM Setup VTOR in preparation for VECTRESET 690 GOSUB 1300 700 REM ======================================================================= 710 END 800 REM ====================== SUB: Configure FlexRAM ======================== 810 PRINT "Configuring FlexRAM for 256KB I-TCM, 256KB D-TCM, 0KB OCRAM" 820 REM FlexRAM TCM_CTRL - force RAM clocking ON and set fast mode = b100 830 Poke32 this 0x40028000 0x4 840 REM IOMUXC_GPR17/18 FlexRAM 32KB banks allocation - I(b11), D(b10), OC(b01) 850 Poke32 this 0x400E4044 0x0000AAFF 860 Poke32 this 0x400E4048 0x0000AAFF 870 REM IOMUXC_GPR16 Enable FLEXRAM_BANK_CFG in GPR16/17 880 s% = Peek32 this 0x400E4040 890 s% = s% | 4 900 Poke32 this 0x400E4040 s% 910 RETURN 1000 REM ==================== SUB: Set up M4 spin code ======================== 1010 REM Setup some spin code into an area of D-TCM (0x2021FF00) 1020 REM Condensed vector table format taking up 2 words of memory: 1030 REM - x00: SP (dummy), two back-to-back branch-to-self opcodes (b 0) 1040 REM - x04: PC - points to address x00 (+1 Thumb) 1050 PRINT "Setting M4 spin code" 1060 Poke32 this 0x2021FF00 0xE7FEE7FE 1070 Poke32 this 0x2021FF04 0x2021FF01 1080 REM Set top/bottom 16 bits of RAM address into CM4 VTOR iomuxc_lpsr_GPR0/1 1090 Poke32 this 0x40C0C000 0xFF00 1100 Poke32 this 0x40C0C004 0x2021 1110 RETURN 1300 REM ==================== SUB: Setup CM7 VTOR ============================= 1310 REM Upon VECTRESET, VTOR is loaded with the value from this register. 1320 REM If the address is invalid, a hard fault occurs after VECTRESET. 1330 REM These registers are set in preparation for a pre-flash driver VECTRESET 1340 REM requested by the stub. 1350 REM BootROM VTOR 1360 s% = 0x210000 1370 REM Set addr >> 7 into CM7 VTOR iomuxc_lpsr_GPR26 (RevB) or 0x400e404c (Rev A) 1380 v% = Peek32 this 0x40C84800 1390 IF v% & 0x00FFFFF0 == 0x1170A0 Then GOTO 1420 1400 Poke32 this 0x40C0C068 s% >> 7 1410 GOTO 1430 1420 Poke32 this 0x400E404C s% >> 7 1430 RETURN 1440 REM ======================================================================= 1500 REM ====================== SUB: Disable M7 TCM ECC and OCRAM ECC ========== 1510 REM FlexRAM_CTRL - disable TCM ECC and OCRAM ECC 1520 Poke32 this 0x40028108 0x00000000 1530 REM MECC1/2 PIPE_ECC_EN - disable ECC 1540 Poke32 this 0x40014100 0x00000000 1550 Poke32 this 0x40018100 0x00000000 1560 RETURN  MCUXpresso debug configuration,in the “connect script” item, select the above prepared .scp file: 6.jpg Fig 6 The result after Debug is: 7.jpg Fig 7 We can see, the code downloading and debugging all works now. 3.2 IAR IDE ECC script and testing IAR project script path: \MIMXRT1170-EVK-hello_world_demo_cm7\hello_world_demo_cm7\evkmimxrt1170 Prepare the file: evkmimxrt1170_connect_cm7_disableECC.mac The content is:   /* * Copyright 2019-2021 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ __var rev; initSysPll2() { __var t; // ANADIG_PLL_PLL_528_CTRL t = __readMemory32(0x40C84240, "Memory"); if (t & 0x800000) { // SysPll2 has been initialized t &= ~0x40000000; __writeMemory32(t, 0x40C84240, "Memory"); return; } t = __readMemory32(0x40C84270, "Memory"); t |= 0x80808080; __writeMemory32(t, 0x40C84270, "Memory"); t = __readMemory32(0x40C84240, "Memory"); t &= ~(0x802000); t |= 0x40000000; __writeMemory32(t, 0x40C84240, "Memory"); // ANADIG_PLL_PLL_528_MFN __writeMemory32(0, 0x40C84280, "Memory"); // ANADIG_PLL_PLL_528_MFI __writeMemory32(22, 0x40C84290, "Memory"); // ANADIG_PLL_PLL_528_MFD __writeMemory32(0x0FFFFFFF, 0x40C842A0, "Memory"); // ANADIG_PLL_PLL_528_CTRL __writeMemory32(0x40000008, 0x40C84240, "Memory"); __delay(30); // ANADIG_PLL_PLL_528_CTRL t = __readMemory32(0x40C84240, "Memory"); t |= 0x800000 | 0x800; __writeMemory32(t, 0x40C84240, "Memory"); __delay(250); t = __readMemory32(0x40C84240, "Memory"); t &= ~0x800; __writeMemory32(t, 0x40C84240, "Memory"); do { t = __readMemory32(0x40C84240, "Memory"); } while ((t & 0x20000000) == 0); t |= 0x2000; __writeMemory32(t, 0x40C84240, "Memory"); t &= ~0x40000000; __writeMemory32(t, 0x40C84240, "Memory"); } initSysPll2Pfd1() { __var t, stable; t = __readMemory32(0x40C84270, "Memory"); if (((t & 0x8000) != 0) || (((t & 0x3F00) >> 😎 != 16)) { stable = t & 0x4000; t |= 0x8000; __writeMemory32(t, 0x40C84270, "Memory"); t = __readMemory32(0x40C84270, "Memory"); t &= ~0x3F00; t |= 16 << 8; __writeMemory32(t, 0x40C84270, "Memory"); t = __readMemory32(0x40C84250, "Memory"); t ^= 0x4; __writeMemory32(t, 0x40C84250, "Memory"); t = __readMemory32(0x40C84270, "Memory"); t &= ~0x8000; __writeMemory32(t, 0x40C84270, "Memory"); do { t = __readMemory32(0x40C84270, "Memory") & 0x4000; } while (t == stable); } else { t &= ~0x8000; __writeMemory32(t, 0x40C84270, "Memory"); } } SDRAM_WaitIpCmdDone() { __var reg; do { reg = __readMemory32(0x400D403C, "Memory"); __delay(10); }while((reg & 0x3) == 0); __writeMemory32(0x00000003, 0x400D403C, "Memory"); // clear IPCMDERR and IPCMDDONE bits } setSemcClock() { initSysPll2(); initSysPll2Pfd1(); // Set SEMC root clock to use sys pll2 pfd1 divided by 3: 198Mhz __writeMemory32(0x602, 0x40cc0200, "Memory"); } initSDRAM() { // Config IOMUX __writeMemory32(0x00000000, 0x400E8010, "Memory"); __writeMemory32(0x00000000, 0x400E8014, "Memory"); __writeMemory32(0x00000000, 0x400E8018, "Memory"); __writeMemory32(0x00000000, 0x400E801C, "Memory"); __writeMemory32(0x00000000, 0x400E8020, "Memory"); __writeMemory32(0x00000000, 0x400E8024, "Memory"); __writeMemory32(0x00000000, 0x400E8028, "Memory"); __writeMemory32(0x00000000, 0x400E802C, "Memory"); __writeMemory32(0x00000000, 0x400E8030, "Memory"); __writeMemory32(0x00000000, 0x400E8034, "Memory"); __writeMemory32(0x00000000, 0x400E8038, "Memory"); __writeMemory32(0x00000000, 0x400E803C, "Memory"); __writeMemory32(0x00000000, 0x400E8040, "Memory"); __writeMemory32(0x00000000, 0x400E8044, "Memory"); __writeMemory32(0x00000000, 0x400E8048, "Memory"); __writeMemory32(0x00000000, 0x400E804C, "Memory"); __writeMemory32(0x00000000, 0x400E8050, "Memory"); __writeMemory32(0x00000000, 0x400E8054, "Memory"); __writeMemory32(0x00000000, 0x400E8058, "Memory"); __writeMemory32(0x00000000, 0x400E805C, "Memory"); __writeMemory32(0x00000000, 0x400E8060, "Memory"); __writeMemory32(0x00000000, 0x400E8064, "Memory"); __writeMemory32(0x00000000, 0x400E8068, "Memory"); __writeMemory32(0x00000000, 0x400E806C, "Memory"); __writeMemory32(0x00000000, 0x400E8070, "Memory"); __writeMemory32(0x00000000, 0x400E8074, "Memory"); __writeMemory32(0x00000000, 0x400E8078, "Memory"); __writeMemory32(0x00000000, 0x400E807C, "Memory"); __writeMemory32(0x00000000, 0x400E8080, "Memory"); __writeMemory32(0x00000000, 0x400E8084, "Memory"); __writeMemory32(0x00000000, 0x400E8088, "Memory"); __writeMemory32(0x00000000, 0x400E808C, "Memory"); __writeMemory32(0x00000000, 0x400E8090, "Memory"); __writeMemory32(0x00000000, 0x400E8094, "Memory"); __writeMemory32(0x00000000, 0x400E8098, "Memory"); __writeMemory32(0x00000000, 0x400E809C, "Memory"); __writeMemory32(0x00000000, 0x400E80A0, "Memory"); __writeMemory32(0x00000000, 0x400E80A4, "Memory"); __writeMemory32(0x00000000, 0x400E80A8, "Memory"); __writeMemory32(0x00000010, 0x400E80AC, "Memory"); // EMC_39, DQS PIN, enable SION __writeMemory32(0x00000000, 0x400E80B8, "Memory"); __writeMemory32(0x00000000, 0x400E80BC, "Memory"); __writeMemory32(0x00000000, 0x400E80C0, "Memory"); __writeMemory32(0x00000000, 0x400E80C4, "Memory"); __writeMemory32(0x00000000, 0x400E80C8, "Memory"); __writeMemory32(0x00000000, 0x400E80CC, "Memory"); __writeMemory32(0x00000000, 0x400E80D0, "Memory"); __writeMemory32(0x00000000, 0x400E80D4, "Memory"); __writeMemory32(0x00000000, 0x400E80D8, "Memory"); __writeMemory32(0x00000000, 0x400E80DC, "Memory"); __writeMemory32(0x00000000, 0x400E80E0, "Memory"); __writeMemory32(0x00000000, 0x400E80E4, "Memory"); __writeMemory32(0x00000000, 0x400E80E8, "Memory"); __writeMemory32(0x00000000, 0x400E80EC, "Memory"); __writeMemory32(0x00000000, 0x400E80F0, "Memory"); __writeMemory32(0x00000000, 0x400E80F4, "Memory"); __writeMemory32(0x00000000, 0x400E80F8, "Memory"); __writeMemory32(0x00000000, 0x400E80FC, "Memory"); // PAD ctrl // PDRV = 1b (normal); PULL = 10b (PD) __writeMemory32(0x00000008, 0x400E8254, "Memory"); __writeMemory32(0x00000008, 0x400E8258, "Memory"); __writeMemory32(0x00000008, 0x400E825C, "Memory"); __writeMemory32(0x00000008, 0x400E8260, "Memory"); __writeMemory32(0x00000008, 0x400E8264, "Memory"); __writeMemory32(0x00000008, 0x400E8268, "Memory"); __writeMemory32(0x00000008, 0x400E826C, "Memory"); __writeMemory32(0x00000008, 0x400E8270, "Memory"); __writeMemory32(0x00000008, 0x400E8274, "Memory"); __writeMemory32(0x00000008, 0x400E8278, "Memory"); __writeMemory32(0x00000008, 0x400E827C, "Memory"); __writeMemory32(0x00000008, 0x400E8280, "Memory"); __writeMemory32(0x00000008, 0x400E8284, "Memory"); __writeMemory32(0x00000008, 0x400E8288, "Memory"); __writeMemory32(0x00000008, 0x400E828C, "Memory"); __writeMemory32(0x00000008, 0x400E8290, "Memory"); __writeMemory32(0x00000008, 0x400E8294, "Memory"); __writeMemory32(0x00000008, 0x400E8298, "Memory"); __writeMemory32(0x00000008, 0x400E829C, "Memory"); __writeMemory32(0x00000008, 0x400E82A0, "Memory"); __writeMemory32(0x00000008, 0x400E82A4, "Memory"); __writeMemory32(0x00000008, 0x400E82A8, "Memory"); __writeMemory32(0x00000008, 0x400E82AC, "Memory"); __writeMemory32(0x00000008, 0x400E82B0, "Memory"); __writeMemory32(0x00000008, 0x400E82B4, "Memory"); __writeMemory32(0x00000008, 0x400E82B8, "Memory"); __writeMemory32(0x00000008, 0x400E82BC, "Memory"); __writeMemory32(0x00000008, 0x400E82C0, "Memory"); __writeMemory32(0x00000008, 0x400E82C4, "Memory"); __writeMemory32(0x00000008, 0x400E82C8, "Memory"); __writeMemory32(0x00000008, 0x400E82CC, "Memory"); __writeMemory32(0x00000008, 0x400E82D0, "Memory"); __writeMemory32(0x00000008, 0x400E82D4, "Memory"); __writeMemory32(0x00000008, 0x400E82D8, "Memory"); __writeMemory32(0x00000008, 0x400E82DC, "Memory"); __writeMemory32(0x00000008, 0x400E82E0, "Memory"); __writeMemory32(0x00000008, 0x400E82E4, "Memory"); __writeMemory32(0x00000008, 0x400E82E8, "Memory"); __writeMemory32(0x00000008, 0x400E82EC, "Memory"); __writeMemory32(0x00000008, 0x400E82F0, "Memory"); __writeMemory32(0x00000008, 0x400E82FC, "Memory"); __writeMemory32(0x00000008, 0x400E8300, "Memory"); __writeMemory32(0x00000008, 0x400E8304, "Memory"); __writeMemory32(0x00000008, 0x400E8308, "Memory"); __writeMemory32(0x00000008, 0x400E830C, "Memory"); __writeMemory32(0x00000008, 0x400E8310, "Memory"); __writeMemory32(0x00000008, 0x400E8314, "Memory"); __writeMemory32(0x00000008, 0x400E8318, "Memory"); __writeMemory32(0x00000008, 0x400E831C, "Memory"); __writeMemory32(0x00000008, 0x400E8320, "Memory"); __writeMemory32(0x00000008, 0x400E8324, "Memory"); __writeMemory32(0x00000008, 0x400E8328, "Memory"); __writeMemory32(0x00000008, 0x400E832C, "Memory"); __writeMemory32(0x00000008, 0x400E8330, "Memory"); __writeMemory32(0x00000008, 0x400E8334, "Memory"); __writeMemory32(0x00000008, 0x400E8338, "Memory"); __writeMemory32(0x00000008, 0x400E833C, "Memory"); __writeMemory32(0x00000008, 0x400E8340, "Memory"); // Config SDR Controller Registers/ __writeMemory32(0x10000004, 0x400d4000, "Memory"); // MCR __writeMemory32(0x00000081, 0x400d4008, "Memory"); // BMCR0 __writeMemory32(0x00000081, 0x400d400C, "Memory"); // BMCR1 __writeMemory32(0x8000001D, 0x400d4010, "Memory"); // BR0, 64MB __writeMemory32(0x00000F32, 0x400d4040, "Memory"); // SDRAMCR0, 32bit __writeMemory32(0x00772A22, 0x400d4044, "Memory"); // SDRAMCR1 __writeMemory32(0x00010A0D, 0x400d4048, "Memory"); // SDRAMCR2 __writeMemory32(0x21210408, 0x400d404C, "Memory"); // SDRAMCR3 __writeMemory32(0x80000000, 0x400d4090, "Memory"); // IPCR0 __writeMemory32(0x00000002, 0x400d4094, "Memory"); // IPCR1 __writeMemory32(0x00000000, 0x400d4098, "Memory"); // IPCR2 __writeMemory32(0xA55A000F, 0x400d409C, "Memory"); // IPCMD, SD_CC_IPREA SDRAM_WaitIpCmdDone(); __writeMemory32(0xA55A000C, 0x400d409C, "Memory"); // SD_CC_IAF SDRAM_WaitIpCmdDone(); __writeMemory32(0xA55A000C, 0x400d409C, "Memory"); // SD_CC_IAF SDRAM_WaitIpCmdDone(); __writeMemory32(0x00000033, 0x400d40A0, "Memory"); // IPTXDAT __writeMemory32(0xA55A000A, 0x400d409C, "Memory"); // SD_CC_IMS SDRAM_WaitIpCmdDone(); __writeMemory32(0x00000017, 0x400d4150, "Memory"); // DCCR __writeMemory32(0x21210409, 0x400d404C, "Memory"); // enable sdram self refresh after initialization done. __message "SDRAM init done"; } restoreFlexRAM() { __var base; __var value; base = 0x400E4000; value = __readMemory32(base + 0x44, "Memory"); value &= ~(0xFFFF); value |= 0xFFAA; __writeMemory32(value, base + 0x44, "Memory"); value = __readMemory32(base + 0x48, "Memory"); value &= ~(0xFFFF); value |= 0xFFAA; __writeMemory32(value, base + 0x48, "Memory"); value = __readMemory32(base + 0x40, "Memory"); value &= ~(0xFF << 8); value |= 0x7 | (0xaa << 8); __writeMemory32(value, base + 0x40, "Memory"); __message "FlexRAM configuration is restored"; } clearECC() { __writeMemory32(0x00000000, 0x40014100, "Memory"); __writeMemory32(0x00000000, 0x40018100, "Memory"); __writeMemory32(0x00000000, 0x40028108, "Memory"); } execUserPreload() { restoreFlexRAM(); setSemcClock(); initSDRAM(); clearECC(); }   Mainly add the above red code, which is used to clear the MECC and FlexRAM ECC enable bit. Add the modified mac script: 8.jpg Fig 8 Debug result is: 9.jpg Fig 9 We can see, in the IAR also can do the code downloading and debugging, the script also works for the ECC enabled board. 3.3 MDK IDE ECC script and test result   Open the project path: \MIMXRT1170-EVK-hello_world_demo_cm7\hello_world_demo_cm7\evkmimxrt1170 Prepare the file:evkmimxrt1170_flexspi_nor_sdram.ini, the content is:   /* * Copyright 2019-2021 NXP * All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause */ FUNC void restoreFlexRAM(void) { unsigned int value; value = _RDWORD(0x400E4044); value &= ~(0xFFFF); value |= 0xFFAA; _WDWORD(0x400E4044, value); value = _RDWORD(0x400E4048); value &= ~(0xFFFF); value |= 0xFFAA; _WDWORD(0x400E4048, value); value = _RDWORD(0x400E4040); value &= ~(0xFF << 8); value |= 0x7 | (0xAA << 8); _WDWORD(0x400E4040, value); } FUNC void SDRAM_WaitIpCmdDone(void) { unsigned long reg; do { reg = _RDWORD(0x400D403C); }while((reg & 0x3) == 0); _WDWORD(0x400D403C,0x00000003); // clear IPCMDERR and IPCMDDONE bits } FUNC void EnableOSC400M(void) { unsigned int reg; // CTRL1: power down reg = _RDWORD(0x40C84050); reg &= ~0x1; _WDWORD(0x40C84050,reg); // CTRL2: enable clock reg = _RDWORD(0x40C84060); reg |= 0x1; _WDWORD(0x40C84060,reg); } FUNC void EnableOSC24M(void) { unsigned int reg; reg = _RDWORD(0x40C84020); if(0 == (reg & 0x10)) { reg = 0x14; // OSC_EN and LP_EN _WDWORD(0x40C84020,reg); reg = _RDWORD(0x40C84020); while (0 == (reg & 0x80000000)); } } FUNC void EnablePllLdo(void) { unsigned int reg; // CTRL_AI_CTRL _WDWORD(0x40C84820,0x00000000); // CTRL_AI_WDATA _WDWORD(0x40C84830,0x00000105); // PMU_LDO_PLL reg = _RDWORD(0x40C84500); reg |= 0x10000; _WDWORD(0x40C84500,reg); _Sleep_(100); // PMU_POWER_DETECT_CTRL _WDWORD(0x40C84580,0x00000100); _Sleep_(1); // PMU_REF_CTRL _WDWORD(0x40C84570,0x00000010); } FUNC void InitSysPll2Pfd1(void) { unsigned int reg; unsigned int stable; // ANADIG_PLL_PLL_528_PFD reg = _RDWORD(0x40C84270); if (((reg & 0x8000) != 0) || (((reg & 0x3F00) >> 😎 != 16)) { stable = reg & 0x4000; reg |= 0x8000; _WDWORD(0x40C84270,reg); reg = _RDWORD(0x40C84270); reg &= ~0x3F00; reg |= 16 << 8; _WDWORD(0x40C84270,reg); reg = _RDWORD(0x40C84250); reg ^= 0x4; _WDWORD(0x40C84250,reg); reg = _RDWORD(0x40C84270); reg &= ~0x8000; _WDWORD(0x40C84270,reg); do { reg = _RDWORD(0x40C84270) & 0x4000; } while (reg == stable); } else { //syspll2 pfd1 has been initialized already reg &= ~0x8000; _WDWORD(0x40C84270,reg); } } FUNC void InitSysPll2(void) { unsigned int reg; // ANADIG_PLL_PLL_528_CTRL reg = _RDWORD(0x40C84240); if (reg & 0x800000) { // SysPll2 has been initialized reg &= ~0x40000000; _WDWORD(0x40C84240, reg); return; } reg = _RDWORD(0x40C84270); reg |= 0x80808080; _WDWORD(0x40C84270, reg); reg = _RDWORD(0x40C84240); reg &= ~(0x802000); reg |= 0x40000000; _WDWORD(0x40C84240, reg); // ANADIG_PLL_PLL_528_MFN _WDWORD(0x40C84280, 0); // ANADIG_PLL_PLL_528_MFI _WDWORD(0x40C84290, 22); // ANADIG_PLL_PLL_528_MFD _WDWORD(0x40C842A0, 0x0FFFFFFF); // ANADIG_PLL_PLL_528_CTRL _WDWORD(0x40C84240, 0x8 | 0x40000000); _Sleep_(30); // ANADIG_PLL_PLL_528_CTRL reg = _RDWORD(0x40C84240); reg |= 0x800000 | 0x800; _WDWORD(0x40C84240, reg); _Sleep_(250); reg = _RDWORD(0x40C84240); reg &= ~0x800; _WDWORD(0x40C84240, reg); do { reg = _RDWORD(0x40C84240); } while ((reg & 0x20000000) == 0); reg |= 0x2000; _WDWORD(0x40C84240, reg); reg &= ~0x40000000; _WDWORD(0x40C84240, reg); } FUNC void SetSemcClock(void) { //EnableOSC400M(); EnablePllLdo(); InitSysPll2(); InitSysPll2Pfd1(); // Set SEMC root clock // Use sys pll2 pfd1 divided by 3: 198Mhz _WDWORD(0x40CC0200,0x00000602); } FUNC void _clock_init(void) { SetSemcClock(); } FUNC void _sdr_Init(void) { // Config IOMUX _WDWORD(0x400E8010, 0x00000000); _WDWORD(0x400E8014, 0x00000000); _WDWORD(0x400E8018, 0x00000000); _WDWORD(0x400E801C, 0x00000000); _WDWORD(0x400E8020, 0x00000000); _WDWORD(0x400E8024, 0x00000000); _WDWORD(0x400E8028, 0x00000000); _WDWORD(0x400E802C, 0x00000000); _WDWORD(0x400E8030, 0x00000000); _WDWORD(0x400E8034, 0x00000000); _WDWORD(0x400E8038, 0x00000000); _WDWORD(0x400E803C, 0x00000000); _WDWORD(0x400E8040, 0x00000000); _WDWORD(0x400E8044, 0x00000000); _WDWORD(0x400E8048, 0x00000000); _WDWORD(0x400E804C, 0x00000000); _WDWORD(0x400E8050, 0x00000000); _WDWORD(0x400E8054, 0x00000000); _WDWORD(0x400E8058, 0x00000000); _WDWORD(0x400E805C, 0x00000000); _WDWORD(0x400E8060, 0x00000000); _WDWORD(0x400E8064, 0x00000000); _WDWORD(0x400E8068, 0x00000000); _WDWORD(0x400E806C, 0x00000000); _WDWORD(0x400E8070, 0x00000000); _WDWORD(0x400E8074, 0x00000000); _WDWORD(0x400E8078, 0x00000000); _WDWORD(0x400E807C, 0x00000000); _WDWORD(0x400E8080, 0x00000000); _WDWORD(0x400E8084, 0x00000000); _WDWORD(0x400E8088, 0x00000000); _WDWORD(0x400E808C, 0x00000000); _WDWORD(0x400E8090, 0x00000000); _WDWORD(0x400E8094, 0x00000000); _WDWORD(0x400E8098, 0x00000000); _WDWORD(0x400E809C, 0x00000000); _WDWORD(0x400E80A0, 0x00000000); _WDWORD(0x400E80A4, 0x00000000); _WDWORD(0x400E80A8, 0x00000000); _WDWORD(0x400E80AC, 0x00000010); // EMC_39, DQS PIN, enable SION _WDWORD(0x400E80B8, 0x00000000); _WDWORD(0x400E80BC, 0x00000000); _WDWORD(0x400E80C0, 0x00000000); _WDWORD(0x400E80C4, 0x00000000); _WDWORD(0x400E80C8, 0x00000000); _WDWORD(0x400E80CC, 0x00000000); _WDWORD(0x400E80D0, 0x00000000); _WDWORD(0x400E80D4, 0x00000000); _WDWORD(0x400E80D8, 0x00000000); _WDWORD(0x400E80DC, 0x00000000); _WDWORD(0x400E80E0, 0x00000000); _WDWORD(0x400E80E4, 0x00000000); _WDWORD(0x400E80E8, 0x00000000); _WDWORD(0x400E80EC, 0x00000000); _WDWORD(0x400E80F0, 0x00000000); _WDWORD(0x400E80F4, 0x00000000); _WDWORD(0x400E80F8, 0x00000000); _WDWORD(0x400E80FC, 0x00000000); // PAD ctrl // PDRV = 1b (normal); PULL = 10b (PD) _WDWORD(0x400E8254, 0x00000008); _WDWORD(0x400E8258, 0x00000008); _WDWORD(0x400E825C, 0x00000008); _WDWORD(0x400E8260, 0x00000008); _WDWORD(0x400E8264, 0x00000008); _WDWORD(0x400E8268, 0x00000008); _WDWORD(0x400E826C, 0x00000008); _WDWORD(0x400E8270, 0x00000008); _WDWORD(0x400E8274, 0x00000008); _WDWORD(0x400E8278, 0x00000008); _WDWORD(0x400E827C, 0x00000008); _WDWORD(0x400E8280, 0x00000008); _WDWORD(0x400E8284, 0x00000008); _WDWORD(0x400E8288, 0x00000008); _WDWORD(0x400E828C, 0x00000008); _WDWORD(0x400E8290, 0x00000008); _WDWORD(0x400E8294, 0x00000008); _WDWORD(0x400E8298, 0x00000008); _WDWORD(0x400E829C, 0x00000008); _WDWORD(0x400E82A0, 0x00000008); _WDWORD(0x400E82A4, 0x00000008); _WDWORD(0x400E82A8, 0x00000008); _WDWORD(0x400E82AC, 0x00000008); _WDWORD(0x400E82B0, 0x00000008); _WDWORD(0x400E82B4, 0x00000008); _WDWORD(0x400E82B8, 0x00000008); _WDWORD(0x400E82BC, 0x00000008); _WDWORD(0x400E82C0, 0x00000008); _WDWORD(0x400E82C4, 0x00000008); _WDWORD(0x400E82C8, 0x00000008); _WDWORD(0x400E82CC, 0x00000008); _WDWORD(0x400E82D0, 0x00000008); _WDWORD(0x400E82D4, 0x00000008); _WDWORD(0x400E82D8, 0x00000008); _WDWORD(0x400E82DC, 0x00000008); _WDWORD(0x400E82E0, 0x00000008); _WDWORD(0x400E82E4, 0x00000008); _WDWORD(0x400E82E8, 0x00000008); _WDWORD(0x400E82EC, 0x00000008); _WDWORD(0x400E82F0, 0x00000008); _WDWORD(0x400E82FC, 0x00000008); _WDWORD(0x400E8300, 0x00000008); _WDWORD(0x400E8304, 0x00000008); _WDWORD(0x400E8308, 0x00000008); _WDWORD(0x400E830C, 0x00000008); _WDWORD(0x400E8310, 0x00000008); _WDWORD(0x400E8314, 0x00000008); _WDWORD(0x400E8318, 0x00000008); _WDWORD(0x400E831C, 0x00000008); _WDWORD(0x400E8320, 0x00000008); _WDWORD(0x400E8324, 0x00000008); _WDWORD(0x400E8328, 0x00000008); _WDWORD(0x400E832C, 0x00000008); _WDWORD(0x400E8330, 0x00000008); _WDWORD(0x400E8334, 0x00000008); _WDWORD(0x400E8338, 0x00000008); _WDWORD(0x400E833C, 0x00000008); _WDWORD(0x400E8340, 0x00000008); // Config SDR Controller Registers/ _WDWORD(0x400d4000,0x10000004); // MCR _WDWORD(0x400d4008,0x00000081); // BMCR0 _WDWORD(0x400d400C,0x00000081); // BMCR1 _WDWORD(0x400d4010,0x8000001D); // BR0, 64MB _WDWORD(0x400d4040,0x00000F32); // SDRAMCR0, 32bit _WDWORD(0x400d4044,0x00772A22); // SDRAMCR1 _WDWORD(0x400d4048,0x00010A0D); // SDRAMCR2 _WDWORD(0x400d404C,0x21210408); // SDRAMCR3 _WDWORD(0x400d4090,0x80000000); // IPCR0 _WDWORD(0x400d4094,0x00000002); // IPCR1 _WDWORD(0x400d4098,0x00000000); // IPCR2 _WDWORD(0x400d409C,0xA55A000F); // IPCMD, SD_CC_IPREA SDRAM_WaitIpCmdDone(); _WDWORD(0x400d409C,0xA55A000C); // SD_CC_IAF SDRAM_WaitIpCmdDone(); _WDWORD(0x400d409C,0xA55A000C); // SD_CC_IAF SDRAM_WaitIpCmdDone(); _WDWORD(0x400d40A0,0x00000033); // IPTXDAT _WDWORD(0x400d409C,0xA55A000A); // SD_CC_IMS SDRAM_WaitIpCmdDone(); _WDWORD(0x400d4150,0x00000017); // DCCR _WDWORD(0x400d404C,0x21210409 ); // enable sdram self refresh again after initialization done. } FUNC void Setup (void) { SP = _RDWORD(0x30002000); // Setup Stack Pointer PC = _RDWORD(0x30002004); // Setup Program Counter _WDWORD(0xE000ED08, 0x30002000); // Setup Vector Table Offset Register } FUNC void DisableECC(){ _WDWORD(0x40014100, 0x00000000); _WDWORD(0x40018100, 0x00000000); _WDWORD(0x40028108, 0x00000000); } FUNC void OnResetExec (void) { // executes upon software RESET _clock_init(); _sdr_Init(); DisableECC(); Setup(); // Setup for Running } restoreFlexRAM(); _clock_init(); _sdr_Init(); DisableECC(); LOAD %L INCREMENTAL // Download Setup(); // Setup for Running // g, main  In the project, add the prepared script file: 10.jpg Fig 10 Debug result is: 11.jpg Fig 11 We can see, in MDK, debugging can also be successful using CMSIS DAP. Information sharing: For MCUXPresso IDE, subsequent scripts will automatically add ECC support, the new version is MCUXpresso11.10.0. Scripts for other IDEs need to be added by themselves.  
查看全文
1. Backgroud Customers adopting multi-i.MXRT master-slave architectures (one master, multiple slaves) aim to meet functional requirements while simultaneously reducing costs and improving system efficiency through optimized hardware design. 2.  Multi-i.MXRT Architecture Design 2.1 Independent Flash Architecture (Master-Slave) In multi-i.MXRT systems, a typical design adopts a master-slave architecture where one i.MXRT acts as the master and others as slaves. Since the i.MXRT chip lacks on-chip non-volatile memory, each i.MXRT requires an independent boot device (e.g., NOR Flash connected via FlexSPI) to load programs and initiate startup.  Traditional Architecture: - Each i.MXRT has its own dedicated Flash memory, ensuring operational independence. Sam_Gao_0-1750324582842.png Advantages: - Full System Independence: Each i.MXRT operates independently with its own firmware and boot configuration. Fault isolation: A failure in one Flash or i.MXRT does not affect others. - Simplified Firmware Management: Independent firmware updates for each i.MXRT without coordination. Easier OTA version control (each device has its own update path). Disadvantages: - Complex programming workflow (multiple Flash devices need individual firmware updates). - Higher hardware complexity, larger PCB footprint, and increased cost due to multiple Flash chips. 2.2 Shared Flash Architecture (Master-Slave with Flash Sharing) A single Flash device is connected to multiple i.MXRTs. The master i.MXRT controls the POR_B (Power-On Reset) signal of all slave i.MXRTs, enabling shared access to the same Flash. Boot Process: 1. The master i.MXRT boots first in Non-XIP mode. 2. The master sequentially releases the POR_B signals of slave i.MXRTs, allowing them to occupy the Flash and boot in Non-XIP mode one at a time. Sam_Gao_1-1750324650518.png Advantages: - Reduced cost and simplified hardware design. - Smaller PCB footprint with only one Flash required. - Streamlined firmware programming (single Flash update) for mass production. Disadvantages: - If slave i.MXRTs require different firmware, the Flash must be partitioned into regions, leading to: - Complex OTA version management challenges. - Reduced system independence among slave devices. 3. Hardware Platform Setup Master Board: MIMXRT1010-EVK Slave Board: MIMXRT1010-EVK Rework: Remove U13 (Flash) from the slave board. Retain U13 on the master board and fly-wire it to U13 of the slave board (only CS, SCLK, IO0, IO1 are required for low-speed boot). Connect GPIO_11 signal of the master i.MXRT1010 to POR_B of the slave i.MXRT1010 (Pin3/4 of SW3). Sam_Gao_0-1750234973021.png   4. Software Design Due to both master and slave i.MXRTs sharing a single application (differentiated via conditional branches), the app must be Non-XIP. Therefore, we designed a boot_loader project that copies and jumps to the boot_app, instead of using SPT or MCUBootUtility. 🔗 Key modules: /boards/evkmimxrt1010/demo_apps/boot_loader /boards/evkmimxrt1010/demo_apps/boot_app . ├── boards │ └── evkmimxrt1010 │ ├── demo_apps │ │ ├── boot_app │ │ ├── boot_loader │ │ ├── hello_world │ │ └── led_blinky │ └── xip │ ├── evkmimxrt1010_flexspi_nor_config.c │ └── evkmimxrt1010_flexspi_nor_config.h ├── CMSIS │ ├── Core │ ├── Driver │ ├── DSP │ ├── LICENSE.txt │ ├── NN │ └── RTOS2 ├── components │ ├── lists │ ├── serial_manager │ └── uart ├── devices │ └── MIMXRT1011 ├── LICENSE └── README.md Note: Please see the whole reference project from attchement.  4.1 boot_loader Design The boot_loader is a XiP project directly booted by the chip's BootROM. It can be based on the SDK's hello_world example ( flexspi_nor target). The FCB boot header should be modified as follows (1-bit SPI, 30MHz, Normal Read Mode): // boot_loader // xip/evkmimxrt1010_flexspi_nor_config.c const flexspi_nor_config_t qspiflash_config = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClkLoopbackInternally, .csHoldTime = 3u, .csSetupTime = 3u, .deviceType = kFlexSpiDeviceTypeSerialNOR, .sflashPadType = kSerialFlash_1Pad, .serialClkFreq = kFlexSpiSerialClk_30Hz, .sflashA1Size = 16u * 1024u * 1024u, .lookupTable = { // Read LUTs FLEXSPI_LUT_SEQ(CHIP_SELECT, FLEXSPI_1PAD, 0x03, RADDR_SDR, FLEXSPI_1PAD, 0x18), FLEXSPI_LUT_SEQ(READ_SDR, FLEXSPI_1PAD, 0x04, STOP, FLEXSPI_1PAD, 0x0), }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, }; The boot_app is a Non-XIP project (based on SDK’s debug target). Its binary is imported into the boot_loader project. With proper linking address and memory layout, the copy & jump logic can be implemented with standard code. The finalized boot_loader can then be downloaded to Flash using an IDE. 4.2 boot_app Design The boot_app is also derived from the SDK's hello_world . It supports receiving simple UART commands ( A , B , etc.) for various tests. Currently, six test commands are supported:  Commands Target Device i.MX RT Description 'A' Master Drive master i.MXRT's GPIO_11 high to pull POR_B high and release slave i.MXRT from reset. 'B' Master Drive master i.MXRT's GPIO_11 low to pull POR_B low and hold slave i.MXRT in reset.   Commands Target Device Description 'F' Salve Toggle GPIO_11 periodically with a timer to blink the D25 LED.   Commands Target Device Description 'C' Master or Slave  Initialize Flash-related pins for FlexSPI functionality. 'D' Master or Slave  Restore Flash-related pins to default GPIO state. 'E' Master or Slave  Erase, program, and read U13 Flash.   Notes: Commands A and E may cause conflicts when both master and slave i.MXRT attempt to drive the same Flash through FlexSPI pins. Before executing Command A (to release the slave), the master should first execute Command D, calling the following function to restore FlexSPI pins to GPIO mode. Otherwise, the slave may fail to boot normally (BootROM configures these pins as FlexSPI during boot). void bsp_deinit_flexspi_pins(void) { IOMUXC_SetPinMux(IOMUXC_GPIO_SD_06_GPIO2_IO06, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_SD_07_GPIO2_IO07, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_SD_09_GPIO2_IO09, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_SD_10_GPIO2_IO10, 0U); IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_06_GPIO2_IO06, 0x10A0U); IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_07_GPIO2_IO07, 0x10A0U); IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_09_GPIO2_IO09, 0x10A0U); IOMUXC_SetPinConfig(IOMUXC_GPIO_SD_10_GPIO2_IO10, 0x10A0U); } Commands C and E are typically used together. If the slave has already executed them and remains active, the master must either: The Master execute Command B to reset the slave which resets FlexSPI pin configurations The Slave to execute Command D before running C/E. 5. On-Board Testing Power up both boards. Download the boot_loader (containing embedded boot_app ) to Flash. Quick Test: Sending Command A initially may not start the slave properly. However, after executing Command D followed by Command A, the slave boots successfully. Both master and slave boards can read/write the shared Flash normally, verifying the feasibility of this innovative shared flash boot method. Sam_Gao_1-1750239829328.png Sam_Gao_2-1750239858597.png Note: Please see readme.md from attchement for more details. 6. Conclusion The i.MXRT master-slave architectures (Independent Flash vs. Shared Flash) offer distinct trade-offs: - Independent Flash: Prioritizes system reliability and independent firmware management at the cost of higher hardware complexity and cost. - Shared Flash: Reduces costs and PCB footprint but introduces firmware dependency and OTA management challenges. The prototype successfully validated the Shared Flash approach, demonstrating its feasibility for cost-sensitive, mass-production scenarios. Customers can choose between these designs based on their specific priorities: high reliability with independence (Independent Flash) or cost-efficiency with streamlined workflows (Shared Flash).
查看全文
This document describes how to use I2S (Inter-IC Sound Bus) and DMA to record and playback audio using NXP's i.MX RT600 crossover MCUs. It also includes the process of how to use the codec chip to process audio data on the i.MX RT600 Evaluation Kit (EVK) based on the Cadence® Tensilica® HiFi4 Audio DSP. Click here to access the full application note.
查看全文
[中文翻译版] 见附件   原文链接: https://community.nxp.com/community/imx/blog/2019/04/17/do-you-have-a-minute 
查看全文
Source code: https://github.com/JayHeng/NXP-MCUBootUtility 【v2.1.0】 Features: > 1. [RTyyyy] Support for loading bootable image into SEMC NOR boot device >     [RTyyyy] 支持下载Bootable image进主动启动设备 - SEMC NOR接口Flash > 2. [RTyyyy] Support operation under both CM7 and CM4 of RT117x A0 >     [RTyyyy] 在RT1170无论是CM7还是CM4作为主核下均能正常工作 > 3. [RTyyyy] Support two FlexSPI map addresses for RT117x A0 >     [RTyyyy] 支持RT1170的两个FlexSPI XIP映射地址 > 4. [RTyyyy] Support efuse memory operation for RT117x A0 >     [RTyyyy] 支持RT1170的eFuse回读与烧写 > 5. [RTyyyy] Can import user fuse table file to set efuse value >     [RTyyyy] 支持导入用户fuse配置文件去设置fuse > 6. [RTyyyy] Enable OTFAD encryption secure boot mode (User Key) for RT117x A0 >     [RTyyyy] 为RT1170 A0开启OTFAD加密(User Key)支持 > 7. [RTyyyy] Support RT1170/1010 bootable image from SDK as source input >     [RTyyyy] 支持RT1170/RT1010 SDK生成的Bootable image作为源文件输入 Improvements: > 1. [RTyyyy] Image format auto detection can be used for axf file from MCUX or GCC >     [RTyyyy] 程序格式自动检测选项也可用于MCUX生成的axf格式源文件 > 2. Specify file path instead of file to save readback data >    指定目录而不是指定文件去存放回读的数据 > 3. If readback data is enabled to be saved in file, then it will not displayed on the screen >    如果回读的数据已经选择保存到文件中,那么点击Read按钮将不会在窗口显示数据 Bugfixes: > 1. 'Cmd Pads' is not set correctly for some typical octal-flash models in FlexSPI NOR configuration >     在FlexSPI NOR配置界面里,对于一些octal-flash模型,其Cmd Pads参数没有被正确设置 > 2. 'Max Frequency' option is not exactly aligned with selected MCU device in FlexSPI NOR configuration >     在FlexSPI NOR配置界面里,Max Frequency参数选项与当前MCU型号不完全匹配 > 3. [RTyyyy] Cannot show total size of SD/eMMC correctly, so SD/eMMC cannot be programmed >     [RTyyyy] SD/eMMC总容量未能正确显示,导致无法编程SD/eMMC > 4. [RTyyyy] Some fields are not aligned with selected MCU device in Flexible User Key Setting >     [RTyyyy] 在用户自定义Key设置界面里,有些选项与当前选中的MCU型号不匹配 > 5. [RTyyyy] Cannot generate bootable image when original image size is less than 4KB >     [RTyyyy] 当输入的源image文件大小小于4KB时,生成可启动程序会失败 > 6. [RTyyyy] Sometimes tool cannot recognize .axf format from MCUX or Keil MDK >     [RTyyyy] 有时候无法识别MCUX或Keil MDK生成的axf格式源文件 > 7. [RTyyyy] Signed flashloader cannot be generated if DCD is enabled >     [RTyyyy] 当DCD使能的时候,无法生成含签名的Flashloader > 8. [RTyyyy] Cannot mark DCD in readback image if it comes from source bootable image >     [RTyyyy] 如果DCD来自源Bootable image,则无法在读回的image中标记DCD Interests: > 1. Add sound effect (Contra) >    增加魂斗罗音效
查看全文
[中文翻译版] 见附件   原文链接: https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT1050-HAB-Encrypted-Image-Generation-and-Analysis/ta-p/1124877  
查看全文
MCUXPRESSO SECURE PROVISIONING TOOL是官方今年上半年推出的一个针对安全的软件工具,操作起来非常的简单便捷而且稳定可靠,对于安全功能不熟悉的用户十分友好。但就是目前功能还不是很完善,只能支持HAB的相关操作,后续像BEE之类的需等待更新。 详细的介绍信息以及用户手册请参考官方网址:MCUXpresso Secure Provisioning Tool | Software Development for NXP Microcontrollers (MCUs) | NXP | NXP  目前似乎知道这个工具的客户还不是很多,大部分用的更多的还是MCU BOOT UTILITY。那么如果已经用了MCU BOOT UTILITY烧录了FUSE,现在想用官方工具了怎么办了?其实对两者进行研究对比后,他们最原始的执行部分都是一样的,所以我们按照如下步骤进行相应的简单替换就能把新工具用起来: 首先是crts可keys的替换, MCU BOOT UTILITY的路径是在: ..\NXP-MCUBootUtility-2.2.0\NXP-MCUBootUtility-2.2.0\tools\cst MCUXPRESSO SECURE PROVISIONING的对应路径是在对应workspace的根目录: 另外还有一个就是encrypted模式会用到的hab_cert,需要将下面这两个文件对应替换,而且两个工具的命名不同,注意修改。 MCU BOOT UTILITY的路径是在: ..\NXP-MCUBootUtility-2.2.0\NXP-MCUBootUtility-2.2.0\gen\hab_cert MCUXPRESSO SECURE PROVISIONING的路径是workspace里: ..\secure_provisioning_RT1050\gen_hab_certs MCU BOOT UTILITY里命名为:SRK_1_2_3_4_table.bin; SRK_1_2_3_4_fuse.bin MCUXPRESSO SECURE PROVISIONING里命名为:SRK_fuses.bin; SRK_hash.bin 至此,就能够在新工具上用起来了 最后提一下,就是这个新工具是可以建不同的workspace来相应存储不同秘钥的项目,能够方便用户区分。在新工具下建的项目也是可以互相替换秘钥的,参考上术步骤中的secure provisioning部分即可。
查看全文
Background: The CAAM manufacturing protection feature provides a mechanism to authenticate the chip to the OEM's server. The manufacturing protection feature can be used to ensure that the chip:  Is a genuine NXP SoC  Is the correct device type and part number  Has been properly configured by means of fuses  Is running authenticated OEM software  Is currently in the secure or trusted mode The CAAM manufacturing protection feature is based on an ECC private key generated by the High Assurance Boot (HAB) code on every boot cycle. The Manufacturing Protection (MP) private key generation takes as input several fixed secrets and the MANUFACTURE_PROTECTION_KEY[255:0] being one of them in SoC fuses.   Issue Description: On certain i.MX RT117x and RT116x devices the MANUFACTURE_PROTECTION_KEY[255:0] fuses were incorrectly programmed at the NXP factory. During the MP private key generation, the CAAM block validates the inputs provided and fails as the MANUFACTURE_PROTECTION_KEY[255:0] provided is not a valid one. As the MPPubK-generation and MPSign CAAM functions depends on the result of MPPrivK-generation function the CAAM manufacturing protection feature cannot be used on the impacted devices. Details regarding manufacturing protection functions can be found in the section "Manufacturing-protection chip-authentication process" in the security reference manuals (SRM).  Please note that in closed mode the CAAM MPPrivK-generation function can be only executed once in the same power-on session. Running a second time returns a CAAM error (0x40000481) undefined protocol command which is not related to the issue described in this document.   Checking if your device is impacted: Customers can check if their device is impacted by following the 3 steps below: Checking the date code: Devices from datecodes prior to 2213 are impacted. Checking HAB events: The HAB code logs a warning event in the HAB persistent memory region after detecting a failure in the MP private key generation. This warning is logged independently regardless of whether HAB is enabled (SEC_CONFIG =1) or not. Customers can parse the HAB persistent memory region at 0x20242000 in order to get the warning events.  Impacted devices should report the event below: Event    | 0xdb | 0x0024 | 0x45 |  SRCE Field: 69 30 e1 1d             |         |             |         |             STS = HAB_WARNING (0x69)             |         |             |         |             RSN = HAB_ENG_FAIL (0x30)             |         |             |         |            CTX = HAB_CTX_ENTRY (0xE1)             |         |             |         |            ENG = HAB_ENG_CAAM (0x1d)             |         |             |         |  Evt Data (hex):             |         |             |         |   00 01 00 02 40 00 04 cc 00 00 00 0f 00 00 00 00             |         |             |         |   00 00 00 00 00 00 00 00 00 00 00 01 3. Checking the CAAM SCFGR register: After running the MPPrivK-generation function the CAAM block stores in the CAAM SCFGR register the elliptic curve that was selected when the MPPrivK generation protocol was executed. Users can check the MPCURVE field [31:28] in the CAAM SCFGR register and on impacted devices this field will be 0.    List of impacted devices:  All i.MX RT117x and RT116x devices prior to 2213 datecode are impacted.   Workaround: No Software Workaround can be implemented. Customers planning to use the Manufacturing Protection feature should request for SoC's that have the correct fuse programming. Please Note: This issue does not impact the Secure Boot flow and does not compromise security.
查看全文
There are two version of the i.MX RT1170 Evaluation Kit:  MIMXRT1170-EVK (no longer available for purchase) MIMXRT1170-EVKB   The key differences between the two versions of are laid out in the MIMXRT1170-EVKB Board Hardware User Guide:  anthony_huereca_0-1758051309228.png   One important change is the QuadSPI flash used on each board. This means that if you attempt to use SDK projects created for the RT1170-EVKB, it will not run properly on an older RT1170-EVK board due to using the mismatched QSPI configuration data. And new releases of MCUXpresso SDK only support the newer EVKB board.  However there is a simple fix to get those newer i.MX RT1170 EVKB MCUXpresso SDK projects to run on the older i.MX RT1170 EVK hardware. Simply download the MCUXpresso SDK 2.16.00 for the original RT1170-EVK board, unzip the archive file, and then copy the evkmimxrt1170_flexspi_nor_config.h and evkmimxrt1170_flexspi_nor_config.c files found in \SDK_2_16_000_MIMXRT1170-EVK\boards\evkmimxrt1170\xip into your EVKB project's xip folder. Then either delete/rename the EVKB version of the evkbmimxrt1170_flexspi_nor_config.c and evkbmimxrt1170_flexspi_nor_config.h files from the project to avoid compiler conflicts. This will update the QSPI configuration for that project to be compatible with the QSPI hardware on the original EVK. As an exmaple, here is the RT1170 Hello World project with that change - the EVKB files were renamed with a .orig extension so they would not be included in the compilation:  anthony_huereca_1-1758051632103.png   Note that due to the new hardware features found on the EVKB board there are some EVKB SDK projects that simply can't be supported on the original EVK board. But this work-around will provide support for many MCUXpresso SDK projects that don't require those new EVKB board features.    VSCode: For VSCode projects the repo\mimxrt1170_evkb\boards\xip\board_boot_header.make file will need to be modified to comment out the evkbmimxrt1170_flexspi_nor_config.c file and add the evkmimxrt1170_flexspi_nor_config.c  anthony_huereca_0-1764912226964.png  
查看全文