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を確認したところ、これらの条件を満たしていると思います。デバッガでさえレジスタ値を確認できないのはなぜですか?

S32K312 フォーマットの KeyCatalog の状態は? 私の主要なカタログはすべてHSE_KEY_OWNER_OEMで、MCUのライフサイクルはOEMで、adkpm = 1、start_from_user = 0で始まります。 FormatKeyCatalogs()を実行しようとしましたが、aa55a21cが返ってきましたが、どうすればよいですか? 1. LC = cust_delで失敗しますか? 2. LC = OEMの最初に実行されるフォーマットキーでも大丈夫ですか? 3. 2が「はい」の場合、主要なカタログをどのように再フォーマットしますか?、現在、私はAA55A21Cを手に入れました、 回复: S32K312 形式のキーカタログの状態は? 私の主要なカタログはすべてHSE_KEY_OWNER_OEMで、MCUのライフサイクルはOEMで、adkpm = 1、start_from_user = 0から始まります。 FormatKeyCatalogs()を実行しようとしましたが、aa55a21cが返ってきましたが、どうすればよいですか? 1. LC = cust_delで失敗しますか? >形式のカタログはLC=cust_delでしかできないので、すべてのグループでOKです。 2. LC = OEMの最初に実行されるフォーマットキーでも大丈夫ですか? >そうではないかもしれませんが、カタログがフォーマットされていない場合、LCはOEMに進むことができないと思います。 3. 2が「はい」の場合、主要なカタログをどのように再フォーマットしますか?、現在、私はAA55A21Cを手に入れました、 OEMでは不可能な>、キーの消去とインポートは許可を得て許可されています。 4.カタログのフォーマット カタログがすでに存在する場合は、HSEを呼び出して最初にすべてのキーを削除する必要がありますか? > LC=CUST_DEL は消去せずに直接フォーマットできます。OEM CANT 形式。 5. LC=CUST_DELでキーをフォーマットすることは可能ですか、およびキーカタログの所有者はHSE_KEY_OWNER_OEMですか? >参考文献1。 Re:s32k312形式のキーカタログの条件? こんにちは@victory  1.カタログのフォーマット カタログが直接フォーマットできない カタログがすでに存在する場合は、最初にHSEを呼び出してすべてのキーを削除する必要がありますか?NVM と RAM のキー カタログは、キーをプロビジョニングする前にフォーマットする必要があります。HSE RM のセクション 6.1.5.3 (キー・カタログのフォーマット) および HSE Service API RM の hseFormatKeyCatalogsSrv_t 構造の説明を参照してください。 2. LC=CUST_DELでキーをフォーマットすることは可能ですか、そしてキーカタログの所有者はHSE_KEY_OWNER_OEMですか? HSE RM に「LC 状態 OEM_PROD (OEM_START_AS_USER が 0) の場合、SU 権限を持つホスト (OEM として識別) は、キー グループ オーナーが HSE_KEY_OWNER_OEM と HSE_KEY_OWNER_ANY に設定されているすべての NVM キーのみを消去できます。 LC 状態 IN_FIELD では、ホストが CUST が所有するキーを使用して SU 権限を付与されると、キー グループの所有者が HSE_KEY_OWNER_CUST および HSE_KEY_OWNER_ANY に設定されているすべての NVM キーのみを消去できます。 Re:s32k312形式のキーカタログの条件? こんにちはベーンB、 あなたのアドバイスをありがとう、詳細にいくつかの質問、 1.カタログのフォーマット カタログが直接フォーマットできない カタログがすでに存在する場合は、最初にHSEを呼び出してすべてのキーを削除する必要がありますか? 2. LC=CUST_DELでキーをフォーマットすることは可能ですか、およびキーカタログの所有者はHSE_KEY_OWNER_OEMですか? BRSの

about IDPS(Intrusion Detection and Prevention Systems) in S32G Hi all,     What are the IDPS features of S32G, and which modules in S32G can reflect IDPS? Re: about IDPS(Intrusion Detection and Prevention Systems) in S32G Hello, @brian_w An intrusion detection and prevention system (IDPS) is a solution that monitors a network for threats and then takes action to stop any threats that are detected. On S32G platforms, from the product page(https://www.nxp.com/products/processors-and-microcontrollers/s32-automotive-platform/s32g-vehicle-network-processors:S32G-PROCESSORS), we could see that this is related with cybersecurity part, which is implemented by  partner, you may reference the introduction from https://www.nxp.com/webapp/connect/displayPartnerProfile.sp?partnerId=15960 Since the CAN/ethernet IDPS are mentioned, the PFE, LLCE would have been utilized in implementing this feature. Hope it helps. Best Regards Chenyin

AN12218SW java GUI Bootloader diagram Hello, I have the same problem ( Can't load IA 32-bit .dll on a AMD 64-bit platform) that was already some discussions regarding the GUI for UART bootloader: Unable to run AN12218SW Bootloader (because of 32 bit dll) - NXP Community I have a business laptop and IT department doesn't allow to install whatever I want and that's why I am not allow to install the old version of java Because of this issue I want to create my custom GUI for bootloader. Is there any diagram or steps that I should when creating my interface? I saw in S32 Platform that the uC is answering sometimes with "0x41" or "0x45". How should my application interpret all those messages? Thank you! Re: AN12218SW java GUI Bootloader diagram Hello, I think the information you are looking for can be found in the Application Note, more specifically in chapter 2.2. AN12218: S32K1xx Bootloader – Application Note (nxp.com) Regards

iMX8MQのU-BootでのHDMIサポートに関する質問 あいさつ iMX8MQをベースにカスタマイズされたボードで作業しており、その上でU-BootでHDMIを機能させようとしています。MIPI-DSIからHDMIへのブリッジを使用しない、SOCからのHDMIについて話しています。 NXPのU-Bootバージョン(お客様のご要望)を使用しています:lf_v2022.04、タグ: LF-6.1.1-1.0.0.   問題は、HDMIがU-Bootでそのまま動作せず、この機能がまったくサポートされているかどうかを確認するためのNXPのEVKボードがないことです。   さらに、NXPの公式ドキュメントにはこの質問に対する答えが見つかりません。   しかし、iMX8MP SoC では、現時点では U-Boot で HDMI がサポートされていないと明確に述べられている同様のトピックがいくつか見つかりました。 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 ここで、HMDIの実装はiMX8MPとiMX8MQで非常に似ていると推測しているため、U-BootでHDMIを機能させるのに時間を費やすべきではありません。 可能であれば、NXP のリファレンス ソフトウェアを使用して、HDMI ビデオ出力がリファレンス EVK デザインでサポートされているかどうかを明確にしていただけますか。 よろしくお願いいたします ミハイル・バニュリン。

SDカードの起動T2081プロセッサ こんにちは、NXPチームと寄稿者、 私はSDカードの起動を試みているT2081カスタムボードを持っています、 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カードブートモードになることをどのように確認できますか。 Re:SDカードの起動T2081プロセッサ こんにちはYipingwang、 迅速な対応をいただきありがとうございます。 SRAMプロジェクトの作成と実行を成功裏に行うことができました。SRAMオブジェクトを使用して、DDRの設定とアクセスもできました。次に、SDカードからの起動に進みました。そして、ブーツで打たれました。 SDK ドキュメント ページ 1930 に記載されているように、次の RCW および PBI コマンドを使用して codewarrior を使用して PBL を作成します。PBL は、指定された dd コマンドを使用してセクター 8 に再度配置します。 AA 55 AA 55 01 0E 01 00 12 0C 00 17 15 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 00 00 00 03 87 ff 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 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カードのデータラインやコマンドラインに問題はありません。 関連するメモとして、このPBLまたはu-boot-splをSRAMから実行したい場合、どうすればいいのでしょうか?必要に応じて、このクエリの別のスレッドを開くことができます。 これは、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) 感謝 Re:SDカードの起動T2081プロセッサ こんにちはyipingwang、 あなたの迅速な対応に感謝します、私たちはあなたの変更を試しました SDカードに正しいRCWを挿入したにもかかわらず、SDカードの読み取りが失敗している可能性があります。PBLに正しいRCWがあるかどうかはどうすれば確認できますか? CodeWarrior のタップ デバッガーを使用してターゲットに接続しようとしていますが、"機能するための引数が正しくない" と言って接続されません。PBL とフォローアップ コードの実行中にコア ステータスと他のレジスタを確認する最善の方法は何ですか? 感謝。 Re: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を起動するようにスイッチ設定を構成します。

what SOG means in s32k? I am reading the s32k datasheet, and I found one block called SOG, but there is no explain, could you tell me? thanks very much! Re: what SOG means in s32k? thank you~ I think I should learn many things- - Re: what SOG means in s32k? Hello, SOG = Sea-Of-Gates Best regards, Peter

NFC Cockpit - Transfer more than 64-byte through USB-VCOM Hello, I have been using the NFC Cockpit v8.1.0.0 with the CLEV6630BM development boards. While playing with some tags, we ended up having issues with very long blocks of data. After checking, it seems the VCOM supports up to 64 bytes only, before it needs to split into multiple chunks. With more than 64 bytes, a fatal error occurs. While debugging, I used the UcBalPCTestApp.exe tool to catch the USB-VCOM. Please find the log attached to this case. We immediately see that it fails when it requires to send multiple chunks of data (> 64 bytes). Do you have an idea how to bypass this limitations? Thanks for your support! NFC Frontend Solutions NFC Reader Library Re: NFC Cockpit - Transfer more than 64-byte through USB-VCOM Hello @EduardoZamora  Forget my last post. I found some JLink hardware and was able to update the CLEV6630BM FW to the latest proposed in NFCCockpit installation directory (firmware/Secondary_RC663/BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin). I did not think that the default FW would not handled the VCOM driver properly... Thanks for the pointers! Re: NFC Cockpit - Transfer more than 64-byte through USB-VCOM I'll try to update the firmware anyway. Re: NFC Cockpit - Transfer more than 64-byte through USB-VCOM Hello @EduardoZamora  Thanks for the quick feedback. We are not doing software development on it, so LPC FW has not been touched. I did install the drivers as in the guidlines and NFCockpit is generally working fine with whatever commands I am using. I also tried to reinstall the drivers just in case and I am using the latest version of NFCCockpit 8.1.0.0. For the scenario, I am doing the following steps, with a Type A PICC: Activate Layer 3 -> OK Activate Layer 4 -> OK Select NDEF file (data exchange 00 A4 00 0C 02 E104) -> OK Read X bytes (data exchange 00 B0 0000 XX) This is OK up to 0x36 bytes This fails with 0x37 bytes Checking the log file of NFCCockpit, I am getting the same error as when I am using the UcBalPCTestApp.exe tool: From 0x37 bytes, the it seems the packets are split in chunks of 64-byte packets for some reason. Comparing the 2 logs, could it be related to the "Unable to load ADB process. Check if adb is part of environment variable" exception? Thanks! Re: NFC Cockpit - Transfer more than 64-byte through USB-VCOM Hello @Yann_O Hope you are doing well. Just to confirm, have you followed the procedure described in CLRC663 evaluation board quick start guide, Chapter 3; and NXP NFC Cockpit User Guide, Section 3.3 for the NFC Cockpit FW programming? Also, please make sure to use the latest driver version according to your NFC Cockpit version, otherwise the application might not work correctly. What is the procedure you are following for the test in NFC Cockpit? This would be helpful for me to try to reproduce the scenario on my side. I tested the Microcontroller BAL - PC Test Application and no errors were thrown; please, find the log I obtained from the test attached to this post. Regards, Eduardo.

S32K344 RTD5.0 trigger UsageFault when D_CACHE Enabled Hi there, I created a Uart project using RTD5.0, If D_CACHE is enabled, and called Lpuart_Uart_Ip_AsyncReceive() before send. It will trigger UsageFault. If i undefined the D_CACHE_ENABLE Macro, It works fine. or, If i comment Lpuart_Uart_Ip_AsyncReceive() , the uart can send data normally, but can not receive any data now. so, How should I solve this problem？ Thanks！ Here is my S32DS 3.5 with RTD 5.0 project. 回复： S32K344 RTD5.0 trigger UsageFault when D_CACHE Enabled The root cause of this problem has been found. the thread stack is too small caused the context to be corrupted. 回复： S32K344 RTD5.0 trigger UsageFault when D_CACHE Enabled here is my project.