i.MX RT Crossover MCUs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT Crossover MCUs Knowledge Base

Discussions

Sort by:
RT1050 HAB Encrypted Image Generation and Analysis 1, Introduction      The NXP RT series can support multiple boot modes, it incluses: unsigned image mode, HAB signed image mode, HAB encryption image mode, and BEE encryption  image mode.       In order to understand the specific structure of the HAB encryption app, this article will generate a non-XIP app image, then generate the relevant burning file through the elftosb.exe tool in the flashloader i.MX-RT1050, and use MFGTOOL to enter the serial download mode to download the .sb file.       This article will focus on the download steps of RT1050 HAB encryption related operations, and analyze the structure of the HAB encrypted app image.     2, RT1050 HAB Encypted Operation Procedure At first, we analyze the steps of MFGtool burning, which files are needed, so as to give specific preparation, open the ucl2.xml file in the following path of the flashloader: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\mfgtools-rel\Profiles\MXRT105X\OS Firmware Because we need to use the HAB encrypated boot mode, then we will use MXRT105X-SecureBoot, from the ucl2.xml file, we will find the following related code: Fig 1. MXRT1050-SecureBoot structure As you can see from the above, to implement the secure boot of RT1050, you need to prepare these three files: ivt_flashlloader_signed.bin: it is the signed flashloader binary file enable_hab.sb: it is used to modify the SRK and HABmode in the fuse map boot_image.sb: HAB encrypted app program file       Here is a flow chart of the overall HAB encryption operation step, after checking this figure, then we will follow it step by step.     Fig 2. MXRT1050 HAB encrypted image flow chart     The app image we used in this article is the RAM app, so, at first, we need to prepare one RAM based app image. In this document, we are directly use the prepared  RAM based app image: evkbimxrt1050_led_softwarereset_0xa000.s19, this app code function is: After download the code to the MIMXRT1050-EVKB(qspi flash) board, the on board led D18 will blinky and printf the information, after pressing the WAKEUP button SW8, the code will implement software reset and printf the related information. The unsigned code test print result are as follows:      BOARD RESET start.  Helloworld. WAKEUP key pressed, will do software system reset.    BOARD RESET start.  Helloworld. 2.1 CST tool preparation      Because the contains a lot of steps, then customer can refer to the following document do the related configuration, this document, we won’t give the CST configuration detail steps. Please check these documents: https://www.cnblogs.com/henjay724/p/10219459.html https://community.nxp.com/docs/DOC-340904 Security Application Note AN12079 After the CST tool configuration, please copy the cst.exe, crts folder, key folder from cst folder to the same folder that holds elftosb executable files: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Please also copy SRK_1_2_3_4_fuse.bin and SRK_1_2_3_4_table.bin to the above folder. 2.2  Sign flashloader    Please refer to application note AN12079 chapter 3.3.1, copy flashloader.elf from folder path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Flashloader And the imx-flexspinor-normal-signed.bd  from folder path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\bd_file\imx10xx to the folder: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Please open commander window under the elftosb folder, then input this commander: elftosb.exe -f imx -V -c imx-flexspinor-flashloader-signed.bd -o ivt_flashloader_signed.bin flashloader.elf   Fig 3.  Sign flashloader  This steps will generate the  ivt_flashlaoder_signed.bin, which is needed to put under the MFGtool OS Firmware folder, just used for enter the signed flashloader mode. 2.3 SRK and HAB mode fuse modification files Please refer to AN12079 chapter 4.3, copy the enable_hab.bd file from folder path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\bd_file\imx10xx to this folder path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Please refer to the chapter 2.1 generated SRK_1_2_3_4_fuse.bin, modify the enable_hab.bd like the following picture: Fig 4. enable_hab.bd SRK and HAB mode fuse modification Then,  in the elftosb window, please input the following command, just used to generate the enable_hab.sb program file: elftosb.exe -f kinetis -V -c enable_hab.bd -o enable_hab.sb   Fig 5. SRK and HAB mode program files generation 2.4 APP Encrypted Image      If you want to do the HAB encrypted image download, you need to prepare one non-XIP app image, here we prepared one RAM based APP srec files.      Because the app file is the RAM files, then we also need the related RAM encrypted .bd files, please copy imx-itcm-encrypted.bd from the folder path:      Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\bd_file\imx10xx to this folder path: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\elftosb\win Open imx-itcm-encrypted.bd, then modify the following content: options {     flags = 0x0c;     # Note: This is an example address, it can be any non-zero address in ITCM region     startAddress = 0x8000;     ivtOffset = 0x1000;     initialLoadSize = 0x2000;     # Note: This is required if the cst and elftsb are not in the same folder     # Note: This is required if the default entrypoint is not the Reset_Handler     #       Please set the entryPointAddress to Reset_Handler address   entryPointAddress = 0x0000a2dd; } Here, we need to note these two points: (1)    ivtOffset = 0x1000; If the external flash is flexspi flash, then we need to modify ivtOffset as 0X1000, if it is the nandflash, we need to use the 0X400. (2) entryPointAddress = 0x0000a2dd; The entryPointsAddress should be the app code reset handlder, it is the app start address+4 data, the entry address is also OK, but we suggest you to use the app Reset_Handler address. Fig 6. App reset handler address Then input the following commander in the elftosb windows: elftosb.exe -f imx -V -c imx-itcm-encrypted.bd -o ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin evkbimxrt1050_led_softwarereset_0xa000.s19 Fig 7. App HAB Encrypted file generation Please note, we need to record the generated key blob offset address, it is 0XA00, just like the above data in the red frame, this address will be used in the next chapter’s .bd file. After this step, it will generate 7 files:          (1)  ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin, this file includes the FDCB which is filled with 0, IVT, BD, DCD, APP HAB encrypted image data, CSF data (2)  ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted_nopadding.bin, compare with ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin, this file deletes the 0s which is above IVT range. (3)  Csf.bin, it is the HAB data area, you can find the data contains the csf data, it is from 0X8000 to 0X8F80 in the generated ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin. Fig 8. Csf data and the encrypted app relationship      (4) dek.bin Fig 9. Dek data DEK data is the AES-128 bits key, it is not defined by the customer, it is random generated automatically by the HAB encrypted tool. (5) input.csf Open it, you can find the following content: Fig10. Input csf file content (6) rawbytes.bin,  this is the app image plaintext data, it doesn’t contains the FDCB,IVT,BOOTDATA, DCD, csf etc.    (7) temp.bin, it is the temporary file, compare with ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin, no csf files.   2.5 HAB Encrypted QSPI program file    Here we need to prepare one program_flexspinor_image_qspinor_keyblob.bd file, and put it under the same folder as elftosb, this file is used to generate the HAB encrypted program .sb file. Because the flashloader package didn’t contains it, then we paste all the related content, and I will also attach it in the attachment. # The source block assign file name to identifiers sources { myBinFile = extern (0); dekFile = extern (1); } constants { kAbsAddr_Start= 0x60000000; kAbsAddr_Ivt = 0x60001000; kAbsAddr_App = 0x60002000; } # The section block specifies the sequence of boot commands to be written to the SB file section (0) { #1. Prepare Flash option # 0xc0000006 is the tag for Serial NOR parameter selection # bit [31:28] Tag fixed to 0x0C # bit [27:24] Option size fixed to 0 # bit [23:20] Flash type option # 0 - QuadSPI SDR NOR # 1 - QUadSPI DDR NOR # 2 - HyperFLASH 1V8 # 3 - HyperFLASH 3V # 4 - Macronix Octal DDR # 6 - Micron Octal DDR # 8 - Adesto EcoXIP DDR # bit [19:16] Query pads (Pads used for query Flash Parameters) # 0 - 1 # 2 - 4 # 3 - 8 # bit [15:12] CMD pads (Pads used for query Flash Parameters) # 0 - 1 # 2 - 4 # 3 - 8 # bit [11: 08] Quad Mode Entry Setting # 0 - Not Configured, apply to devices: # - With Quad Mode enabled by default or # - Compliant with JESD216A/B or later revision # 1 - Set bit 6 in Status Register 1 # 2 - Set bit 1 in Status Register 2 # 3 - Set bit 7 in Status Register 2 # 4 - Set bit 1 in Status Register 2 by 0x31 command # bit [07: 04] Misc. control field # 3 - Data Order swapped, used for Macronix OctaFLASH devcies only (except MX25UM51345G) # 4 - Second QSPI NOR Pinmux # bit [03: 00] Flash Frequency, device specific load 0xc0000006 > 0x2000; # Configure QSPI NOR FLASH using option a address 0x2000 enable flexspinor 0x2000; #2 Erase flash as needed. erase 0x60000000..0x60020000; #3. Program config block # 0xf000000f is the tag to notify Flashloader to program FlexSPI NOR config block to the start of device load 0xf000000f > 0x3000; # Notify Flashloader to response the option at address 0x3000 enable flexspinor 0x3000; #5. Program image load myBinFile > kAbsAddr_Ivt; #6. Generate KeyBlob and program it to flexspinor # Load DEK to RAM load dekFile > 0x10100; # Construct KeyBlob Option #--------------------------------------------------------------------------- # bit [31:28] tag, fixed to 0x0b # bit [27:24] type, 0 - Update KeyBlob context, 1 Program Keyblob to flexspinor # bit [23:20] keyblob option block size, must equal to 3 if type =0, # reserved if type = 1 # bit [19:08] Reserved # bit [07:04] DEK size, 0-128bit 1-192bit 2-256 bit, only applicable if type=0 # bit [03:00] Firmware Index, only applicable if type = 1 # if type = 0, next words indicate the address that holds dek # the 3rd word #---------------------------------------------------------------------------- # tag = 0x0b, type=0, block size=3, DEK size=128bit load 0xb0300000 > 0x10200; # dek address = 0x10100 load 0x00010100 > 0x10204; # keyblob offset in boot image # Note: this is only an example bd file, the value must be replaced with actual # value in users project load 0x0000a000 > 0x10208; enable flexspinor 0x10200; #7. Program KeyBlob to firmware0 region load 0xb1000000 > 0x10300; enable flexspinor 0x10300; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Please note, in the above chapter, fig 7, we mentioned the keyblob offset address, we need to modify it in the following code:     load 0x0000a000 > 0x10208; Now, combine program_flexspinor_image_qspinor_keyblob.bd, ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted_nopadding.bin and dek.bin file together, we use the following commander to generate the boot_image.sb: elftosb.exe -f kinetis -V -c program_flexspinor_image_qspinor_keyblob.bd -o boot_image.sb ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted_nopadding.bin dek.bin Fig 11. App HAB encrypted program file generation Until now, we will find, all the related HAB encrypted files is prepared. 2.6 MFG Tool program HAB Encrypted files to RT1050-EVKB        Before we program it, please copy the following 3 files which is in the elftosb folder: ivt_flashloader_signed.bin enable_hab.sb boot_image.sb to this folder: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\mfgtools-rel\Profiles\MXRT105X\OS Firmware Please modify cfg.ini, the file path is: Flashloader_i.MXRT1050_GA\Flashloader_RT1050_1.1\Tools\mfgtools-rel Modify the content as: [profiles] chip = MXRT105X [platform] board = [LIST] name = MXRT105X-SecureBoot Choose MXRT105X-SecureBoot program mode. Then open the tool MfgTool2.exe, the board MIMXRT1050-EVKB(need to modify the on board resistor, use the qspi flash) mode should be serial download mode, just modify SW7:1-OFF,2-OFF,3-OFF, 4-ON, connect two usb cable between PC and the board J28 and J9. After the connection, you will find the MfgTool2.exe can detect the HID device: Fig 12. MFG tool program After the program is finished, power off the board, modify the boot mode to internal boot, it is SW7:1-OFF,2-OFF,3-ON, 4-OFF,connect the COM terminal, power on the EVKB board, after reset, you will find the D18 led is blinking, after you press the SW8, you will find the following printf information: BOARD RESET start. Helloworld. WAKEUP key pressed, will do software system reset. ? BOARD RESET start. Helloworld.‍‍‍‍‍‍‍‍‍‍‍‍‍ So, the HAB encrypted image works OK now. 3. App HAB encrypted image structure analysis 3.1 MCUBootUtility Configuration to check the RT Encrypted image      Here, we can also use  MCUBootUtility tool to check the RT chip encrypted image and the fuse data.      If the cst is your own configured, please do the following configuration at first:     (1)Copy the configured cst folder to folder: NXP-MCUBootUtility-2.0.0\tools Delete the original cst folder. (2)Copy SRK_1_2_3_4_fuse.bin and SRK_1_2_3_4_table.bin to folder:  NXP-MCUBootUtility-2.0.0\gen\hab_cert Now, you can use the new MCUBootutility to connect your board which already done the HAB encrypted method. 3.1 RT1050 fuse map comparation Before do the HAB encrypted image program, I have read out the whole fuse map as follows: Fig 13. MIMXRT1050-EVKB fuse map before HAB encrypted image Fig 14. MIMXRT1050-EVKB fuse map after HAB encrypted image Compare the fuse map between do the HAB encrypted image and no HAB encrypted image, we can find two difference: HAB mode, 0X460 bit1:0 open, 1 close SRK area We can find, after program the HAB encrypted image, the SRK fuse data is the same as the SRK data which is defined in the enable_hab.bd. 3.2  Readout HAB encrypted QSPI APP image structure analysis From MCUBootUtility tool, we can find the HAB Encypted image structure should be like this: Fig 15. HAB Encrypted image structure What about the real example image case? Now, we use the MCUbootUtility tool to read out our HAB encrypted image, from address 0X60000000, the readout size is 0XB000. The detail image structure is like following:   Fig 16. HAB Encypted image example structure   1): IVT:  hdr,  IVT header, more details, check hab_hdr 2):    IVT: entry, the app entrypointAddress, it should be the reset_handler address, in this document example, it is the address 0xa004 data, the plaintext is 0X00A2DD, but after the HAB encrypted, we can find the address -x60002004 data is the encrypted data 3):  IVT: reserved 4):  IVT: DCD, it is used for the DRAM SEMC configuration, in this example, we didn’t use the SDDRAM, so the data is 0. 5):  IVT: BOOT_DATA, used to indicate the BOOT_DATA  RAM start address 0X9020. 6):  IVT: self, ivt self RAM start address is 0X9000 7):  IVT:CSF, it is used to indicate the CST start address, this example csf ram address is 0X00010000. 8):  IVT:reserved 9): BOOT_DATA:  RAM image start,  the whole image RAM start address, this RAM example BOOT_DATA is 0X8000,0XA000-0X2000=0X8000 10): BOOT_DATA: size, APP file size, it is 0X0000A200, after checking the file generated HAB encrypted app image size, you can find the image end size is really 0XA200, just like the fig 16. 11):  HAB  Encypted app data,  please check ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin file, the address 0X2000-0X7250 data, you will find it is the same.   12): HAB data, it incluses the csf, certificate etc data, you can compare the file ivt_evkbimxrt1050_led_softwarereset_0xa000_encrypted.bin address 0X8000-0x8f70 data, it is the same. 13):DEK blob, it is the DEK key blob related data, the offset address is 0XA000, the same as fig 7. FDCB,IVT,BOOT DATA are all plaintext, but app image area is the HAB encrypted data, HAB and the DEK blob is the generated data put in the related memory. Conclusion     This document we mainly use the elftosb and the MFGTool to generate the HAB encrypted image, and download it to the RT1050 EVKB board, document give the whole detail steps, and us ethe MCUBootutility tool to read out the HAB encrypted image, and analysis the HAB encrypted image structure with the examples.  After compare with the generated mid files, we can find all the data is consist, and all the encrypted data range is the same. The test result also demonstrate the HAB encrypted code function works, the HAB encrypted boot has no problems. All the related files is in the attachment.      
View full article
RT1170 Octal flash enablement 1. Abstract The MIMXRT1170-EVK hardware can directly support two types of flash: QSPI flash IS25WP128 and Octal flash MX25UM51345GXDI00. QSPI flash is used by default, so the FCB of the related SDK and some IDE debugger download flash drivers are also default to the QSPI flash. In practical usage, some customers need to use Octal flash with RT1170, but after modifying the EVK hardware to Octal flash MX25UM51345GXDI00, they may encounter various issues, such as download issues, boot issues, debug issues, and when the flash is empty or there is a valid boot code in the flash, the download result is different and so on. This article will be based on NXP's official MIMXRT1170-EVK REV C1, modify the hardware onboard flash from QSPI flash to Octal flash MX25UM51345GXDI00, and modify the SDK project FCB, do ROM API test, do related tool download, do the debugger related flashloader modification and test with different IDE, so that customers who need it can refer to it. This article is not limited to EVK, but also applies to RT1170+Octal flash MX25UM51345GXDI00 with customer-defined board Pic 1 2. Hardware modification MIMXRT1170-EVK board modify flash to the octal flash, it needs to disconnect the QSPI flash pins, and connect the octal flash pins, the related modification points are: OPTION2: USE Octal Flash( Mount R381/R378/R382/R389/R402/R377/R388/R391, DNP R380/R399/R386/R390/R392/R385) Pic 2 The octal flash BOOT_CFG pin configuration are as follows: Pic 3 Pic 4 After modifying the hardware related resistors to choose the octal flash, SW1, SW2 should be configured to internal boot, and boot from octal flash, then it is controlled by the software part. 3. Octal flash APP FCB 3.1 Test SDK ROM API run from RAM To verify the board hardware can run from the octal flash, we can test the SDK attached fsl_romapi project: \SDK_2_12_0_MIMXRT1170-EVK\boards\evkmimxrt1170\driver_examples\fsl_romapi\cm7 Please note, can’t test the default project directly, as this project configuration is used by the QSPI flash, not the octal flash, if need to use the octal flash, customer need to modify the code at first, and add the GPIO to control the Flash_RST pin, which is used to reset the octal flash. The option0,1 value need to be modified to the octal flash values. 3.1.1 Octal flash option value     Pic 5 We can use the following option0 for testing, don’t need to configure the option1, as the octal flash is connected to the primary pin. option0= 0Xc0400007, option1 = 0 //query_pad =1, cmd_pad=1,133MHz option0= 0Xc0433007, option1 = 0 //query_pad =8, cmd_pad=8,133MHz option0= 0Xc0403007, option1 = 0 //query_pad =1, cmd_pad=8,133MHz 3.1.2 fsl_romapi project testing    The modified code for the ROM API project are as follows, before call ROM_FLEXSPI_NorFlash_GetConfig API, it needs to use the GPIO to reset the external octal flash at first, so, here add the Flash_RST=GPIO_AD_03=GPIO09_IO02 pin GPIO configuration. Pinmux.c related code:     gpio_pin_config_t gpio9_pinP15_config = { .direction = kGPIO_DigitalOutput, .outputLogic = 1U, .interruptMode = kGPIO_NoIntmode }; GPIO_PinInit(GPIO9, 02U, &gpio9_pinP15_config); IOMUXC_SetPinMux( IOMUXC_GPIO_AD_03_GPIO9_IO02, 0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_03_GPIO9_IO02,//OD,it is a workaround for EVK HW bug 0X12);     Flexspi_romapi.c added code:     static serial_nor_config_option_t option_1bit = { .option0.U = 0xc0400007U, .option1.U = 0U, }; static serial_nor_config_option_t option_8bit = { .option0.U = 0xc0433007, .option1.U = 0U, }; static serial_nor_config_option_t option_1_8bit = { .option0.U = 0xC0403007, .option1.U = 0U, }; GPIO_PinWrite(GPIO9, 02U, 0U); // Delay some time to reset external flash with Flash_RST pin for (uint32_t i = 0; i < 60000; i++) __asm volatile ("nop"); GPIO_PinWrite(GPIO9, 02U, 1U); status = ROM_FLEXSPI_NorFlash_GetConfig(FlexSpiInstance, &norConfig, &option_8bit); if (status == kStatus_Success) { PRINTF("\r\n Successfully get FLEXSPI NOR configuration block with option_8bit\r\n "); } else { status = ROM_FLEXSPI_NorFlash_GetConfig(FlexSpiInstance, &norConfig, &option_1_8bit); if (status == kStatus_Success) { PRINTF("\r\n Successfully get FLEXSPI NOR configuration block with option_1_8bit\r\n "); } else { status = ROM_FLEXSPI_NorFlash_GetConfig(FlexSpiInstance, &norConfig, &option_1bit); if (status == kStatus_Success) { PRINTF("\r\n Successfully get FLEXSPI NOR configuration block with option_1bit\r\n "); } else { PRINTF("\r\n Get FLEXSPI NOR configuration block failure!\r\n"); error_trap(); } } }     The test result is: Pic 6 Pic 7 From the test result, we can see, after using the GPIO to reset the external flash, the practical used option value is: option0= 0xc0403007, option1 = 0 //query_pad =1, cmd_pad=8,133MHz It can read the SFDP successfully, get the flash config data to the norConfig, then use these values to configure the flexSPI module, at last, it realizes the octal flash related address area erase-write-read-erase operation. From the above test result, it means, the modified hardware is totally working. Please note, as we can’t confirm the external flash hardware is working, so this project FCB is still the default for the QSPI flash, not the octal flash, then when testing this fsl_romapi project, it’s better to run it from RAM not the external flash. The following picture is how to run the project from the internal RAM, not download the flash directly: Pic 8    Here, for the configuration, we also have one point that needs to note, why configure the GPIO pin Flash_RST: GPIO_AD_03 as OD(open drain)?    It is caused by the current MIMXRT1170-EVK hardware having a bug, so this OD configuration is used as the workaround. Octal flash MX25UM51345GXDI00 power supply voltage is 1.8V, but the GPIO_AD_03 bank voltage is 3.3V, between these two modules, no voltage convert hardware, so it will have the following situation: a) Default GPIO_AD_03 is input mode, this pin has the internal PD(pull down) 35K resistor,  and the external PU(pull up) 10K resistor to the 1.8V, Flash_RST=1.8V*35K/(10K+35K)=1.4V, this voltage also can be used as the enable signal. To the normal boot, as the ROM didn’t control the octal flash Flash_RST pin, then this pin can be freely chose by any pin in the practical usage, so, the reset pin default is input, the voltage is 1.4V, it can enable the octal flash, no influence. b) When need to control the octal flash reset, then it needs to use the GPIO control GPIO_AD_03 pin, if want to output 0, it is OK. But if want to output high level, use the internal PULL resistor, it will output 3.3V to the Flash_RST pin, this voltage already higher than the octal flash 1.8V, and the octal flash datasheet defines the max voltage is 2V, although the flash chip has the voltage buffer, input 3.3V in short time, won’t damage the chip, but after long time working, the chip normal working can’t be guaranteed, this will cause the risk. So, to solve this issues, we can do some workaround in the flashloader, rom API, when output the Flash_RST pin to higher, we can use OD mode, then the detail pin voltage is totally determined by the external pull circuit, and the EVK also have the external 10K PU to 1.8V, so it can output 1.8V not the 3.3V. Pic 9   In the NXP new MIMXRT1170-EVKB board, the hardware adds the voltage convert chip to solve these issues, it can realize the 3.3V and 1.8V conversion: Pic 10 3.2 MCUBootUtility program octal flash We can use the MCUBootUtility to test MIMXRT1170-EVK+octal flash in serial download mode, normally for the chip connect, memory erase, read and program. This method also can use the tool to generated the correct FCB header for the octal flash, then can test the boot situation in the internal boot mode. Serial download-> SW1:1-OFF,2-OFF,3-OFF,4-ON Internal boot-> SW1:1-OFF,2-OFF,3-ON,4-OFF The MCUBootUtility configuration is: Pic 11 This configuration is: option0=0Xc0403007,query 1wire, cmd 8 wire. Then app image can use the MCUBootUtility attached code: NXP-MCUBootUtility-3.5.0\apps\NXP_MIMXRT1170-EVK_Rev.A\cm7\led_blinky_0x3000a000.srec Pic 12   We can see, the code downloading is finished, after this, reset device, configure the board as internal boot mode, then do the POR or the HW reset, we can see the on board LED D34 is blinking, it means the hardware also can boot from the octal flash. 3.3 SDK APP FDCB modification If you need to debug the SDK APP demo from octal flash, you must ensure that the app correct FDCB is provided, then how to modify the app FDCB to octal flash? You can refer to the FDCB which is burned by the MCUBootUtility tool and the datasheet of the octal flash. Here is the FDCB that has been tested for many times. The key point is to provide the correct LUT table. Taking the RT1170 SDK led_blinky project as an example, the evkmimxrt1170_flexspi_nor_config.c file in the project xip file is modified as follows:     const flexspi_nor_config_t octalflash_config = { .memConfig = { .tag = FLEXSPI_CFG_BLK_TAG, .version = FLEXSPI_CFG_BLK_VERSION, .readSampleClksrc=kFlexSPIReadSampleClk_ExternalInputFromDqsPad, .csHoldTime = 3, .csSetupTime = 3, .deviceModeCfgEnable = 1, .deviceModeType = kDeviceConfigCmdType_Spi2Xpi, .waitTimeCfgCommands = 1, .deviceModeSeq = { .seqNum = 1, .seqId = 6, /* See Lookup table for more details */ .reserved = 0, }, .deviceModeArg = 2, /* Enable OPI DDR mode */ .controllerMiscOption = (1u << kFlexSpiMiscOffset_SafeConfigFreqEnable) | (1u << kFlexSpiMiscOffset_DdrModeEnable), .deviceType = kFlexSpiDeviceType_SerialNOR, .sflashPadType = kSerialFlash_8Pads, .serialClkFreq = kFlexSpiSerialClk_133MHz, .sflashA1Size = 64ul * 1024u * 1024u, .dataValidTime = { [0] = {.time_100ps = 16}, }, .busyOffset = 0u, .busyBitPolarity = 0u, .lookupTable = { /* Read */// EEH+11H+32bit addr+20dummy cycles+ 4Bytes read data //133Mhz 20 dummy=10+10 [0 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0xEE, CMD_DDR, FLEXSPI_8PAD, 0x11),//0x871187ee, [0 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, DUMMY_DDR, FLEXSPI_8PAD, 0x0A),//0xb30a8b20, [0 + 2] = FLEXSPI_LUT_SEQ(DUMMY_DDR, FLEXSPI_8PAD, 0x0A, READ_DDR, FLEXSPI_8PAD, 0x04),//0xa704b30a, /* Read Status SPI */// SPI 05h+ status data 0X24 maybe 0X04 [4*1 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR , FLEXSPI_1PAD, 0x05, READ_SDR, FLEXSPI_1PAD, 0x24),//0x24040405, /* Read Status OPI *///05H+FAH+ 4byte 00H(addr)+4Byte read [4*2 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x05, CMD_DDR, FLEXSPI_8PAD, 0xFA),//0x87fa8705, [4*2 + 1] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x00, CMD_DDR, FLEXSPI_8PAD, 0x00),//0x87008700, [4*2 + 2] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x00, CMD_DDR, FLEXSPI_8PAD, 0x00),//0x87008700, [4*2 + 3] = FLEXSPI_LUT_SEQ(READ_DDR , FLEXSPI_8PAD, 0x04, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x0000a704, /* Write enable SPI *///06h [4*3 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR , FLEXSPI_1PAD, 0x06, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00000406, /* Write enable OPI *///06h+F9H [4*4 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x06, CMD_DDR, FLEXSPI_8PAD, 0xF9),//0x87f98706, /* Erase sector */ //21H+DEH + 32bit address [4*5 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x21, CMD_DDR, FLEXSPI_8PAD, 0xDE),//0x87de8721, [4*5 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR , FLEXSPI_8PAD, 0x20, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00008b20, /*Write Configuration Register 2 =01, Enable OPI DDR mode*/ //72H +32bit address + CR20x00000000 = 0x01 [4*6 + 0] = FLEXSPI_LUT_SEQ(CMD_SDR , FLEXSPI_1PAD, 0x72, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000472, [4*6 + 1] = FLEXSPI_LUT_SEQ(CMD_SDR , FLEXSPI_1PAD, 0x00, CMD_SDR, FLEXSPI_1PAD, 0x00),//0x04000400, [4*6 + 2] = FLEXSPI_LUT_SEQ(CMD_SDR , FLEXSPI_1PAD, 0x00, WRITE_SDR, FLEXSPI_1PAD, 0x01),//0x20010400, /*block erase*/ //DCH+23H+32bit address [4*8 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0xDC, CMD_DDR, FLEXSPI_8PAD, 0x23),//0x872387dc, [4*8 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, STOP_EXE, FLEXSPI_1PAD, 0x00),//0x00008b20, /*page program*/ //12H+EDH+32bit address+ write data 4bytes [4*9 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x12, CMD_DDR, FLEXSPI_8PAD, 0xED),//0x87ed8712, [4*9 + 1] = FLEXSPI_LUT_SEQ(RADDR_DDR, FLEXSPI_8PAD, 0x20, WRITE_DDR, FLEXSPI_8PAD, 0x04),//0xa3048b20, /* Chip Erase (CE) Sequence *///60H+9FH [4*11 + 0] = FLEXSPI_LUT_SEQ(CMD_DDR , FLEXSPI_8PAD, 0x60, CMD_DDR, FLEXSPI_8PAD, 0x9F),//0x879f8760, }, }, .pageSize = 256u, .sectorSize = 4u * 1024u, .blockSize = 64u * 1024u, .isUniformBlockSize = false, };     The LUT here is the full function LUT table, it includes: 8 wire read, 1/8 wire status read, 1/8 wire write enable, 8 wire sector erase, 1 wire write configuration enable for OPI DDR mode, 8 wire block erase, 8 wire page program, 8 wire chip erase. The detail command is the same as the MX25UM51345GXDI00 datasheet, and also the same as the MCUBootUtility tool generated FCB. 4. CMSIS DAP Flashloader MIMXRT1170-EVK default use the CMSIS DAP debugger, take the MCUXPresso IDE as an example, it will call the flashloader named as .cfx file, flashloader source code can be found from this path: C:\nxp\MCUXpressoIDE_11.6.0_8187\ide\Examples\Flashdrivers\NXP\iMXRT\ iMXRT117x_FlexSPI_SFDP.zip The exist .cfx file which can be used directly, the path is: C:\nxp\MCUXpressoIDE_11.6.0_8187\ide\binaries\Flash\ MIMXRT1170_SFDP_QSPI.cfx:  QSPI flash MIMXRT1170_SFDP_MXIC_OPI.cfx: octal flash Pic 13 When use flashloader + CMSIS DAP + MCUXpresso debug result is: Pic 14 One point need to note, mcuxpresso IDE flashloader source code iMXRT117x_FlexSPI_SFDP.zip, the project configured to the octal flash, the related Flash_RST control code need to be modified, otherwise, when it output high, the voltage will be 3.3V. Pic 15 In the above picture, add code: MEM_WriteU32(0x400E835CU, 0x12); Which is SW_PAD_CTL_PAD_GPIO_AD_03 register = 0x12, OD mode, then generate the mxic MX25UM51345GXDI00 octal flash .cfx file again, which is used for the mcuxpresso+CMSIS DAP debugger. 5. JLINK Flashloader with RT-UFL In actual use, many customers not only use the on-board CMSIS-DAP debugger, but also like to use external JLINK/JLINK plus, or use the on-board JLINK firmware (use LPCScrypt modify firmware, pay attention to update the JINK firmware according to the instructions on the webpage), or use the external JLINK firmware (need to disconnect the onboard debugger jumper). But if the JLINK flash driver is called directly, it will be QSPI flash. Here is how to use the flash driver of the octal flash in JLINK. Now the JLINK driver uses JLinkARM.dll to define the flash used by different chips, unlike the old JLINK driver. The firmware of the flash is called by JLinkDevices.xml. The .dll file cannot allow users to directly modify the corresponding flash of the device, so it is necessary to provide a flash driver file that supports RT1170 octal flash, and add a calling command in JLinkDevices.xml to override the default QSPI definition in JLinkARM.dll. NXP FAE has developed a very useful full-function flash driver called RT-UFL, which can support general QSPI, hyperflash, octaflash, etc. Users can use JLINK to call RT-UFL flash driver, and then use JFLASH, JLINK commander, or IDE (MCUXpresso, IAR, MDK) to realize the debugging and downloading of RT chips combined with different flashes RT-UFL download link: https://github.com/JayHeng/RT-UFL More detail usage of RT-UFL, please check this blog link:   https://www.cnblogs.com/henjay724/ After downloading, install the RT-UFL to the JLINK driver, copy the following folder file: RT-UFL-1.0\algo\SEGGER\JLink_Vxxx to the JLINK driver install path: C:\Program Files\SEGGER\JLINKV768B The JLINK driver link is: https://www.segger.com/downloads/jlink/JLink_Windows_x86_64.exe Now, use the original RT-UFL firmware combined with JFLASH to test the octal flash in RT1170 directly, and the debugger is JLINK plus, just to check whether it can be run, device selection: MIMXRT1170_UFL_L0. _L0 suffix algorithm is suitable for QSPI Flash and Octal Flash (Page size is 256 Bytes, Sector size is 4KB), _L1/2 suffix algorithm is suitable for Hyper Flash (Page size is 512 Bytes, Sector size is 4KB/64KB). 5.1 RT-UFL JFlash Test Generate a .srec file for the led_blinky project which FCB has been modified to octal flash before, it will be used by JFLASH or JLINK commander later. Use JFLASH combined with JLINK plus to create a new JFLASH project. The chip is selected as MIMXRT1170_UFL_L0 which can support octal flash. The test situation is as follows, you can see that the connect can be successful, and the ARM CortexM7 core can be found, but the programming, reading, and erasing functions will fail. It can be said that the connection to the external octal flash is not successful at all: Pic 16 If the used JLINK is not the JLINK plus, due to the license can’t support the JFLASH, then customer can use the JLINK commander to test it, but here, the test result with the original RT-UFL is totally the same as the JFLASH: Pic 17 It can still meet the issues of “Failed to initialize RAMCode”, even use the mem32 readout the address data, sometimes, the data is not correct, not the real flash data, customer can compare the memory which the data which is readout from the MCUBootUtility. So, the RT-UFL flashdriver code need to be modified to the octal flash, to let the octal flash works. 5.2 RT-UFL Flashloader source code modification     From the analysis of the original RT-UFL combined with the octal flash test, after many modifications and tests, the modification points are listed one by one, the new flashloader file generated by the modified RT-UFL is tested using JFlash, JLINK commander, IDE, etc. JLINK tools are divided into external JLINK plus and onboard JLINK firmware (JFLASH is not supported). 5.2.1 Flashloader modification points 1) RAMCode errors In the JLinkDevices.xml file, define the RAM location to the OCRAM address:     <Device> <ChipInfo Vendor="NXP" Name="MIMXRT1170_UFL_octalFlash" WorkRAMAddr="0x20240000" WorkRAMSize="0x00040000" Core="JLINK_CORE_CORTEX_M7" JLinkScriptFile="Devices/NXP/iMXRT_UFL/iMXRT117x_CortexM7.JLinkScript" Aliases="MIMXRT1176xxx8_M7; MIMXRT1176xxxA_M7" /> <FlashBankInfo Name="Octal Flash" BaseAddr="0x30000000" MaxSize="0x01000000" Loader="Devices/NXP/iMXRT_UFL/MIMXRT_FLEXSPI_UV5_UFL.FLM" LoaderType="FLASH_ALGO_TYPE_OPEN" /> </Device>     2) Add erase sector ROM API The JLINK calls the erase sector, so add the related sector erase API: ufl_main.c     static void ufl_fill_flash_api(void) { ... case kChipId_RT117x: uflTargetDesc->flashDriver.init = g_bootloaderTree_imxrt117x->flexspiNorDriver->init; uflTargetDesc->flashDriver.page_program= g_bootloaderTree_imxrt117x->flexspiNorDriver->page_program; uflTargetDesc->isFlashPageProgram = true; uflTargetDesc->flashDriver.erase_all = g_bootloaderTree_imxrt117x->flexspiNorDriver->erase_all; uflTargetDesc->flashDriver.erase = g_bootloaderTree_imxrt117x->flexspiNorDriver->erase; uflTargetDesc->flashDriver.erase_sector= g_bootloaderTree_imxrt117x->flexspiNorDriver->erase_sector;//kerry add uflTargetDesc->flashDriver.read = g_bootloaderTree_imxrt117x->flexspiNorDriver->read; uflTargetDesc->flashDriver.set_clock_source = NULL; uflTargetDesc->flashDriver.get_config= g_bootloaderTree_imxrt117x->flexspiNorDriver->get_config; uflTargetDesc->iarCfg.enablePageSizeOverride = true; break; … }     ufl_flexspi_nor_flash_imxrt117x.h     typedef struct _flexspi_nor_flash_driver_imxrt117x { uint32_t version; status_t (*init)(uint32_t instance, flexspi_nor_config_t *config); status_t (*page_program)(uint32_t instance, flexspi_nor_config_t *config, uint32_t dst_addr, const uint32_t *src); status_t (*erase_all)(uint32_t instance, flexspi_nor_config_t *config); status_t (*erase)(uint32_t instance, flexspi_nor_config_t *config, uint32_t start, uint32_t lengthInBytes); status_t (*read)(uint32_t instance, flexspi_nor_config_t *config, uint32_t *dst, uint32_t addr, uint32_t lengthInBytes); void (*clear_cache)(uint32_t instance); status_t (*xfer)(uint32_t instance, flexspi_xfer_t *xfer); status_t (*update_lut)(uint32_t instance, uint32_t seqIndex, const uint32_t *lutBase, uint32_t seqNumber); status_t (*get_config)(uint32_t instance, flexspi_nor_config_t *config, serial_nor_config_option_t *option); status_t (*erase_sector)(uint32_t instance, flexspi_nor_config_t *config, uint32_t address);//kerry add status_t (*erase_block)(uint32_t instance, flexspi_nor_config_t *config, uint32_t address); const uint32_t reserved0; status_t (*wait_busy)(uint32_t instance, flexspi_nor_config_t *config, bool isParallelMode, uint32_t address); const uint32_t reserved1[2]; } flexspi_nor_flash_driver_imxrt117x_t;     3) Speed up the erase and program speed FlashDev.c     struct FlashDevice const FlashDevice = { FLASH_DRV_VERS, // Driver Version, do not modify! "MIMXRT_FLEXSPI_RT1170", // Device Name EXTSPI, // Device Type 0x30000000, // Device Start Address 0x01000000, // Device Size in Bytes (16mB) 256*4, // Programming Page Size 0, // Reserved, must be 0 0xFF, // Initial Content of Erased Memory 100, // Program Page Timeout 100 mSec 15000, // Erase Sector Timeout 15000 mSec // Specify Size and Address of Sectors 4096*8, 0x00000000, // Sector Size 4kB (256 Sectors) SECTOR_END };       FlashPrg.c:     int EraseSector (unsigned long adr) { uint32_t instance = g_uflTargetDesc.flexspiInstance; uint32_t baseAddr = g_uflTargetDesc.flashBaseAddr; /*Erase Sector*/ status_t status = flexspi_nor_flash_erase(instance, (void *)&flashConfig, adr - baseAddr, FLASH_DRV_SECTOR_SIZE*8);//kerry *8, 4096 if (status != kStatus_Success) { return (1); } else { return (0); } } int ProgramPage (unsigned long adr, unsigned long sz, unsigned char *buf) { status_t status = kStatus_Success; uint32_t instance = g_uflTargetDesc.flexspiInstance; uint32_t baseAddr = g_uflTargetDesc.flashBaseAddr; uint32_t loadaddr = adr - baseAddr; unsigned char *buffer; buffer = buf; int i; for(i = 0; i < 4; i ++) // kerry add 256*4 { status = flexspi_nor_flash_page_program(instance, (void *)&flashConfig, loadaddr, (uint32_t *)buffer); if (status != kStatus_Success) { return (1); } buffer+=256; loadaddr+=256; } return (0); }     The principle is to reduce the times it takes for the PC to send commands to JLINK and then send to the board, now, one command can directly erase and program multiple blocks. 4) Octal Flash option value polling It should be noted that after Flash Reset, or the first programming, it is necessary to read SFDP in a 1-wire manner. If it is not reset and there is a valid FCB in the flash, the flash is initialized to OPT mode and needs to be read in 8-wire mode. At this time, the valid SFDP table of the flash chip cannot be read in the 1-wire mode. RT-UFL is a flashloader that supports multiple chips, and it does not use specific GPIO as the chip flash_RST. For RT-UFL, GPIO is not added to control flash_RST pin, and a large degree of freedom is reserved. Otherwise, once the customer uses the RST pins that are different from EVK still have problems, and even require customers to spend time modifying the flashloader source code, increasing development time. Therefore, in view of the above considerations, modify the code here, do not add RESET signal control, do not fix option value for 1-wire or 8-wires, but polling the option with 1-wire and 8-wires to read SPDF. ufl_main.c     static void ufl_set_target_property(void) 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 = 0xc0433007; // uflTargetDesc->configOption.option1.U = 0x0; break;     Make sure that the above option are not configured, otherwise the option configuration will be fixed and the polling option function will no longer be enabled. ufl_auto_probe_flash.c     static const serial_nor_config_option_t s_flashConfigOpt[] = { // 1st Pinmux, PortA for octal 1 bit SFDP for no FCB in flash eg. MX25UM51345G {.option0.U = 0xc0403007, .option1.U = 0x00000000}, // 1st Pinmux, PortA for octal 8 bit SFDP for FCB in flash eg. MX25UM51345G {.option0.U = 0xc0433007, .option1.U = 0x00000000}, // 1st Pinmux, PortA for octal 1 bit SFDP &1 bit CMD for no FCB in flash eg. MX25UM51345G {.option0.U = 0xc0400007, .option1.U = 0x00000000}, ..}     After the above modifications, compile the source code project of RT-UFL: RT-UFL-1.0\build\mdk\MIMXRT_FLEXSPI_UV5.uvprojx, Generate a new MIMXRT_FLEXSPI_UV5_UFL.FLM programming algorithm and copy it to the following path: C:\Program Files\SEGGER\JLINKV768B\Devices\NXP\iMXRT_UFL The device name defined in JLinkDevices.xml is: MIMXRT1170_UFL_octalFlash. JLinkDevices.xml path: C:\Program Files\SEGGER\JLINKV768B modify the .xml, and add the above-mentioned "RAMCode error" section. After the modification is completed, refresh the JLinkDLLUpdater.exe file, so that several IDEs can synchronize the firmware defined by the updated xml file. 5.2.2 JFlash Test As can be seen from the test results of Jflash below, it can be successfully erased, and the app image can be downloaded to octal flash. After the download is successful, reset it, and you can see the onboard led is flashing. It shows that the modified RT-UFL flashloader has worked. It should be noted here that the use of JFLASH requires the use of an external Segger JLINK Plus. Some customers use normal JLINK or RT EVK onboard JLINK firmware, then they can try the JLINK commander method. Pic 18 5.2.3 JLINK command Test Use the JLINK plus associated with JLINK commander test result is: Pic 19 You can see that the firmware can be downloaded successfully. Now uses the EVK onboard JLINK firmware to test as follows, it can be seen that the programming is normal, so if users don’t have external JLINK can also directly use the RT EVK onboard JLINK firmware. One thing need to pay attention to is when using the onboard JLINK firmware, the firmware will cause the debugger port USB to not directly supply power to the RT chip, so it needs to be configured that J38 is connected to 3-4, and then find another USB cable to connect J20 to supply power to the board. Pic 20 5.3 MCUXpresso + JLINK +Modified RT-UFL Testing At first, select the MCUXPresso IDE JLINK debug path, add the JLINK driver path which is already added RT-UFL firmware, window->preferences, then the path should like this: Pic 21 When downloading, still need to configure RUN->Debugger configurations, the JLINK configuration should be: Pic 22 Please note, don’t check the item “Reset before running” in the debug configuration, as this item is checked in default. Pic 23 If checked “Reset before running”, when debug it, the code will be blocked after downloading the code, and can’t jump to the main function. If customer click halt button, it will meet the issues that the code is stop at 0x223104, but after exit the debug mode, and do the POR again, you will find the flash already downloaded with the app successfully. Pic 24 This problem is related to the impact of RT1170 security policy on JLINK. For details, please refer to the following link: https://www.cnblogs.com/henjay724/p/15725966.html When JLink is connected to the chip, as long as the reset command is executed, it will directly enter the safe debugging mode (the PC stops at 0x223104). Therefore, make sure that "Reset before running" is not checked, so that you can enter the debug and main functions normally, and the test results are as follows: Pic 25 5.4  MDK+JLINK+Modified RT-UFLTesting Next, use the MCUXPresso CFG tool combined with the SDK package to export an MDK project, also based on the led_blinky project, and modify the FCB code for Octal flash, and then call the modified RT-UFL flashloader, the device name is: MIMXRT1170_UFL_octalFlash. Note, be sure to refresh: C:\Program Files\SEGGER\JLINKV768B\JLinkDLLUpdater.exe Make sure the IDE is using the latest firmware link. The following is a specific MDK project related configuration pictures: Pic 26 The project is selected as flexspi_nor_debug, and after compiling, the debug tool is configured as JLINK, the JLINK simulation sequence can be found, and the updated target before debugging in utilities should not be checked: Pic 27 Pic 28 Pic 29 Modify JlinkSettings.ini,configure override =1, device as the RT-UFL modified firmware device name: MIMXRT1170_UFL_octalFlash. Pic 30 Pic 31 As can be seen from the above picture, the modified RT-UFL Octal flash has been successfully used to run the MDK project. It should be noted that do not use the download button, because this button cannot use the overwritten and modified RT-UFL programming algorithm, it will still call the programming algorithm of the deleted area of ​​the interface, and an error will be reported if it cannot be found. 5.5 IAR + JLINK + Modified RT-UFL Testing Here is the use of IAR combined with JLINK to debug RT1170 octal flash, using the modified RT-UFL programming algorithm. The specific configuration is as follows: Pic 32 Don’t check “use flash loaders”, it means don’t use the IAR attached .out download algorithm, and use the JLINK driver’s modified RT-UFL octal flash flashdriver. Pic 33 Reset can choose core, if it is normal, debug will meet the same issues with the MCUXPresso which checked reset item, PC will stop to 0x223104. Pic 34 Here, modify project settings folder ->.jlink file, use the RT-UFL device name: MIMXRT1170_UFL_octalFlash, And override =1, then it will call the modified RT-UFL flashloader. If you can’t find the .jlink in the new created project, just select the JLINK debugger, click download at first, then it will generate the .jlink file, then modify it and debug it again. Pic 35 After modify the RT-UFL program algorithm to the octal flash, click “download and debug” button, it will enter the debug mode, in the following picture, the code is running successfully: Pic 36 6. Conclusion After the above details, the code download of the MIMXRT1170-EVK on-board octalflash can be realized, and the fsl_romspi project is used to run in RAM, which can verify the normal reading and writing of the hardware octalflash, and MCUBootutility to verify the programming and boot conditions. The modification of APP FCB is matched octal flash. The debugger uses JLINK or CMSIS DAP, and the correct flashdriver programming algorithm needs to be used. In particular, JLINK needs to use the RT-UFL as flashloader, but the source code needs to be modified. Finally, you can see that the combination of RT-UFL download algorithm and JLINK, successfully realize the download and operation of octal flash code on MCUXpresso, IAR, MDK three IDEs. This article is not limited to MIMXRT1170-EVK, but also applies to customer design boards using RT1170+ MX25UM51345GXDI00 octal flash. The attachment adds the modified RT-UFL programming algorithm and the octal flash project of the three major IDEs.  
View full article
RT1170 AVB fresh tasting 1 Abstract AVB (Audio Video Bridging) is the audio and video bridging technology. AVB is also a time-sensitive network. It is mainly used to solve audio and video transmission problems within the local area network: delay problems and synchronization problems. AVB consists of a series of IEEE standards aimed at efficiently transmitting audio and video data in a local area network. The protocol of AVB is as follows: Fig 1 AVB is mainly a link layer protocol and coexists with the traditional TCP/IP protocol.     AVB related protocols include: gPTP (IEEE 802.1AS-2020): Precision time synchronization protocol AVTP (IEEE 1722-2016): Audio and video transmission protocol FQTSS (IEEE 802.1Q-2018, section 34): Credit Based Shaper protocol SRP (IEEE 802.1Q-2018, section 35) :Stream Reservation Protocol AVDECC (IEEE 1722.1-2013): Audio and video management protocol EST (IEEE 802.1Qbv-2015) FP (IEEE 802.3br-2016/IEEE 802.1Qbu-2016) The topology diagram of AVB is as follows: Fig 2 End Station:Listener andTalker Listener: Node that accepts audio and video data Talker: Node that outputs audio and video data AV Bridge:AVB bridge The purpose of this article is not to talk about the AVB protocol. As a first-time experience of AVB with RT1170, it mainly explains how to use the officially provided AVB/TSN protocol stack to implement the AVB audio data transmission function on the NXP MIMXRT1170-EVK board.。 2 .RT1170 AVB testing 2.1 Hardware prepare    2*MIMXRT1170-EVK REV C4,one is Talker,another is Listener.    Pin modification: remove R228, R234, R232, R229 resistor    Board default configuration:      J27:1-2      J5,J6,J7,J8:short connect      J38:5-6      SW1: 1-OFF,2-OFF,3-ON,4-OFF      SW2: 1-OFF,2-OFF,3-OFF,4-OFF,5-OFF,6-OFF,7-OFF,8-OFF,9-OFF,10-OFF      J11: code downloading and vcom port      J4  : 1G ENET, used for AVB communication Fig 3   2.2 Software tool prepare 2.2.1 Related code SDK_2_13_0_MIMXRT1170-EVK: https://mcuxpresso.nxp.com/en/builder?hw=MIMXRT1170-EVK&rel=667 Download the corresponding SDK according to the system which you need to use (windows/linux). For example, download the Linux version for Linux, and download the windows version for windows. This article takes the Linux compilation system as an example, so download the SDK Linux version. genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0.zip: https://mcuxpresso.nxp.com/en/dashboard?download=84124a72b3f5916f99168a06ef287f2f genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0 file includes: Fig 4 Binaries:include RT1170 AVB/TSN bin file, RT1050 AVB bin file. Doc:AVB/TSN stack related document, very important, recommend to read it at first. Genavb-apps-freertos-5_6_0:GenAVB/TSN app examples genavb-sdk –5_6_0.tar.gz GenAVB/TSN SDK supported configuration and device .patch:GenAVB/TSN patch to RT1170,RT1050 SDK   2.2.2 Related software tool Linux platform CMake (>= 3.10.2, tested with 3.16.3) make unzip patch Windows platform CMake (>= 3.10, tested with 3.22.1) minGW-w64 (tested with 4.3.5) 7zip Git with git bash (necessary for patch utility) This document use the linux ubuntu platform, the software version is: Fig 5 A small experience sharing, as the used Ubuntu version is lower, then the installed cmake version is also low, when install the cmake 3.16.3, meet some issues, here share the experience: At first, download cmake-3.16.3-Linux-x86_64.tar.gz: https://github.com/Kitware/CMake/releases/download/v3.16.3/cmake-3.16.3-Linux-x86_64.tar.gz unzip cmake-3.16.3-Linux-x86_64.tar.gz to get cmake-3.16.3-Linux-x86_64: tar -zxvf cmake-3.16.3-Linux-x86_64.tar.gz Add the linker to /usr/bin/cmake: sudo ln -s /home/nxa07323/TSN_GENAVB/cmake-3.16.3-Linux-x86_64/bin/cmake /usr/bin/cmake In /usr/bin/cmake path, use:ls -al, we can see the link information: Fig 6 After the above operation, use : cmake –version We can see the cmake version is cmake 3.16.3, which Fig 5 shows. 2.2.2 Code configuration   To build the AVB code, it also needs to use the RT1170 SDK, the steps are:   Unzip genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0.zip and SDK_2_13_0_MIMXRT1170-EVK_linux.zip Fig 7   Enter SDK_2_13_0_MIMXRT1170-EVK_linux folder path, add genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/ mcuxpresso-sdk-SDK_2_13_0_MIMXRT1170-EVK-5_6_0.patch  Patch add commander is: $ patch -p1 < path/to/mcuxpresso-sdk-SDK_2_13_0_MIMXRT1170-EVK-5_6_0.patch   The real operation command is: patch -p1 < /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/mcuxpresso-sdk-SDK_2_13_0_MIMXRT1170-EVK-5_6_0.patch Fig 8    Add the linker for the SDK and AVB SDK, the structure is: genavb-apps-freertos-5_6_0 ├── boards │ ├── evkbimxrt1050 │ │ ├── demo_apps │ │ └── mcu-sdk -> /path/to/SDK_2_13_0_EVKB-IMXRT1050 (required for RT1052) │ ├── evkmimxrt1170 │ │ ├── demo_apps │ │ └── mcu-sdk -> /path/to/SDK_2_13_0_MIMXRT1170-EVK (required for RT1176) │ └── src │ └── demo_apps └── gen_avb -> /path/to/genavb-sdk-5_6_0 To the RT1170, it contains 2 link: 1)Add the SDK path for the avb sdk board level $ cd path/to/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170 $ ln -s path/to/SDK_2_13_0_MIMXRT1170-EVK mcu-sdk The used situation: For path /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170 It needs to add the SDK path link: /home/nxa07323/avbdoc/SDK_2_13_0_MIMXRT1170-EVK_linux Firstly, unzip the genavb-apps-freertos-5_6_0.tar.gz: tar -zxvf genavb-apps-freertos-5_6_0.tar.gz Fig 9 The commander is: cd /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170 ln -s /home/nxa07323/avbdoc/SDK_2_13_0_MIMXRT1170-EVK_linux mcu-sdk Fig 10   We can see, in the path genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170, already add the SDK path with link, the name is: mcu-sdk. 2)Add the GENAVB/TSN SDK path link to AVB app top level $ cd path/to/genavb-apps-freertos-5_6_0/ $ ln -s path/to/genavb-sdk-5_6_0 gen_avb To /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/ Add the AVB SDK path link:/home/nxa07323/avbdoc/SDK_2_13_0_MIMXRT1170-EVK_linux Unzip genavb-sdk-5_6_0.tar.gz: tar -zxvf genavb-sdk-5_6_0.tar.gz Fig 11 Link commander: cd /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0 ln -s /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-sdk-5_6_0 gen_avb Fig 12 We can see, /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0 path link also added, the name is gen_avb. 2.3 code build   The build file path: genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170/demo_apps/avb_tsn/avb_audio_app/armgcc use build_release.sh file for the linux version. Commander: ./build_release.sh Fig 13 Result: Fig 14 We can see, the avb_app.bin already be generated. File path: /home/nxa07323/avbdoc/genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0/genavb-apps-freertos-5_6_0/boards/evkmimxrt1170/demo_apps/avb_tsn/avb_audio_app/armgcc/release Open avb_app.bin file: Fig 15     We can see, the generated bin file’s RT1170 QSPI FCB. 2.4 Code programming 2.4.1 MSD downloading method     By referring the doc: genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0\doc\NXP_GenAVB_TSN_Stack_FreeRTOS_Eval_User_s_Guide-5_6_rev0.pdf. It is recommended to use the MSD method and directly copy app_avb.bin to the MSD of EVK. However, in the actual test, since there is no information for successful burning progress after copying, it is easy to cause problems. For example, after copying the bin file to the MSD disk (it seems that the copy has been completed), reset or power off the board, but the burning has not actually been completed. At this time, there will be a problem that the code has not been successfully burned, and AVB cannot be successfully run. Therefore, if you use the MSD method, after copying to the MSD, it is best to wait for a period of time to ensure that the code is successfully burned, such as 30s. Fig 16 However, after many tests, the MSD method cannot perform chip mass erase. For example, some filesystem configurations of AVB have been made, but the code needs to be re-downloaded for reconfiguration. It is found that even if app_avb.bin is burned again, the previous AVB configuration is still exists, so if you need a new system file configuration, it is recommended to perform a full chip erase first and then use this method to burn, or directly use the serial download mode to burn.     In addition, some customers may update EVK's opensda version, and sometimes the updated opensda may not have MSD. In this way, it is also recommended to use the following serial download MCUBootutility method to burn.    2.4.2 MCUBootutility downloading method At first, EVK enter the serial download mode: SW1:1-OFF,2-OFF,3-OFF,4-ON Use two USB cables to connect the J11 and J20 SDP, then power off and power on the board or reset the board to enter the serial download mode. MCUBootutility tool download link: https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v5.3.0 Tool related document: https://github.com/JayHeng/NXP-MCUBootUtility   Use the generated avb_app.bin file, and burn it to the MIMXRT1170-EVK board: Fig 17 It should be noted here that from Figure 15 you can see that the bin file stores the FCB starting from 0, but for the MIMXRT1170 chip, the FCB storage is offset by 0X400, so the burning position of avb_app.bin needs to start from 0X30000400. Follow the 7-steps in Figure 17 to burn the bin file. After burning in this way, change SW1 of EVK to: 1-OFF, 2-OFF, 3-ON, 4-OFF, which is the internal boot mode.   AVB testing requires two MIMXRT1170-EVK development boards. The codes burned on the two boards are the same, avb_app.bin is burned in both.   After restarting and testing, you will find that the old filesystem has also been cleared. At this time, you can configure a new system file again.     2.5 talker listener configuration   Two MIMXRT1170-EVK board, one as AVB Talker, another as AVB Listener. Because the programmed app is the same, then just need to use the filesystem to configure which EVK is talker, which is listener.   This document use 2 EVK, and with the back-to-back method, the connection is: Fig 18 Talker: collect the Mic audio data, then transfer to the Listener through the AVB network Listener:receive the talker audio data, play the talker mic audio data through Audio Out J33 2.5.1 Talker filesystem configuration Talker related configuration commander is: ---------------------------------------- cd .. ls mkdir avb_app write avb_app/mclock_role 0 mkdir avdecc write avdecc/btb_mode 0 mkdir fgptp write fgptp/gmCapable 1 mkdir port0 write port0/hw_addr 00:22:33:44:55:66 ----------------------------------------------- The description for the talker configuration: avb_app/mclock_role=0, Media Clock Master. avdecc/btb_mode=0, avdecc back-to-back mode fgptp/gmCapable=1,gPTP grand master port0/hw_addr=00:22:33:44:55:66, configure the hardware address For hw_addr, it should be noted that the first byte must be 00. The author previously configured it as 11, but the communication was always unsuccessful. Through EVK's J11 serial port configuration, after powering on, you can see that the terminal prints a lot of data. First, you need to enter the shell and press the ISERT key. At this time, the terminal will appear >>. For specific shell commands, you can view the documentation: NXP_GenAVB_TSN_Stack_FreeRTOS_Eval_User_s_Guide-5_6_rev0.pdf, Chapter 6.1.1 Filesystem commands. The mainly used commander is: write: write a file with a given string cat: print the content of a file ls: list all files and directories in the current directory rm: remove a file or a directory (if it is empty) cd: change directory pwd: print working directory mkdir: create a directory The following picture is for the shell entry and the file system configuration: Fig 19  According to the Talker command mentioned above, configure the talker file system: Fig 20   Until now, the talker filesystem is configured. 2.5.2 Listener filesystem configuration   Listener related commander is: ------------------------------- cd .. ls mkdir avb_app write avb_app/mclock_role 1 mkdir avdecc write avdecc/btb_mode 1 write avdecc/talker_id 0x00049f4455660000 ------------------------------------------ The description for the listener configuration: avb_app/mclock_role =1, Media Clock Slave. avdecc/btb_mode=1, avdecc fast-connect back-to-back mode avdecc/talker_id =0x00049f4455660000,for fast connect mode configure the talker entity id。 Entity id configuration rule is: eui[0] = 0x00; eui[1] = 0x04; eui[2] = 0x9f; eui[3] = mac_addr[3]; eui[4] = mac_addr[4]; eui[5] = mac_addr[5]; eui[6] = 0x00; eui[7] = 0x00; mac_addr is determined by the hw_addr, eg, talker configure the hw_addr to: 00:22:33:44:55:66, this is the mac_addr[0-5] Then talker_id: eui[0] = 0x00; eui[1] = 0x04; eui[2] = 0x9f; eui[3] = mac_addr[3]=44; eui[4] = mac_addr[4]=55; eui[5] = mac_addr[5]=66; eui[6] = 0x00; eui[7] = 0x00; talker_id =0x00049f4455660000。 Next, configure the Listener file system: Press the computer's insert button to enter shell mode, and then do the filesystem configuration commander input: Fig 21   Until now, the Listener filesystem configuration is finished. 2.6 Test Result Let's start the connection test. Find a network cable to connect two MIMXRT1170-EVK boards, which is the 1G network port J4 of the Talker and the listener. Listener's J33 is inserted into the earphone to listen to the microphone audio data sent from the talker board. Connection picture is as follows: Fig 22 The test result is, when two board power on, after the short time sync, the audio sound collected from the Talker microphone can be heard in the Listener's headphones, indicating that the RT1170 AVB communication is working. Partial log diagrams are given below. The complete logs of talker and listener can be viewed in the attachment. Fig 23 Fig 24 Fig 25 Fig 26 3.Summarization After several testing, we can realize the RT1170 AVB audio transfer function. If the customer don’t want to build the project, just want to do the simple testing, they also can use the AVB/TSN stack’s generated bin file, the path is: \genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_0\binaries\genavb-avb_audio_app-evaluation-freertos_rt1176-5_6_0.tar\genavb-avb_audio_app-evaluation-freertos_rt1176-5_6_0\release\ avb_app.bin This document is just the AVB tasting, for the deeper knowledge, will learn and share it later. Meet issues during the testing: 1). The cmake install during the linux build, which can be found from chapter 2.2.2 Related software tool 2). The printf log is messing, in Tera Term, use the 115200 baudrate to printf, the default printf log is miss order, it is difficult to the detail content, just like this: Fig 27 Solution: Fig 28 Fig 29 After the above configuration, we can see the log is in order. 3). Board programming, at first use the MSD to download the code, but didn’t wait the 30s, then do the power off or the reset, it always causes MSD burning failure, and the generated avb_app.bin , didn’t find the FCB location is not do the 0x400 offset when use the mcubootutility, It also meet issues. So when use the mcubootutility, need to burn from 0x30000400, please refer to chapter 2.4 Code programming 4). Talker filesystem configuration for port0/hw_addr, the first bytes should be 0X00, if none 0, it will have the AVB communication issues, after modify the first byte to the 0X00 in hw_addr, the issue is solved.  
View full article
This guide will walk through how to do connect the camera and LCD modules to i.MX RT boards and how to test to ensure the camera and LCD are connected properly. Update May 2022: There are now updated versions of these LCD panels that have an impact on software. See this post for more details. The physical connections are the same for both the original and new panels however so there are no changes to this guide.   This first part of this guide is for the i.MX RT1050, i.MX RT1060, i.MX RT1064 EVKs. The second part of this guide is for i.MX RT595, i.MX RT1160 and i.MX RT1170 EVKs.      Part 1: Camera and LCD for i.MX RT1050, i.MX RT1060, and i.MX RT1064:  The camera used by the RT1050, RT1060, and RT1064 EVKs are the same. However this camera only comes with the RT1060 and RT1064 EVKs. There are alternatives available for the RT1050 as discussed in this blog post.    The LCD screen compatible with these boards is the RK043FN66HS-CTG    Camera:  1) The camera connector is on the front of the board. Flip the black connector up so it's 90 degrees from its original position.  2) Then slide in the flat ribbon connector of the camera 3) Flip the black connector back down. It should keep the ribbon cable snug.   LCD: 1) On the back of the board, slide the black connector for the LCD ribbon forward. 2) Then slide in the flat LCD ribbon cable underneath the black connector. 3) Slide the black connector back to its original position. The cable should be snug. 4) Do the same for the touch controller connector and slide the black connector forward Then insert the cable between the black connector and the white top so that the cable is in the middle. It might take a few tries as its somewhat difficult. You could also use needle nose pliers to help guide in the cable but be careful about damaging the cable. 5) Then slide the black connector back to the original position. The cable should be snug. 6) It should look like the following when complete.   Testing: 1) To test the camera and LCD, use the CSI driver examples in the MCUXpresso SDK.  2) The camera will likely be out of focus the first time you use it. Adjust it by rotating the lens clockwise until the image is in focus. You can use your fingers or some needle nose pliers. It could take up to two rotations and it should turn easily. Also remove the plastic cover.    3) To test the touch controller, use the emwin temperature control example in the MCUXpresso SDK   Tape: 1) Once the LCD has been confirmed to work, you can use two layers of thick double sided foam tape to securely attach it to the board.      Part 2: Camera and LCD for i.MX RT1160 and i.MX RT1170 EVKs:  The i.MX RT1160 and i.MX RT1170 EVKs both come with a OV5640 MIPI camera module in the box.    The LCD screen compatible with the i.MX RT1160 and i.MX RT1170-EVK is the RK055HDMIPI4MA0 and it can be found here.   i.MX RT1170-EVK Camera:  1) The camera connector is on the front of the board at J2. It connects by simply pressing the camera down onto the connector. It takes a bit of force but should not be too difficult.    i.MX RT1170-EVK LCD: 1) On the back of the board, slide the black connector (J40) for the LCD ribbon forward towards the edge of the board.    2) Then carefully slide in the flat LCD ribbon cable into the connector. The blue writing should be facing up like in the photo. It should go above the black part of the connector that you just slid out, and under the white part of the connector.  3) Slide the black plastic connector back to its original position. The cable should be snug if pulled. It should look like the following:    i.MX RT1170-EVK Power: 1) If using the LCD, then the external power adapter must be used with the board. Connect the barrel connector to J43 on the board. 2) Also change the jumper on J38 to be on pins 1-2 so that it uses the external power.  3) Connect a micro-USB cable to J11, which will cause the board to enumerate as a COM port and as a debug interface for downloading and debugging code   i.MX RT1170-EVK Camera and LCD Testing: 1) To test the camera and LCD, use the csi_mipi_rgb_cm7 driver example that can be found in the MCUXpresso SDK for i.MX RT1170. The camera input should be displayed on the LCD screen if everything is connected properly.          
View full article
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. 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. 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).   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. 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).
View full article
The table below contains notable updates to the current release of the Reference Manual. The information provided here is preliminary and subject to change without notice. ​​​​​​​​​​​​​​​​​​ Affected Modules Issue Summary Description Date QDC Incorrect Input Filter Register (FILT) configuration.  FILT_PRSC bitfield is not implemented in Design. 22 May 2025 ​ ​
View full article
Created by:  jeremyzhou Introduction Normal Cortex-M core-based MCUs generally have built-in parallel NOR Flash. The parallel NOR Flash is directly hung on the Cortex-M core high-performance AHB bus. If a well-known IDE supports the MCU, it should integrate the corresponding Flash driver algorithm which enables the developer to program and debug the MCU in the IDE. However, the i.MX RT series MCU doesn't contain the internal flash, how do developers debug these MCUs with online XIP (eXecute-In-Place)? Take easy, i.MXRT can support external parallel NOR and serial NOR to run the XIP, benefit from saving the number of pins, serial NOR Flash is most commonly used and FlexSPI supports XIP feature which makes online debug available. The article introduces the mechanism of debugging the external serial NOR flash with the RT MCU and illustrates the steps of modifying the flash driver algorithm of MCUXpresso. CoreSight Technical The i.MX RT series MCU is based on the Cortex-M core and the CoreSight Technical is a new debugging architecture launched by ARM in 2004 and is also a part of the core authorization, supports the debug and trace feature for Cortex-M core-based MCU. CoreSight is very powerful. It contains many debugging components (ie various protocols). The following figure is from the CoreSight Technical Introduction Manual, which shows the connections between various debugging components under the CoreSight architecture. Fig 1 CoreSight Technical This article does not mainly aim to introduce CoreSight technical. Therefore, for CoreSight, we only need to know that it in charge of the main debugging work and the CoreSight can access the system memory and peripheral register from the AMBA bus through the DAP component in real-time, definitely, it includes the code in the external serial Flash. FlexSPI module To implement debugging in serial Flash, the code must be XIP in serial Flash, that is, the CPU must be able to fetch instructions and data from any address in serial Flash in real-time. The serial Flash mentioned in this article generally refers to the 4-wire SPI Interface NOR Flash and the SPI mode can be Single/Dual/Quad/Octal. No matter which SPI mode is, the Flash is essentially serial Flash, and the address lines and data lines are not only shared but also serial. According to conventional knowledge, to implement the XIP, Flash should be a parallel bus interface and hung on AMBA, further, this parallel bus should have independent address lines and data lines, and the width of the address lines correspond to the size of Flash. So why can run XIP in serial Flash with i.MXRT? The answer is the FlexSPI peripheral. Figure 2 is the FlexSPI module block diagram. On the right side of the block diagram is the signal connection between FlexSPI and external serial Flash. The left side is the connection between FlexSPI and the internal bus of the i.MXRT system. There are two types of bus interface: 32bit IPS BUS (manual manipulate the FlexSPI register sends Flash reading and writing commands) and 64bit AHB BUS (FlexSPI translates the AHB access address and automatically sends the corresponding Flash reading and writing commands) which is the key feature enables the XIP available. Fig 2 FlexSPI module In the Reference manual, it lists detailed information about the AHB bus: - AHB RX Buffer implemented to reduce read latency. Total AHB RX Buffer size: 128 * 64 Bits - 16 AHB masters supported with priority for reading access - 4 flexible and configurable buffers in AHB RX Buffer - AHB TX Buffer implemented to buffer all write data from one AHB burst. AHB TX Buffer size: 8 * 64 Bits - All AHB masters share this AHB TX Buffer. No AHB master number limitation for Write Access. In addition, the AHB bus includes the below-enhanced features to optimize the reading of Serial Flash memory. - Cachable and Non-Cachable access - Prefetch Enable/Disable - Burst size: 8/16/32/64 bits - All burst type: SINGLE/INCR/WRAP4/INCR4/WRAP8/INCR8/WRAP16/INCR16 Debugging process of serial Flash Fig 3 illustrates the debugging process of serial Flash with the RT series MCU and in basic, the overview of the debugging process is not complicated. When you click IDE debugging icon, the Flash driver algorithm (executable file) pre-installed in the IDE will be downloaded to the internal FlexRAM of i.MXRT via the debugger firstly. The Flash driver algorithm provides FlexSPI initialization, erase and programming APIs, etc. Next, the debugger caches the application code (binary machine code) in FlexRAM in segments prior to calling the Flash programming API to implement the program work. After completing programming application code (from FlexRAM to Flash), CoreSight will take over the debugging work. At this time, the CPU can access the serial Flash that connects the FlexSPI module through the AHB bus, in another word, CoreSight can control and track code in real-time, and single-step debugging is available too in the IDE. Fig 3 Flash Driver of MCUXpresso IDE The latest version (24.12) of MCUXpresso IDE supports all i.Mx RT series MCU (as the following figure shows).   Fig 4 MCUXpresso IDE supported Parts The  developer should select a suitable flash driver file to apply to his board (Fig 5). Fig 5 Flash driver files   For more details about the flashdrivers supported by the MCUXpresso IDE, please refer to the MCUXpresso IDE  User Guide. Specifically check the two following sections : Flash drivers using SFDP (LPC and i.MX RT) and i.MX RT QSPI and Hyper Flash frivers   As mentioned above, the RT series MCUs don't have an internal flash, so they must use an either external parallel or serial NOR. For IDE providers, it's too hard to provide enough flash drivers to fit all external NOR flashes, the workload is huge, so IDEs general provide the flash driver files for mainstream Serial NOR, especially, 4-wire SPI Interface NOR Flash, it means we need to modify or tune the flash driver to fit our specific application. Add new flash driver of MCUXpresso IDE Before start, we should realize that MCUXpresso IDE is different from MDK/IAR. The flash driver algorithms of MDK and IAR are independent of the specific debug tools and they are able to use with all supported debug tools (JLink/DAPLink, etc). For MCUXpresso IDE, the flash driver algorithms are only able to use with the CMSIS-DAP type debug tool. For instance, when you use JLink with MCUXPresso IDE, it will use the flash driver algorithm of Jlink instead of its own. There's a real case from a customer: He currently designs his new card reader module based on RT1024 and he plans to make a board without external RAM and Flash. In other words, he only utilizes the internal 4MB flash and 256KB FlexRAM which consist of SRAM_DTC(64KB), SRAM_ITC(64KB), SRAM_OC(128KB). So he wants to configure the 256KB RAM area as normal 256KB RAM without being allocated to ITCM and DTCM. He follows the thread to reconfigure the FlexRAM, but he still encounters the below problem (as Fig 6 shows ) when entering debug mode. Fig 6 According to the debug failure log, we can come to a conclusion that the flash drive file: MIMXRT1020.cfx needs to be updated, and the following steps illustrate how to do it. a) Select a source project Flashdriver projects  on latest versions of the MCUXpresso IDE are delivered in Linkserver package. You can install Linkersever independently or during the MCUXPresso IDE installation. Therefore If you already installed MCUXpresso IDE you do not need to manually install the Linkserver, unless you want the latest version of Linkserver. If you are using MCUXpresso IDEv24 or above flashdriver projects can be found at  C:\nxp\LinkServer_24.12.21\Examples\Flashdrivers\NXP subdirectory within the MCUXpresso's Linkserver installation directory (as Fig 7 shows) and iMXRT folder contains some flash driver projects for external flash parts that work with the RT series MCU (as Fig 8 shows).   Fig 7   Fig 8 Select the flash driver project which is the closest to the target as a prototype, in this case, we select the iMXRT1020_QSPI project, extract the project file and import them in the MCUXpresso IDE (as Fig 9). Fig 9 b) Modify pin assignment The RT1024 integrates a 4 MB QSPI flash as an "internal flash", it is connected to different FlexSPI pins versus to the default pins of the iMXRT1020_QSPI project just as the below table shows. FlexSPI pin RT1020 RT1024 FLEXSPI_A_DQS GPIO_SD_B1_05 GPIO_SD_B1_05 FLEXSPI_A_SS0_B GPIO_SD_B1_11 GPIO_AD_B1_05 FLEXSPI_A_SCLK GPIO_SD_B1_07 GPIO_AD_B1_01 FLEXSPI_A_DATA0 GPIO_SD_B1_08 GPIO_AD_B1_02 FLEXSPI_A_DATA1 GPIO_SD_B1_10 GPIO_AD_B1_04 FLEXSPI_A_DATA2 GPIO_SD_B1_09 GPIO_AD_B1_03 FLEXSPI_A_DATA3 GPIO_SD_B1_06 GPIO_AD_B1_00 So it needs to adjust the pin initialization in the BOARD_InitPins() function in pin_mux.c. /* FUNCTION ************************************************************************************************************ * * Function Name : BOARD_InitPins * Description : Configures pin routing and optionally pin electrical features. * * END ****************************************************************************************************************/ void BOARD_InitPins(void) { CLOCK_EnableClock(kCLOCK_Iomuxc); /* iomuxc clock (iomuxc_clk_enable): 0x03u */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B0_06_LPUART1_TX, /* GPIO_AD_B0_06 is configured as LPUART1_TX */ 0U); /* Software Input On Field: Input Path is determined by functionality */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B0_07_LPUART1_RX, /* GPIO_AD_B0_07 is configured as LPUART1_RX */ 0U); /* Software Input On Field: Input Path is determined by functionality */ IOMUXC_SetPinMux( IOMUXC_GPIO_SD_B1_05_FLEXSPI_A_DQS, /* GPIO_SD_B1_05 is configured as FLEXSPI_A_DQS */ 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_05 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_06_FLEXSPI_A_DATA03, /* GPIO_SD_B1_06 is configured as FLEXSPI_A_DATA03 */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_06 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_07_FLEXSPI_A_SCLK, /* GPIO_SD_B1_07 is configured as FLEXSPI_A_SCLK */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_07 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_08_FLEXSPI_A_DATA00, /* GPIO_SD_B1_08 is configured as FLEXSPI_A_DATA00 */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_08 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_09_FLEXSPI_A_DATA02, /* GPIO_SD_B1_09 is configured as FLEXSPI_A_DATA02 */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_09 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_10_FLEXSPI_A_DATA01, /* GPIO_SD_B1_10 is configured as FLEXSPI_A_DATA01 */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_10 */ // IOMUXC_SetPinMux( // IOMUXC_GPIO_SD_B1_11_FLEXSPI_A_SS0_B, /* GPIO_SD_B1_11 is configured as FLEXSPI_A_SS0_B */ // 1U); /* Software Input On Field: Force input path of pad GPIO_SD_B1_11 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_00_FLEXSPI_A_DATA03, /* GPIO_AD_B1_00 is configured as FLEXSPI_A_DATA03 */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_00 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_01_FLEXSPI_A_SCLK, /* GPIO_AD_B1_01 is configured as FLEXSPI_A_SCLK */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_01 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_02_FLEXSPI_A_DATA00, /* GPIO_AD_B1_02 is configured as FLEXSPI_A_DATA00 */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_02 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_03_FLEXSPI_A_DATA02, /* GPIO_AD_B1_03 is configured as FLEXSPI_A_DATA02 */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_03 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_04_FLEXSPI_A_DATA01, /* GPIO_AD_B1_04 is configured as FLEXSPI_A_DATA01 */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_04 */ IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_05_FLEXSPI_A_SS0_B, /* GPIO_AD_B1_05 is configured as FLEXSPI_A_SS0_B */ 1U); /* Software Input On Field: Force input path of pad GPIO_AD_B1_05 */ IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B0_06_LPUART1_TX, /* GPIO_AD_B0_06 PAD functional properties : */ 0x10B0u); /* Slew Rate Field: Slow Slew Rate Drive Strength Field: R0/6 Speed Field: medium(100MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B0_07_LPUART1_RX, /* GPIO_AD_B0_07 PAD functional properties : */ 0x10B0u); /* Slew Rate Field: Slow Slew Rate Drive Strength Field: R0/6 Speed Field: medium(100MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_05_FLEXSPI_A_DQS, /* GPIO_SD_B1_05 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_06_FLEXSPI_A_DATA03, /* GPIO_SD_B1_06 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_07_FLEXSPI_A_SCLK, /* GPIO_SD_B1_07 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_08_FLEXSPI_A_DATA00, /* GPIO_SD_B1_08 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_09_FLEXSPI_A_DATA02, /* GPIO_SD_B1_09 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_10_FLEXSPI_A_DATA01, /* GPIO_SD_B1_10 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ IOMUXC_SetPinConfig( IOMUXC_GPIO_SD_B1_11_FLEXSPI_A_SS0_B, /* GPIO_SD_B1_11 PAD functional properties : */ 0x10F1u); /* Slew Rate Field: Fast Slew Rate Drive Strength Field: R0/6 Speed Field: max(200MHz) Open Drain Enable Field: Open Drain Disabled Pull / Keep Enable Field: Pull/Keeper Enabled Pull / Keep Select Field: Keeper Pull Up / Down Config. Field: 100K Ohm Pull Down Hyst. Enable Field: Hysteresis Disabled */ } c) Modify linker file According to Fig 3, a flash driver should be downloaded into FlexRAM on the target MCU during the debuggingprocess, for the iMXRT1020_QSPI project, the flash driver needs to be downloaded to DTCM (0x2000_0000~0x2001_0000), however, to meet the customer's demand, the whole of FlexRAM is reconfigured to SRAM_OC in the ResetISR() function. In another word, there's no DTCM area to load the flash driver and it causes the above debug failure. So we need to use the SRAM_OC instead of DTCM to load the flash driver just like the below shows. In the FlashDriver_32Kbuffer.ld of iMXRT1020_QSPI project: /* * Linker script for NXP LPC546xx SPIFI Flash Driver (Messaged) */ MEMORY { /*SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = (64 * 1024)*/ SRAM (rwx) : ORIGIN = 0x20200000, LENGTH = (64 * 1024) } /* stack size : multiple of 8*/ __stack_size = (4 * 1024); /* flash image buffer size : multiple of page size*/ __cache_size = (32 * 1024); /* Supported operations bit map * 0x40 = New device info available after Init() call * This setting must match the actual target flash driver build! */ __opmap_val = 0x1000; /* Actual placement of flash driver code/data controlled via standard file */ INCLUDE "../../LPCXFlashDriverLib/linker/placement.ld" d) Recompile In the LPCXFlashDriverLib project, select the Release_SectorHashing option prior to clicking the Build icon to generate libLPCXFlashDriverLib.a file (as Fig 10 shows). Fig 10 Next, in the iMXRT1020_QSPI project, select the MIMXRT1020-EVK_IS25LP064 option (as Fig 11 shows), then click the Build icon to generate a new flash driver file that resides in ~\Examples\Flashdrivers\NXP\iMXRT\iMXRT1020_QSPI\iMXRT1020_QSPI\builds directory. Fig 11 Note: I've attached a test project which is based on the hello_world demo that comes from the RT1024's SDK library, in addition, the attachment also contains the new flash driver and corresponding debug script files, so please give it a try.   Debug the  flash driver of MCUXpresso IDE As mentioned on other parts of this document you could change the pin mux assignments and edit the flashdriver. However, before testing your custom flash driver you could do a simple debug. All the flashdriver projects come with a debug build configuration.  Make sure debug build configuration is enabled as shown in Fig 12 Fig 12  After enabling debug build you can simply trigger a standard debug operation, and the IDE will load into SRAM a simple test code. The test code will detect the flash and perform an erase procedure. See Fig 13 Fig 13 In the terminal you will see the output log from the test program.       Edit changes by @diego_charles : Update Fig 7, Fig 8 and a) Select source project , updated  Flash Driver of MCUXpresso IDE section, updated Flash Driver of MCUXpresso IDE section, fig 4, added  Debug the flash Driver of MCUXpresso IDE section    
View full article
​ The table below contains notable updates to the current release of the Reference Manual. The information provided here is preliminary and subject to change without notice. ​​​​​​​​​​​​​​​​​​ Affected Modules Issue Summary Description Date System Boot Incorrect encoding for BOOT_CFG[9] - ECC Selection The encoding for the boot configuration bit for the ECC selection is incorrect. Device ECC should be 0 and Software ECC should be 1. Before:    After:    - ​
View full article
Frequently, we receive questions related to the DQS pins present on i.MXRT whether how to use it and what it is exactly the function of this as well as why it is important to use it. The goal of this document is answering common questions and expose the most common mistakes when connecting this pin. Lets start defining why DQS signal is helpful for memory interfaces; DQS stands as data strobe and it is the clock signal for the data lines used to solve an issue during the memory read. The controller must first transmit the clock to memory, where it arrives x ns later, then the memory sends data bits to the controller and this takes x nanoseconds. There is a clock skew, which limits how fast you can transmit. On iMXRT family it is present on FlexSPI and SEMC interfaces where you can connect multiple memories, it also allows to have multiple configurations as not all memories provide DQS signal on the memory. The next section will detail the particular configuration on each memory interface, RT1170 data will be used but information on RT10xx family is also applicable on this.  SEMC SEMC has two configurations for DQS pad, on DQSMD register.   For DQSMD = 0: We do not have an exact maximum/minimum for the achievable frequency, we only know that when DQSMD we will not reach the maximum SEMC frequency on SDRAM. There could be variations on the frequency on this mode. It is impossible to run at the max 200MHz 1 and meet this input timing spec on datasheet, so the clock frequency needs to be decreased to ensure you still meet timing., this depends on the data output delay spec for the memory that is being used. For DQSMD = 1: As the signal delay is calculated in DQS pad, 200MHz 1 frequency can be achieved on this mode, please consider that the pin needs to be floating or apply extra capacitance on special cases which will be discussed below. As SDRAM device don't output DQS signal, so it take DQS pad as loopback and measure signals delay, and take this delay to compensate and get the correct data strobe point, this can cover most application case and get the good performance, however, if external signal delay is big, it has the complicated topology and long trace, so it can't take DQS pad delay to compensate external SDRAM signal delay. There are two methods to adjust the delay, the first one is using Delay Chain Control Register(DCCR) while the other one is adding capacitance to the DQS pad; unfortunately there is no formula to calculate the register value and capacitance as this is related to SDRAM signal layout, different layout will get the different signal delay. There are some particular cases where more than 3 SDRAMs were added to RT1xx, since the combined memories capacitance exceeded the pad capacitance there were issues using the memory at the max speed; this was solved by adding extra capacitance to DQS pin.   FlexSPI FlexSPI DQS pins behaves similarly as the one we found on SEMC with some difference on the available configuration and maximum speeds. For FlexSPI device there are three different modes of configuration controlled by the RXCLKSRC field on MCR0 register. RXCLKsrc=0x0 (Internal dummy read strobe and internal loopback) In this mode DQS pin not used so an alternative option for this pin can be configured, however the achieved frequency is the lowest as the timings for highest speeds cannot be achieved.   RXCLKsrc=0x1 (Internal dummy read strobe and loopback from DQS pad) In this mode FlexSPI uses DQS pin and it must be configured for the FlexSPI function, it is not an option to use it for a different purpose in this mode. The internally generated read strobe is sent to the DQS pin and is sampled at the pin to match more closely the data pin timings. The timing for sampling with an internal dummy read strobe loopback is very similar to the timing for loopback from pad but it can achieve a higher frequency than loopbacking internally however not the highest one. Similarly to the described on the SEMC side, there are some special cases where signal delay is big, the design has a complicated topology or long traces were the solution is adding extra capacitance to DQS pad, As this is dependent of design there is no formula to calculate the needed capacitance.   RXCLKsrc=0x3 (Flash-memory-provided read strobe) In this mode DQS signal is provided by the connected memory, this mode allows maximum frequency for the memory however only certain memories provide this signal. The FlexSPI controller delays the read strobe for one half cycle of the serial root clock (with DLL), then samples read data with the delayed strobe. Conclusion On i.mxRT family commonly uses external memories to execute code or access important data where good performance on the device is needed. To optimize the access speed of the memory DQS signal is always needed as it may limit the speed rate. 1 Please consult the device specific datasheet for detailed rates.   
View full article
Compared with the RT10xx series, the i.MX RT117x has an additional M4 core, which makes multi-core collaboration possible. The general practice of multi-core operation is to run in independent program data space and communicate through a shared memory space. For example, in the official SDK routine, the M7 code runs in Flash, while the M4 code runs in SRAM, and they communicate from each other via a shared SRAM space, which can ensure the maximum performance. However, during the development stage, customers may need to put both the M7 and M4 codes in external SDRAM for debugging. Although this will affect some performance, it will not perform too many erase and write operations on the flash, which also has certain practical significance.
View full article
 This article provides a generic introduction related to the cryptographical algorithms and HW acceleration. By using i.MX RT117x with related hands-on examples, it aims at helping NXP customers to quickly understand how to use and make a well decision regarding the selection of cryptographic algorithms to use in their products and systems. Note: TL, DR. If the reader has the basic knowledge of the cryptography, please skip to chapter 3. A cryptographic accelerator is a co-processor designed specifically to perform computationally intensive cryptographic operations, there are different names from different chip manufactures. For NXP, ‘CASPER’ on LPC55xx series, but ‘DCP’ or ‘CAAM’ for i.MX and i.MX RT. i.MX RT Name Features i.MXRT10xx   DCP (Data Co-Processor) Symmetric Engines: AES-128 Hash Engines: SHA-1, SHA-256   i.MXRT11xx CAAM  (Cryptographic Acceleration and Assurance Module) Symmetric Engines: AES 128, 192, 256; 3DES, DES; PKHA: RSA, ECDSA,DH,ECDH  Hash Engines: SHA-1, SHA-2, MD5, HMAC Random Number Generation It shows cryptographic features and benchmark performance with 2 examples: Features: CAAM usage in mbedTLS. Performance: Benchmark of HW acceleration or software only   CAAM Features Key Function APIs JobRing0 kCAAM_Sha256 kCAAM_HmacSha1/sha224/384/512 kCAAM_Aes_cbc-128/192/256 RunShaExamples(base,&caamHandle); RunHmacExamples(base,&caamHandle); RunAesCbcExamples(base,&caamHandle); JobRing1 kCAAM_Aes_gcm RunAesGcmExamples(base,&caamHandle); JobRing2 kCAAM_Aes_cbc RunAesCbcExamples(base,&caamHandle); JobRing3 kCAAM_Aes_gcm kCAAM_RNG kCAAM_Red-Block kCAAM_Black-Block kCAAM_CRC RunAesGcmExamples(base,&caamHandle); RunRngExample(base, &caamHandle); RedBlobExample(base, &caamHandle); BlackBlobExample(base, &caamHandle); RunCrcExamples(base, &caamHandle);   Key words: Cryptography, Cryptographic HW Acceleration, i.MX RT   
View full article
Porting JLink RTT to RT595 Porting JLink RTT to RT595         1. Introduction         2. RTT (Real-Time Terminal)         3. Porting                  Steps for Porting         4. Conclusion 1. Introduction For most beginners learning MCU or embedded systems, the first step often involves simple tasks like "lighting up an LED" or a "Hello World" program. Today, we will discuss a topic closely related to "Hello World." Serial output is a highly effective debugging tool, allowing developers to monitor program states, interact with the program, and diagnose issues. This is a familiar friend to anyone engaged in embedded development. The most common approach, as seen in NXP SDK examples, uses a UART peripheral for logging: Initialize the MCU's UART: Configure clock frequency, pin multiplexing, pin settings, baud rate, etc. Open a serial tool on the PC and configure the correct baud rate. Use the UART driver in the project to enable serial logging. This is the simplest and most widely used method for serial output. However, what if the precious UART resource is already occupied? Here's a great alternative: porting SEGGER's RTT (Real-Time Terminal) driver and using the JLink RTT functionality for logging. The biggest advantage of this approach is conserving UART resources! Next, let’s explore the powerful capabilities of JLink RTT. 2. RTT (Real-Time Terminal) RTT, developed by SEGGER, is a real-time terminal solution for interactive communication in embedded applications. Beyond conserving UART resources, RTT offers significant advantages over semi-hosting methods provided by tools like MCUXpresso IDE. RTT allows for high-speed bidirectional data transfer between the MCU and the host without compromising real-time performance. Key features of JLink RTT include: Low Overhead: Efficient data transfer mechanisms ensure minimal impact on target system performance. Real-Time Capability: Developers can output debugging information or receive data from the target system in real time without halting execution. Flexibility: Supports multiple channels for transmitting different types of data, such as debugging logs and performance metrics. OS Independence: Unlike traditional printf debugging methods, RTT can be used on embedded systems without an operating system. JLink RTT typically pairs with JLink debuggers and SEGGER's development tools, providing powerful support for debugging and tracking embedded systems. To try out this functionality, a JLink debugger is essential. Using the classic RT595-EVK as an example, we will demonstrate how to port RTT. 3. Porting The development environment includes the MCUXpresso IDE and the hello_world project from the SDK. The SDK version is not critical. Steps for Porting Locate RTT Resources According to SEGGER's official documentation, RTT resources can be found in the JLink installation directory:   C:\Program Files\SEGGER\JLink\Samples\RTT Copy Required Files Copy the following files to the source folder of the hello_world project: SEGGER_RTT_Syscalls_GCC.c SEGGER_RTT_Conf.h SEGGER_RTT_printf.c SEGGER_RTT.c SEGGER_RTT.h Copy these source files to the source folder of the hello_world project:   Integrate into Project If using Keil or IAR, you may need to add header file dependencies. However, since the RTT files are placed directly in the MCUXpresso project’s source folder, you only need to call the relevant RTT functions in hello_world.c.   Initialize and Configure Buffers Add the following code to initialize RTT and create up/down buffers: SEGGER_RTT_Init(); uint8_t rx_buffer[32], tx_buffer[32]; SEGGER_RTT_ConfigUpBuffer(0, "RTTUP", rx_buffer, sizeof(rx_buffer), SEGGER_RTT_MODE_NO_BLOCK_SKIP); SEGGER_RTT_ConfigDownBuffer(0, "RTTDOWN", tx_buffer, sizeof(tx_buffer), SEGGER_RTT_MODE_NO_BLOCK_SKIP); SEGGER_RTT_SetTerminal(0); SEGGER_RTT_printf(0, "hello world\r\n"); Use RTT for sending: SEGGER_RTT_SetTerminal(0); SEGGER_RTT_printf(0, "hello world\r\n"); Here, after we port the file and add the RTT operation to the source code of hello_world, the code part is ready to be completed. Use JLink RTT Viewer Launch the JLink RTT Viewer program, select the appropriate device number, run the program, and open "Terminal 0" to view the output.   4. Conclusion Compared to traditional UART-based logging, utilizing the debugger’s built-in RTT functionality reduces peripheral usage and eliminates the need for UART initialization and configuration. With JLink, RTT is essentially plug-and-play, providing convenient and fast logging and interaction. In addition to basic functionality, SEGGER offers advanced features such as changing font colors. Explore more on SEGGER's official website: SEGGER RTT Documentation   For Chinese version and demo project, please check this link: https://www.nxpic.org.cn/module/forum/forum.php?mod=viewthread&tid=803638&fromuid=3253523
View full article
Updating Firmware via USB DFU Based on RT1170 Updating Firmware via USB DFU Based on RT1170         Development Environment         Preparing dfu-util                  Steps to Prepare dfu-util         Running the Demo                  Using Prebuilt Firmware from SDK                  Using Custom Firmware Performing microcontroller (MCU) firmware upgrades in the field without the aid of external programming tools is a necessary feature. For MCUs that support USB device controllers, the USB Device Firmware Update (DFU) class offers a solution. the USB_DFU bootloader requires only a PC and a USB cable. The RT series also provides this feature. In the case of the RT1170, for example, a DFU project is provided in the SDK under the USB class. The project is based on the MCUXpresso IDE. by running the dev_dfu_freertos_cm7 project in the SDK, the RT1170 will be enumerated as a dfu device, and after connecting it to the Host PC via another USB cable, the user can use the “dfu-util” utility to download a firmware to this device. Development Environment Software Environment: SDK Version: 2.15.000 IDE: MCUXpresso IDE Demo Project: dev_dfu_freertos_cm7 Host Software: dfu-util Download link: dfu-util For Windows 64-bit: Download dfu-util-0.9-win64.zip   Hardware Environment: Board: RT1170-EVKB   Preparing dfu-util dfu-util is used to download Firmware to a DFU device, but it does not add CRC32 to the Firmware. Since the DFU demo in the SDK verifies the CRC32 to ensure the Firmware written to Flash is free from bit errors, modifications to the dfu-util source code are necessary. Steps to Prepare dfu-util Install Dependencies sudo apt-get build-dep libusb-1.0-0 dfu-util sudo apt-get install gcc-mingw-w64-x86-64 Download dfu-util and libusb Source Code git clone https://git.code.sf.net/p/dfu-util/dfu-util git clone https://github.com/libusb/libusb.git Modify CRC Code in Source Modify the dfu_store_file function in dfu_file.c to add CRC32 to the Firmware suffix. /* write suffix, if any */ if (write_suffix) {     uint8_t dfusuffix[DFU_SUFFIX_LENGTH];     dfusuffix[0] = file->bcdDevice & 0xff;     dfusuffix[1] = file->bcdDevice >> 8;     dfusuffix[2] = file->idProduct & 0xff;     dfusuffix[3] = file->idProduct >> 8;     dfusuffix[4] = file->idVendor & 0xff;     dfusuffix[5] = file->idVendor >> 8;     dfusuffix[6] = file->bcdDFU & 0xff;     dfusuffix[7] = file->bcdDFU >> 8;     dfusuffix[8] = 'U';     dfusuffix[9] = 'F';     dfusuffix[10] = 'D';     dfusuffix[11] = DFU_SUFFIX_LENGTH;     /*crc = dfu_file_write_crc(f, crc, dfusuffix,     DFU_SUFFIX_LENGTH - 4);*/     dfusuffix[12] = crc;     dfusuffix[13] = crc >> 8;     dfusuffix[14] = crc >> 16;     dfusuffix[15] = crc >> 24;     crc = dfu_file_write_crc(f, crc, dfusuffix +     12, 4); }   Build libusb mkdir -p build cd libusb-1.0.24 ./autogen.sh PKG_CONFIG_PATH=$PWD/../build/lib/pkgconfig ./configure --host=x86_64-w64-mingw32 --prefix=$PWD/../build make make install cd .. Build dfu-util cd dfu-util-0.11 ./autogen.sh PKG_CONFIG_PATH=$PWD/../build/lib/pkgconfig ./configure --host=x86_64-w64-mingw32 --prefix=$PWD/../build make make install cd .. After these steps, the newly built tool will be located in the /build/bin folder.   Open cmd for Windows. Run the following command with the new dfu-suffix.exe and CRC32 will be added to the Firmware. dfu-suffix.1 exe -a your_Firmware   Running the Demo Using Prebuilt Firmware from SDK The SDK provides a prebuilt Firmware binary (dev_hid_mouse_bm.bin) that already includes CRC32. Follow these steps: Use MCUXpresso IDE to flash the dev_dfu_freertos_cm7 demo to the EVKB board.     Connect the board to the Host PC via USB.   In the USB Device Descriptor, we find the Vendor ID and Product ID:     Run the following command to download the Firmware: dfu-util.exe -d <your_vid:pid> -D <your_Firmware> After downloading, the DFU demo will verify the CRC32 and execute the new Firmware in RAM. The device will be enumerated as a USB mouse, moving in a rectangular pattern on the screen. Using Custom Firmware When using custom Firmware, ensure that the image is loaded at the correct address (e.g., 0x10000). If the offset is incorrect, the DFU demo will fail to load the Firmware, even if the CRC check passes.   To build and load custom Firmware: Import the hello_world_cm7 project into MCUXpresso IDE. In the Managed Linker Script settings, enable "Link application to RAM".   Adjust memory settings to match the DFU project requirements, ensuring ITCM is the first RAM region.   Build the project and generate a binary file.   Use the modified dfu-util tool to append CRC32 to the binary and download it to the board. Verify that the custom Firmware executes correctly. CRC Added:   New Firmware loaded successfully:   For Chinese version and demo, please check this link:  https://www.nxpic.org.cn/module/forum/forum.php?mod=viewthread&tid=803149&fromuid=3253523
View full article
There are two main methods for importing a project from GUI Guider to MCUXpresso: Linking the whole GUI Guider project into MCUXpresso. Copying and replacing the GUI on a pre-built LVGL project on MCUXpresso (like the "lvgl_guider" SDK example code). Although the first method is quite convenient, there are times when a user might have a GUI already on an established project. In this case, the second method might be very useful. However, when trying to add lottie widgets to a GUI of an already established project (like the "lvgl_guider" SDK example code), extra steps are required, as this widget uses a proprietary library from Samsung which requires extra steps to add and enable. This document describes the steps needed to add rlottie widgets to a project that is already established in MCUXpresso. GUI Guider 1.8.0, MCUXpresso v11.10.0 and SDK 2.16.000 were used for this document, although the process should be the same for future versions.   Once the Lottie widget has been added to the GUI on GUI Guider, you will want to follow the common steps to import this GUI into the MCUXPresso project. Replace the "custom" and "generated" folders on the MCUXpresso project with the GUI Guider folders: <GUI Guider Project Installation>\custom. <GUI Guider Project Installation>\generated.   TIP: You can open the default location of the MCUXpresso project on the file explorer by selecting the project, opening the "Show In" window by pressing Alt + Shift + W, and selecting "System Explorer":   TIP: You can open the default location of the GUI Guider project on the file explorer by clicking on the green folder icon on the top menu bar:   Copy the "lib" folder from: <GUI Guider Project Installation>\lib into the MCUXpresso project.   Copy the "rlottie" folder from: <GUI Guider Project Installation>\sdk\core\rlottie into the MCUXpresso project.   That’s it for file management. Now, in MCUXpresso: Include the "lib" and "rlottie" folders as source folders by adding their path under: Project properties > C/C++ General > Paths and Symbols > Source Location.   Include the rlottie folder as include path by adding its path under the following two compilers' include paths: Project properties > C/C++ Build > Settings > MCU C++ Compiler > Includes > Include Paths.   Project properties > C/C++ Build > Settings > MCU C Compiler > Includes > Include Paths.   As mentioned on the LVGL documentation for "Rlottie player", we need to add the "-rlottie" flag to the linker, but also link the rlottie library (librlottie.a) to the project. This is done by setting the following on Project Properties > C/C++ Build > Settings > MCU C++ Linker > Libraries:   Finally, enable the macro definition: #define LV_USE_RLOTTIE 1 under the "lv_conf.h" file on "source" to tell LVGL that we are using the rlottie library.   With these steps, the rlottie application was imported, along with its headers and libraries, and this rlottie feature was enabled by linking them to the build configuration. Because of this, the application compiles without any errors. Great! Note: There's a possibility that the following error shows up when compiling: If this is the case, simply change the following macro in "source" > "lv_conf.h" from '0' to '1' to enable user data in the lv_font_t variable type:   However, when executing the application, the screen goes black. Turns out, as soon as the application tries to execute the first rlottie instruction from the ".a" archived library, it is unable to execute anything, which causes the application to halt and get stuck on a black screen. This happens as soon as the application calls line 113 of the "lv_rlottie.c" file to construct the rlottie widget: (This file is under <project folder>\lvgl\lvgl\src\extra\libs\rlottie)   But there was no issue when building the application, so what gives? Well, the Rlottie library is quite memory heavy, so we also need to provide it with memory according to its requirements. We can do this by increasing the heap and stack size from their "default" state to something like 0x800000 for the stack and 0x1000 for the heap. These values are what GUI Guider provides to its projects when using Rlottie widgets.   With this, the MCUXpresso project will now have the rlottie libraries enabled, and also have enough memory to successfully debug/run the project on the i.MX RT board.       Happy "Lottie-ing"!   Edwin.
View full article
1. Abstract This article aims to implement the simultaneous input of 4 groups of 48Khz 32bit 2ch audio data on the RT685 platform, and then assemble the received data into a 48Khz 32bit 8ch audio and output it through I2S. This solution is also done at the request of customers, because there are always harmonic problems when customers make it. After analyzing the customer's situation, it is found that the customer has two main problems: (1) Harmonic problem: After receiving 4 channels of 8 bytes, it is directly copied to the sending buffer. This will cause timing problems. It does not take into account the problem of buffering data in the audio data storage pool. The time required to receive enough audio data is at least greater than the time required for copying and sending. Therefore, the problem is reflected in the problem that the customer found harmonic problems when testing the output audio waveform. (2) Audio synchronization problem: After the customer received 4 channels of audio data, he tested the receiving buffer and found that the 4 channels of data were out of sync. Therefore, in order to help customers, I helped customers make this application demo directly, and made a matching test audio source to send a set of 48Khz sampling rate 32bit dual-channel, fixed increment audio data in a loop, such as 0X00-0XFF in a loop. The following is the block diagram of this application platform:   Figure 1 System Block Diagram In the above figure, a MIMXRT685-EVK implements the function of outputting 48Khz, 32bit*2ch, and sends data in a loop: 0X00, 0X01….0XFF. Another MIMXRT685-EVK is the focus of this article, which implements 4 groups of I2S to receive data at a sampling rate of 48khz and 32bit*2ch, and then assembles the received data into audio data with a sampling rate of 48Khz and 32bit*8ch and sends it out. In the above figure, in order to reduce the connection of external lines, for BCLK and WS signals, only one group is directly connected to I2S3, and the other I2S2, I2S4, and I2S5 share the I2S3 signal internally. Then, for DATA data, a line is made externally with 4 heads, and connected to the data pins of each group of audio interfaces respectively. The following is a detailed description of this solution. 2. Hardware platform establish The pinouts of the two boards are given below. Because the platform uses many pins, specific allocation is required. 2.1 Audio source board A MIMXRT685-EVK is used as an audio source, and the pinouts for sending 48Khz 32bit*2ch are as follows:   Figure 2 Pinout of audio source board 2.2 Audio transceiver board Another MIMXRT685-EVK is used as an audio transceiver board to receive 4-channel audio synchronization data sent by the audio source and assemble it into a 48Khz 32bit*8ch waveform for transmission.   Figure 3 Pin assignment of audio transceiver board 2.3 Dual-board hardware connection The source and target connections of the two boards are as follows:   Figure 4 Two board pin connection   Figure 5 two board connection After the hardware is ready, the software solution and code are provided. 3. Software solution and software implementation In the process of writing the code, we tried many solutions, such as: (1) When receiving, directly assemble it into the TDM format buffer to be sent, and then send it. However, since it is assembled into TDM, one I2S needs to receive 8 byte per frame, and then do the offset to receive the next one. If the reception is carried out according to the 8-byte DMA, the callback of the 4 groups of I2S will enter frequently, resulting in a large CPU load, so this solution is abandoned. (2) The 4 groups of I2S are connected to each other, and the 10ms buffer is connected, and then the DMA method is used to copy from memory to memory. However, since the DMA of RT685 is relatively weak, it can only achieve a maximum offset of 32bit 4word=16byte, that is, a 16-byte offset. However, in fact, a group of audio data is 32bit*2, and 4 groups are 32bit*8=32byte offset, so DMA cannot meet the requirements. Therefore, the DMA memory-to-memory copy solution is abandoned and memcpy is used instead. (3) Use the I2S_RxTransferReceiveDMA function to perform DMA reception. However, in fact, when one group is called, it starts receiving directly, and waits until the next group of I2S interfaces calls I2S_RxTransferReceiveDMA. This has caused an asynchronous situation. Even if the I2S enable is turned off in I2S_RxTransferReceiveDMA, the 4th group of I2S is enabled after the several groups of I2S of I2S_RxTransferReceiveDMA are called. This method can only achieve the synchronization of the reception of the first group of data, because later, it is necessary to go to the callback to re-trigger the reception of the second frame of data. Therefore, the callback of the 4 groups of I2S calls I2S_RxTransferReceiveDMA, which will inevitably cause new synchronization problems. Therefore, this method is abandoned and it is considered to use two groups of DMA descriptors to do ping-pong. In this way, the reception will continue in a loop without the intervention of CPU code. 3.1 Solution Implementation Several solutions have been described above. Finally, we choose to use 4 audio channels to receive audio data and cache 10ms audio data buffer. The conversion from receiving buffer to sending buffer adopts memcpy method, and test whether this copy time can meet the actual needs, to ensure that the buffer pool of receiving buffer is greater than this copy time, which is enough to prepare the sending buffer. The solution for receiving data transfer is as follows:   Figure 6 Data buffer transfer The above is 4 groups of I2S receiving their own 10ms data respectively. The buffer is actually prepared for 20ms. A single DMA receives a frame for 10ms, and the other 10ms is used for pingpong buffer. The sending buffer is used to copy the received 4 groups of I2S buffers into a 32bit*8ch array in TDM format, and then two groups of ping-pong buffers are also made. In fact, it is to cache 10ms data. The buffer prepares two groups of 10ms. When the first 10ms frame is received, the second buffer is used to receive it. At the same time, the data of the first buffer is copied to the first buffer of the sending buffer, and the first buffer is used for sending. After the sending is completed, it is transferred to the second buffer to receive and send. In this way, as long as the time is controlled well, there will be no data error problem. The data volume of 10ms is 3840Byte, because the receiving frequency is 48Khz, that is, there are 48000 frames in 1s, and each frame is 32bit*2=8Byte, then 10ms=>4800*8Byte=38400Byte. 3.2 Software code implementation The software code implementation part is mainly divided into 4 I2S receiving signal sharing, I2S DMA pingpong configuration, data transfer, sending I2S and other parts. The details are given below 3.2.1 4-way I2S receiving From the above, we can know that the 4 I2S receiving signal is not completely connected with wires, but adopts the method of sharing BCLK and WS signals and receiving DATA separately. I2S2, I2S4, I2S5 share the BCLK of I2S3, and the WS code is as follows: /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm3); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm3); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm2, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm4, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm5, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); 3.2.2 I2S DMA pingpong configuration In order to achieve 4-channel audio synchronization and receive 10ms audio buffer, two I2S DMA descriptors are used to implement the ping-pong function to collect data to two ping-pong buffers in turn. The code is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static dma_descriptor_t I2S2_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S3_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S4_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static dma_descriptor_t I2S5_s_rxDmaDescriptors[2U], FSL_FEATURE_DMA_LINK_DESCRIPTOR_ALIGN_SIZE); SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); static i2s_transfer_t I2S2_s_RxTransfer[2] = {{ .data = I2S2_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S2_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S3_s_RxTransfer[2] = {{ .data = I2S3_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S3_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S4_s_RxTransfer[2] = {{ .data = I2S4_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S4_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; static i2s_transfer_t I2S5_s_RxTransfer[2] = {{ .data = I2S5_s_Buffer[0], .dataSize = I2S_BUFFER_SIZE, }, { .data = I2S5_s_Buffer[1], .dataSize = I2S_BUFFER_SIZE, }}; I2S_RxGetDefaultConfig(&I2S2_s_RxConfig); I2S2_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S2_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S2_RX, &I2S2_s_RxConfig); I2S_RxGetDefaultConfig(&I2S3_s_RxConfig); I2S3_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S3_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S3_RX, &I2S3_s_RxConfig); I2S_RxGetDefaultConfig(&I2S4_s_RxConfig); I2S4_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S4_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S4_RX, &I2S4_s_RxConfig); I2S_RxGetDefaultConfig(&I2S5_s_RxConfig); I2S5_s_RxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; I2S5_s_RxConfig.masterSlave = DEMO_I2S_TX_MODE;//DEMO_I2S_RX_MODE I2S_RxInit(DEMO_I2S5_RX, &I2S5_s_RxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S2_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S2_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S2_s_DmaRxHandle, DEMO_DMA, DEMO_I2S2_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_DmaRxHandle, I2S2_RxCallback, (void *)&I2S2_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S3_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S3_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S3_s_DmaRxHandle, DEMO_DMA, DEMO_I2S3_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_DmaRxHandle, I2S3_RxCallback, (void *)&I2S3_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S4_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S4_RX_CHANNEL, kDMA_ChannelPriority1); DMA_CreateHandle(&I2S4_s_DmaRxHandle, DEMO_DMA, DEMO_I2S4_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_DmaRxHandle, I2S4_RxCallback, (void *)&I2S4_s_RxTransfer); DMA_EnableChannel(DEMO_DMA, DEMO_I2S5_RX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S5_RX_CHANNEL, kDMA_ChannelPriority2); DMA_CreateHandle(&I2S5_s_DmaRxHandle, DEMO_DMA, DEMO_I2S5_RX_CHANNEL); I2S_RxTransferCreateHandleDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_DmaRxHandle, I2S5_RxCallback, (void *)&I2S5_s_RxTransfer); I2S_TransferInstallLoopDMADescriptorMemory(&I2S2_s_RxHandle, I2S2_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S3_s_RxHandle, I2S3_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S4_s_RxHandle, I2S4_s_rxDmaDescriptors, 2U); I2S_TransferInstallLoopDMADescriptorMemory(&I2S5_s_RxHandle, I2S5_s_rxDmaDescriptors, 2U); if (I2S_TransferReceiveLoopDMA(DEMO_I2S2_RX, &I2S2_s_RxHandle, &I2S2_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S3_RX, &I2S3_s_RxHandle, &I2S3_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S4_RX, &I2S4_s_RxHandle, &I2S4_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } if (I2S_TransferReceiveLoopDMA(DEMO_I2S5_RX, &I2S5_s_RxHandle, &I2S5_s_RxTransfer[0], 2U) != kStatus_Success) { assert(false); } I2S_Enable(DEMO_I2S2_RX); I2S_Enable(DEMO_I2S3_RX); I2S_Enable(DEMO_I2S4_RX); I2S_Enable(DEMO_I2S5_RX); Here, the code has been modified, mainly the I2S_TransferLoopDMA function in fsl_i2s_dma.c, which is blocked: I2S_Enable(base); In order to realize the function of 4-channel synchronous reception. 3.2.3 Audio data received and transferred Because when receiving, each audio interface takes turns to receive its own 2ch data, but when sending, it is necessary to send 4-channel received audio dual-channel data, that is, 32bit*8ch data, so after receiving ping, the ping data needs to be transferred to the sending ping buffer. The code for transfer is as follows: #define I2S_BUFFER_SIZE 3840 //10ms SDK_ALIGN(static uint8_t I2S2_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S3_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S4_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S5_s_Buffer[2][I2S_BUFFER_SIZE], sizeof(uint32_t)); SDK_ALIGN(static uint8_t I2S1_s_Buffer[2][I2S_BUFFER_SIZE*4], sizeof(uint32_t)); if( s_pingpong == 1) { for(ch = 0;ch < 480; ch++) //480=I2S_BUFFER_SIZE(3840)/8 { memcpy(&I2S1_s_Buffer[0][0 + (32*ch)], &I2S2_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][8 + (32*ch)], &I2S3_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][16 + (32*ch)], &I2S4_s_Buffer[0][8*ch], 8); memcpy(&I2S1_s_Buffer[0][24 + (32*ch)], &I2S5_s_Buffer[0][8*ch], 8); } } else { for(ch = 0;ch < 480; ch++) { memcpy(&I2S1_s_Buffer[1][0 + (32*ch)], &I2S2_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][8 + (32*ch)], &I2S3_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][16 + (32*ch)], &I2S4_s_Buffer[1][8*ch], 8); memcpy(&I2S1_s_Buffer[1][24 + (32*ch)], &I2S5_s_Buffer[1][8*ch], 8); } } 3.2.4 Send TDM audio code The sending code also uses the I2S DMA method, but because there is no need to send multiple channels at the same time, only a single channel, there is no need to consider the synchronization problem, and no DMA descriptor is used. After the sending buffer is ready, the I2S_TxTransferSendDMA method is used. The code is as follows: I2S_TxGetDefaultConfig(&I2S1_s_TxConfig); I2S1_s_TxConfig.divider = DEMO_I2S1_CLOCK_DIVIDER; I2S1_s_TxConfig.masterSlave = kI2S_MasterSlaveNormalMaster; I2S1_s_TxConfig.wsPol = true; I2S1_s_TxConfig.mode = kI2S_ModeDspWsLong;//kI2S_ModeDspWsShort; I2S1_s_TxConfig.dataLength = 32U; I2S1_s_TxConfig.frameLength = 32 * 8U; I2S1_s_TxConfig.position = DEMO_TDM_DATA_START_POSITION; I2S1_s_TxConfig.pack48 = true; I2S_TxInit(DEMO_I2S1_TX, &I2S1_s_TxConfig); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel1, false, 64 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel2, false, 128 + DEMO_TDM_DATA_START_POSITION); I2S_EnableSecondaryChannel(DEMO_I2S1_TX, kI2S_SecondaryChannel3, false, 192 + DEMO_TDM_DATA_START_POSITION); DMA_EnableChannel(DEMO_DMA, DEMO_I2S1_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S1_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&I2S1_s_DmaTxHandle, DEMO_DMA, DEMO_I2S1_TX_CHANNEL); I2S_TxTransferCreateHandleDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, &I2S1_s_DmaTxHandle, I2S1_TxCallback, (void *)&I2S1_s_TxTransfer); if( s_pingpong == 1) { I2S1_s_TxTransfer.data = I2S1_s_Buffer[0]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } else { I2S1_s_TxTransfer.data = I2S1_s_Buffer[1]; I2S1_s_TxTransfer.dataSize = I2S_BUFFER_SIZE*4; I2S_TxTransferSendDMA(DEMO_I2S1_TX, &I2S1_s_TxHandle, I2S1_s_TxTransfer); } 3.2.5 Send and receive I2S callback processing For the receiving I2S2, 3, 4, 5, there are 4 channels in total. Each time 10ms of data is received, a callback will be entered. In the callback, you only need to record the flag. When all 4 flags are recorded, it means that the 4 channels of the same 10ms data have been received, and the data can be copied to the sending buffer. Of course, in order to test whether the callback entry frequency is once every 10ms, this article makes a GPIO callback for testing. The following is the code for recording I2S callback static void I2S2_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x01; } static void I2S3_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x02; } static void I2S4_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { s_allRXTriggerred |= 0x04; } static void I2S5_RxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ s_allRXTriggerred |= 0x08; GPIO_PortToggle(GPIO, 1, 1<<0); if( s_pingpong == 0) { s_pingpong = 1; } else { s_pingpong = 0; } } static void I2S1_TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { GPIO_PortToggle(GPIO, 1, 1<<8); //__NOP(); } So far, all functions of a MIMXRT685-EVK for 4 I2S reception and 1 I2S TDM transmission have been completed. 3.2.6 Audio source code The audio source is made on another MIMXRT685-EVK to send 48Khz, 32bit*2ch audio data, and the data is sent in a loop from 0X00 to 0XFF. The code is as follows: int main(void) { BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitDebugConsole(); BOARD_I3C_ReleaseBus(); BOARD_InitI3CPins(); CLOCK_EnableClock(kCLOCK_InputMux); /* attach main clock to I3C (500MHz / 20 = 25MHz). */ CLOCK_AttachClk(kMAIN_CLK_to_I3C_CLK); CLOCK_SetClkDiv(kCLOCK_DivI3cClk, 20); /* attach AUDIO PLL clock to FLEXCOMM1 (I2S1) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM1); /* attach AUDIO PLL clock to FLEXCOMM3 (I2S3) */ CLOCK_AttachClk(kAUDIO_PLL_to_FLEXCOMM3); /* attach AUDIO PLL clock to MCLK */ CLOCK_AttachClk(kAUDIO_PLL_to_MCLK_CLK); CLOCK_SetClkDiv(kCLOCK_DivMclkClk, 1); SYSCTL1->MCLKPINDIR = SYSCTL1_MCLKPINDIR_MCLKPINDIR_MASK; wm8904Config.i2cConfig.codecI2CSourceClock = CLOCK_GetI3cClkFreq(); wm8904Config.mclk_HZ = CLOCK_GetMclkClkFreq(); /* Set shared signal set 0: SCK, WS from Flexcomm1 */ I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_Flexcomm1); I2S_BRIDGE_SetShareSignalSrc(kI2S_BRIDGE_ShareSet0, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_Flexcomm1); /* Set flexcomm3 SCK, WS from shared signal set 0 */ I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalSCK, kI2S_BRIDGE_ShareSet0); I2S_BRIDGE_SetFlexcommSignalShareSet(kI2S_BRIDGE_Flexcomm3, kI2S_BRIDGE_SignalWS, kI2S_BRIDGE_ShareSet0); #if 1 PRINTF("Configure codec\r\n"); /* protocol: i2s * sampleRate: 48K * bitwidth:16 */ if (CODEC_Init(&codecHandle, &boardCodecConfig) != kStatus_Success) { PRINTF("codec_Init failed!\r\n"); assert(false); } /* Initial volume kept low for hearing safety. * Adjust it to your needs, 0-100, 0 for mute, 100 for maximum volume. */ if (CODEC_SetVolume(&codecHandle, kCODEC_PlayChannelHeadphoneLeft | kCODEC_PlayChannelHeadphoneRight, DEMO_CODEC_VOLUME) != kStatus_Success) { assert(false); } PRINTF("Configure I2S\r\n"); #endif /* * masterSlave = kI2S_MasterSlaveNormalMaster; * mode = kI2S_ModeI2sClassic; * rightLow = false; * leftJust = false; * pdmData = false; * sckPol = false; * wsPol = false; * divider = 1; * oneChannel = false; * dataLength = 16; * frameLength = 32; * position = 0; * watermark = 4; * txEmptyZero = true; * pack48 = false; */ I2S_TxGetDefaultConfig(&s_TxConfig); s_TxConfig.divider = DEMO_I2S_CLOCK_DIVIDER; s_TxConfig.masterSlave = DEMO_I2S_TX_MODE; I2S_TxInit(DEMO_I2S_TX, &s_TxConfig); DMA_Init(DEMO_DMA); DMA_EnableChannel(DEMO_DMA, DEMO_I2S_TX_CHANNEL); DMA_SetChannelPriority(DEMO_DMA, DEMO_I2S_TX_CHANNEL, kDMA_ChannelPriority3); DMA_CreateHandle(&s_DmaTxHandle, DEMO_DMA, DEMO_I2S_TX_CHANNEL); StartSoundPlayback(); while (1) { } } static void StartSoundPlayback(void) { PRINTF("Setup looping playback of sine wave\r\n"); s_TxTransfer.data = &g_Music[0]; s_TxTransfer.dataSize = sizeof(g_Music); I2S_TxTransferCreateHandleDMA(DEMO_I2S_TX, &s_TxHandle, &s_DmaTxHandle, TxCallback, (void *)&s_TxTransfer); /* need to queue two transmit buffers so when the first one * finishes transfer, the other immediatelly starts */ I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); I2S_TxTransferSendDMA(DEMO_I2S_TX, &s_TxHandle, s_TxTransfer); } static void TxCallback(I2S_Type *base, i2s_dma_handle_t *handle, status_t completionStatus, void *userData) { /* Enqueue the same original buffer all over again */ i2s_transfer_t *transfer = (i2s_transfer_t *)userData; I2S_TxTransferSendDMA(base, handle, *transfer); } Audio data buffer:   Figure 7 Audio source sends buffer The corresponding test results are given:   Figure 8 Audio source sending data test It can be seen that the data sent by the audio source is cyclical and can be sent in an increasing loop. 4. Test results There are several points to verify about the test results: (1) 4-channel audio receives pingpong buffer, whether a single buffer is 10ms, that is, a 10ms audio data pool. (2) How long is the data memory copy time, whether it will exceed the length of the receiving audio data pool. (3) Whether the received 4-channel data is synchronized, whether the assembled send buffer data is the 32bit*8ch data assembled from the corresponding 4-channel 2ch data. (4) Whether the sent audio waveform is the correct 32bit*8ch TDM data. The following are the verification test results for these points. 4.1 4 I2S audio 10ms data pool This verification is very simple. Define a pin GPIO, initialize the output to 0, and then reverse it in the received callback interrupt. This article chooses to reverse it in the I2S5 callback. The test results are as follows:   Figure 9 ch1 10ms duration Channel 1 is the exact 10ms because of the callback reversal received. Here is a general picture of the test:   Figure 10 Time test overview Ch1: I2S5 callback entry frequency Ch2: memory copy time Ch3: Send callback entry frequency It can be seen that the frequency of sending and receiving is 10ms, because the sending frequency is also 48Khz, but because it is 8ch, the data volume is 4 times that of receiving, and all the data of the 4 receiving channels need to be stuffed in. 4.2 Time consumption of receiving and copying to sending buffer For data copying, that is, assembling the data received from 4 I2S channels into 4 buffers into the sending buffer, this time test is on the second channel of the oscilloscope, and the results are as follows:   Figure 11 copy data time It can be seen that the copying time is less than 500us, which is much shorter than the 10ms of the audio receiving data pool. Therefore, you can use memcpy casually without worrying about the copying time being too long. This also makes up for the regret that I wanted to use DMA for memory to memory copying before, but it could not be realized due to DMA performance issues. 4.3 Verification of the synchronization of the data received on the 4 I2S In order to verify the synchronization, this article closes the 4 I2S receiving channel after receiving 100times 10ms, and prints out the corresponding 4 I2S audio receiving buffer. The results of the 4 I2S buffer are as follows:   Figure12 I2S2 receive buffer   Figure 13 I2S3 receive buffer   Figure 14 I2S4 receive buffer   Figure 15 I2S5 receive buffer It can be seen that the receive buffer data of the 4 I2S are completely synchronized, and all start from 0XB8.   4.4 Send buffer corresponding to 4-channel audio TDM The send buffer is printed after 100 receptions, and then memcpy is performed to the send buffer, and the printout of the send buffer data is as follows:   Figure 16 I2S1 transfer buffer It can be seen that the buffer also starts from 0XB8, and the 4 groups of received data are copied to the send buffer and assembled into 32bit*8ch data. It can be seen that the TDM send buffer is also correct.   4.5 Sending 48Khz 32bit 8ch audio data waveform   Figure 17 Transmitting and receiving audio waveforms The upper group is the waveform of the audio source, and the lower group is the waveform of TDM transmission. Due to the limitation of the analysis software of the logic analyzer, it can only analyze 2ch 64bit data at most, so only part of the data can be seen here, but from the waveform, it can be seen that the waveform of sending TDM can achieve 32bit*8ch, and every 8byte data in a frame is the same, which also explains the synchronization of 4-channel audio reception. In the above figure, the data of ch2 is actually 00, 01, 02, 03, 04, 05, 06, 07, 4 groups of the same data in one frame, and the waveform can also be seen that there are 4 groups of the same data, and 4 groups of 2ch are enough to form 32bit 8ch TDM. Finally, here is another TDM waveform tested on the oscilloscope:   Figure 18 Sending TDM waveform It can be seen that BCLK=12.28Mhz is consistent with the expected 48khz*32bit*8=12.288Mhz. The WS signal is also measured to be 48Khz, which meets the set 48Khz sampling rate. DATA is also transmitting with data changes, and it can be seen that the waveform pattern within a frame is repeated by about 4 groups, which also shows that the 4 groups of received data are synchronized. So far, the function of RT600 4-channel 48KHZ 32bit*2ch input and assembling into 48Khz 32bit*8ch output has been realized!  
View full article
How to create RT AVB switch&endpoint platform 1. Abstract In the previous article, it talked about how to use a single-point RT1170 as a talker and a single-point RT1170 as a listener, and connect the two boards directly to implement AVB endpoint testing. However, in actual use, many applications are multipoint to multipoint, but AVB switch is required. Therefore, based on the previous article, this article adds another listener endpoint and AVB switch to implement an AVB platform with one talker and two listeners. Fig 1 The AVB switch can be a third-party AVB switch product. Of course, you can also consider using NXP's upcoming new product RT1180. This chip has AVB/TSN switch function, and our RT1180 supporting stack has also been released. 2. Platform creation This article will use two AVB switches to do AVB testing: one uses the NXP official MIMXRT1180-EVK as an AVB switch, and the other uses the third-party product MOTU's AVB switch. The endpoints use three NXP MIMXRT1170-EVK boards, one for talker configuration and the other two for listener configuration. For the configuration of RT1170 as endpoint, that is, talker and listener, you can refer to the previous article: RT1170 AVB fresh tasting Here you can directly start quickly, take the avb_app.bin prepared in the stack and burn it directly to MIMXRT1170-EVK for talker and listener configuration. Of course, if there are some customized functions that modify the source code, you can also refer to the above article to recompile, generate the avb_app.bin file and then burn it. 2.1 Software and hardware Hardware:       MOTU AVB SWITCH(switch)       MIMXRT1180-EVK*1(switch)       MIMXRT1170-EVK*3(1: talker, 2: listener), hardware need to be modified, refer to the previous document Software: RT1170 AVB/TSN stack: genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_1: https://mcuxpresso.nxp.com/download/52643189c4d74a7b26b8e096ab28df0e RT1180 AVB/TSN stack: genavb_tsn-mcuxpresso-SDK_2_15_0-6_0_0 : https://mcuxpresso.nxp.com/download/c584c33a8d4f55c29b5505b9be8f537a   2.2 Configure RT1170 AVB endpoints Directly burn the files in avbstack: genavb_tsn-mcuxpresso-SDK_2_13_0-5_6_1\binaries\genavb-avb_audio_app-evaluation-freertos_rt1176-5_6_1.tar\genavb-avb_audio_app-evaluation-freertos_rt1176-5_6_1\release\avb_app.bin to the three MIMXRT1170-EVK development boards and enter the serial download mode to program: Fig 2 The three boards are burned with the same code. After burning, let the board enter the internal boot mode and configure the talker and listener through the serial port. After the code is burned successfully, the onboard serial port will keep sending log information. You only need to enter INSERT on the keyboard to enter the shell command line state. 2.2.1 1MIMXRT1170-EVK do the talker configuration cd .. ls mkdir avb_app write avb_app/mclock_role 0 mkdir avdecc write avdecc/btb_mode 0 mkdir fgptp write fgptp/gmCapable 1 mkdir port0 write port0/hw_addr 00:22:33:44:55:66 2.2.2 2 MIMXRT1170-EVK do the listener configuration cd .. ls mkdir avb_app write avb_app/mclock_role 1 mkdir avdecc write avdecc/btb_mode 1 write avdecc/talker_id 0x00049f4455660000 2.3 AVB Switch configuration     The following are two SWITCH configuration connections: 2.3.1 MOTU AVB Switch Use MOTU AVB switch as the AVB switch connection block diagram: Fig 3   The physical board connections are as follows: Fig 4 For the dedicated AVB switch, no specific configuration is required, because you can think of it as a switch with AVB function, which can realize the forwarding function of AVB data. You only need to connect the 1G network port of a talker and the 1G network ports of two listeners to the network port of MOTU AVB SWITCH. Then as long as the functions of the talker and the listener are normal, the entire audio transmission can be normal. The talker is responsible for collecting the audio data information of the microphone and then forwarding it to the two listeners for playback. Of course, the two listeners need to be connected to the speakers respectively. 2.3.2 RT1180 AVB switch For the configuration of RT1180 AVB switch, there are two methods: quick start and self-compilation. If there is no change in the source code, you can directly use the bin file that comes with the stack. Here you need to pay attention to select the correct bin file. RT1180 has two cores: CM33 and CM7 cores. The CM33 image supports the TSN/AVB bridge function, that is, the switch, and the CM7 image supports the TSN endpoint function.    MIMXRT1180-EVK contains multi-network ports, the situation is: Fig 5 Fig 6 Therefore, when using the AVB switch network port, you need to pay attention to using ENET0, 1, 2, and 3 ports. The connection diagram of using MIMXRT1180-EVK as the AVB switch network port is as follows: Fig 7 The actual connection diagram is as follows: Fig 8 To implement the RT1180 code, you need to download the RT1180 M33 TSN bridge code to the MIMXRT1180-EVK board. If the source code of the AVB/TSN stack does not need to be modified, you can use the ready-made bin file for testing: genavb_tsn-mcuxpresso-SDK_2_15_0-6_0_0\binaries\genavb-tsn_app-evaluation-freertos_rt1189_cm33-6_0_0\release\tsn_app.bin There are many ways to burn, you can use tools or command line methods. The tool can be MCUBootutility or the official SEC tool. Here we choose to use the MCUBootutility tool, download link: https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v6.2.0 If you use the SEC tool to download, you can refer to the stack documentation: genavb_tsn-mcuxpresso-SDK_2_15_0-6_0_0\doc\ NXP_GenAVB_TSN_MCUXpresso_User_s_Guide_6_0_rev0.pdf, chapter 11 Flash Image booting. When use the MCUBootutility tool, it needs to do the modification: \NXP-MCUBootUtility-6.2.0\src\targets\MIMXRT1189 \MIMXRT1189\bltargetconfig.py Modify: #flexspiNorMemBase0 = 0x38000000 # CM33 Secure #flexspiNorMemBase0Ns = 0x28000000 # CM33 Non-Secure To: flexspiNorMemBase0 = 0x28000000 # CM33 Non-Secure flexspiNorMemBase0Ns = 0x38000000 # CM33 Secure Fig 9 Burn the tsn_app.bin to the RT1180 address 0x2800b000。 Let the MIMXRT1180-EVK board enter serial download mode,SW5:1-OFF,2-OFF,3-OFF,4-ON. Then, find another usb cable to connect J33 to do the code flash downloading. After the code is programmed, need to enter the internal boot mode for QSPI: SW5:1-OFF,2-ON,3-OFF,4-OFF. This completes the burning of the app with AVB switch function. This code does not need to enter the shell to configure the filesystem like RT1170. For the RT1180 bridge code, after burning, the switch function will be built-in after restarting. Of course, if you need to recompile your own project, you can directly refer to the stack documentation: NXP_GenAVB_TSN_MCUXpresso_User_s_Guide_6_0_rev0.pdf. If you use Linux system to compile, the method is the same as RT1170, three steps:      (1) Patch the AVB stack for the RT1180 SDK     (2)add two soft links to the RT1180 AVB stack, one for the board SDK and the other for the AVB SDK source code. The structure is as follows:   Fig 10    (3) At last, build ./ build_release.sh \genavb_tsn-mcuxpresso-SDK_2_15_0-6_0_0\genavb-apps-freertos-6_0_0.tar\genavb-apps-freertos-6_0_0\boards\evkmimxrt1180\demo_apps\avb_tsn\tsn_app\cm33\armgcc\ build_release.sh Then, it will generate the according tsn_app.bin file. 3. AVB network data packet analysis I have always wanted to check the AVB network data packets, so I thought of the following method to do it. I also found a general network switch that can package some of the network ports to specific network ports. This method is used here just to check the basic packets. In principle, the general switch does not have the AVB physical layer function, so it should have some impact on the synchronization function. However, due to the limitation of the equipment, this article only has a basic understanding of the AVB data packet structure. Prepare a switch with port mirror function: NETGERA plus switch ProSAFE GS105E. Then configure the switch to mirror the data of ports 2 and 3 to port 1: Fig 11 Then the entire AVB system connection diagram is as follows: Fig 12 The physical connection diagram is as follows: Fig 13 Open the entire system platform and let the system function run, that is, the talker endpoint has sound input and the amplifiers of the two listener endpoints have output. Open the wireshark software on the PC and capture the packets. The captured situation is as follows: Fig 14 As you can see, there are many AVTP packets, and there are two destination addresses. To analyze AVTP packets, you must first know what the standard AVTP packets are like. The standard packets have the following structure: Fig 15 Next, open the wireshark software, configure the network port to be captured, and compare the captured data packets: Fig 16 As you can see, the whole packet is basically captured, but the details, such as VLAN tag and IEC 61883 header, are not present. This is probably caused by the physical layer of ordinary switches cannot support AVB. However, the audio data above can still be seen, and it is indeed dual-channel, but the data is only transmitted through one channel. Therefore, for the RT1170 listener, although a dual-channel speaker is connected, the two speakers correspond to the left and right channels, but when listening, only one speaker channel has sound, and the other has no sound. This is consistent with the captured data packet. The source of this is that the stack code uses one channel for microphone acquisition, and although the audio is configured with two channels, there is actually only one channel with data. So far, the architecture and test of the AVB switch&endpoint platform have been realized. The test effect can be viewed in the video.    
View full article
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: 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: 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:  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.
View full article
1.    Abstract When using the RT600 SDK USB composite example, the customer found that the default HS interval was 125us, and the code was: mimxrt685audevk_dev_composite_hid_audio_unified_bm. However, in actual applications, the 125us packet interval for data transmission will cause a large interrupt load on the CPU, so the customer hopes to change the interval to a larger during, such as 1ms. After changing interval to 1ms, it is found that the data packet can be sent to the RT chip, but there is indeed a problem with the playback on the RT side, speaker no voice. Changing it to 500us in synchronous mode is possible work, but at 500us, the customer's CPU load still reaches more than 80%, which is not convenient for subsequent application code expansion, so it is still hoped to achieve a 1ms method. This article will give the transmission of different intervals of UAC and provide a solution for 1ms intervals. 2.    Test situation    Board:MIMXRT685-AUD-EVK    SDK:SDK_2_15_000_MIMXRT685-AUD-EVK    USB Analyzer:Lecroy USB-TOS2-A01-X 2.1 Platform connection situation First, given the connection between MIMXRT685-AUD-EVK, USB analyzer and audio source. This article mainly tests the RT685 UAC speaker function, that is, USB transmits audio source data to RT685, and plays the audio source through a player (which can be headphones), or speaker. The J7 USB port of EVK is connected to the A port of Lecroy, and the B port of Lecroy is connected to the audio source, which can be a PC or a mobile phone. If using a PC, the speaker needs to be selected as USB AUDIO+HID DEMO, because the name of the board after UAC enumeration is USB AUDIO+HID DEMO. The other end of Lecroy is connected to the PC for transmitting USB bus data. The specific connection diagram is as follows:      Fig 1 EVK USB analyzer connection 2.2 Different audio interval data package situation This chapter gives the modifications under different intervals, as well as the results of USB analyzer packet capture. The clock system of the audio synchronous/isochronous audio endpoint can be synchronized through SOF. The USB 1.0 sampling rate must be locked to the 1ms SOF beat. The USB2.0 high-speed HS endpoint can be locked to the 125us SOF beat. If you want to change the interval, it is usually a multiple of 125us, that is, it can be 250us, 500us, 1ms, etc. The modification method is usually to directly modify the USB stack's usb_audio_config.h:   #define HS_ISO_OUT_ENDP_INTERVAL (0x01) The relationship between HS_ISO_OUT_ENDP_INTERVAL and the real during time is: 125us*2^( HS_ISO_OUT_ENDP_INTERVAL -1) So: HS_ISO_OUT_ENDP_INTERVAL=1 : 125us HS_ISO_OUT_ENDP_INTERVAL=2 : 250us HS_ISO_OUT_ENDP_INTERVAL=3 : 500us HS_ISO_OUT_ENDP_INTERVAL=4 : 1000us The following are the four situations mentioned above respectively through USB analyzer packet capture test. 2.2.1 125us interval packet situation #define HS_ISO_OUT_ENDP_INTERVAL (0x01) Fig 2 125us interval It can be seen that when the interval is configured to 125us, the SOF beat interval in front of each OUT packet is 125us, and the length of the OUT data packet is 24Byte. The data in this 24Byte packet is the actual audio data. In this case, the playback is normal   2.2.2 250us interval packet situation #define HS_ISO_OUT_ENDP_INTERVAL (0x02) The packet capture configured as 250us is shown in the figure below. It can be seen that the SOF beat interval in front of the two OUT packets is 250us, and the length of the OUT data packet is 48 Byte. In other words, as the interval increases, the length of the data packet also increases proportionally, that is, the transmission time is longer, but a packet contains more data packets. At this time, the RT side also needs to provide more USB receiving buffers to receive data. Fig 3 250us interval This situation, the speaker play normally, have the audio sound. 2.2.3 500us interval packet situation #define HS_ISO_OUT_ENDP_INTERVAL (0x03) Fig 4 500us interval SYNC mode At this time, you can see that the data packet has become 96 Bytes, and the data content is also normal audio data, but the playback has problems and no sound can be heard. However, if you configure: #define USB_DEVICE_AUDIO_USE_SYNC_MODE (0U) It is not the SYNC mode, it can hear the audio sound, the packet situation is: Fig 5 500us interval no SYNC mode However, the asynchronous mode also has problems. After a long period of operation, it may become out of sync and the playback may become stuck. Therefore, it is still necessary to use the 1ms method in the synchronous mode. 2.2.4 1ms interval packet situation #define HS_ISO_OUT_ENDP_INTERVAL (0x04) Fig 6 interval 1ms It can be seen that the data packet length has become 192 bytes, and the SOF beat interval in front of the OUT packet has indeed become 1ms. The audio data packet also looks like normal audio data, so the audio data here is successfully transmitted from USB to RT. However, the playback is abnormal and no sound can be heard. 3. 1ms interval solution Now let's debug the project to find the problem. Because the USB analyzer can show that the audio data of the USB bus is actually transmitted, we must first check whether the USB receives the data packet in the kUSB_DeviceAudioEventStreamRecvResponse event in USB_DeviceAudioCompositeCallback of audio_unified.c, whether the data packet length is correct, and whether the data content looks like audio data. The following is the debug result: Fig 7 data packet received situation So from this point of view, the USB interface data packet is received, and the data looks like real audio data. If it is abnormal data, it is either all 0 or irregular data that changes, but the test result cannot be played. So now to check the I2S playback function, composite.h file, TxCallback function: Fig 8 I2S play data buffer We can see, the real data transfer to the I2S data buffer are always 0, and the reality should be g_composite.audioUnified.startPlayFlag none zero, and also use: s_TxTransfer.dataSize = g_composite.audioUnified.audioPlayTransferSize; s_TxTransfer.data=audioPlayDataBuff + g_composite.audioUnified.tdReadNumberPlay; But, after testing, audioPlayDataBuff data are also 0. So the issue should be the USB received side, receive the data, but when save the data to the audioPlayDataBuff have issues, go back to audio_unified.c Fig 9 USB_DeviceAudioCompositeCallback Fig10 USB_AudioSpeakerPutBuffer After testing, in the Fig 9, audioUnified.tdWriteNumberPlay never larger than g_deviceAudioComposite->audioUnified.audioPlayTransferSize * AUDIO_CLASS_2_0_HS_LOW_LATENCY_TRANSFER_COUNT=192*6   #define AUDIO_CLASS_2_0_HS_LOW_LATENCY_TRANSFER_COUNT \ (0x06U) /* 6 means 6 mico frames (6*125us), make sure the latency is smaller than 1ms for sync mode */ The low latency here is a delay buffer. Therefore, the USB cache data must at least be able to hold the delayed data packet. Unit 1 represents an interval frame. Now it is changed to an interval of 1ms, 6 delay units, which means that the delay here is 6ms. Here, the receiving buffer size needs to be larger, which is related to the following definition: Fig 11 USB device callback g_composite.audioUnified.audioPlayBufferSize = AUDIO_PLAY_BUFFER_SIZE_ONE_FRAME * AUDIO_SPEAKER_DATA_WHOLE_BUFFER_COUNT; #define AUDIO_PLAY_BUFFER_SIZE_ONE_FRAME AUDIO_OUT_TRANSFER_LENGTH_ONE_FRAME #define AUDIO_OUT_FORMAT_CHANNELS (0x02U) #define AUDIO_OUT_FORMAT_SIZE (0x02) #define AUDIO_OUT_SAMPLING_RATE_KHZ (48) /* transfer length during 1 ms */ #define AUDIO_OUT_TRANSFER_LENGTH_ONE_FRAME \ (AUDIO_OUT_SAMPLING_RATE_KHZ * AUDIO_OUT_FORMAT_CHANNELS * AUDIO_OUT_FORMAT_SIZE) #define AUDIO_SPEAKER_DATA_WHOLE_BUFFER_COUNT \ (2U) /* 2 units size buffer (1 unit means the size to play during 1ms) */ Here, try to set larger AUDIO_SPEAKER_DATA_WHOLE_BUFFER_COUNT, let it should be at least can put 6ms data, as 1 unit is 1ms play data size, and it needs to have more than 6ms, so, set to 12 unit, the modified definition: #define AUDIO_SPEAKER_DATA_WHOLE_BUFFER_COUNT 12 Build the project and download it, now capture the USB bus data again: Fig 12 1ms interval data packet play successfully   This data waveform is the data that can be played normally. Below is the video of the MIMXRT685-AUD-EVK test. The attachment provides two demos of RT685 and RT1170, both modified to 1ms interval, and the modification method of RT1170 is exactly the same 4.    Summarize Whether it is RT600, RT1170, or more precisely the UAC code of the entire RT series, if you need to modify the interval, the main focus is on the following macros in usb_audio_config.h, the following is for 1ms interval: #define HS_ISO_OUT_ENDP_INTERVAL (0x04)//(0x01)//(0X04) #define AUDIO_CLASS_2_0_HS_LOW_LATENCY_TRANSFER_COUNT \ (0x06U) /* 6 means 16 mico frames (6*125us), make sure the latency is smaller than 1ms for ehci high speed */ #define AUDIO_SPEAKER_DATA_WHOLE_BUFFER_COUNT \ (12U)//(2U) /* 2 units size buffer (1 unit means the size to play during 1ms) */ Test video:
View full article
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: 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: 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 Fig 3 0x40028108 FLEXRAM_CTRL ECC_EN, control FlexRAM ECC 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: 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: Fig 6 The result after Debug is: 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: Fig 8 Debug result is: 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: Fig 10 Debug result is: 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.  
View full article
How to load MDK RAM app to the RT1170 external flash 1. Abstract This guide is requested by our end customer, he wants to realize the MDK project RAM code download to the MIMXRT1170 external QSPI flash. So, based on the NXP RT1170 SDK, and the MIMXRT1170-EVK board, generate the MDK project, reallocate the app image, generate the image, and use the tool to download the code to the external flash. 2. App image prepare 2.1 Generate one SDK MDK standalone project Open the SDK_2_15_000_MIMXRT1170-EVK webpage: https://mcuxpresso.nxp.com/en/builder?hw=MIMXRT1170-EVK Download the SDK, and generate one MDK standalone project: Fig 1 Fig 2 After downloading, we will get the MIMXRT1170-EVK-iled_blinky_cm7.zip, which is the MDK project. 2.2 MDK project image reallocation As the RAM image is the none-xip image, normally to the IDE, can’t download to the flash directly, as the debug is in the RAM. If want to download to the flash, we can generate the app image, then use the tool to program it to the external flash. Normally, none-xip image, the IVT offset is 0X400, so we need to reallocate the image start address, here, we can use 0X2000 as the app entry address. Fig 3 ITCM default size is 256K=0X4000, so modify the linker file-> scf file like this: Fig 4 Now, to generate the hex and bin image file, which is used for the tool downloading. Fig 5 To build the bin file command: $K\ARM\ARMCC\bin\fromelf.exe --bin --output=debug\@L.bin !L Fig 6   Building, you can find the file in the folder: MIMXRT1170-EVK-iled_blinky_cm7\iled_blinky_cm7\debug Fig 7 2.3 MDK project debug after reallocation After the image reallocation, some customer may still need the MDK RAM project can do the debugging, here, also need to modify the debug .ini file. The Setup also need to change the SP, PC and Vector table offset register address. Fig 8 Then build and debug the code, we can find it can enter the ram image debug mode: Fig 9 3. App image download We can use the MCUBootUtility Tool to download the code: https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v6.1.0 the related user manual is: https://github.com/JayHeng/NXP-MCUBootUtility Download the tool. MIMXRT1170-EVK enter the serial download mode by changing SW1: 1-OFF,2-OFF,3-OFF,4-ON Power off and power on the board again, find another USB cable to connect the J20 USB1 interface. Then, use the MCUBootutility to connect the board: Fig 10 After connection, select the MDK project generated .hex file: Fig 11 Press the All-in-One-Action button, to download the code, this is the downloaded result: Fig 12 Press the “Reset device” button to exit the tool. Then MIMXRT1170-EVK board change SW1: 1-OFF, 2-OFF, 3-ON,4-OFF Press the EVK on board reset button, SW4, you will find the LED is blinking, it means the MDK RAM project already download to the external QSPI flash, and boot OK.
View full article