PCA9450A+I.MX8M MINI LPDDR4 Reference Design Materials Please see attached for the PCA9450A+I.MX8M MINI Reference Design Board Materials: Including: 1. Schematic; 2. Layout; 3. Software Patch, unzip password is "NXP"; 4. Software Patch Userguide; PMIC for i.MX

S32G Serial Boot A53 for Image Burning       S32G just support serial download a M7 image to run by internal rom codes, our S32G DS IDE have a flash tools to use this feature to burn the image to external device. So current image burn method will divide into 2 step: 1: burn a uboot into the external device by S32G DS flash tools. 2: reboot the codes with uboot and run with network to burn the linux image into external device.      which need two working place on manufacture line, and customer wish to have a one time on-line tools, which means we need use serial port to boot uboot directly but S32G rom codes do not support it.       We have a reference tools of S32V but which IP difference is big between on S32V and S32G, So we can not reuse it and have to develop a new one.       The development working include: 序号 开发工作 说明 开发者 1 开发 根据S32G的serial boot协议要求，开发PC端的串口工具来下载M7镜像 John.Li 2 开发 根据自定义协议要求，开发PC端的串口工具来下载A核Bootloader到SRAM中 John.Li 3 开发 根据自定义协议要求，开发M7镜像的串口接收与Checksum逻辑 John.Li 4 开发 修改M7镜像支持串口0 John.Li 5 开发 开发实现M7镜像的串口单字节同步收发函数 John.Li 6 开发 开发实现A53启动功能 John.Li 7 调试与Debug 调试解决串口接收乱码问题(Serial boot rom codes仍然在回送消息串口) John.Li 8 调试与Debug 提供 解决A核启动串口halt思路(Serial boot rom codes仍然占用串口) John.Li 9 调试与Debug 优化M7镜像，缩小大小 Tony.Zhang 10 调试与Debug 根据M7镜像和A核 Uboot在SRAM中的内存分配要求，重排M7镜像位置，避免冲突 Tony.Zhang 11 调试与Debug 在M7中初始化SRAM空间 Tony.Zhang 12 调试与Debug 在M7中设置SRAM可执行空间 Tony.Zhang 13 调试与Debug 调试解决由于cache没有及时回写导致的下载镜像错误的问题 Tony.Zhang 14 调试与Debug 集成，调优与文档 John.Li Pls check the attachment for the doc/codes/binary release which include:  Release      |->M7: Linflexd_Uart_Ip_Example_S32G274A_M7: S32DS M7工程。      |->PC: s32gSerialBoot_Csharp: PC端的Visual Studio的C#的串口工具工程。      |->Test:      |    |-> 115200_bootloader.bin: S32DS M7工程编译出来的bin文件，波特率为115200      |    |-> 921600_bootloader.bin: S32DS M7工程编译出来的bin文件，波特率为921600      |    |->load_uboot.bat: 运行工具的批处理文件，运行成功后打开串口可以看到Uboot执行，默认使用的波特率是115299         |    |->readme.txt:其它测试命令 |    |->s32gSerialBoot.exe:编译出来的PC端串口工具 |    |->u-boot.bin: BSP29默认编译出来的u-boot.bin.      Product Category NXP Part Number URL Auto MPU S32G274 https://www.nxp.com/s32g Automotive

Demo code of lpddr4_mr_read for reading MR registers in DRAM BSP: L5.15.5_1.0.0 Platform: i.MX8MPlus EVK Background The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; } Test Result i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project

Running code from external memory with MCX N94x The MCX  N series are MCUs with an integrated flash memory like many traditional MCU series. Having an embedded flash memory is particularly useful, as facilitates board design, development, simplifies BOM, software development.  However, the size of the embedded flash might not meet applications required memory footprint. Some customers simply need more flash memory. For example, Graphical applications require store large image buffers in a non-volatile memory. Data logger devices that need to store large amounts of data. Or heavy inference models for object recognition.  Applications that need to store backup versions of their firmware or are way too complex and big. To solve this requirement the MCX N94x provides the capability to interface a great variety of wider and external memories. There are several traditional options to expand flash storage, but the one we are addressing is the use of external NOR  flash memories. To access an external memory the MCX N94x integrates modules that support external memory interfacing, those are  FlexIO and the FlexSPI. The FlexSPI module is capable of communicating with several kinds of memories. One of them is the Serial NOR flash which can be used as booting device. The goal of this article is to present the solution of a customer case scenario: How to run code from an external flash memory. Demonstrating the flexibility of the MCX N94x platform as well as introducing several tools, peripherals, and concepts that a developer will need to be familiar with while developing an application that runs from an external flash memory. The below figure illustrates the goal of this article, Run code from an external flash memory. The same hello world application can be run from the internal and external memory, for example, a NOR serial QuadSPI memory, without any functionality changes. The core simply will fetch and execute the instructions, using dedicated peripherals like FlexSPI. Figure 1 Executing same code from internal memory vs external memory. The MCX N94x series integrates a FlexSPI module, which enables running code from an external NOR flash memory. Figure 2 MCX N94x block diagram To follow this article, you will need the FRDM-MCXN947 Development board. Which is the evaluation board for the MCX N94x and N54x MCUs. The FRDM-MCXN947 integrates a W25Q64JVSSIQ QuadSPI flash memory. Therefore, this platform is perfect for creating an application that runs from an external flash memory. Figure 3 External NOR flash memory on FRDM-MCXN947 Boot, PFR, and SPSDK With the boot ROM  that the MCX  N integrates you can erase, program, and read the on-chip or external flash memory, which means you can use the boot ROM to download a boot image into the on-chip or external flash memory via the ISP interfaces. This article shows how to load a customized led_blinky demo, from the SDK  to the external flash memory using the boot ROM. However, other application projects may be used as well. Also, the boot ROM takes responsibility for the boot flow. It selects whether to boot from on-chip flash memory, external flash memory, or ISP mode.  The figure below shows an extremely simplified boot flow, which gives an overall understanding of the chip boot flow.  For more details on the boot flow mechanism refer to the section Top-level boot flow of the MCX Nx4x Reference manual. Figure 4 Simplified boot Flow After the reset handling routine, the boot ROM will take control of the chip’s boot flow. It will begin with pertinent chip’s initialization. Then will check the status of the ISP pin. If the ISP pin is currently asserted, the ISP boot handling routine will be executed. ISP or  In-system programming is an execution mode where the boot ROM will wait for commands from an external host, over protocols like UART or USB, to do actions like read and write the chip memory, burn fuses, and many more. If the ISP pin is not asserted, the boot ROM will continue to determine the boot mode. Boot mode can be controlled with the CMPA[BOOT_SOURCE] bit of the CMPA of the PFR or eFUSES. If  CMPA[BOOT_SOURCE]= 01b the boot ROM will run FlexSPI NOR boot handling routine. If CMPA[BOOT_SOURCE] is 00b or 11b internal flash memory handling routine is executed. After the boot mode selection, the image will be validated. If it is not valid, for example, is not present in memory, is corrupted, or does not have proper format,  the ISP boot handling routine is executed. If the image is valid, finally the boot ROM will perform the jump to the user´s application. The default boot flow is by internal flash, most of the SDK examples will be configured to boot from internal flash, as CMPA[BOOT_SOURCE] equals zero by default, or when CMPA area is erased. According to the Simplified bot Flow diagram, we need to make boot ROM go to FlexSPI NOR boot handling routine, to boot from the external flash. Therefore, we need to make   CMPA[BOOT_SOURCE] = 01b. The PFR holds critical boot and security settings that are monitored by the boot ROM after every reset. As just described earlier, the CMPA area can be used to control boot mode. Therefore, PFR areas need to be carefully configured, as they control boot flow and also security features of the chip. The below figure shows a very minimalistic representation of the PFR containing the CMPA, next to the internal flash. Figure 5 PFR's CMPA area For specific details of the PFR  please refer to the MCXNx4x_IFR.xlsx, attached to the MCX Nx4x Reference Manual. To facilitate writing into the CMPA and other areas of the  PFR, signing applications, burning fuses.  programming applications, NXP already developed several host command tools, APIs, and applications and integrated into a python tool called SPSDK. The below figure shows all the tools contained by the SPSDK. To get  details on the SPSDK and description of APIs, Applications, and tools  refer to SPSDK documentation at  https://spsdk.readthedocs.io/en/latest/spsdk.html# Figure 6 SPSDK API modules, applications, and tools The above figure highlights 3 applications, provided by the SPSDK,  that is going to be used to configure the chip to boot from the external flash memory those are: nxpdebugmbox, PRF, and BLHOST. Detailed step-by-step usage of these applications will be described later on.  The nxpdebugmbox application sends interfaces with the chip’s debug mailbox over SWD. The purpose of this tool is set MCU into ISP mode, without having to set low ISP pin,  also to make a mass erase to the chip's memory and PFR. Once the MCU enters ISP mode the host PC will be able to communicate with the boot ROM over UART or USB protocols. This enables the use of PFR and BLHOST applications. The PFR application will be used to write the CMPA[BOOT_SOURCE] = 01b and enable FlexSPI, port to probe and let the chip communicate with the external flash, in the CMPA area of the PFR. The BLHOST application will be used to erase the chip and program application image, in this particular case,  a led_blinky demo.  External Serial NOR flash interfacing The following terms are critical to understand how we can execute code in an external NOR flash memory with the MCX N94x. First of all, Execute-in-Place refers to the capability that the MCU core has to fetch and execute instructions directly from the external memory. It refers to the capability that an MCU has to execute code from the flash memory instead of an internal and traditional flash. To do XIP the MCX  N94x requires a capable peripheral with the ability to fetch instructions from the external memory. The FlexSPI module is capable of doing this. The FlexSPI does support several types of external memories. One of them is Serial NOR Flash. To interface the external memory with the FlexSPI supports SPI. SPI is an excellent serial protocol for short-distance and high-speed communications. The term QuadSPI could be simply understood as an implementation of the SPI protocol, where instead of having a single Data line, there are 4 data lines. SPI also supports two, and eight data lines. Flexible Serial Peripheral Interface (FlexSPI) memory controller supports connection to external serial NOR, NAND, and RAMs. It supports two SPI channels and up to four external devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines). Flexible sequence engine (LUT table) to support various vendor devices (serial NOR, serial NAND, HyperBus, FPGA, etc). Memory-mapped read/write access by AHB Bus AHB RX Buffer implemented to reduce read latency. Total AHB RX Buffer size: 1024 Kbytes 8 flexible and configurable buffers in AHB RX Buffer Software triggered Flash read/write access by IP Bus IP RX FIFO implemented to buffer all read data from External device. FIFO size: 1024 Bytes IP TX FIFO implemented to buffer all Write data to External device. FIFO size: 1024 Bytes DMA support to fill IP TX FIFO DMA support to read IP RX FIFO Figure 7 FlexSPI block diagram FlexSPI system memory map regions are remapped to different addresses at the FlexSPI sub-module: Figure 8 FlexSPI memory map FlexSPI can support serial devices compliant with JESD216. Pre-requisites You will need the following Hardware: FRDM-MCXN947 evaluation board. USB C cable. Windows or Linux PC. You will need to install the following Software. MCUXpresso IDE v11.9.0 or above.  FRDM-MCXN947 SDK v2.15.0 or above.  SPSDK and python.   SPSDK installation and virtual environment We recommend to run the SPSDK on a python virtual environment, as this simplifies the installation of the SPSDK. Before proceeding with installation steps for the SPSDK we recommend to create a folder in your computer. This is where the virtual environment will be running, the SPSDK tools will be called,  and all the files generated by the SPSDK will be stored. Open a terminal, command, or Power Shell prompt  and navigate to your folder and follow the SPSDK installation  commands listed in this guide: Installation Guide — SPSDK documentation            To double check installation of the SPSDK run the following command in your virtual environment. spsdk --version         This figure shows the example of this command and the spsdk version used for this document. Figure 9 SPSDK version.  Setup  This chapter describes all steps to generate and boot an image from the external memory.  To run the commands listed in this document you will need use your python’s virtual environment. Use the virtual environment you created during SPSDK installation.  PFR settings This section describes the settings that need to be done in the MCX N94x PFR and bootable image.      Create CMPA and CFPA yaml  templates   In the following steps, we are going to focus on editing CMPA area since it contains boot-related fields for external execution.  CFPA area is not required to be edited.            Note:The commands used to generate the templates are based on ‘pfr’ tool  For details on the capabilities of these commands, visit: User Guide - pfr — SPSDK documentation First we are going to use pfr to create our yml CMPA/CFPA templates. These templates contain only the default configurations specified for the CMPA and CFPA areas of  device. If the command run successful the templates will be generated. As shown in figure this figures Figure 10 Yaml template created. Edit the CMPA and CFPA yaml templates Open CMPA   template in any text editor and follow the below steps. Set DEFAULT_BOOT_SOURCE to FLEXSPI_FLASH_XIP_0b01 Set FLEXSPI_AUTO_PROBE   to ENABLE Save the changes in the CMPA template.      Create and write the  CMPA and CFPA binaries       After editing the cmpa yaml, you will generate the CMPA/CFPA binaries from the yml templates.   Import and edit image This section shows how to create an XIP bootable image from the  MCUXpresso SDK  led_blinky example.  Import the led_blinky demo from the SDK.  Click on “Import SDK example(s)…” (1), then search and select the FRDM-MCXN947 (2), and click “Next” (3). Inside the “SDK import wizard” search and select the “led_blinky  demo (4) and click on “Finish” (5) Figure 11 Import the blinky example.  Once the demo project is imported open the project properties. Do a right-click in the project’s name (1), then click on “Properties” option (2) and open the project properties(3) Figure 12 Project ´properties Navigate to the Properties> C/C++ Build > MCU settings section Figure 13 MCU settings window Make sure that there are two  Flash areas for the external memory: QSPI_FLASH and             QSPI_FCB as shown in Figure 14. If the areas are missing add them as shown in the next step. Figure 14 External flash areas in the linker. Add the two flash areas for the  QSPI_FLASH and QSPI_FCB in the “Memory details” table, the move them to the Top.  Click in “Add Flash”  (1) twice, then click on “Move selected memory up in table” (2), the two newly created flash areas should be placed at the top. Note: Moving a memory area to the top of the “Memory details” table indicates the linker that text and data should be placed preferably in that area. Update the newly created flash areas name and parameters with the ones from the below table. Type Name Alias Location Size Driver Flash QSPI_FLASH Flash 0x80001000 0xFFFF000 MCXN9xx_SFDP_FlexSPI.cfx Flash QSPI_FCB Flash 2 0x80000400 0x400 MCXN9xx_SFDP_FlexSPI.cfx   Make sure that the flash areas match the ones shown in the Figure 15. Figure 15 Configured flash areas  Click “Build” (1), once compilation is finished, should return 0 errors (2). Figure 16 Successfully compiled image.                                      Note: You should see that the QSPI_FLASH section is being used and that the PROGRAM_FLASH section is not. Generate the binary. Navigate to the project’s debug folder and locate generated .axf (1). Then do a right-click in the .axf, and click on Binary utilities > Create Binary. Figure 17 Create binary. 7 The binary should appear in the debug folder. Get  easily get the binary location by doing a right click on the binary and navigating to  “Show in>System Explorer” Figure 18 Get created binary with ease. 8. Paste the binary into the workspace where you created the cmpa_bin.bin. This step is only to simplify the commands shown later on. Erase and ISP mode entry      ISP (In system programming ) is a mode where a host is able to instruct the ROM bootloader to program a new image or the PFR. The which holds the CMPA field with our configuration to do XIP from the external flash memory. Basically, the Host computer sends commands to the ROM bootloader to program the PFR using NXP’s BLHOST. To enter into ISP mode there are two options: ISP pin entry and Debugger mailbox. ISP pin entry requires keeping ISP pin asserted during reset sequence and de-asserting this pin after reset has been completed. Debugger mailbox only requires to use of a SWD debugger to make the ROM entry ISP mode. To enter into ISP mode over ISP pins follow is necessary keep ISP pin asserted during reset sequence and de-assert this pin after reset has been completed. To use the debugger mailbox is only needed having a debugger. For simplicity, the communication protocol will be USB. However, UART can be used as well. Erase the flash memory and enter ISP mode using the nxpdebugmbox. Proceed to run each command nxpdebugmbox erase  nxpdebugmbox ispmode -m 0 This figure shows the expected output when running the two commands from above. This operation will erase the contents on the internal and external flash memory. Also the PFR contents. Repeating this operation can be useful to get the chip to boot from internal flash memory. Note:  nxpdebugmbox commands need to be run using a SWD-JTAG debugger. For this example on-board debugger of the FRDM-MCXN947 is used. Ping rom Bootloader  Run the following command to ping the rom Bootloader, this way we can ensure that the device was set correctly in ISP mode. blhost  -t 2000 -p COMxxx,115200 -j -- get-property 1 Figure 19 Ping rom Bootloader From now on, an external debugger is not strictly required. The communication with the rom bootloader can be done over UART or USB. For simplicity, the UART protocol-based commands are used from now on in the rest of this document. Write  image and PFR and run demo We are going to follow the steps to write image.  1 Write CMPA binary. pfr write -p COMxxx,115200 -t cmpa -f mcxn9xx -b cmpa_bin.bin 2 Write CFPA binary. pfr write -p COM140,115200 -t cfpa -f mcxn9xx -b cfpa_bin.bin 3 Provide FlexSPI flash memory configuration blhost  -t 2000 -p COMxxx,115200 -- fill-memory 0x20000000 0x04 0xc0000405 4 Configure and fill memory. blhost  -t 2000 -p COMxxx,115200 -- configure-memory 0x09 0x20000000 blhost  -t 2000 -p COMxxx,115200 -- fill-memory 0x20003000 0x04 0xf000000f 5 Erase flash blhost  -t 2000 -p COMxxx,115200 -- flash-erase-region 0x80000000 0x100000 6 Configure memory. blhost  -t 2000 -p COMxxx,115200 -- configure-memory 0x09 0x20003000  7 Write image. blhost  -t 2000 -p COMxxx,115200 write-memory 0x80001000 frdmmcxn947_led_blinky.bin 8 Reset. blhost  -t 2000 -p COMxxx,115200 reset You might use this command or directly press the reset button from the FRDM board. The below image shows the successful execution of each command. Your FRDM-MCXN947  should be blinking by now. Figure 20 Successful image write and reset. Once the board is reset you will notice that the loaded example will begin to execute.  Double-check execution from external flash  To double-check that the image is executing from the external flash you can use the disassembly view from MCUXpresso. 1  Attach the debugger to the running target and place a breakpoint at any part of the code. Figure 21 Attach debugger to a running target. Once your debug probe is discovered, click “OK.” Halt the processor execution. Use the debug button. Figure 22 halt execution. Reset processor. Use the “Restart button”. The program should be stop at the first line of the main function. Figure 23 Breakpoint at main. Find and open the disassembly view. Click on “Instruction Stepping Mode” button or search for disassembly. Any option will open the MCUXpresso “Disassembly” view. Figure 24 Open "Disassembly" view Processor must be running at 0x8000_0000 address space. On the disassembly view you can check that the instructions are executed from address on the range of 0x8000_xxxx which is assigned for external flash. Figure 25 Running code from external flash. If you want to return the device to run from internal memory, then you need to go back to default values. If there are no modifications, to the ones shown in this document,  to the CMPA and CMPA areas, the nxpdebugmbox command can be executed. Board Design Boot ROM|Booting | Flash Clock|Timers Core and Memory MCXA MCXN

Build MATTER chip-tool Android APK in Ubuntu server   Introduction   MATTER chip-tool android APK is a very useful tool for commission, control the MATTER network by smart phone. Vendor can add various features into the APK. It supports build by Android Studio and command line. The official build steps can be found here: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/android_building.md But the official guide does not cover how to build in a non-GUI linux distribution (without Android Studio installed). This article describes how to build under Ubuntu server. Install Android SDK  Install SDK command line from: https://developer.android.com/studio, And follow the steps: https://developer.android.com/tools/sdkmanager to install.  Install the Android-26 SDK and 23 NDK: $./sdkmanager "platforms;android-26" "ndk;23.2.8568313"  Export env  $export ANDROID_HOME=   $export ANDROID_NDK_HOME= /ndk/23.2.8568313/   Install kotlin (1.8.0)  $curl -s https://get.sdkman.io | bash  $sdk install kotlin 1.8.0  $whereis kotlin  $export PATH=$PATH:   Configure proxy for gradle  $ cat ~/.gradle/gradle.properties  # Set the socket timeout to 5 minutes (good for proxies)  org.gradle.internal.http.socketTimeout=300000  # the number of retries (initial included) (default 3)  org.gradle.internal.repository.max.retries=10  # the initial time before retrying, in milliseconds (default 125)  org.gradle.internal.repository.initial.backoff=500  systemProp.http.proxyHost=apac.nics.nxp.com  systemProp.http.proxyPort=8080  systemProp.http.nonProxyHosts=localhost|*.nxp.com  systemProp.https.proxyHost=apac.nics.nxp.com  systemProp.https.proxyPort=8080  systemProp.https.nonProxyHosts=localhost|*.nxp.com    Configure proxy  Configure proxy for download packages during build export FTP_PROXY="http://apac.nics.nxp.com:8080"  export HTTPS_PROXY="http://apac.nics.nxp.com:8080"  export HTTP_PROXY="http://apac.nics.nxp.com:8080"  export NO_PROXY="localhost,*.nxp.com"  export ftp_proxy="http://apac.nics.nxp.com:8080"  export http_proxy="http://apac.nics.nxp.com:8080"  export https_proxy="http://apac.nics.nxp.com:8080"  export no_proxy="localhost,*.nxp.com"    Patch for gradle java option  This step can be skipped if using OpenJDK16.  Otherwise if you're using OpenJDK 17 (Java 61), you have to upgrade the gradle from 7.1.1 to 7.3, and add java.io open to ALL-UNNAMED:  diff --git a/examples/android/CHIPTool/gradle.properties b/examples/android/CHIPTool/gradle.properties  index 71f72db8c8..5bce4b4528 100644  --- a/examples/android/CHIPTool/gradle.properties  +++ b/examples/android/CHIPTool/gradle.properties  @@ -6,7 +6,8 @@  # http://www.gradle.org/docs/current/userguide/build_environment.html  # Specifies the JVM arguments used for the daemon process.  # The setting is particularly useful for tweaking memory settings.  -org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +#org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  +org.gradle.jvmargs=-Xmx4096m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8  --add-opens=java.base/java.io=ALL-UNNAMED  # When configured, Gradle will run in incubating parallel mode.  # This option should only be used with decoupled projects. More details, visit  # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects  diff --git a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  index 05679dc3c1..e750102e09 100644  --- a/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  +++ b/examples/android/CHIPTool/gradle/wrapper/gradle-wrapper.properties  @@ -1,5 +1,5 @@  distributionBase=GRADLE_USER_HOME  distributionPath=wrapper/dists  -distributionUrl=https\://services.gradle.org/distributions/gradle-7.1.1-bin.zip  +distributionUrl=https\://services.gradle.org/distributions/gradle-7.3-bin.zip  zipStoreBase=GRADLE_USER_HOME  zipStorePath=wrapper/dists  Build & Install Clone all the modules from github: $git clone --single-branch --recurse-submodules https://github.com/project-chip/connectedhomeip.git Enviroment setup: $source scripts/bootstrap.sh Build: ./scripts/build/build_examples.py --target android-arm64-chip-tool build Install built apk into phone: $adb install out/android-arm64-chip-tool/outputs/apk/debug/app-debug.apk Android i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano

Example S32K144 LPIT DMA LPSPI ******************************************************************************************** * Detailed Description: * LPIT_ch0 triggers DMA_ch0 periodically (1ms). * Every trigger starts a minor DMA loop (8 bytes) transfer to the LPSPI1 TX FIFO. * There are 8 minor loops per one major loop (64 bytes in 8ms). * LPSPI1 sends two 32bit frames every 1ms. * LPSPI1 RX data are masked, they are not stored in the RX FIFO. * ------------------------------------------------------------------------------ * Test HW: S32K144EVB-Q100 * MCU: S32K144 0N57U * Debugger: S32DS 2.2, OpenSDA * Target: internal_FLASH ********************************************************************************************

RT1170 Octal flash enablement 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: 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.

u-boot runtime modify Linux device tree(dtb) In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime. Here is u-boot fdt command for  How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709 run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2  i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano i.MX6 All i.MX7Dual i.MX7ULP Linux Re: u-boot runtime modify Linux device tree(dtb) Dump dtb content before modifying. .\fdtdump imx8mm-evk.dtb > .\dtb-dump_0.txt Change the status of i2c3: .\fdtput -t s imx8mm-evk.dtb i2c3 status okay Modify clock frequency of i2c0: .\fdtput -t i imx8mm-evk.dtb i2c0 clock-frequency 100000 Check if the changes were successful. .\fdtdump imx8mm-evk.dtb > .\dtb-dump_1.txt Note: use fdt tools in the package dtc_utils-v1.6.1-win-x86_64.zip. Use Grep for Windows instead of saving dump data to files. https://gnuwin32.sourceforge.net/packages/grep.htm

HOWTO: Start Trace with S32 Debugger and S32 Debug Probe on S32V2xx Trace functionality is supported in the S32 Debugger for A53 cores on the S32V, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest. This document outlines the method to begin using Trace on the S32V234 device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project. Create a new application project, selecting the 'S32V234 Cortex-A53' processor and 'S32 Debugger' options.  There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32V234, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list. The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. Click on the configure button to change settings. Click on the Advanced Trace Generators configuration button For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.  To turn on the Trace logging, click on the 'Close this trace stream' button. The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace. Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended. Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data. A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer. Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree. Trace - this is the fully decoded trace data log Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function Call Tree - shows the call tree for identification of the depth of stack utilization See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.

Local Access Windows (LAWs), memory overlap About LAW understanding : about the B4860 , just e.g B4860QDS; Local Access Windows (LAWs): in the B4860_QDS_Init.tcl file have set the Local Access Window Registers (as below have defined the phy address 0x000000, size 2Gbytes target to DDR) and in the  dpaa_demo.c of CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos add the LAW setting the phy address 0x20000000 target  to  QMAN my query or confusing is  the LAW 10 setting (0x0000000~0x7fffffff target to DDR)   memory overlapped with  QMAN software port  LAW setting the phy address 0x20000000 target  to  QMAN. memory overlapped  between LAW , is it ok? and can explain detail why it can work ? there is not descript memory overlapped situation of LAW  in the reference manual of B4860.  ## LAW10 to DDRC2  # LAWBARH  mem [CCSR_ADDR 0x000CA0] = 0x00000000  # LAWBARL  mem [CCSR_ADDR 0x000CA4] = 0x00000000  # LAWAR  mem [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap It’s interesting how local administrative systems handle data integration, especially when managing complex files like local access windows and memory overlap. Navigating these technicalities can sometimes feel as complicated as dealing with a newsportnewscourt.org schedule. Having a reliable, centralized resource to clear up the confusion makes a huge difference. Hopefully, more updates will roll out soon to make these processes much smoother for everyone involved. Re: Local Access Windows (LAWs), memory overlap Thanks for sharing the [RTD200P04 MCAL] S32M244 PWM PDB ADC MCAL demo—really helpful for developers working with embedded systems. For those handling compliance or security logging alongside hardware interfaces, reviewing Missouri offense records could offer useful insights for managing real-world data inputs. Always good to bridge technical applications with broader contextual awareness. Re: Local Access Windows (LAWs), memory overlap Please refer to the B4860 QorIQ Qonverge Multicore Baseband Processor Reference Manual, 2.3.1 Precedence of Local Access Windows.

NXP是否提供用于MC33XS2410原型设计的简易TSSOP28分线/适配器板？ 大家好， 我们目前正在为一个 12V 汽车项目搭建原型和测试平台。根据 NXP 的建议，我们为保护电路选择了 MC33XS2410（电子熔断器）。 然而，由于我们身处组装车间，目前无法设计或制造定制PCB，因此对于手工布线而言，处理HTSSOP28封装（间距为0.65mm，带有散热焊盘）在物理上具有挑战性。 虽然我们知道功能齐全的 FRDM-XS2410EVB 评估板，但它对于我们目前在这个特定测试台上的需求来说太复杂、太大、太贵了。我们只需要一种最简便的方法来访问引脚。 在购买通用第三方适配器（例如 Aries Electronics 的 LCQT-TSSOP28 分线板）之前，我们想先咨询一下 NXP 社区： NXP 是否提供低成本、极简的转接板或原型适配器，专门用于将 MC33XS2410 的 HTSSOP28 封装转换为标准的 2.54mm DIP 引脚？ 如果没有，NXP 是否正式推荐任何经过验证可与该芯片良好配合使用的第三方适配器或插座品牌（考虑到裸露中心焊盘的接地和散热要求）？ 非常感谢您抽出时间提供帮助！ 评估板 StarCore DSP Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 感谢托马斯的解释和注意事项，我想这就是我该如何处理我的卡片的方法。 Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 你好，穆罕默德， 目前我们没有提供专用的低成本转接板或适配器板，可以将 MC33XS2410 HTSSOP28 封装直接转换为标准的 2.54 毫米 DIP 封装。您说得对，我们提供的 FRDM-XS2410EVB 是用于全面功能评估，而不是简单的代码包，软件包适配。 一个重要的考虑因素是 MC33XS2410 封装的裸露散热焊盘，为了保证散热和电气性能，应该将其焊接至 GND。我们还建议将裸露的焊盘连接到接地平面，并且在生产设计中，使用导热过孔来改善散热。 另请注意，通用分线板通常适用于功能原型设计和低功耗台式测试。然而，它们通常无法提供设计合理的 PCB 所能达到的热性能，这可能会限制可以测试的最大连续电流。 如果您的应用需要接近设备的限流运行，我建议您仔细评估其散热性能，或者使用官方评估板。 BRs，托马斯

Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Inspecting last u-boot bootloader contained in Android 16 1.4.0 release I have discovered that an config option "CONFIG_INCLUDE_DTB_TO_VENDOR_BOOT" has been added to the bootloader. I assumed that it fixes the problem, that older Android versions used "dtbo" partition to store the main device tree. In my understanding that was wrong, because main device tree should be placed in "vendor_boot" partition (at least for vendor_boot v4) and dtbo partition gets filled with device tree overlays which can be applied to the main device tree to support hardware variants. See https://source.android.com/docs/core/architecture/partitions/vendor-boot-partitions where it is documented, that only one device tree to be inside vendor_boot. But now NXP has made an implementation to abandon "dtbo" partition and use the "dt_table_header" struct inisde vendor_boot to add more than one full device tree directly to vendor_boot. This header is normally used inside "dtbo" partition to organize multiple device tree overlays, but not inside "vendor_boot". This NXP specific way of handling device trees conflicts with the standard Android way to use one main device tree and device tree overlays from dtbo. This makes it hard for users (like me) who use the concept of device tree overlays to maintain their Android ports. Why has NXP chosen to implemeted device tree variants in that way? Do you have plans to change this behaviour back to the way as documented by Android? Android Re: Android 16: Why has NXP invented an own way to handle device trees in vendor_boot Hello, Please note that having multiple device tree is not mandatory for Android, so unless there is a mandatory change in the architecture of the OS I do not think this will change on how we provide our BSP as this has been the default for many versions so far. Also, note that for selecting the device tree the bootloader needs to: 1> Identify the SoC and load the corresponding .dtb from storage into memory. 2> Identify the board and load the corresponding .dtbo from storage into memory. 3> Overlay the .dtb with the .dtbo to be a merged DT. 4> Start kernel given the memory address of the merged DT. Following this we do not have a way to identify if one device tree should be used or the other, as we use the same hardware and just small changes for different implementation/demonstration, I would see this useful only if you are working with different hardware while using the same SOM (same basic configuration SoC+DDR+power IC). So, this does not comply on how we deliver our hw/sw and see no benefit on adding it. Best regards/Saludos, Aldo.

imx8mmini sai1 最大サンプルレート hi SAI1 Connectのコーデックはサンプルレート768kHz/32bitに対応しています。 SAI1-RX0 codec_DOUT接続。 768kHz/32bitおよびL/Rチャネルで読み取れるデータはありませんが、SAI1-TXFS/SAI1-TXCは768kHz/49.152Mhzを出力可能です。768khz/16bitおよび384khz/32bitのL/Rチャネル読み取りは問題ありません。カーネルバージョン6.1.36です。 ありがとうございます。 Re: imx8mmini sai1 max sample rates コーデックdtsについては以下の通りです。 「-f S32_LE -r 384000 -c 2 -d 1 test.wav」を指定して arecord コマンドを実行します。または「-f S16_LE -r 786000 -c 2 -d 1 test.wav」でも問題ありません。しかし、「-f S32_LE -r 768000 -c 2 -d 1 test.wav」で実行すると、test.wav は NULL になります。 Re: imx8mmini sai1 max sample rates こんにちは、 デバイスツリーの設定を教えていただけますか? どのコーデックを使用していますか？ よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 サンプルレートに関連するエラーが出る場合、クロックソースがそのサンプルレートに必要な周波数を生成できないため、原因かもしれません。 特定のサンプリングレートを得るためには、外部クロックなどの専用のクロックソースを使用する必要がある場合があります。 よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 テスト中にアンダーフローエラーやオーバーフローエラーが発生しますか？ よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates 768kHzの32ビット×2チャンネルで読み取ると、SAI1_TXFS/SAI1_TXC出力は正常(768kHz/49.152MHz)です。コーデックのデータ出力ピン（SAI1_RX0に接続）は、オシロスコープで確認するとデータ出力があります。imx8mminiのSDMAが動作していない可能性はありますか？ Re: imx8mmini sai1 max sample rates テスト中に以下のようなカーネル出力エラーが発生しました。 [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: キャプチャ書き込みエラー (DMA または IRQ の問題?)

Toolbox workflow 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. Figure 5. Embedded Coder. Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.

WhisperはNPU上で動作しています こんにちは、 私は95 i.MX でCPUに縛られたささやきを動かしています NPUを使ってプロセッシング速度を上げる方法はありますか?opsetは主にCNN向けのようですが、いずれにせよ聞いてみる価値はあるでしょう。 具体的な例を見たことがないので、可能かどうかは分かりません（NPUはCNN専用のようですが？）。 既にこれをやった人はいますか？何か例はありますか？

如何缩短 eIQ Toolkit 对包含 6000 张图像的数据集的训练时间？ 我正在使用 eIQ Toolkit 训练一个图像分类模型，数据集大约有 6,000 张图像。我的目标是生成一个小于800 KB的 TensorFlow Lite (TFLite) 模型，以便它可以在MCXN947上运行。 我目前的训练配置是： 型号：MobileNetV2 Alpha：0.35 修剪：已启用 输出格式：TFLite 问题在于，整个培训过程需要近24小时才能完成。我想知道是否有任何推荐的设置或优化方法，可以在将最终模型大小保持在800 KB以下的同时，将训练时间缩短到1-2 小时左右。 有人遇到过类似的情况吗？eIQ Toolkit 中是否有任何最佳实践可以在不显著影响模型准确率或增加模型大小的情况下减少训练时间？ 任何建议都将不胜感激。谢谢你！ FRDM 培训 MCX N Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? 嗨@sivamankomb 对于小型 MobileNetV2-alpha-0.35 迁移学习作业来说，除非训练是在 CPU 上运行、使用较大的输入规模、过多的 epoch、大量的动态增强，或者在整个训练过程中进行剪枝/QAT，否则预计不会出现 24 小时运行约 6,000 张图像的情况。 我认为你可以参考以下内容。 确认已安装并正在使用 CUDA + cuDNN。 使用能够保证可接受精度的最小输入分辨率；如果您使用的是 224×224，请先尝试 128×128。 首先设定较低的训练轮数限制并提前停止，而不是进行固定的长时间训练。 初始训练运行禁用剪枝； 部署时使用 INT8 TFLite 量化； 在第一次速度优化运行中避免使用 QAT； 首先选择“无增强功能”， 具体内容请参阅 eIQ Toolkit 用户指南。 BR 哈里

如何将 C++ TFLite 模型集成到基于 C 的 MCUXpresso 项目中？ 您好，NXP团队， 我正在将 TensorFlow Lite Micro 模型集成到我的 MCUXpresso 项目中，用于 MCXN947。我的应用程序是用 C 编写的，而 TensorFlow Lite Micro 推理代码和生成的模型是用 C++ 编写的。 在合并 C 和 C++ 源文件时，我遇到了编译和链接问题。我已经尝试使用“extern "C"”，但问题仍然存在。 请问您能否就以下问题提供建议？ 在 MCUXpresso 项目中混合使用 C 和 C++ 源文件是否可行？ 将 C++ TensorFlow Lite Micro 模型集成到基于 C 的应用程序中的推荐方法是什么？ 此集成是否需要任何编译器/链接器设置或参考示例？ 任何指导都将不胜感激。谢谢。 开发板 MCX N Re: How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? 你好@sivamankomb ， 感谢你的帖子。 当然，您可以在 MCUXpresso 项目中混合使用 C 和 C++ 源文件。事实上，我们的 SDK 演示也采用了这种方法。您可以参考 SDK 中包含的几个与 eIQ 相关的示例项目。您可以从“选择开发板 | MCUXpresso SDK 构建器”下载 SDK。 要点如下： - .c文件被编译成 C 代码。 - .cpp文件被编译成 C++ 代码。 - 最终的链接阶段必须使用支持 C++ 运行时和 C++ 符号解析的工具链。 - C 代码只能调用通过 extern "C" 包装器公开的函数，而不能直接包含或使用 TFLM C++ 类、模板或命名空间。 因此，推荐的方法是将 TFLM 推理实现封装在一个 .cpp 文件中。文件仅向 C 应用程序公开与 C ABI 兼容的包装接口。 例如，在 SDK 的 tflm_label_image 演示中，核心 TFLM 推理逻辑在 common/tflm/model.cpp 中实现。此文件使用了 TFLM C++ API，例如： #include "tensorflow/lite/micro/micro_interpreter.h" #include "tensorflow/lite/micro/micro_op_resolver.h" static const tflite::Model* s_model = nullptr; static tflite::MicroInterpreter* s_interpreter = nullptr; extern tflite::MicroOpResolver &MODEL_GetOpsResolver(); 然后创建一个 tflite::MicroInterpreter 实例，并在 MODEL_Init() 中调用 AllocateTensors() 来执行初始化。 外部暴露的模型.h，提供 C 语言友好的接口。 #if defined(__cplusplus) extern "C" { #endif status_t MODEL_Init(void); uint8_t* MODEL_GetInputTensorData(tensor_dims_t* dims, tensor_type_t* type); uint8_t* MODEL_GetOutputTensorData(tensor_dims_t* dims, tensor_type_t* type); void MODEL_ConvertInput(uint8_t* data, tensor_dims_t* dims, tensor_type_t type); status_t MODEL_RunInference(void); const char* MODEL_GetModelName(void); #if defined(__cplusplus) } #endif 函数声明通过 extern "C" 导出，这样 C 源文件就可以简单地 #include "model.h"无需了解 tflite::MicroInterpreter 或 MicroMutableOpResolver 等 C++ 类型，即可调用 MODEL_Init() 和 MODEL_RunInference() 等函数。 这种架构也是我们的 SDK 示例所采用的方法，并且在将 TFLM 集成到基于 C 的应用程序中时通常建议采用这种方法，因为它能够干净利落地隔离 C++ 实现细节，同时为应用程序层保留纯 C 接口。 如果您想将客户 ML 模型集成到 SDK 演示中，您可以参考AN14241 。 希望对您有所帮助。 BR 塞莱斯特

TI LSF0204を交換してください。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 NXP NTB0104をTI LSF0204の代替品として直接使用することは可能でしょうか？ あるいは回路の変更が必要でしょうか？ 追伸:UARTインターフェース、1.8Vから3.3Vまでです。 本当にありがとうございます。 Re: Replace TI LSF0204 コントローラーから1.8VのUARTのTX信号とRX信号を3.3V、さらにBERGピンに変換するためにNTB0104を使っています。うまくいかなかった。しかし、NTB0104をNTS0104に交換したら正常に動作しました。その理由は何でしょうか？ Re: Replace TI LSF0204 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NXP製品に興味を持ってくださりありがとうございます。 はい、直接交換できます。 よろしくお願いいたします

MIMXRT1170およびMIMXRT1180における外部メモリインターフェースのECCサポートについての説明が必要です NXPチームの皆様、こんにちは。 メモリの整合性が重要な要件である重要なアプリケーションに対して、 MIMXRT1170 と MIMXRT1180 を評価しています。そのため、これらのデバイスにおける正確なECCカバレッジを理解することは、当社のアーキテクチャ設計およびデバイス選定プロセスにおいて非常に重要です。 利用可能なドキュメントを検討したものの、 どの外部メモリインターフェースがECC保護を提供し、そのECCがどのように実装されているかについて明確な概要を見つけることができませんでした。 1. 外部インターフェースECCカバレッジ MIMXRT1170とMIMXRT1180の両方で、以下のインターフェースのうちどれがECCをサポートしていますか? FlexSPI NORフラッシュ FlexSPI HyperFlash FlexSPI HyperRAM SEMC SDRAM SEMC SRAM/PSRAM EMMC SDカード・インターフェース その他の外部メモリインターフェース(該当する場合) 2. ECCの実装 対応する各インターフェースについて: ECCはハードウェアコントローラーからネイティブで提供されていますか? ECCはハードウェアで自動的にアクティブですか、それともソフトウェアの設定が必要ですか? 3. XECCの使用方法（RT1170） リファレンスマニュアルではXECCモジュールについて論じています。しかし、それが外部記憶とどのように関係しているかは完全には明確ではありません。 もう少し詳しく教えていただけますか: XECCで保護できるメモリやインターフェースはどれですか? XECCは内部メモリ専用ですか?それとも外部SDRAM、SRAM、HyperRAM、フラッシュなどに保存されたデータを保護することも可能でしょうか? 外部メモリインターフェースに対するXECC保護を示す使用例やアプリケーションノートはありますか? よろしくお願いいたします。 プージャ Re: Clarification Required on ECC Support for External Memory Interfaces in MIMXRT1170 and MIMXRT118 i.MX RT1170 ECCアプリケーションECCのイネーブルメントについては、AN13204を参照してください。 ECCは主に内部メモリ向けであり、外部メモリ向けとしては、主にNANDフラッシュメモリ（並列接続と直列接続の両方）向けである。詳細な情報はUMで確認できます。ECCにはどのような種類のメモリを使用したいですか？ Re: Clarification Required on ECC Support for External Memory Interfaces in MIMXRT1170 and MIMXRT118 こんにちは、@Pooja_04 さん。 ご質問ありがとうございます！ 1. 外部インターフェースECCカバレッジ MIMXRT1170 FlexSPIおよびSEMCコントローラ自体は外部メモリデータパスに対して汎用ネイティブECCを提供し ません。しかし、RT1170は それぞれFlexSPI1、FlexSPI2、SEMC に関連する3つの独立した外部ECCコントローラ(XECC)インスタンスを統合しています。eMMCおよびSDカード(uSDHC経由)にはMCU側のECC ありません。 MIMXRT1180 現在利用可能な製品ドキュメントでは、SEMC Raw NANDインターフェースのハードウェアECCが明示的に規定されています。SEMC SDRAM/SRAM、FlexSPI NOR/HyperFlash/HyperRAM、SD/eMMCの一般的なコントローラ側ECCは指定されておらず、RT1180のドキュメントにもRT1170スタイルのXECC_FLEXSPI/XECC_SEMCモジュールは されていません。 eMMC/SDデバイスは内部メディアECCを実装でき、SD/eMMCプロトコルは転送エラー検出にCRCを使用しますが、これらのメカニズムはMCU側のエンドツーエンドECC保護として扱うべきではありません。 2. ECCの実装 MIMXRT1170 — XECC（外部メモリ）： ECCはFlexSPI/SEMCコントローラ ネイティブに提供されるわけではなく、専用のXECCモジュールによって提供されています。 ECCは自動的に有効化されません。ソフトウェア(または該当するROM/ヒューズフロー、ヒューズ経由)はECCアドレス領域を設定し、読み書きECCプロセッシングを有効化しなければなりません。 各XECCインスタンスは 4つの設定可能な保護アドレスウィンドウをサポートし、32ビットデータワードごとに32ビットのECCを拡張します。 領域全体は、読み取る前に初期化（プリロード）しておく必要があります。そうしないと、読み取り時にECCエラーが発生します。 MIMXRT1180 — SEMC NANDハードウェアECC: SEMコントローラハードウェアによってネイティブに提供され Raw NANDインターフェース(8/16ビット)用に  3. XECCの使用方法（RT1170） XECCは、 外部メモリ。 内部メモリ用ではありません — 内部TCM/キャッシュ/OCRAMは別々のECC機構(コア内蔵ECCとFlexRAM/MECCコントローラ)を使用します。 XECCは外部SDRAM、SRAM/PSRAM(SEMCの背後)、およびNOR Flash / HyperFlash / HyperRAM(FlexSPI1/FlexSPI2の背後)でデータを保護できます。 使用例/ドキュメント: AN13204 — 「i.MX RT1170 ECCアプリケーション」 (XECCの外部メモリ、ヒューズ/ソフトウェア設定、ROMプリロード、エラー注入をカバー): https://www.nxp.com/docs/en/application-note/AN13204.pdf （関連コード：AN13204SW） MCUXpresso SDK XECCの例 (RT1170/RT1160のみ) i.MX RT1170 リファレンスマニュアル(IMXRT1170RM) — XECC専用支部。 したがって、外部SDRAM/SRAMやFlexSPIフラッシュ/HyperRA MのECC保護が重要なアプリケーションに必須条件であれば、RT1170(XECC経由)    RT1180はそれを満たしますが、RT1180は同等の外部ECCコントローラを提供しません。RT1180ではコントローラ側の外部ECCはSEMC Raw NANDインターフェースに限定されます。 よろしくお願いします、 ギャビン

Inquiry Regarding JTAG Debugger Support for LX2082A Dear NXP Support Team, I am developing a custom board based on the NXP LX2082A processor and am currently planning the hardware bring-up and debugging setup. I would like to clarify whether SEGGER J-Link is officially supported for the following tasks on the LX2082A: Initial board bring-up JTAG debugging Bare-metal debugging TF-A and U-Boot debugging Linux kernel debugging Flash programming (if supported) My development environment is Linux, and I plan to develop and build all software on a Linux host. Could you please advise: Is SEGGER J-Link officially supported for the LX2082A? If yes, which J-Link models are supported? Are there any limitations compared to NXP-recommended debug solutions? If J-Link is not recommended, could you please suggest the officially supported hardware debugger(s) for the LX2082A? I would appreciate any documentation or application notes related to JTAG debugging and board bring-up for the LX2082A. Thank you for your assistance. I look forward to your guidance. Kind regards. Re: Inquiry Regarding JTAG Debugger Support for LX2082A The NXP officially supported debugger is CWTAP. You can use codewarrior Developer Suite Level for your application. You can also download  Evaluation Edition(free-trial) from below link but it has 30-day time restriction Every customer account (email address) can download the Evaluation Edition from the link below. Please select “DOWNLOAD EVAL”. https://www.nxp.com/design/design-center/software/development-software/codewarrior-development-tools/codewarrior-network-applications/codewarrior-development-suites-for-networked-applications:CW-DS-NETAPPS Please find the useful docuemnttation below:   ARMv8_Targeting_Manual.pdf   CodeWarrior TAP Probe User Guide   Layerscape Linux SDK User Guide Clarification on CodeWarrior License After 30-Day Evaluation (CW TAP / QCVS / QCS) Hello NXP Support, I have a question regarding the 30-day CodeWarrior Evaluation Edition. After the evaluation period expires: Will JTAG connection (using CW TAP) still work, or does CodeWarrior stop functioning completely? Will RCW generation/programming and flash programming still be available without a paid license? Can QCVS (QorIQ Configuration and Validation Suite) continue to be used after the trial expires, or does it also require a valid CodeWarrior license? For customers using only Linux command-line tools (U-Boot, Yocto, OpenOCD, etc.), is purchasing CodeWarrior recommended only for JTAG debugging, or is it mandatory for board bring-up? I would appreciate your clarification on which features remain available after the evaluation period. Thank you. Re: Inquiry Regarding JTAG Debugger Support for LX2082A 1.  CodeWarrior function will stop. 2. No. 3. No. Need a valid license. 4. Linux debug could work without JTAG debugging, but DDR validation on each board, and first time flash should use the JTAG debugger(CW TAP) with CodeWarrior IDE.