Clarification on Zigbee Protocol Support and Linux Driver for IW612 I'm currently working with the NXP MAYA-W271-00B (IW612)  , and I wanted to confirm whether it supports the Zigbee protocol in addition to Wi-Fi and Bluetooth. If Zigbee is supported, could anyone point me to the appropriate resources or provide guidance on where I might find the Linux driver or any necessary integration details? Any help or direction would be greatly appreciated! Thanks in advance! OS LINUX Protocol: Zigbee Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 Hi, @Abhilasha  As my previous comments,  To get the latest IW612's Wi-Fi driver, you can download it through below link: https://github.com/nxp-imx/mwifiex/tree/lf-6.6.36_2.1.0 To get the latest IW612's FW, you can download it through below link: https://github.com/nxp-imx/imx-firmware/tree/lf-6.6.36_2.1.0/nxp/FwImage_IW612_SD The 802.15.4 subsystem is only supported on IW612 evaluation board (EVB) with i.MX 8M Mini(8MMINILPD4-EVK@2020) host platform. Are you using our I.MX8MMini as your host platform? If yes, please refer to below guide: Section 7 7 Bring-up of 802.15.4 and Section 8 Bring-up of ZigBee on i.MX 8M Mini. Getting Started with NXP-based Wireless Modules on i.MX 8M Quad EVK Running Linux OS - User manual If no, I worry Zigbee is not supported on your other host platform currently. We also have below user manual as a guidance for customers to download and build our Wi-Fi drivers: How to Download and Build NXP Wi-Fi Drivers - User manual (restricted) About device tree, I think you can refer to our I.MX8MMini's device tree to configure yours according to your SDIO interface hardware connections: https://github.com/nxp-imx/linux-imx/blob/lf-6.6.y/arch/arm64/boot/dts/freescale/imx8mm-evk-usd-wifi.dts Hope it can help you somehow. Have a nice day~ Best regards, Christine. Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 I've found clarity on the IW612 Bluetooth driver in the Linux kernel, specifically at this link: btnxpuart.c.https://github.com/torvalds/linux/blob/v6.12-rc2/drivers/bluetooth/btnxpuart.c However, I still haven't located information regarding the Wi-Fi and Zigbee drivers for the IW612. Additionally, I would appreciate any insights on device tree support for these functionalities. If anyone can point me in the right direction, I would greatly appreciate it! Thank you! Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 Hi, @Abhilasha  The driver link I shared to you yesterday should include drivers which supports Zigbee. But I checked the information in our user manual, it mentioned that: 8 Bring-up of ZigBee on i.MX 8M Mini This section shows how to bring up ZigBee on i.MX 8M Mini EVK platform. Note: The 802.15.4 subsystem is only supported on IW612 evaluation board (EVB) with i.MX 8M Mini(8MMINILPD4-EVK@2020) host platform. This section describes the steps to bring up the 802.15.4 interface of NXP-based IW612 module on i.MX 8M Mini platform, and for Zigbee-only mode. Zigbee dual-pan mode is not supported. So, please make sure whether you are using our I.Mx8M Mini (8MMINILPD4-EVK@2020) host platform. If not, I worry, it might not support. Sorry for the inconvenience to you. Best regards, Christine. Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 Can you provide me the link for driver that supports zigbee protocol ? Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 Hi， @Abhilasha  It needs secure files access to get download permission. You can download the driver and FW through my given links, which doesn't need secure files access. Best regards, Christine. Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 trying to download  https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IW612-6623-IMX8-18993-P10-MM6X18437-P21&appType=file1&DOWNLOAD_ID=null  unable to dowload this !! Re: Clarification on Zigbee Protocol Support and Linux Driver for IW612 Hi, @Abhilasha  Thanks for creating case to us. For IW612, yes, except Bluetooth and Wi-Fi, it also supported Zigbee which is based on 802.15.4. To use IW612's Zigbee based on Linux, you can refer to below guide:  Getting Started with NXP-based Wireless Modules on i.MX 8M Quad EVK Running Linux OS - User manual  To get the latest IW612's driver, you can download it through below link: https://github.com/nxp-imx/mwifiex/tree/lf-6.6.36_2.1.0 To get the latest IW612's FW, you can download it through below link: https://github.com/nxp-imx/imx-firmware/tree/lf-6.6.36_2.1.0/nxp/FwImage_IW612_SD Please do not hesitate to mark my answer as a solution, if it really does help for you. For other topic's queries or questions, please feel free to create new case to us. Have a nice day~ Best regards, Christine.

[ls1046a] Concerns and questions about using Fuse Provisioning Image to enable secure boot Hello, I am trying to create a procedure for enabling secure boot on our products using the fuse provisioning image provided by the TF-A. I am following these 3 guides: LLDPUG 5.15 Fuse Provisioning on LS1046ARDB TF-A Fuse Provisioning Here is my issue,  In all these guides, it specifies to use the following compile command: make all fip pbl PLAT=ls1046ardb BOOT_MODE=qspi RCW=../rcw_1600_qspiboot.bin BL33=../uboot_ls1046ardb_tfa.bin fip_fuse FUSE_PROG=1 FUSE_PROV_FILE=../cst/fuse_scr.bin This command works, however my concern is that it does not enable TRUSTED_BOARD_BOOT. As a result, the BL2 will not be signed with the CSF header. This seems like it would brick the card, assuming that ITS is set? If we provision the fuses, and then reboot with an unsigned BL2, the card will not boot, right? The troubling part is none of these guides emphasize that point. Imo it seems highly risky to provision the fuses without first having a CST signed BL2 ready for the next boot. There is always the risk that the card loses power or reboots before the user has a chance to correctly download and install a secure BL2 image. It seems reasonable that the BL2 image should be signed with the CSF header as well as be able to provision the fuses. Therefore, I tried to use this command instead: make all fip pbl PLAT=ls1046ardb BOOT_MODE=qspi RCW=../rcw_1600_qspiboot.bin BL33=../uboot_ls1046ardb_tfa.bin fip_fuse FUSE_PROG=1 FUSE_PROV_FILE=../cst/fuse_scr.bin TRUSTED_BOARD_BOOT=1 This way, the fuse provisioning will be enabled, and the BL2 will be signed. I also set SB_EN=1 in the rcw, so that the fuse provisioning BL2 will authenticated on the first boot. However, this does not work. I get the following error messages: ERROR: Failed to add dynamic memory region. ERROR: Failed to load FUSE PRIV image ERROR: FUSE Barker code mismatch. After some debugging, I found out that it was failing to dynamically mmap the memory, because the CSF header requires a dynamic mmap but it fully overlaps with the DRAM0 region. This excerpt is my debug statement in mmap_add_region_check(this is in v2.6 of the qoriq-atf btw): 742 /* 743 * Full VA overlaps are only allowed if both regions are 744 * identity mapped (zero offset) or have the same VA to PA 745 * offset. Also, make sure that it's not the exact same area. 746 * This can only be done with static regions. 747 */ 748 if (fully_overlapped_va) { 749 750 #if PLAT_XLAT_TABLES_DYNAMIC 751 if (((mm->attr & MT_DYNAMIC) != 0U) || 752 ((mm_cursor->attr & MT_DYNAMIC) != 0U)) { 753 ERROR("DEBUG: Dynamic!\n"); 754 return -EPERM; 755 } 756 #endif /* PLAT_XLAT_TABLES_DYNAMIC */ DRAM0 starts at 0x8000_0000 but the FUSE_BUF begins at 0x8100_0000: plat/nxp/common/include/default/plat_default_def.h:#define FUSE_BUF ULL(0x81000000) This causes a conflict and the FUSE_BUF can't be allocated. As a result, it seems that FUSE_PROG and TRUSTED_BOARD_BOOT cannot both be enabled in the same BL2 image. What is the intended solution here? Should I just modify the FUSE_BUF addr to be outside of DRAM0? Should I disable PLAT_XLAT_TABLES_DYNAMIC? Thank you for your help, James Re: [ls1046a] Concerns and questions about using Fuse Provisioning Image to enable secure boot Thank you yipingwang. In our case we unfortunately are strictly limited to qspi boot with a single bank. It sounds like we will have to exercise caution and ensure we program the qspi correctly before rebooting. Would it be possible for us to prepare a fuse provisioning pbl image which contains an unsigned BL2, but which also contains an alternate signed BL2? We would need the pbi to load both BL2's and then load a pointer to the signed one in SCRATCHRW3. This way, in case the card reboots before re-programming the qspi, we have a signed alternate image to fallback on. This seems like a bit of a reach, I'm not sure if there's something I'm overlooking which would prevent this from working. Re: [ls1046a] Concerns and questions about using Fuse Provisioning Image to enable secure boot Fuse Provisioning image is normal boot image not secure boot image, it is used to blow OPTMK and SRKHR keys to fuse array on the target.  FUSE_PROG and TRUSTED_BOARD_BOOT should not be enabled at the same time. You could deploy secure boot boot image on bank 0 of QSPI NOR flash, and fuse provisioning image on the alternate bank or SD card. After booting from alternate bank or SD card to do fuse provisioning, then reboot the target board to do secure boot. If you only have one QSPI NOR flash bank, after running fuse provisioning boot image and check the status, please don't reset the target board, please deploy the secure boot image on the NOR flash, then reset the target board.

S32K3 SHE密钥更新 1.在K3 HSE_B Firmware RM文档中，FID定义为6位，所以K3不支持FID-5bit，对吗？[在K146芯片，FID不仅支持到6位，还支持到5位。] 所以，在S32K3中，如果使用FID-5bit生成M1-M3，SHE密钥无法更新，对吗？ 2.在S32K3 MCAL的加密驱动程序中，SHE密钥的M4存储在密钥元素2（CRYPTO_KE_MAC_PROOF）中，M5存储在密钥元素6（CRYPTO_KE_CIPHER_PROOF）中。但是，据我所知，M4M5应该存储在密钥元素2中，而不是元素6中。NXP的加密代码不符合autosar标准吗？ 回复：S32K3 SHE 密钥更新 你好，lukaszadrapa， 1.在你的图中，S32K3没有像S32K1那样的SFE标志，所以它只支持FID 6位，不能满足FID 5位，因为它必须配置VERIFY_ONLY位。NXP是否提供HSE固件支持使用FID 5bit？ 2. 下一次 RTD 什么时候提供？您能提供修改当前 RTD 中相关代码的方法吗？我们目前正在使用这个 RTD 开发软件，已经需要使用这个功能了。

Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK Hello, I am working with the MIMXRT1180-EVK board and would like to implement a baremetal TCP client using the LwIP stack. Could you kindly provide an example or point me toward resources that would help me achieve this? I am looking for a basic setup that includes Ethernet initialization and a simple TCP client communication implementation. Any assistance would be greatly appreciated! Thank you. Re: Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK HI @PavanKumarS  Sorry, i forgot it. ethernetif_input(&netif) is responsible for processing incoming packets. Without this function being called, your application doesn’t receive Ethernet frames from the network interface. If you remove the loop, network events like incoming packets or timeouts won’t be handled, so the connection won’t be properly maintained. If you want to avoid relying on this polling loop, you can use LwIP with an operating system (like FreeRTOS) to handle network events asynchronously through interrupts and tasks. BR Hang Re: Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK Hi @Harry_Zhang, I followed the steps provided and implemented the TCP client as described, but I encountered an issue where the connection wasn't being established with the server. However, when I added the line ethernetif_input(&netif); in the main while loop, the connection worked. the loop: while (1) { ethernetif_input(&netif); // LwIP needs to be continuously polled to handle network events sys_check_timeouts(); } I’m trying to understand why this loop is necessary. Is there a way to isolate the connection functionality so that it doesn't rely on the loop? How can I make the connection part independent of this polling mechanism? Re: Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK Hi @PavanKumarS  To implement a baremetal TCP client on the MIMXRT1180-EVK using the LwIP stack, Import the lwip_ping_bm_cm33 example. This examples include the necessary Ethernet initialization, which you can adapt to create a TCP client. Then you will add client codes. Here’s a basic example for creating a TCP client. You need to set up a connection and manage sending and receiving data using callbacks. #include "lwip/tcp.h" static struct tcp_pcb *tcp_client_pcb; // Callback when data is received err_t tcp_client_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (p == NULL) { // Connection closed tcp_close(tpcb); return ERR_OK; } // Process received data tcp_recved(tpcb, p->len); pbuf_free(p); return ERR_OK; } // Callback when a TCP connection is established err_t tcp_client_connected(void *arg, struct tcp_pcb *tpcb, err_t err) { if (err == ERR_OK) { // Connection successful // Set the receive callback tcp_recv(tpcb, tcp_client_recv); // Send some data const char *data = "Hello, Server!"; tcp_write(tpcb, data, strlen(data), TCP_WRITE_FLAG_COPY); } else { // Handle connection error tcp_close(tpcb); } return err; } // Initiate the TCP connection void tcp_client_connect(void) { ip_addr_t server_ip; IP4_ADDR(&server_ip, 192, 168, 1, 100); // Set the server's IP address // Create a new TCP control block tcp_client_pcb = tcp_new(); // Connect to the server on port 80 (you can change this to your desired port) tcp_connect(tcp_client_pcb, &server_ip, 80, tcp_client_connected); } Integrate everything in the main() function of your application. int main(void) { // Board initialization (clocks, Ethernet, etc.) BOARD_InitBootPins(); BOARD_InitBootClocks(); BOARD_InitBootPeripherals(); BOARD_InitDebugConsole(); // Initialize the LwIP stack and network interface lwip_init_function(); // Start the TCP client tcp_client_connect(); while (1) { // LwIP needs to be continuously polled to handle network events sys_check_timeouts(); } return 0; } BR Hang Re: Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK Hi @Harry_Zhang, I have checked the SDK, but I was not able to find the bare metal TCP client example. Could you kindly provide an example or point me towards the resources that could help. Re: Request for Baremetal TCP Client Example Using LwIP Stack on MIMXRT1180-EVK Hi @PavanKumarS  You can download the MIMXRT1180-EVK SDK. Select Board | MCUXpresso SDK Builder (nxp.com) And you can refer to lwip examples. BR Hang

OTA_S32K144_Use_Case_WS Access Hi, I was reading AN 12323 "S32kxx Firmware Updates" and was interested in trying out the demo where they do a firmware update using a bootloader and CAN across two partitioned devices. Anyone know where I can get access to the demo workspace: OTA_S32K144_Use_Case_WS?  Also, I notice in the project they are debugging with DEBUG_RAM, I have always done DEBUG_FLASH, is there an important difference that will cause errors if I do one or the other? Thanks in advance! Re: OTA_S32K144_Use_Case_WS Access Thank you! I really appreciate it. Re: OTA_S32K144_Use_Case_WS Access Hi @aipers  the software can be downloaded here: https://www.nxp.com/docs/en/application-note-software/AN12323SW.zip Only the S32K144_Memory_Partition project should be executed from RAM memory. Here is the reason:  Other projects should be programmed to the flash. Regards, Lukas

EMIOS_ICU Hi, I want to use the IPWM mode of the EMIOS module of the S32K358 chip to capture PWM waves, but my function cannot enter the interrupt function (User_EdgeDetect4), what is the problem? I'm sure there is a PWM wave input. Re: EMIOS_ICU Sorry for taking so long to reply you. The problem was solved when I commented out the function Re: EMIOS_ICU Hi, comment Emios_Icu_Ip_StartSignalMeasurement function and you should get callback. BR, Petr

RT1170ボード上でのffmpegのコンパイル 私は、NXP RT1170ボード(MMIXRT1170-EVKB)でQCIF解像度でのH.264ビデオデコードを必要とするプロジェクトに取り組んでいます。この機能を実現するには、必要な構成でffmpegをコンパイルする必要があります。 RT1170 ボードで使用するための ffmpeg の設定およびコンパイル方法についてのガイダンスを教えてください。

sweep mask parameter in a for loop -- block "MC3377xC Get Values" NXP Model-Based Design Toolbox Hello,  I am using the block "MC3377xC Get Values" (and other blocks in the 'BMS_3377xC' library) from the NXP Model-Based Design Toolbox in Matlab Simulink 2023b. I would like to know how to sweep the mask parameters (such as the 'Instance' and 'CID' values in the "MC3377xC Get Values" block) in a For Loop in Simulink simulation and for embedded code generation.  Thanks Cheng Re: sweep mask parameter in a for loop -- block "MC3377xC Get Values" NXP Model-Based Desi Hello @CZ_FB, Unfortunately, this requirement is not possible right away, because it requires a serious update/patch coming from the MBDT team. We have to redesign and modify the blocks from the toolbox to accept both the CID and the Instance as a block input. I will open a ticket for such changes, but because we have no roadmap to cover a new release for the MBDT for S32K1, I cannot promise this will be implemented. To faster help you with such requirements, I can identify 2 options: 1. You could use a switch case, and in each case place a block to handle the CID and Instance you need to cover. 2. The second option would be to create a block that uses custom code, after a template or method described in this article https://community.nxp.com/t5/NXP-Model-Based-Design-Tools/How-to-use-your-own-C-code-in-our-Toolbox-Battery-Management/ta-p/1119004 How many BCCs do you need to cover? Regards, Marius

compiling ffmpeg on RT1170 board I am working on a project that requires H.264 video decoding at QCIF resolution on the NXP RT1170 board (MMIXRT1170-EVKB). I need to compile ffmpeg with the necessary configuration to achieve this functionality. Could you please provide guidance on how to configure and compile ffmpeg for use on the RT1170 board? Re: compiling ffmpeg on RT1170 board Hi @amira, The Video chapter of the GUI Guider user guide shows how to use ffmpeg to convert files into the required h264 format, as well as further information on how to handle these video files for your GUI Guider project. Here's the link: Video | GUIGUIDERUG: GUI Guider User's Guide | NXP Semiconductors. Let me know if you have further inquiries about this topic. BR, Edwin.

Mass Storage FRDM-MCXN947 With SD Card Hello, I am currently trying to run a Mass Storage Device example on FRDM-MCXN974 with SD card support and FreeRTOS. I managed to get the standard example to run fine. The code contains two tasks APP_task and USB_DeviceTask, I am trying to reduce this code to only one task, which I have designed as follows: int main(void) { /* Initialize board hardware. */ APP_InitBoard(); USB_DeviceApplicationInit(); usb_echo("Available heap size before task creation: %d bytes\r\n", xPortGetFreeHeapSize()); if (g_msc.deviceHandle) { if (xTaskCreate(USB_DeviceTask, /* pointer to the task */ (char const *)"usb device task", /* task name for kernel awareness debugging */ 9000L / sizeof(portSTACK_TYPE), /* task stack size */ g_msc.deviceHandle, /* optional task startup argument */ 4, /* initial priority */ &g_msc.device_task_handle /* optional task handle to create */ ) != pdPASS) { usb_echo("usb device task create failed!\r\n"); return 1; } } vTaskStartScheduler(); while (1) { ; } return 1; } But It always end with fard-fault in USB_DeviceApplicationInit() as in the attached picture. The original code looked like this: int main(void) { /* board initialization... */ /* task... */ if (xTaskCreate(APP_task, /* pointer to the task */ (char const *)"app task", /* task name for kernel awareness debugging */ 5000L / sizeof(portSTACK_TYPE), /* task stack size */ &g_msc, /* optional task startup argument */ 3, /* initial priority */ &g_msc.application_task_handle /* optional task handle to create */ ) != pdPASS) { usb_echo("app task create failed!\r\n"); } vTaskStartScheduler(); return 1; } void USB_DeviceTask(void *handle) { while (1U) { USB_DeviceTaskFn(handle); } } void APP_task(void *handle) { USB_DeviceApplicationInit(); #if USB_DEVICE_CONFIG_USE_TASK if (g_msc.deviceHandle) { if (xTaskCreate(USB_DeviceTask, /* pointer to the task */ (char const *)"usb device task", /* task name for kernel awareness debugging */ 5000L / sizeof(portSTACK_TYPE), /* task stack size */ g_msc.deviceHandle, /* optional task startup argument */ 5, /* initial priority */ &g_msc.device_task_handle /* optional task handle to create */ ) != pdPASS) { usb_echo("usb device task create failed!\r\n"); return; } } while (1) { } } Did I miss anything? Can I somehow reduce the code just to one task? Thank you very much. Development Board MCXN USB Re: Mass Storage FRDM-MCXN947 With SD Card Thank you, so the best way is to use as a baseline bare-metal example for my project Re: Mass Storage FRDM-MCXN947 With SD Card hi,Doly02 I don't think it's possible that the SD_Init () function is still connected to the FreeRTOS task resource, and the program ends up with a hard failure, and SD card initialization is done in the USB_DeviceApplicationInit() function. You can refer to the frdmmcxn947_dev_msc_disk_bm demo program where the USB_DeviceApplicationInit() function is initialized in main. If you use SD cards in Freertos, ensure that the tasks have enough stack space and do not conflict with other tasks, ensure that the initialization and use of the SD card is thread-safe, and you can use the Mutex provided by FreeRTOS to prevent problems caused by multiple tasks accessing the SD card at the same time. If the SD card initialization is done in one task, and other tasks need to wait for the initialization to complete before using the SD card, then Semaphore or other synchronization mechanism should be used to coordinate the tasks. BR Xu Zhang Re: Mass Storage FRDM-MCXN947 With SD Card Hi XuZhang, thank you for your reply and great support from NXP. I am developing device on FreeRTOS that has two task and each of them uses SD card. When I move the initialization to the main (to not initialize SD card twice), there is probably still issue that SD_Init() function still has a connection to FreeRTOS task resources, and program ends up in hard-fault, is that possible? Re: Mass Storage FRDM-MCXN947 With SD Card hi，Doly02 Thank you for your interest in NXP Semiconductor products and the opportunity to serve you, I will gladly help you with this. You can try to modify the frdmmcxn947_dev_msc_disk_freertos demo program in the way shown in the picture. Wish it helps you. If you still have question about it,please kindly let me know. BR Zhang Xu Re: Mass Storage FRDM-MCXN947 With SD Card

在 RT1170 板上编译 ffmpeg 我正在开展一个项目，需要在 NXP RT1170 板（MMIXRT1170-EVKB）上以 QCIF 分辨率进行 H.264 视频解码。我需要使用必要的配置来编译 ffmpeg 来实现此功能。 您能否提供有关如何配置和编译 ffmpeg 以在 RT1170 板上使用的指导？

S32K312 high dark current after update MCAL Hello. My product have high dark current issue after update MCAL (RTD). When MCU sleep(POWER_IP_STANDBY_MODE), - S32K3 RTD 2.0.1 (7 July 2022) :  0.2 mA - S32K3 RTD 3.0.0 P01 (31 March 2023) : 0.7 mA I use same application code. After checking little more... When I set my ADC input port to unused, then 0.2 mA measurement with RTD 3.0.0.   Port_SetAsUnusedPin(PortConf_PortPin_PortPin_PTB9_BAT); Is there any change about ADC in standby mode? Best Regards, Sean Sung. Re: S32K312 high dark current after update MCAL Hello @danielmartynek  I solved issue to IBE bit OFF. Thank you. Best Regards, Sean Sung Re: S32K312 high dark current after update MCAL Hello Sean Sung, That means the IBE bit in MSCR is set (input buffer enabled). If the input buffer is enabled, the voltage at the pin must be either VDD or VSS, otherwise it draws some additional current. There is no need to use the input buffer at pins used as ADC inputs. BR, Daniel Re: S32K312 high dark current after update MCAL Hello @danielmartynek  Here is my config for PORT and ADC. Could you check it? Could you explain more about your mention? "If so, the logic level at the pin must be defined, either VDD or VSS." Best Regards, Sean Sung. Re: S32K312 high dark current after update MCAL Hello @ssean, Was the input buffer enabled in the MSCR register of the pin? If so, the logic level at the pin must be defined, either VDD or VSS. Regards, Daniel

S32G399 LLCE CAN Hi experts, I want to test can communication of M core of our self-developed board.The chip is S32G399A and I want to confirm which example of S32 DS supports our design.Thanks! Re: S32G399 LLCE CAN Hello, @piaochunri  Thanks for your post. From the snapshot you shared, seems the LLCE-CANs are required, in order to use it, you may firstly install the LLCE package to the S32DS, which could be found under software manager: https://www.nxp.com/app-autopackagemgr/automotive-software-package-manager:AUTO-SW-PACKAGE-MANAGER Once installed, the following example could be found: It could be used for your reference of using the CAN function from LLCE. BR Chenyin

DDR Test & calibration : please check my test result and is this OK? or not this is my customized I.MX6Q board. this has a problem of bring up. so, I want to check DDR calibration and stress test. this is full log of calibartion and stress test. but I have some question of result. I will ask it inline. please help me. Thank you in advance. basic information : I.MX6Q, 1.2GH, 2GB DDR  ====================================== reading ddr-test-uboot-jtag-mx6dq.bin 121880 bytes read in 29 ms (4 MiB/s) ## Starting application at 0x00907000 ... ============================================ DDR Stress Test (3.0.0) Build: Dec 14 2018, 14:20:05 NXP Semiconductors. ============================================ ============================================ Chip ID CHIP ID = i.MX6 Dual/Quad (0x63) Internal Revision = TO1.5 ============================================ ============================================ Boot Configuration SRC_SBMR1(0x020d8004) = 0x00003040 SRC_SBMR2(0x020d801c) = 0x22000001 ============================================ What ARM core speed would you like to run? Type 1 for 800MHz, 2 for 1GHz, 3 for 1.2GHz ARM Clock set to 800MHz ============================================ DDR configuration BOOT_CFG3[5-4]: 0x00, Single DDR channel. DDR type is DDR3 Data width: 64, bank num: 8 Row size: 15, col size: 10 Chip select CSD0 is used Density per chip select: 2048MB ============================================ Current Temperature: 26 ============================================ Please select the DDR density per chip select (in bytes) on the board Type 0 for 2GB; 1 for 1GB; 2 for 512MB; 3 for 256MB; 4 for 128MB; 5 for 64MB; 6 for 32MB For maximum supported density (4GB), we can only access up to 3.75GB. Type 7 to select this DDR density selected (MB): 2048 Would do you want to change VDD_SOC_CAP/VDD_ARM_CAP voltage? Type 'y' to run and 'n' to skip Would do you want run DDR Calibration? Type 'y' to run and 'n' to skip Calibration will run at DDR frequency 528MHz. Type 'y' to continue. If you want to run at other DDR frequency. Type 'n' Please enter the MR1 value on the initilization script This will be re-programmed into MR1 after write leveling calibration Enter as a 4-digit HEX value, example 0004, then hit enter 0004DDR Freq: 528 MHz ///// Question 1 //// What is the right 4 HEX value. I don't know this meaning, MR1 value is not 4 digit... please let me know what is this valule? I used. example value for test. ///// Question 1 //// ddr_mr1=0x00000004 Start write leveling calibration... running Write level HW calibration MPWLHWERR register read out for factory diagnostics: MPWLHWERR PHY0 = 0x3c3e3c3e MPWLHWERR PHY1 = 0x1e3e3e3c Write leveling calibration completed, update the following registers in your initialization script MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x0021001C MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x002B001E MMDC_MPWLDECTRL0 ch1 (0x021b480c) = 0x00190023 MMDC_MPWLDECTRL1 ch1 (0x021b4810) = 0x000A001C Write DQS delay result: Write DQS0 delay: 28/256 CK Write DQS1 delay: 33/256 CK Write DQS2 delay: 30/256 CK Write DQS3 delay: 43/256 CK Write DQS4 delay: 35/256 CK Write DQS5 delay: 25/256 CK Write DQS6 delay: 28/256 CK Write DQS7 delay: 10/256 CK WARNING: write-leveling calibration value is greater than 1/8 CK. Per the reference manual, WALAT must be set to 1 in the register MDMISC(0x021B0018). This has been performed automatically. However, in addition to updating the calibration values in your DDR initialization, it is also REQUIRED change the value of MDMISC in their DDR initialization as follows: MMDC_MDMISC (0x021b0018) = 0x00091740 Starting DQS gating calibration . HC_DEL=0x00000000 result[00]=0x11111111 . HC_DEL=0x00000001 result[01]=0x11110111 . HC_DEL=0x00000002 result[02]=0x00110011 . HC_DEL=0x00000003 result[03]=0x00000000 . HC_DEL=0x00000004 result[04]=0x01000000 . HC_DEL=0x00000005 result[05]=0x11111111 . HC_DEL=0x00000006 result[06]=0x11111111 . HC_DEL=0x00000007 result[07]=0x11111111 . HC_DEL=0x00000008 result[08]=0x11111111 . HC_DEL=0x00000009 result[09]=0x11111111 . HC_DEL=0x0000000A result[0A]=0x11111111 . HC_DEL=0x0000000B result[0B]=0x11111111 . HC_DEL=0x0000000C result[0C]=0x11111111 . HC_DEL=0x0000000D result[0D]=0x11111111 DQS HC delay value low1 = 0x01020303, high1=0x04040404 DQS HC delay value low2 = 0x02020303, high2=0x04030404 loop ABS offset to get HW_DG_LOW . ABS_OFFSET=0x00000000 result[00]=0x11111111 . ABS_OFFSET=0x00000004 result[01]=0x11111111 . ABS_OFFSET=0x00000008 result[02]=0x11011111 . ABS_OFFSET=0x0000000C result[03]=0x11001101 . ABS_OFFSET=0x00000010 result[04]=0x11001101 . ABS_OFFSET=0x00000014 result[05]=0x11001101 . ABS_OFFSET=0x00000018 result[06]=0x11001101 . ABS_OFFSET=0x0000001C result[07]=0x11001100 . ABS_OFFSET=0x00000020 result[08]=0x11001100 . ABS_OFFSET=0x00000024 result[09]=0x11111111 . ABS_OFFSET=0x00000028 result[0A]=0x11001100 . ABS_OFFSET=0x0000002C result[0B]=0x11001100 . ABS_OFFSET=0x00000030 result[0C]=0x11001100 . ABS_OFFSET=0x00000034 result[0D]=0x11001100 . ABS_OFFSET=0x00000038 result[0E]=0x11111111 . ABS_OFFSET=0x0000003C result[0F]=0x11001100 . ABS_OFFSET=0x00000040 result[10]=0x11001100 . ABS_OFFSET=0x00000044 result[11]=0x11001100 . ABS_OFFSET=0x00000048 result[12]=0x10001100 . ABS_OFFSET=0x0000004C result[13]=0x10001100 . ABS_OFFSET=0x00000050 result[14]=0x10001100 . ABS_OFFSET=0x00000054 result[15]=0x00001100 . ABS_OFFSET=0x00000058 result[16]=0x00001100 . ABS_OFFSET=0x0000005C result[17]=0x00001100 . ABS_OFFSET=0x00000060 result[18]=0x00000100 . ABS_OFFSET=0x00000064 result[19]=0x00000100 . ABS_OFFSET=0x00000068 result[1A]=0x00000100 . ABS_OFFSET=0x0000006C result[1B]=0x00000000 . ABS_OFFSET=0x00000070 result[1C]=0x00000000 . ABS_OFFSET=0x00000074 result[1D]=0x00000000 . ABS_OFFSET=0x00000078 result[1E]=0x00000000 . ABS_OFFSET=0x0000007C result[1F]=0x00000000 loop ABS offset to get HW_DG_HIGH . ABS_OFFSET=0x00000000 result[00]=0x00000000 . ABS_OFFSET=0x00000004 result[01]=0x00000000 . ABS_OFFSET=0x00000008 result[02]=0x00000000 . ABS_OFFSET=0x0000000C result[03]=0x11111111 . ABS_OFFSET=0x00000010 result[04]=0x00000000 . ABS_OFFSET=0x00000014 result[05]=0x00000000 . ABS_OFFSET=0x00000018 result[06]=0x00000000 . ABS_OFFSET=0x0000001C result[07]=0x00000000 . ABS_OFFSET=0x00000020 result[08]=0x00000000 . ABS_OFFSET=0x00000024 result[09]=0x00000000 . ABS_OFFSET=0x00000028 result[0A]=0x00000000 . ABS_OFFSET=0x0000002C result[0B]=0x00000100 . ABS_OFFSET=0x00000030 result[0C]=0x00000100 . ABS_OFFSET=0x00000034 result[0D]=0x00001100 . ABS_OFFSET=0x00000038 result[0E]=0x10001110 . ABS_OFFSET=0x0000003C result[0F]=0x10101110 . ABS_OFFSET=0x00000040 result[10]=0x10101110 . ABS_OFFSET=0x00000044 result[11]=0x10101110 . ABS_OFFSET=0x00000048 result[12]=0x10101110 . ABS_OFFSET=0x0000004C result[13]=0x10111110 . ABS_OFFSET=0x00000050 result[14]=0x10111111 . ABS_OFFSET=0x00000054 result[15]=0x10111111 . ABS_OFFSET=0x00000058 result[16]=0x10111111 . ABS_OFFSET=0x0000005C result[17]=0x11111111 . ABS_OFFSET=0x00000060 result[18]=0x10111111 . ABS_OFFSET=0x00000064 result[19]=0x10111111 . ABS_OFFSET=0x00000068 result[1A]=0x10111111 . ABS_OFFSET=0x0000006C result[1B]=0x11111111 . ABS_OFFSET=0x00000070 result[1C]=0x10111111 . ABS_OFFSET=0x00000074 result[1D]=0x11111111 . ABS_OFFSET=0x00000078 result[1E]=0x11111111 . ABS_OFFSET=0x0000007C result[1F]=0x11111111 BYTE 0: Start: HC=0x02 ABS=0x3C End: HC=0x04 ABS=0x4C Mean: HC=0x03 ABS=0x44 End-0.5*tCK: HC=0x03 ABS=0x4C Final: HC=0x03 ABS=0x4C BYTE 1: Start: HC=0x02 ABS=0x3C End: HC=0x04 ABS=0x34 Mean: HC=0x03 ABS=0x38 End-0.5*tCK: HC=0x03 ABS=0x34 Final: HC=0x03 ABS=0x38 BYTE 2: Start: HC=0x01 ABS=0x6C End: HC=0x04 ABS=0x28 Mean: HC=0x03 ABS=0x0A End-0.5*tCK: HC=0x03 ABS=0x28 Final: HC=0x03 ABS=0x28 BYTE 3: Start: HC=0x00 ABS=0x60 End: HC=0x04 ABS=0x30 Mean: HC=0x02 ABS=0x48 End-0.5*tCK: HC=0x03 ABS=0x30 Final: HC=0x03 ABS=0x30 BYTE 4: Start: HC=0x02 ABS=0x3C End: HC=0x04 ABS=0x48 Mean: HC=0x03 ABS=0x42 End-0.5*tCK: HC=0x03 ABS=0x48 Final: HC=0x03 ABS=0x48 BYTE 5: Start: HC=0x02 ABS=0x3C End: HC=0x04 ABS=0x38 Mean: HC=0x03 ABS=0x3A End-0.5*tCK: HC=0x03 ABS=0x38 Final: HC=0x03 ABS=0x3A BYTE 6: Start: HC=0x01 ABS=0x48 End: HC=0x03 ABS=0x58 Mean: HC=0x02 ABS=0x50 End-0.5*tCK: HC=0x02 ABS=0x58 Final: HC=0x02 ABS=0x58 BYTE 7: Start: HC=0x01 ABS=0x54 End: HC=0x04 ABS=0x34 Mean: HC=0x03 ABS=0x04 End-0.5*tCK: HC=0x03 ABS=0x34 Final: HC=0x03 ABS=0x34 DQS calibration MMDC0 MPDGCTRL0 = 0x4338034C, MPDGCTRL1 = 0x03300328 DQS calibration MMDC1 MPDGCTRL0 = 0x033A0348, MPDGCTRL1 = 0x03340258 Note: Array result[] holds the DRAM test result of each byte. 0: test pass. 1: test fail 4 bits respresent the result of 1 byte. result 00000001:byte 0 fail. result 00000011:byte 0, 1 fail. ///// Question 2 //// this resulte has 1 fail. Is that a problem? or not ///// Question 2 //// Starting Read calibration... ABS_OFFSET=0x00000000 result[00]=0x11111111 ABS_OFFSET=0x04040404 result[01]=0x11111111 ABS_OFFSET=0x08080808 result[02]=0x11111111 ABS_OFFSET=0x0C0C0C0C result[03]=0x11111111 ABS_OFFSET=0x10101010 result[04]=0x11111111 ABS_OFFSET=0x14141414 result[05]=0x11111111 ABS_OFFSET=0x18181818 result[06]=0x11111111 ABS_OFFSET=0x1C1C1C1C result[07]=0x11011001 ABS_OFFSET=0x20202020 result[08]=0x00011001 ABS_OFFSET=0x24242424 result[09]=0x00010000 ABS_OFFSET=0x28282828 result[0A]=0x00010000 ABS_OFFSET=0x2C2C2C2C result[0B]=0x00010000 ABS_OFFSET=0x30303030 result[0C]=0x00000000 ABS_OFFSET=0x34343434 result[0D]=0x00000000 ABS_OFFSET=0x38383838 result[0E]=0x00000000 ABS_OFFSET=0x3C3C3C3C result[0F]=0x00000000 ABS_OFFSET=0x40404040 result[10]=0x00000000 ABS_OFFSET=0x44444444 result[11]=0x00000000 ABS_OFFSET=0x48484848 result[12]=0x00000000 ABS_OFFSET=0x4C4C4C4C result[13]=0x00000000 ABS_OFFSET=0x50505050 result[14]=0x00000000 ABS_OFFSET=0x54545454 result[15]=0x00000100 ABS_OFFSET=0x58585858 result[16]=0x00000100 ABS_OFFSET=0x5C5C5C5C result[17]=0x00100110 ABS_OFFSET=0x60606060 result[18]=0x01100110 ABS_OFFSET=0x64646464 result[19]=0x01100110 ABS_OFFSET=0x68686868 result[1A]=0x11101111 ABS_OFFSET=0x6C6C6C6C result[1B]=0x11111111 ABS_OFFSET=0x70707070 result[1C]=0x11111111 ABS_OFFSET=0x74747474 result[1D]=0x11111111 ABS_OFFSET=0x78787878 result[1E]=0x11111111 ABS_OFFSET=0x7C7C7C7C result[1F]=0x11111111 Byte 0: (0x24 - 0x64), middle value:0x44 Byte 1: (0x1c - 0x58), middle value:0x3a Byte 2: (0x1c - 0x50), middle value:0x36 Byte 3: (0x24 - 0x64), middle value:0x44 Byte 4: (0x30 - 0x68), middle value:0x4c Byte 5: (0x1c - 0x58), middle value:0x3a Byte 6: (0x20 - 0x5c), middle value:0x3e Byte 7: (0x20 - 0x64), middle value:0x42 MMDC0 MPRDDLCTL = 0x44363A44, MMDC1 MPRDDLCTL = 0x423E3A4C Starting Write calibration... ABS_OFFSET=0x00000000 result[00]=0x11111111 ABS_OFFSET=0x04040404 result[01]=0x11111111 ABS_OFFSET=0x08080808 result[02]=0x11111111 ABS_OFFSET=0x0C0C0C0C result[03]=0x10110111 ABS_OFFSET=0x10101010 result[04]=0x10110010 ABS_OFFSET=0x14141414 result[05]=0x10100010 ABS_OFFSET=0x18181818 result[06]=0x00100000 ABS_OFFSET=0x1C1C1C1C result[07]=0x00100000 ABS_OFFSET=0x20202020 result[08]=0x00100000 ABS_OFFSET=0x24242424 result[09]=0x00000000 ABS_OFFSET=0x28282828 result[0A]=0x00000000 ABS_OFFSET=0x2C2C2C2C result[0B]=0x00000000 ABS_OFFSET=0x30303030 result[0C]=0x00000000 ABS_OFFSET=0x34343434 result[0D]=0x00000000 ABS_OFFSET=0x38383838 result[0E]=0x00000000 ABS_OFFSET=0x3C3C3C3C result[0F]=0x00000000 ABS_OFFSET=0x40404040 result[10]=0x00000000 ABS_OFFSET=0x44444444 result[11]=0x00000000 ABS_OFFSET=0x48484848 result[12]=0x00000000 ABS_OFFSET=0x4C4C4C4C result[13]=0x00000000 ABS_OFFSET=0x50505050 result[14]=0x00000000 ABS_OFFSET=0x54545454 result[15]=0x00000000 ABS_OFFSET=0x58585858 result[16]=0x00000000 ABS_OFFSET=0x5C5C5C5C result[17]=0x00000000 ABS_OFFSET=0x60606060 result[18]=0x00000000 ABS_OFFSET=0x64646464 result[19]=0x01000000 ABS_OFFSET=0x68686868 result[1A]=0x01001000 ABS_OFFSET=0x6C6C6C6C result[1B]=0x11011110 ABS_OFFSET=0x70707070 result[1C]=0x11011111 ABS_OFFSET=0x74747474 result[1D]=0x11011111 ABS_OFFSET=0x78787878 result[1E]=0x11111111 ABS_OFFSET=0x7C7C7C7C result[1F]=0x11111111 Byte 0: (0x10 - 0x6c), middle value:0x3e Byte 1: (0x18 - 0x68), middle value:0x40 Byte 2: (0x10 - 0x68), middle value:0x3c Byte 3: (0x0c - 0x64), middle value:0x38 Byte 4: (0x14 - 0x68), middle value:0x3e Byte 5: (0x24 - 0x74), middle value:0x4c Byte 6: (0x0c - 0x60), middle value:0x36 Byte 7: (0x18 - 0x68), middle value:0x40 MMDC0 MPWRDLCTL = 0x383C403E,MMDC1 MPWRDLCTL = 0x40364C3E MMDC registers updated from calibration Write leveling calibration MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x0021001C MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x002B001E MMDC_MPWLDECTRL0 ch1 (0x021b480c) = 0x00190023 MMDC_MPWLDECTRL1 ch1 (0x021b4810) = 0x000A001C Read DQS Gating calibration MPDGCTRL0 PHY0 (0x021b083c) = 0x4338034C MPDGCTRL1 PHY0 (0x021b0840) = 0x03300328 MPDGCTRL0 PHY1 (0x021b483c) = 0x033A0348 MPDGCTRL1 PHY1 (0x021b4840) = 0x03340258 Read calibration MPRDDLCTL PHY0 (0x021b0848) = 0x44363A44 MPRDDLCTL PHY1 (0x021b4848) = 0x423E3A4C Write calibration MPWRDLCTL PHY0 (0x021b0850) = 0x383C403E MPWRDLCTL PHY1 (0x021b4850) = 0x40364C3E Success: DDR calibration completed!!! ///// Question 3 //// DDR calibration was done. that means DDR operation is OK? and I don't need to add action after ? or I need to act something? and how to handle mass production.. let me know guide. ///// Question 3 //// The DDR stress test can run with an incrementing frequency or at a static freq To run at a static freq, simply set the start freq and end freq to the same value Would do you want run DDR Stress Test? Type 'y' to run and 'n' to skip Enter desired START freq (135 to 672 MHz), then hit enter. Note: DDR3 minimum is ~333MHz, do not recommend to go too much below this. 533 The freq you entered was: 533 Enter desired END freq (135 to 672 MHz), then hit enter. Make sure this is equal to or greater than start freq 533 The freq you entered was: 533 Do you want to run DDR Stress Test for simple loop or Over Night Test? Type '0' for simple loop. Type '1' for Over Night Test DDR Stress Test Iteration 1 Current Temperature: 41 ============================================ DDR Freq: 532 MHz t0.1: data is addr test t0: memcpy10 SSN x64 test t1: memcpy8 SSN x64 test t2: byte-wise SSN x64 test t3: memcpy11 random pattern test t4: IRAM_to_DDRv2 test t5: IRAM_to_DDRv1 test t6: read noise walking ones and zeros test DDR Stress Test is complete!     Re: DDR Test & calibration : please check my test result and is this OK? or not Thank you for your comment.     Re: DDR Test & calibration : please check my test result and is this OK? or not Hi, @albatros74  >>>I think that calibaration means all devices need to calibration and save for each device. >>>calibration value is not fix device by device. isn't that right? Each time you boot your board, the DDR will run the training. So, the calibration is used for test if your DDR is OK for your PCB board. No need run it to all of the same board. B.R Re: DDR Test & calibration : please check my test result and is this OK? or not Hi pengyong Question 1 : You can found the MR1 define in JEDEC "JESD79-3F.pdf" document. : I will check Question 2 : It is not a problem. : Thank you. ^^ >>>and how to handle mass production.. let me know guide. What do you mean mass production? : I think that calibaration means all devices need to calibration and save for each device.  calibration value is not fix device by device. isn't that right? so, if i will update calibration value each device. I think that it needs to too or test and save way in the factory. BR Re: DDR Test & calibration : please check my test result and is this OK? or not Hi, @albatros74  Question 1 : You can found the MR1 define in JEDEC "JESD79-3F.pdf" document. Question 2 : It is not a problem. Question 3 :  >>>DDR calibration was done. that means DDR operation is OK? Yes , It is OK. >>>and I don't need to add action after ? or I need to act something? No need more action. >>>and how to handle mass production.. let me know guide. What do you mean mass production? B.R

Secure Provisioning Tool v7 fails to start flashloader in RT1064  I try to burn eFuse, but SEC fails to open OTP configuration page, here are screen shots, any tips are welcome! Jian Li Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,   Many thanks for your help and explanations. The additional details are, my PC is Lenovo Think pad with window 10 enterprise version 2H22, at least 4 my colleagues (use Lenovo, Think Pad, may be different serial numbers, but the same window 10 version) have the same problems when using SEC v7 or v8, when try to flash program a new build of PCA first time (new DSP MCU IC from factory), it works fine. After the first time, flash program the same DSP PCA is always failed due to flash loader failed to start. Sometimes, I have to erase the MCU flash memory with MCUXpresso plus JLINK probe first, make it like a new MCU, that may work sometimes, (by re-starting PC, restart SEC Tool, etc), but not always lucky. Read eFUSE CONFIG always failed.   Now, I am using SEC v8 with SEC v3.1 flash loader replaced SEC v8 its own flash loader as we discussed a few weeks ago. That works much better than SEC v7 or SEC v8 with its own flash loader. Now I can read eFUSE CONFIG and flash program without problem, only when burn eFUSE, it reports failure, but when re-load eFUSE CONFIG again, the eFUSE has been changed as required. Hopefully, it is really changed because the flashed program re-boot and starting correctly after power recycle.  Regards! Jian Li Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian, thank you for the additional details about the problem. From your screenshot I understand the flashloader failed on address 0x20010A7C. On this address, there is function for clock initialization - configure_clock(). I suspect the failure might be caused by different clock source, Xtal frequency, or some other problem related to clock configuration. We tried to compare the source code of the flashloader with previous version, but we did not find any difference (the clock initialization is quite complex, so we cannot guarantee that there is no difference). We did not identify any problem in the flashloader itself, so we will not change flashloader in the SEC tool. You still can use your own version of the flashloader in next versions of the SEC tool. If you find any additional details about the problem, please let us know. Thank you very much for your cooperation to investigate the problem. Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,  Here are screen shots when I debug it,    Jian Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian, thank you for you verification. Could you run the flashloader in debugger in MCU IDE 11.9 and send the screenshot where it fails? What is the last function/command executed and what command failed and what's the exception? In MCU IDE 11.9, there is no needed any specific setup. Just open the "flashloader" example, build and debug. We suppose the flashloader might initialize some peripheral, and this peripheral does not work on your custom board and this causes the failure. Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek, I have tried these two versions flashloader, both are failed by reporting "Selected UART device not found" after 30 seconds waiting in my PC. I compile the example flashloader from SDK2.15 without change, it also fails and even worse. Sorry for bad news. Jian Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Jian Li, We are happy you can now use SEC tool v8. Still, it would be nice to understand, where the flashloader problem is so we can fix it properly. Can you please also try attached flashloaders? - evkmimxrt1064_flashloader_v_2_11.s19 - comes from MCUXpresso SDK 2.11 and it should be same as distributed in SEC v8, just built using MCUXpresso IDE 11.9.0 - evkmimxrt1064_flashloader_v_2_15.s19 - comes from MCUXpresso SDK 2.15 (latest), built with same MCUXpresso IDE.  Both flashloaders works on our side. Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,    Many thanks for your help. I tried SEC v8 before and then I repeat to try to start flashloader as you described, it still fails starting. I do not know why you have no problem; I cannot start it. Then I replace the flashloader.srec in v8 with v3.1 two files ivt_flashloader.bin and flashloader.srec; then I perform start flashloader, open OTP configuration and write image into flash, all are successfully as shown below.    Clearly, v8 is much faster than v3.1 in perform the same tasks. I have not got any new hardware to burn fuse, but I will try that later and believe it should be OK.   Thank you for your help again, I am happy this solution and you can close this thread.  Jian Li Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian Li, I'm happy that you find the workaround. the flashloader in SEC v8 is located in "c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec" in SEC v3.1, thew flashloader is provided in two formats: 1) "c:\nxp\MCUX_Provi_v3.1\bin\data\targets\MIMXRT1064\flashloader.srec" 2) "c:\nxp\MCUX_Provi_v3.1\bin\data\targets\MIMXRT1064\ivt_flashloader.bin" I tried with RT1064-EVK to use flashloader marked as 1) in SEC v8 and I did not find any problem. I also did not reproduce your issue in SEC v8 with original flashloader. I tested UART with 115200 baudrate. Can you please test SEC v8, using "Start flashloader" button on the Write tab? Just select UART on the toolbar, reset the processor and then hit "Start flashloader" button. Kindly test first with the original flashloader and then with flashloader from SEC v3.1 and please let us know your result. Below I'm sending the screenshot, how it looks on my computer Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,    I install MCUXpresso v9 and import flashloader example project, there is no instructions in doc folder in the example as normal example project, I do not know how to debug it, and have to read flashloader manual to figure out what to do with the flashloader. What are criteria to judge the example code suitable for SEC tool and acceptable? How to replace it with existed SEC tool flashloader?    My experience with RT1052 and an external NOR flash memory programming is easy and reliable in my previous project, so I reinstall the older SEC tool, to my surprise, SEC Tool 3.1 can read eFuse as shown below,  Then I change bit 16:19 in eFuse 0x6D0 to partition FlexRAM, while writing image to flash in the same time, it seems the flash program is OK, write eFuse is failed as following log  When I reboot, the flash memory boot to run in RAM is OK. When I try to open OTP configuration, eFuse 0x6D0 has changed even log report failed. Before fuse burn, 0x6D0 was 0x00000040, now it is 0x00020040, am I right?  Now, I am confident that there is no hardware problem with my DSP PCA, old version 3.1 is better than newer versions v7 and v8, can I use flashloader in v3.1 to newer version? If yes, please advise how to do it?   Jian Li Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian, for the -v option, unfortunately you send a log before the connection dialog, so I do not see whether the flashloader was started or not. For the fuse burning script, if you modify the script manually, you cannot run the script from GUI, because GUI always generate a new script. Nevertheless, the log shows the COM7 port for flashloader is not available. And nxpdevscan does not show any other available COM port. So, either the flashloader does not start (you can debug, potential HW issue on your board) OR your computer refuses to communicate with flashloader.  I'd recommend to debug the flashloader. Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,  I start SEC tool with -v,  Test UART connection is fine as below,  Then I generate script, in advance mode, burn_user_OTP_cfg_win.bat and modified as you suggested,  then I try to read OTP configuration, still failed. So that I try to do burn and think it will call the generated script, but it seems not, still call init_flashloader_win.bat as following I try to scan using nxpdevscan.exe, it fails by try to open wrong port com6, not com7,  Is this mean flashloader setting is not right?  Jian Li Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian, the "burn" script is no generated if there is no requirement to burn any fuse. All fuses are zero by default and it is possible to burn any bit to 1. If you specify required value as zero, no script is generated, because it is not technically doable to change any fuse to 0. I still see in the log, the flashloader does not start. Flashloader is a "helper" application running in RT1064 processor allowing to load the custom application and burn the fuses into the processor using "blhost.exe" tool (via UART or USB). It is possible to find the flashloader implementation in MCUXpresso SDK, see https://mcuxpresso.nxp.com, see example project named "flashloader". You can try to run the example project on your board using debugger and check whether it fails or not. If it works, you can replace the default flashloader distributed in SEC tool (c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec) by your own flashloader In the connection dialog you sent, I do not see any error, so it seems the flashloader was started and connection established. Not sure why the same does not work in OTP configuration dialog. Can you please confirm this? To double-check, can you please start SEC tool with parameter -v (verbose mode, i.e. run securep.exe -v) and go to connection dialog, test the connection and send the log back? Still would be nice to try to generate the burn script and once script is generated, open it and modify @echo ### Check presence of FlashLoader ### call "%blhost%" %blhost_connect% -j -- get-property 1 0 to @echo ### Check presence of FlashLoader ### call "%blhost%" %blhost_connect% -j -- get-property 1 0 @rem ignore any error and try again call "%blhost%" %blhost_connect% -j -- get-property 1 0 After this fails, can you run c:\nxp\MCUX_Provi_v8\bin\_internal\tools\spsdk\nxpdevscan.exe. This tool should report, what connections from the processor are available. This might help to understand, whether the flashloader is active or not. Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,   Many thanks for your help. I did the following actions as you requested: 1. I increase delay time from 5 seconds to 15 seconds at 115.2k, and 30 seconds at 57.6k baud rate as shown below,   2. I tried 57600 baud rate as shown above. 3. I try to generate script, but no response from SEC tool, I cannot find the script file in folder of SEC tool. However, I find the script templates as below and it is seems we duplicate "the call: @echo ### Check presence of FlashLoader ### call "%blhost%" %blhost_connect% -j -- get-property 1 0 " by modification of the macro? If so, please advise how to change it.  In SEC tool manual, " Generate Script is expected to be used on an empty processor. It contains the configuration of all fuses and it might fail if any fuse is already burnt." I thought because I cannot read OTP configuration, there are a few unknown values in some eFuse, that might prevent Generate Script?!  I will try different hardware tomorrow and let you know outcome.  Jian  Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian, the same flashloader is used in connection dialog to verify the processor. If this succeeded, I do not see any reason why it is failing in OTP dialog. 1) Can you try to increase a delay in preferences, see "Timeout for communication re-established after reset"? Usually it needs more time if the board is connected through some USB hub (so would be good to connect the board directly to your PC). 2) Can you try Generate the script for OTP fuses and in the generated script, can you to duplicate the call: @echo ### Check presence of FlashLoader ### call "%blhost%" %blhost_connect% -j -- get-property 1 0 I have seen that sometimes it failed for the first time (the communication is not established) and passed for the second time. 3) Can you also try baudrate 57600? Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Libr,  Thank you for help, I installed and tried SEC v8 and results are the same? When I try to open OTP configuration in build image tab and start flashloader in write image tab, it fails to start flashloader.  Jian Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi, Marek,    Thak you for reply. UART is tested OK before and after trial to open OTP configuration as below.  I can flash my program in UART, why it fails to open OTP configuration? The board is my customized board, there is no USB port. I like to change eFuse for FlexRAM configuration, what is the best tool to do it? Why must I debug and build my own flashloader in SEC tool? Could you please more info on why flashloader not compatible with a board? Thank you in advance! Jian Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian Li, is there any reason you are not using the latest Secure Provisioning Tool *v8*? Regards, Libor Re: Secure Provisioning Tool v7 fails to start flashloader in RT1064 Hi Jian Li, based on your log, the issue is not related to fuses. It seems the flashloader does not start or fails to initialize UART or is not compatible with your board. Are you using EVK board? Have you tried USB? The flashloader in SEC tool (c:\nxp\MCUX_Provi_v8\bin\_internal\data\targets\MIMXRT1064\flashloader.srec) is just compiled example from MCUXpresso SDK. You can build your own and debug the problem.

SD卡启动T2081处理器 嗨，NXP 团队和贡献者们， 我有一块 T2081 定制主板，正在尝试使用 SD 卡启动， rcw 源设置附在下面 这是我的 SD 卡启动的 rcw T2081 (2 1) (210001 0x120c0017) (210002 0x15000000) (210003 0x00000000) (210004 0x00000000) (210005 0x6c000002) (210006 0x00008000) (210007 0x68000000) (210008 0xc1000000) (210009 0x00000000) (210010 0x00000000) (210011 0x00000000) (210012 0x000307ff) (210013 0x00000000）（210014 0x00000004）（210015 0x00000000）（210016 0x00000004） 上电（POR）后，我们可以看到 sd_clk， 但我们没有看到 sd_cmd 信号有任何变化。 如果我们的设置有任何问题，请提出建议 我们如何知道处理器将进入 SD 卡启动模式。 回复：SD卡启动T2081处理器 王一平您好， 感谢您的快速回复。 我们能够成功创建并运行 SRAM 项目。使用 SRAM 对象，我们也能够配置和访问 DDR。然后我们继续从 SD 卡启动。并且在启动时被击中。 我们使用 codewarrior 创建 PBL，并使用 SDK 文档第 1930 页中给出的以下 RCW 和 PBI 命令。我们按照您的指定，使用 dd 命令再次将 PBL 放在第 8 扇区。 aa 55 aa 55 01 0e 01 00 12 0c 00 17 15 00 00 00 00 00 00 00 00 00 00 00 6c 00 00 02 00 00 80 00 68 00 00 00 c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 87 ff 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 04 09 01 00 00 00 20 04 00 09 13 80 00 00 00 00 00 09 13 80 c0 00 00 01 00 09 01 01 00 00 00 00 00 09 01 01 04 ff f8 00 09 09 01 0f 00 08 00 00 00 09 01 00 00 80 00 00 00 09 00 0d 00 00 00 00 00 09 00 0d 04 ff f8 00 00 09 00 0d 08 81 00 00 12 09 11 00 00 80 00 04 03 我们看到处理器正在初始化 SD 卡并读取 RCW，但随后受到打击。 我们的 RCW 是否正确（是否存在与字节序或其他方面有关的问题）？ 如何知道处理器是否正确获取了 RCW。我们从硬件角度检查，SD 卡数据线或命令行没有问题。 在相关说明中，如果我们想从 SRAM 运行这个 PBL 或 u-boot-spl，我们该怎么做？如果您愿意，我可以针对此查询开设另一个线程。 这是我们用于 SD 卡启动的 rcw， T2081 (2 1) (210001 0x120c0017) (210002 0x15000000) (210003 0x00000000) (210004 0x00000000) (210005 0x6c000002) (210006 0x00008000) (210007 0x68000000) (210008 0xc1000000) (210009 0x00000000) (210010 0x00000000) (210011 0x00000000) (210012 0x000387ff) (210013 0x00000000）（210014 0x00000004）（210015 0x00000000）（210016 0x00000004） 谢谢 回复：SD卡启动T2081处理器 王一平您好， 感谢您的快速回复，我们尝试了您的更改 即使我们在 SD 卡中写入了正确的 RCW，我们仍然怀疑 SD 卡读取失败。如何检查 PBL 是否具有正确的 RCW？ 我们正在尝试使用 CodeWarrior tap 调试器连接到目标，但它没有连接，并提示“函数参数错误”。在 PBL 和后续代码运行时检查核心状态和其他寄存器的最佳方法是什么？ 谢谢。 回复：SD卡启动T2081处理器 上述RCW文件是通过CodeWarrior加载的JTAG配置文件。 您需要将 RCW 二进制文件部署到 SD 卡，然后配置开关设置以设置目标板从 SD 卡启动。 在 u-boot 源代码中，请根据您的定制板修改文件 board/freescale/t208xqds/t2081_sd_rcw.cfg，然后使用 T2081QDS_SDCARD_defconfig 构建 SD 启动 u-boot 映像。 然后在 SD 卡上的第 8 块处部署带有 RCW 的整个 u-boot 映像，将 SD 卡插入目标板并配置开关设置以从 SD 卡启动 RCW。

Question about HDMI support in U-Boot for iMX8MQ Greetings, we are working with customized board based on iMX8MQ and trying to make HDMI work in U-Boot on it. We are talking about HDMI from SOC, without MIPI-DSI to HDMI bridge. We are using the following U-Boot version from NXP (customers request): lf_v2022.04, tag: lf-6.1.1-1.0.0.   The problem is that HDMI does not work out of box in U-Boot and we do not have an EVK board from NXP to check whether this functionality is supported at all.    Plus we can't find an answer to this question in the official documentation from NXP.   But we've found a few similar topics for iMX8MP SoCs where it's clearly stated that HDMI is not supported in U-Boot at the moment: https://community.nxp.com/t5/i-MX-Processors/IMX8MP-HDMI-u-boot/m-p/1898159 https://community.nxp.com/t5/i-MX-Processors/Support-U-Boot-splash-screen-to-kernel-in-imx8MP-for-Linux-NXP/m-p/1469165 https://community.nxp.com/t5/i-MX-Processors/How-to-add-imx8mp-HDMI-driver-in-uboot/m-p/1817397 Now we just guess that HMDI implementation may be very similar on iMX8MP and iMX8MQ, so we shouldn't spend time attempting to make HDMI work in U-Boot. If possible, could you please clarify whether the HDMI video output is supported on reference EVK design with reference software from NXP? Best regards, Mikhail Vanyulin. Re: Question about HDMI support in U-Boot for iMX8MQ Hello @Bio_TICFSL, thanks for your feedback! The instructions under your link are for adjustment of video modes for the Linux kernel via U-Boot cmdline. We were not aware that it's possible to adjust corresponding nodes in device tree on the fly - thanks for sharing this knowledge. But our problem was different - the HDMI video output did not work in U-boot on our iMX8MQ board out of box itself. Nevertheless we found the root cause - the HDMI video output started to work on our side when we loaded U-Boot binary from eMMC storage (instead of using serial download). At the moment we can't explain why there is such different in the behavior of the same U-Boot binary when it's loaded via serial. We are investigating this now. But we guess that there's some problem with memory mapping in our U-Boot, as other functionality (access to FPGA via I2C) also stops working when the U-Boot binary is loaded over serial. Once again, thanks a lot for your help. Feel free to close this issue now. Best regards, Mikhail Vanyulin. Re: Question about HDMI support in U-Boot for iMX8MQ Hello, Please check it this thread it may be helpful: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-U-boot-Configuration-for-Display/ta-p/1970292 regards

I want to use hardware watchdog for MK22FN1M0AVMC12 Hello Team , I am using MK22FN1M0AVMC12 microcontroller MQX4.2 RTOS Kinetis design studio IDE I want to use Hardware watchdog (Not software watchdog) Do you have any Example.  Thanks Sudhanshu Re: I want to use hardware watchdog for MK22FN1M0AVMC12 Hi, If you hope that the watchdog can reset the K22 when the chip hangs, the watchdog is not related to RTOS, you just need to initialize the watchdog, and use a timer to generate interrupt, in the ISR, you can feed dog, it is okay. In the code, you have to set the Timer interrupt priority higher that the RTOS interrupt priority. You can download SDK package for the K22: https://mcuxpresso.nxp.com/en then load the watchdog example. Hope it can help you BR XiangJun Rong

我想为 MK22FN1M0AVMC12 使用硬件看门狗 大家好， 我正在使用 MK22FN1M0AVMC12 微控制器 MQX4.2 实时操作系统 Kinetis Design Studio IDE 我想使用硬件看门狗（不是软件看门狗） 你有任何例子吗？ 谢谢！ 苏丹舒

EIM レジスターにアクセスできない EIM を使用してエラーを挿入しようとすると、コードが EIM レジスタにアクセス (読み取りまたは書き込み) するたびに、BusFault になります。同時に、Jtagシミュレータを使用して観察すると、EIMは読み取られず、他のレジスタはOKであることがわかります。EIMレジスタにアクセスする際に特別な操作が必要ですか?RMを確認したところ、これらの条件を満たしていると思います。デバッガでさえレジスタ値を確認できないのはなぜですか?