imx93 lvds with kernel 6.12 I'm trying to make an LVDS display work on an imx93 custom board. I'm struggling with this error : imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 After adding some traces, this comes from this line in the driver (in function lcdif_load) lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); So, it seems it cannot find the "axi" clock. I'm using the device tree from the kernel, imx93.dtsi, as the base, which includes the following lines: clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; So there's some inconsistency here between the device tree and the driver here. Problem is that i don't know if the clocks are correct, which ones i should use. I tried to have a look to what is in the 6.18 branch, but this part (lcdif controller) has completely disappeared from the imx93.dtsi file. Any hints? Re: imx93 lvds with kernel 6.12 Ok, found one cause, this was using the wrong driver. Now, with the lcdif_v3 driver, no clock issues. On the other hand, i still get this problem imx93-ldb ldb-display-controller: Failed to create device link (0x180) with 4ae30000.lcd-controller Any hints ? Re: imx93 lvds with kernel 6.12 Hello @julienblanc  Hope you are doing very well. Are you still having the issue? Best regards, Salas. Re: imx93 lvds with kernel 6.12 Unfortunately, no. I keep having the same error. Here's how i tried to configure things : backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_power is a gpio-hog on an exander : display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; This is mostly taken from some examples in the device-trees. I can't get what's wrong, or why it won't bring the display up, even not the backlight. I know i should use a TPM instead of a software gpio, but that need a hardware fix, currently i have to deal with it and i don't think that's the problem. Thanks for your support, Regards, Julien Re: imx93 lvds with kernel 6.12 For anyone interested, i finally got it working, even with the soft pwm. Causes were : * missing modules in kernel compilation (CONFIG_BACKLIGHT_CLASS_DEVICE=y , CONFIG_BACKLIGHT_PWM=y ,CONFIG_DRM_PANEL_LVDS=y ) * backlight must use a regulator for power supply

i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface We are developing a custom board using the PHYTEC phyCORE-i.MX8M Plus SOM and are reviewing the Ethernet pinmux for migration from the existing RGMII interface to MII. The PHYTEC SOM pin A25 is associated with the i.MX8M Plus ENET_RXC signal. In the i.MX8MP pinmux, ENET_RXC supports ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK and ALT1 = ENET_QOS_RX_ER. We need clarification regarding the correct pin assignment and interface requirements for the intended MII configuration. Specifically, is ENET_RXC required for the MII receive interface, or can the required RX_ER function be assigned to another suitable i.MX8M Plus pad/GPIO? If a different pad can be used, please provide the recommended pin mapping. We also need confirmation of whether the i.MX8M Plus ENET_QOS controller supports the intended MII interface and whether any IOMUX, MAC, device-tree, GPR, or PHY configuration changes are required. Please advise on the recommended Ethernet pin mapping and configuration for the i.MX8M Plus with the PHYTEC phyCORE SOM. Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface Hi, Thank you for your interest in NXP Semiconductor products, i.MX 8M Plus does not support MII, please refer to the following extract from RM: Seamless interface to commercial ethernet PHY devices via one of the following: a 2-bit Reduced MII (RMII) operating at 50 MHz. a (double data rate) 4-bit Reduced GMII (RGMII) operating at 125 MHz. For signal mapping, you can refer to i.MX 8M Plus DS. Regards

i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands I am working with an i.MX8M Quad EVK SD card image and would like to understand the correct procedure for booting and running an application on the Cortex-M4 core from U-Boot. I have downloaded the MCUXpresso SDK for the i.MX8M Quad and successfully compiled the Hello World example for the M4 core. I now have the generated .bin firmware file. Please provide the correct U-Boot commands and boot sequence to load and start this M4 .bin firmware from U-Boot? And how to check M4 console ? #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot-commands i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands Hello, Step-by-Step U-Boot Commands 1. Prepare the SD Card Copy your compiled .bin file (e.g., hello_world.bin ) to the FAT/boot partition (partition 1) of the SD card before inserting it into the EVK. 2. Stop U-Boot Autoboot Power on the board and immediately press any key to interrupt autoboot at the U-Boot prompt. 3. Option A — TCM Execution (Recommended for MCUXpresso SDK apps) This is the standard method for MCUXpresso SDK Hello World examples, which are linked to run from TCM at 0x1FFE0000 (alias 0x7E0000 😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   You should see output like: ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. Option B — DDR Execution If your binary is linked to run from DDR (e.g., 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ Important: Use 0x7e0000 (TCM) or 0x80000000 (DDR) depending on the linker script used when you compiled the MCUXpresso SDK app. For the default Hello World example, TCM ( 0x7e0000 ) is the correct target. Optional: Clear Resource Table Area (for Hello World / bare-metal) If your image does not have an RPMsg resource table (like a simple hello_world.bin ), clear the resource table area to avoid garbage values that could confuse Linux later: u-boot=> mw 0xb80ff000 0 4 Optional: Run prepare_mcore (When Linux Will Also Boot) If you plan to continue booting Linux after starting the M4, run this additional command before bootaux . It configures clocks so Linux does not disable M4-used clocks: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     Checking the M4 Console The i.MX8MQ EVK uses an FTDI USB-serial chip that enumerates two separate COM ports when connected to the PC: Port Core Lower number (e.g., COM9 / /dev/ttyUSB0 ) Cortex-A53 (U-Boot / Linux console) Higher number (e.g., COM10 / /dev/ttyUSB1 ) Cortex-M4 console       Settings for both ports: 115200 baud, 8 data bits, No parity, 1 stop bit (115200 8N1). Open two separate terminal windows (e.g., TeraTerm, minicom, PuTTY): Terminal 1 → Lower COM port → for U-Boot commands Terminal 2 → Higher COM port → to see M4 Hello World output Quick Reference: Automation via Environment Variables You can save these as U-Boot environment variables for convenience: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     Key Reference Documents UG10163 — i.MX Linux User's Guide (Section 4.7.4) — Official M4 boot procedure for i.MX8M Quad AN5317 — Loading Code on Cortex-M from U-Boot/Linux for the i.MX — Deep dive on TCM vs DDR loading GS-MCIMX8M-EVK — Getting Started with the MCIMX8M-EVK — Board-specific step-by-step guide Regards

MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Environment MCU: MWCT2016S based Wireless Charging Controller Working Setup (Legacy): HSE FW Version: 2.6.0 (Application + Secure Boot) merge hex. New Setup (Failing): HSE FW Version: 2.40.0 (Application + Secure Boot) merge hex. We are migrating from HSE FW v2.6.0 to HSE FW v2.40.0 while maintaining the same Qi key provisioning and Secure Boot flow. Problem Statement With HSE FW v2.6.0, the complete provisioning sequence executes successfully: HSE installation Erase Keys S2TP key slot provisioning Qi key programming Secure Boot configuration Application boots successfully With HSE FW v2.40.0, all provisioning steps complete successfully until Secure Boot configuration is started. During Secure Boot configuration the following API fails: ImportPlainSymKeyReqMuChannel() in secure boot code.   return HSE response: 0x55A5A399 which corresponds to:  #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   After this failure, Secure Boot configuration cannot be completed, and the ECU remains stuck in the Secure Boot code.   Provisioning Sequence Working Configuration (HSE 2.6.0) 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_HSE_flash.srec  version 2.6.0 Power Reset 02_EraseKeysSW.hex Power Reset 03_S2TP_KeySlotsAligned.srec  S2TP SW Version: 1.1.1 Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset     HSE response after merge hex flashing from UART log:  HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0   Code debug log HSE response:  ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33    LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp: 0x55a5aa33    KeyProvisioningForJTAG-status: 1    SecureBootConfiguration-hseResp: 0x55a5aa33    KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33    SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33    writeDefaultData    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.6.0 , full mem  using interface version : 0.13.0.2.6.0  HseStatus : 2862         bit 0   : 0 RFU         bit 1   : 1 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 1 , smrStatus[0] : 1 Failing Configuration-HSE FW 2.40.0 reports: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec Power Reset 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex Power Reset 03_S2TP_2_1_0_KeySlotsAligned.srec Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset    HseStatus : 2912         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0 ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399   after Power reset:  UML SW Version : WSB00.3B_UART_ENABLE    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.40.0 , full mem  using interface version : 0.13.0.2.40.0    HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0    ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399 ECU getting stuck in secure boot only Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @ShrikantM  Could you please share your key catalogs as well as the parameters used in the ImportPlainSymKeyReqMuChannel() function call? The reported error indicates that one or more HSE request parameters are invalid. BR, VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  Thank you for sharing the information. Based on your configuration, I have the following observations: The SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY. This is also demonstrated in the NVM SHE Key Catalog Configuration example. The targetKeyHandle passed to ImportPlainSymKeyReqMuChannel() is defined as: #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ However, according to your NVM key catalog configuration, the AES key group is the third group (NvmKeyGroup_2). Based on this configuration, the correct definition for NVM_AES128_BOOT_KEY should be:  GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , We are using below key catalogs: /* Table containing NVM key catalog entries */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* Table containing RAM key catalog entries */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; For below function we receive HSE_SRV_RSP_INVALID_PARAM hseSrvResponse_t Generic_ImportKeys(void) {     hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;     /*Import key linked with SMR#0*/     srvResponse = ImportPlainSymKeyReqMuChannel(             MU0,             1U,             NVM_AES128_BOOT_KEY,             HSE_KEY_TYPE_AES,             ( HSE_KF_USAGE_VERIFY ),             0U,             aesEcbKeyLength,             aesEcbKey,             TRUE             );     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit;     /* load keys for SHE secure boot */     srvResponse = LoadBootMacKey();     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit; exit:     return srvResponse; } Please check attached global_defs.h for more details about the parameters. Thanks and Regards, Swapnil Gawade Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  According to your description, I noticed that you appear to have combined the DemoApp framework with the Hse_Ip drivers. Is my understanding correct? If so, what modifications have been applied? Also, have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory. I also noticed that you are passing HSE_DTCM_ADDR(pHseSrvDesc) as the pHseSrvDesc parameter to the Hse_Ip_ServiceRequest() function. Please refer to the thread HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR, where my colleague explains some considerations regarding the use of HSE with DTCM memory. You may also want to take a look at Hse_Ip_ToAHBAddress(), which converts a local address into an HSE host address when TCM support is enabled. It could be useful in this scenario. Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , As per your suggestion I have done the changes, but it also gives similar response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). After debugging we found that it, in ImportPlainSymKeyReqMuChannel(...)->EraseKeyReq(targetKeyHandle, HSE_ERASE_NOT_USED))->HSE_Send(muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)->Hse_Ip_ServiceRequest(u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))->Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) retruns response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). The parameters of pHseSrvDesc are added in attached Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx. Thanks and Regards, Swapnil Gawade Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  As mentioned, the SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY. Have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory. Also, would it be possible to share a simple example showing all the steps you are performing to import the key? Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , In working setup with HSE 2.6.0 we are using following libraries: 1. RTD AUTOSAR 4.4 2. Key catalog as below /* Table containing NVM key catalog entries */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* Table containing RAM key catalog entries */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; Same RTD AUTOSAR 4.4 and Key catalog we are using with HSE 2.40.0, but we are facing issue. ImportPlainSymKeyReqMuChannel(...) function returns HSE Response as HSE_SRV_RSP_INVALID_PARAM. Hse_Ip_ToAHBAddress() function is not available in this RTD AUTOSAR 4.4. Thanks and Regards, Swapnil Gawade

i.MX8M 四核 – M4 核心启动步骤和所需的 U-Boot 命令 我正在使用 i.MX8M Quad EVK SD 卡镜像 ，想了解 从 U-Boot 启动并在 Cortex-M4 内核 上运行应用程序的正确步骤。 我已经下载了 适用于 i.MX8M 四核处理器的 MCUXpresso SDK ，并成功编译了 M4 内核的 Hello World 示例程序。现在我已经得到了生成的.bin 固件文件。 请提供正确的U-Boot 命令和启动顺序，以便从 U-Boot 加载并启动此 M4 .bin固件？以及如何查看 M4 控制台？ #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot命令 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands 你好， U-Boot 命令分步指南 1. 准备 SD 卡 复制你编译好的 .bin 文件文件（例如， hello_world.bin ）在将 SD 卡插入 EVK 之前，将其写入 SD 卡的FAT/启动分区（分区 1）。 2. 停止 U-Boot 自动启动 打开板电源，然后立即按任意键中断 U-Boot 提示符处的启动。 3. 选项 A — TCM 执行（推荐用于 MCUXpresso SDK 应用） 这是 MCUXpresso SDK Hello World 示例的标准方法，这些示例链接到位于 0x1FFE0000 （别名 0x7E0000 的 TCM 运行。😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   你应该看到类似这样的输出： ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. 选项 B — DDR 执行 如果您的二进制文件链接到 DDR 运行（例如， 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ 重要提示： 根据编译 MCUXpresso SDK 应用程序时使用的 链接器脚本 ，使用 0x7e0000 (TCM) 或 0x80000000 (DDR)。 对于默认的 Hello World 示例，TCM（ 0x7e0000 ）是正确的目标。 可选：清除资源表区域（用于 Hello World / 裸机环境） 如果你的镜像没有RPMsg 资源表（例如简单的 hello_world.bin ），清除资源表区域，以避免产生可能在以后导致 Linux 系统混乱的垃圾值： u-boot=> mw 0xb80ff000 0 4 可选：运行 prepare_mcore （当 Linux 系统也启动时） 如果您计划在启动 M4 后继续启动 Linux，请在 bootaux 之前运行此附加命令。它配置时钟，使 Linux 不会禁用 M4 使用的时钟： u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     检查M4控制台 i.MX8MQ EVK 使用 FTDI USB 转串口芯片，连接到 PC 时会枚举两个独立的 COM 端口： 端口 内核 较低的编号（例如，COM9 / /dev/ttyUSB0 ） Cortex-A53（U-Boot/Linux 控制台） 更高的数字（例如，COM10 / /dev/ttyUSB1 ） Cortex-M4 控制台       两个端口的设置： 115200 波特率，8 位数据位，无奇偶校验，1 位停止位 (115200 8N1)。 打开两个独立的终端窗口（例如，TeraTerm、minicom、PuTTY）： 终端 1 → 下方 COM 端口 → 用于 U-Boot 命令 终端 2 → 更高端口的 COM 端口 → 查看 M4 Hello World 输出 快速参考：通过环境变量实现自动化 为了方便起见，您可以将这些值保存为 U-Boot 环境变量： u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     关键参考文件 UG10163 — i.MX Linux 用户指南（4.7.4 节） — i.MX8M 四核处理器的官方 M4 启动步骤 AN5317 — 通过 U-Boot/Linux 在 i.MX 上向 Cortex-M 加载代码— TCM 与 DDR 加载深度解析 GS-MCIMX8M-EVK — MCIMX8M-EVK 入门指南 — 针对特定开发板的逐步指南 此致

S32K118EVB2Q048：ADC读数与所选MCU供电电压不匹配 您好，NXP团队： 我正在使用 S32K118EVB2Q048 板（原理图 SCH-47530 Rev A1）测试 ADC。当输入电压超过约 3.3 V 时，我的读数就会出错。 设置： - MCU：S32K118（48-LQFP） - IDE：[S32 设计工作室版本] - 驱动程序：[RTD 版本 / SDK 版本 / 裸机版本] - ADC通道：[例如PTA7 – ADC0_SE3] 分辨率：12 位 - 输入：[外部直流电源/板载电位器] - 跳线：J10 = 2-3 (5V)、J107、J15 - 板供电方式：[USB / 12V] 问题： 我将 J10 设置为 2-3，这样 MCU 就可以在 5V 电压下运行。 - 输入 4.10 V：原始值 = 4095。以 5V 为参考电压，我预期读数约为 3358。 - 4V 至 5V 之间的任何输入：始终为 4095（满量程）。 - 当我使用 5V 电压进行计算时，随着输入电压的增加，误差也会增加。 问题： 在 SCH-47530 Rev A1 上，将 J10 设置为 2-3 是否足以使 VDDA 和 ADC 参考电压为 5V，还是我还需要更改其他任何东西（J15、J107、任何电阻器）？ 能否分享一个适用于此EVB的S32K118 ADC工作示例，并用5V基准电压进行测试？能否也提供不同分辨率下的计算范围？ Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage 你好 请问您使用的是哪个RTD/SDK版本？ 另外，我看到你正在使用 PTA7，但是你提到了 ADC_POT。由于 EVB 上未安装 R761，因此 ADC_POT 未连接： 我假设您是通过 J3.1 接头使用 PTA7。 请确认J10和J107都设置为 2-3，并尝试测量 VDD，以确保它确实设置为 5V。 我使用了RTD软件包中的Adc_Pdb_Ip_example_S32K118 ，并简单地修改了main函数，使其循环并启动软件转换： while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } 之后，我使用电源测量了 0 到 5V 之间的电压，可以看到正确的数值。 ADC0_SE2 @3.3V： ADC0_SE2 @5V： 最后，检查 ADC_SC2[REFSEL] 中 REFSEL 是否设置正确： 此致， 朱利安

S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage Hi NXP team, I'm using the S32K118EVB2Q048 board (schematic SCH-47530 Rev A1) and testing the ADC. I'm getting wrong readings when the input voltage goes above about 3.3 V. Setup: - MCU: S32K118 (48-LQFP) - IDE: [S32 Design Studio version] - Driver: [RTD version / SDK version / bare-metal] - ADC channel: [e.g. PTA7 – ADC0_SE3] - Resolution: 12-bit - Input: [external DC power supply / on-board potentiometer] - Jumpers: J10 = 2-3 (5V), J107, J15  - Board powered from: [USB / 12V] Issue: I set J10 to 2-3 so the MCU runs at 5V. - Input 4.10 V: raw = 4095. With a 5V reference I expected about 3358. - Any input from 4 V to 5 V: always 4095 (full scale). - When I calculate with 5V, the error increases as the input voltage increases. Questions: On SCH-47530 Rev A1, is setting J10 to 2-3 enough to make VDDA and the ADC reference 5V, or do I need to change anything else (J15, J107, any resistor)? Can you share a working S32K118 ADC example for this EVB, tested with a 5V reference , can u also give ur calculated range for different for resolution  Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage Hello  Can you share which RTD/SDK version you are using? Also, I can see you are using PTA7, however, you mentioned ADC_POT. ADC_POT is not connected as R761 is not populated on the EVB: I assume you are using PTA7 through the J3.1 header. Please confirm both J10, and J107 are set 2-3, and try to measure VDD to make sure it is indeed set at 5V. I used Adc_Pdb_Ip_example_S32K118 from RTD package, and simply modified main to loop and start a SW conversion: while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } After this, I used a power supply to measure between 0 and 5V, and I could see the correct values. ADC0_SE2 @3.3V: ADC0_SE2 @5V: Lastly, check if REFSEL is correctly set in ADC_SC2[REFSEL]: Best regards, Julián

MWCT2016 HSE 2.40.0 セキュアブート構成エラー - ImportPlainSymKeyReqMuChannel 環境 MCU:MWCT2016Sベースのワイヤレス充電コントローラー 動作環境設定（従来型） ： HSE FW バージョン: 2.6.0 (アプリケーション+セキュアブート)16進をマージします。 新規設定（失敗） : HSE FW バージョン: 2.40.0 (アプリケーション+セキュアブート)16進をマージします。 Qiキーのプロビジョニングとセキュアブートのフローはそのまま維持しつつ、HSE FW v2.6.0からHSE FW v2.40.0への移行を進めています。 問題提起 HSE FW v2.6.0では、プロビジョニングシーケンス全体が正常に実行されます。 HSE設備 キーを消去する S2TPキースロットのプロビジョニング Qiキープログラミング セキュアブート構成 アプリケーションが正常に起動します HSE FW v2.40.0では、セキュアブート構成が開始されるまで、すべてのプロビジョニング手順が正常に完了します。 セキュアブートの設定中に、以下のAPIが失敗します。 ImportPlainSymKeyReqMuChannel() はセキュアブートコードに含まれています。   HSE応答を返します: 0x55A5A399これは以下に対応します: #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   この失敗後、セキュアブートの設定が完了できず、ECUはセキュアブートコードに閉じ込められてしまいます。   プロビジョニングシーケンス 動作構成（HSE 2.6.0） 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 電源リセット 01_HSE_flash.srecバージョン2.6.0 電源リセット 02_EraseKeysSW.hex 電源リセット 03_S2TP_KeySlotsAligned.srec  S2TPソフトウェアバージョン: 1.1.1 電源リセット UART経由でQiキーを書き込む 電源リセット Application+SecureBoot.hex 電源リセット     UARTログからのマージ後の16進数フラッシュ後のHSE応答： HseStatus: 2848 ビット0：0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4：0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9：1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14：0 RFU ビット15：0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0   コードデバッグログHSE応答:  ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33   LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp: 0x55a5aa33   KeyProvisioningForJTAG-status: 1   SecureBootConfiguration-hseResp: 0x55a5aa33   KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33    SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33   writeDefaultData   セキュアブートCFGプログラムを実行中 Hse-FW バージョン: 0.13.0.2.6.0、フルメモリ インターフェースバージョン使用:0.13.0.2.6.0 HseStatus: 2862 ビット0：0 RFU ビット 1 : 1 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT ビット 3 : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4：0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9：1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14：0 RFU ビット15：0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 1 、smrStatus[0] : 1 構成エラー - HSE FW 2.40.0 のレポート: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 電源リセット 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec 電源リセット 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex 電源リセット 03_S2TP_2_1_0_KeySlotsAligned.srec 電源リセット UART経由でQiキーを書き込む 電源リセット Application+SecureBoot.hex 電源リセット   HseStatus: 2912 ビット0：0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4：0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9：1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14：0 RFU ビット15：0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0 ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399   電源リセット後： UMLソフトウェアバージョン：WSB00.3B_UART_ENABLE   セキュアブートCFGプログラムを実行中 Hse-FW バージョン: 0.13.0.2.40.0、フルメモリ インターフェースバージョン:0.13.0.2.40.0の使用   HseStatus: 2848 ビット0：0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4：0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9：1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14：0 RFU ビット15：0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0    ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399 ECUがセキュアブートのみで停止する Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @ShrikantM さん。 ImportPlainSymKeyReqMuChannel() 関数呼び出しで使われているパラメータと、キーカタログを教えていただけますか?報告されたエラーは、1つ以上のHSEリクエストパラメータが無効であることを示しています。 BR、VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @VaneB さん。 弊社では以下のキーカタログを使用しています。 /* NVMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; /* RAMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; 以下の関数では、HSE_SRV_RSP_INVALID_PARAM を受け取ります。 hseSrvResponse_t Generic_ImportKeys(void) {     hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;     /*SMR#0にリンクされたインポートキー*/     srvResponse = ImportPlainSymKeyReqMuChannel(             MU0、 1U、             NVM_AES128_BOOT_KEY、             HSE_KEY_TYPE_AES、             ( HSE_KF_USAGE_VERIFY )             0U、             aesEcbKeyLength、             aesEcbKey、 真実             );     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             出口へ移動;     /* SHEセキュアブート用のキーをロード */     srvResponse = LoadBootMacKey();     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             出口へ移動; 出口：     return srvResponse; } 添付のglobal_defs.hをご確認ください。パラメータの詳細については、こちらをご覧ください。 よろしくお願いいたします。 スワプニル・ガワデ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @SwapnilGawade さん。 情報共有ありがとうございます。お客様の設定に基づき、以下の点を確認いたしました。 SHEキーグループはHSE_KEY_OWNER_CUSTを所有者として設定しています。しかし、HSEサービスAPIリファレンスマニュアルでは、SHEキーカタログ構成の場合、SHEキーグループの所有者をHSE_KEY_OWNER_ANYに設定しなければならないと規定されています。これは、NVM SHEキーカタログ構成の例でも示されています。 ImportPlainSymKeyReqMuChannel() に渡される targetKeyHandle は次のように定義されます。 #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ ただし、NVMキーカタログの設定によると、AESキーグループは3番目のグループ(NvmKeyGroup_2)となります。この構成に基づくと、NVM_AES128_BOOT_KEY の正しい定義は次のようになります。 GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @SwapnilGawade さん。 あなたの説明によると、DemoAppフレームワークとHse_Ipドライバーを組み合わせているように見えました。私の理解は正しいでしょうか？もしそうなら、どのような修正が加えられましたか? また、プロジェクトでデータキャッシュを無効にしていますか？これは、HSE_SRV_RSP_INVALID_PARAM エラーの一般的な原因です。HSEとの通信に使用されるすべてのデータオブジェクトは、キャッシュ不可能なメモリに強制的に格納されなければならない。 また、Hse_Ip_ServiceRequest() 関数に pHseSrvDesc パラメータとして HSE_DTCM_ADDR(pHseSrvDesc) を渡していることに気づきました。HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR Threadを参照してください。同僚がDTCMメモリでのHSE使用に関するいくつかの考慮点を説明しています。 また、TCMサポートを有効にするとローカルアドレスをHSEホストアドレスに変換する機能Hse_Ip_ToAHBAddress()も検討すると良いでしょう。この状況では役立つかもしれません。 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @VaneB さん。 ご提案いただいたとおり変更を行いましたが、 HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) と同様の応答も返されます。 デバッグの結果、 ImportPlainSymKeyReqMuChannel (...)-> EraseKeyReq (targetKeyHandle, HSE_ERASE_NOT_USED))-> HSE_Send (muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)-> Hse_Ip_ServiceRequest (u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))-> Mu_Ip_SetTxRegister (Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) でHSE_SRV_RSP_INVALID_PARAM (0x55a5a399)という応答が返されることがわかりました。 pHseSrvDesc のパラメータは、添付の Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx に追加されています。 よろしくお願いいたします。 スワプニル・ガワデ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @VaneB さん。 HSE 2.6.0 を使用した作業環境では、以下のライブラリを使用しています。 1. RTD AUTOSAR 4.4 2.キーカタログは以下のとおりです /* NVMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; /* RAMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; 同じRTD AUTOSAR 4.4とKeyカタログをHSE 2.40.0で使用していますが、問題が発生しています。ImportPlainSymKeyReqMuChannel(...) 関数は、HSE レスポンスとしてHSE_SRV_RSP_INVALID_PARAMを返します。 Hse_Ip_ToAHBAddress()機能はこの RTD AUTOSAR 4.4では利用できません。 よろしくお願いいたします。 スワプニル・ガワデ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @SwapnilGawade さん。 前述の通り、SHEキーグループはHSE_KEY_OWNER_CUSTを所有者として設定されています。しかし、HSEサービスAPIリファレンスマニュアルでは、SHEキーカタログ構成の場合、SHEキーグループの所有者をHSE_KEY_OWNER_ANYに設定しなければならないと規定されています。 プロジェクトでデータキャッシュを無効にしましたか？これは、HSE_SRV_RSP_INVALID_PARAM エラーの一般的な原因です。HSEとの通信に使用されるすべてのデータオブジェクトは、キャッシュ不可能なメモリに強制的に格納されなければならない。 また、キーをインポートするために実行しているすべての手順を示す簡単な例を共有していただけますか？

i.MX8MP ENET_RXC/A25 Pinmux MIIインターフェースの説明 PHYTEC phyCORE-i.MX8M Plus SOMを使用したカスタムボードを開発しており、既存のRGMIIインターフェースからMIIへのイーサネットピンマックス移行を検討しています。PHYTEC SOMのピンA25は、i.MX8M PlusのENET_RXC信号に関連付けられています。i.MX8MPピンマックスでは、ENET_RXC ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLKおよびALT1 = ENET_QOS_RX_ERをサポートしています。意図されたMII構成の正しいピン割り当てとインターフェース要件についての明確な説明が必要です。具体的には、MII受信インターフェースにENET_RXCが必要でしょうか?それとも必要なRX_ER機能は別の適切なi.MX8M Plusパッド/GPIOに割り当てられるのでしょうか?別のパッドが使える場合は、推奨されるピンマッピングをご提供ください。また、i.MX8M Plus ENET_QOSコントローラが意図されたMIIインターフェースをサポートしているか、IOMUX、MAC、デバイスツリー、GPR、PHYの設定変更が必要かどうかも確認する必要があります。i.MX8M PlusとPHYTEC phyCORE SOMの推奨イーサネットピンマッピングと設定についてアドバイスをお願いします。 Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 i.MX 8M PlusはMIIをサポートしていないため、RMからの以下の抜粋を参照してください。 以下のいずれかを通じて商用イーサネットPHYデバイスへのシームレスなインターフェースが可能です: 50MHzで動作する2ビット縮小MII（RMII）。 125 MHzで動作する、 1 つの （ダブル･データ･レート）4 ビットの縮小GMII (RGMII)。 信号マッピングについては、8M Plus DS i.MX を参照してください。 よろしくお願いします。

MWCT2016 HSE 2.40.0 安全启动配置失败 - ImportPlainSymKeyReqMuChannel 环境 MCU：基于MWCT2016S的无线充电控制器 工作设置（旧版） ： HSE固件版本：2.6.0 （应用程序 + 安全启动）合并十六进制。 新设置（失败） ： HSE固件版本：2.40.0 （应用程序 + 安全启动）合并十六进制。 我们正在从 HSE FW v2.6.0 迁移到 HSE FW v2.40.0，同时保持相同的 Qi 密钥配置和安全启动流程。 问题陈述 使用 HSE FW v2.6.0，完整的配置序列可以成功执行： HSE 安装 擦除按键 S2TP密钥槽配置 Qi 键编程 安全启动配置 应用程序启动成功 使用HSE FW v2.40.0时，所有配置步骤均成功完成，直到启动安全启动配置。 在安全启动配置期间，以下API 失败： 在安全启动代码中导入PlainSymKeyReqMuChannel()。   返回HSE 响应： 0x55A5A399 ，对应于： #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   出现此故障后，安全启动配置无法完成，ECU 将卡在安全启动代码中。   配置顺序 工作配置（HSE 2.6.0） 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 电源 RESET 01_HSE_flash.srec版本 2.6.0 电源 RESET 02_EraseKeysSW.hex 电源 RESET 03_S2TP_KeySlotsAligned.srec S2TP 软件版本：1.1.1 电源 RESET 通过 UART 写入 Qi 密钥。 电源 RESET 应用程序+安全启动.hex 电源 RESET     从 UART 日志中获取合并十六进制烧录后的 HSE 响应： HseStatus：2848 位 0：0 RFU 位 1：0 HSE_SHE_STATUS_SECURE_BOOT 位 2：0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3：0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4：0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5：1 HSE_STATUS_RNG_INIT_OK 位 6：0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7：0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8：1 HSE_STATUS_INIT_OK 位 9：1 HSE_STATUS_INSTALL_OK 位 10：0 HSE_STATUS_BOOT_OK 位 11：1 HSE_STATUS_CUST_SUPER_USER 位 12：0 HSE_STATUS_OEM_SUPER_USER 位 13：0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14：0 RFU 位 15：0 RFU smrCoreStatus_Get： smrCoreStatus[1]：0，smrCoreStatus[0]：0 smrStatus[1]：0，smrStatus[0]：0   代码调试日志 HSE 响应：  ImportPlainSymKeyReqMuChannel-hseResp：0x55a5aa33   LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp：0x55a5aa33   KeyProvisioningForJTAG-status: 1   SecureBootConfiguration-hseResp: 0x55a5aa33   KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp：0x55a5aa33    SECURE_IVT-BLOCK0-hseResp：0x55a5aa33   writeDefaultData   运行安全启动配置程序 Hse-FW 版本：0.13.0.2.6.0，完整内存 使用的接口版本：0.13.0.2.6.0 HseStatus：2862 位 0：0 RFU 位 1：1 HSE_SHE_STATUS_SECURE_BOOT 位 2：1 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3：1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4：0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5：1 HSE_STATUS_RNG_INIT_OK 位 6：0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7：0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8：1 HSE_STATUS_INIT_OK 位 9：1 HSE_STATUS_INSTALL_OK 位 10：0 HSE_STATUS_BOOT_OK 位 11：1 HSE_STATUS_CUST_SUPER_USER 位 12：0 HSE_STATUS_OEM_SUPER_USER 位 13：0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14：0 RFU 位 15：0 RFU smrCoreStatus_Get： smrCoreStatus[1]：0，smrCoreStatus[0]：0 smrStatus[1]：1，smrStatus[0]：1 配置失败 - HSE 固件 2.40.0 报告： 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 电源 RESET 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec 电源 RESET 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex 电源 RESET 03_S2TP_2_1_0_KeySlotsAligned.srec 电源 RESET 通过 UART 写入 Qi 密钥。 电源 RESET 应用程序+安全启动.hex 电源 RESET   房屋状态：2912 位 0：0 RFU 位 1：0 HSE_SHE_STATUS_SECURE_BOOT 位 2：0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3：0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4：0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5：1 HSE_STATUS_RNG_INIT_OK 位 6：1 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7：0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8：1 HSE_STATUS_INIT_OK 位 9：1 HSE_STATUS_INSTALL_OK 位 10：0 HSE_STATUS_BOOT_OK 位 11：1 HSE_STATUS_CUST_SUPER_USER 位 12：0 HSE_STATUS_OEM_SUPER_USER 位 13：0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14：0 RFU 位 15：0 RFU smrCoreStatus_Get： smrCoreStatus[1]：0，smrCoreStatus[0]：0 smrStatus[1]：0，smrStatus[0]：0 ImportPlainSymKeyReqMuChannel-hseResp：0x55A5A399   断电重启后： UML 软件版本：WSB00.3B_UART_ENABLE   运行安全启动配置程序 Hse-FW 版本：0.13.0.2.40.0，完整内存 使用的接口版本：0.13.0.2.40.0   HseStatus：2848 位 0：0 RFU 位 1：0 HSE_SHE_STATUS_SECURE_BOOT 位 2：0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3：0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4：0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5：1 HSE_STATUS_RNG_INIT_OK 位 6：0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7：0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8：1 HSE_STATUS_INIT_OK 位 9：1 HSE_STATUS_INSTALL_OK 位 10：0 HSE_STATUS_BOOT_OK 位 11：1 HSE_STATUS_CUST_SUPER_USER 位 12：0 HSE_STATUS_OEM_SUPER_USER 位 13：0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14：0 RFU 位 15：0 RFU smrCoreStatus_Get： smrCoreStatus[1]：0，smrCoreStatus[0]：0 smrStatus[1]：0，smrStatus[0]：0    导入PlainSymKeyReqMuChannel-hseResp：0x55a5a399 ECU 仅卡在安全启动模式 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@ShrikantM 能否请您分享一下您的密钥目录以及在ImportPlainSymKeyReqMuChannel()函数调用中使用的参数？报告的错误表明一个或多个 HSE 请求参数无效。 BR，VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@VaneB ， 我们使用以下主要目录： /* 包含 NVM 密钥目录条目的表 */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = { /* NvmKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* NvmKeyGroup_1 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}}, /* NvmKeyGroup_2 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* 包含 RAM 键目录条目的表 */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = { /* RamKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; 对于以下函数，我们收到 HSE_SRV_RSP_INVALID_PARAM 错误 hseSrvResponse_t Generic_ImportKeys(void) { hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR; /*导入与 SMR#0 关联的密钥*/     srvResponse = ImportPlainSymKeyReqMuChannel( MU0， 1U             NVM_AES128_BOOT_KEY,             HSE_KEY_TYPE_AES,             ( HSE_KF_USAGE_VERIFY ),             0U, aesEcbKeyLength， aesEcbKey， 真的             ); ASSERT(HSE_SRV_RSP_OK == srvResponse); 如果(HSE_SRV_RSP_OK != srvResponse)             跳转到出口； /* 加载 SHE 安全启动的密钥 */ srvResponse = LoadBootMacKey(); ASSERT(HSE_SRV_RSP_OK == srvResponse); 如果(HSE_SRV_RSP_OK != srvResponse)             跳转到出口； 出口： 返回 srvResponse； } 请查看附件 global_defs.h 文件。有关参数的更多详细信息。 感谢并致意 斯瓦普尼尔·加瓦德 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@SwapnilGawade 感谢您分享信息。根据您的配置，我有以下几点看法： SHE 密钥组配置的所有者为 HSE_KEY_OWNER_CUST。但是，HSE 服务 API 参考手册规定，对于 SHE 密钥目录配置，SHE 密钥组的所有者必须设置为 HSE_KEY_OWNER_ANY。NVM SHE 密钥目录配置示例也证明了这一点。 传递给 ImportPlainSymKeyReqMuChannel() 的 targetKeyHandle 定义如下： #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ 但是，根据您的 NVM 密钥目录配置，AES 密钥组是第三组 (NvmKeyGroup_2)。基于此配置，NVM_AES128_BOOT_KEY 的正确定义应该是： GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@VaneB ， 根据您的建议，我已经进行了更改，但它仍然给出与HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) 类似的响应。 经过调试，我们发现ImportPlainSymKeyReqMuChannel (...)-> EraseKeyReq (targetKeyHandle, HSE_ERASE_NOT_USED))-> HSE_Send (muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)-> Hse_Ip_ServiceRequest (u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))-> Mu_Ip_SetTxRegister (Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) 返回的响应为HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) 。 pHseSrvDesc 的参数已添加到附件 Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx 中。 感谢并致意 斯瓦普尼尔·加瓦德 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@SwapnilGawade 根据您的描述，我注意到您似乎将 DemoApp 框架与 Hse_Ip 驱动程序结合使用了。我的理解正确吗？如果进行了修改，具体做了哪些修改？ 另外，您是否已在项目中禁用数据缓存？这是导致 HSE_SRV_RSP_INVALID_PARAM 错误的一个常见原因。所有用于与 HSE 通信的数据对象都必须强制存储在不可缓存的内存中。 我还注意到，您将 HSE_DTCM_ADDR(pHseSrvDesc) 作为 pHseSrvDesc 参数传递给了 Hse_Ip_ServiceRequest() 函数。请参阅HSE_ReadAdkp 返回 HSE_SRV_RSP_INVALID_ADDR 的线程，我的同事在其中解释了有关将 HSE 与 DTCM 内存一起使用的一些注意事项。 您可能还想了解一下 Hse_Ip_ToAHBAddress()，当启用 TCM 支持时，它会将本地地址转换为 HSE 主机地址。在这种情况下，它或许有用。 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@VaneB ， 在 HSE 2.6.0 的工作环境中，我们使用了以下库： 1. RTD AUTOSAR 4.4 2.主要目录如下 /* 包含 NVM 密钥目录条目的表 */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = { /* NvmKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* NvmKeyGroup_1 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}}, /* NvmKeyGroup_2 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* 包含 RAM 键目录条目的表 */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = { /* RamKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; 我们使用的是与 HSE 2.40.0相同的RTD AUTOSAR 4.4和密钥目录，但我们遇到了问题。ImportPlainSymKeyReqMuChannel(...) 函数返回 HSE 响应为HSE_SRV_RSP_INVALID_PARAM 。 此RTD AUTOSAR 4.4中不提供 Hse_Ip_ToAHBAddress() 函数。 感谢并致意 斯瓦普尼尔·加瓦德 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@SwapnilGawade 如前所述，SHE 密钥组配置的所有者为 HSE_KEY_OWNER_CUST。但是，HSE 服务 API 参考手册规定，对于 SHE 密钥目录配置，SHE 密钥组的所有者必须设置为 HSE_KEY_OWNER_ANY。 你的项目中是否禁用了数据缓存？这是导致 HSE_SRV_RSP_INVALID_PARAM 错误的一个常见原因。所有用于与 HSE 通信的数据对象都必须强制存储在不可缓存的内存中。 另外，能否分享一个简单的示例，展示您导入密钥的所有步骤？

S32K118EVB2Q048:ADCの読み取り値が選択されたMCUの電源電圧と一致しない こんにちは、NXPチームの皆様、 私はS32K118EVB2Q048ボード（回路図SCH-47530 Rev A1）を使用してADCをテストしています。入力電圧が約3.3Vを超えると、誤った測定値が表示されます。 セットアップ: - MCU:S32K118(48-LQFP) - IDE:[S32 Design Studio版] - ドライバ:[RTDバージョン/SDKバージョン/ベアメタル] - ADCチャネル:[例:PTA7 – ADC0_SE3] - 解像度:12ビット - 入力:[外部直流電源/搭載ポテンショメータ] - ジャンパー:J10 = 2-3(5V)、J107、J15 - 基板電源:[USB / 12V] 問題: J10を2-3に設定してMCUを5Vで動作させています。 - 入力 4.10 V: 生データ = 4095。5Vの基準電圧であれば、約3358を期待していました。 - 4V～5Vの入力：常に4095（フルスケール）。 - 5Vで計算すると、入力電圧が高くなるにつれて誤差が大きくなります。 質問: SCH-47530 Rev A1では、J10を2～3に設定するだけでVDDAとADCの基準電圧が5Vになりますか？それとも他に何か変更する必要はありますか（J15、J107、抵抗など）？ このEVBの動作するS32K118 ADCの例を5Vの基準でテストしたものを共有してもらえますか?また、解像度のために異なる異なる計算範囲も教えてもらえますか? Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage こんにちは どのRTD/SDKバージョンを使っているか教えてもらえますか? また、PTA7を使っているのはわかりますが、ADC_POTも言及されていましたね。ADC_POTは接続されていません。なぜならR761はEVBに登録されていないからです: あなたはJ3.1ヘッダーを介してPTA7を使用しているものと想定します。 J10とJ107の両方が2-3に設定されていることを確認し、VDDを測定して、実際に5Vに設定されていることを確認してください。 RTDパッケージの Adc_Pdb_Ip_example_S32K118 を使い、メインをループに改造して SW 変換を始めるだけです: while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } その後、電源ユニットで0Vから5Vの間で測定し、正しい値が確認できました。 ADC0_SE2 @3.3V: ADC0_SE2 @5V: 最後に、ADC_SC2[REFSEL]でREFSELが正しく設定されているか確認してください。 よろしくお願いします、 ジュリアン

彩色/旧屏幕，带 IVI-SHELL IMX8QXP - Scarthgap - L 6.6.52-weston 12-ivishell 在更新后的屏幕之前，会先显示彩色/旧屏幕。如何避免/清除/去除它。 weston.ini [核] #gbm-format=argb8888 空闲时间=0 shell=ivi-shell.so # 使用 g2d=1 重绘窗口=16 # 翻页超时=0 背景颜色=0x00000000 [libinput] touchscreen_calibrator=true [输出] 名称=LVDS-1 模式=1280x720@60 [ivi-shell] ivi-shell-user-interface=weston-ivi-shell-user-interface ivi-input-module=ivi-input-controller.so ivi-id-agent-module=ivi-id-agent.so 输入方法=ivi-输入控制器 基础层ID=1000 基础层 ID 偏移量=10000 工作区背景图层 ID=2000 工作区图层 ID=3000 应用程序层 ID=4000 过渡持续时间=0 [桌面应用程序默认] default-surface-id=2000000 default-surface-id-max=2001000 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: Coloured/Old Screen with IVI-SHELL 你好， 我试了建议的方法，但问题依旧。彩色/旧式屏幕仍然显示。 还有其他建议或需要配置吗？ 谢谢，此致敬礼！ VKS Re: Coloured/Old Screen with IVI-SHELL 你好， 请尝试将背景颜色更改为 0x00000000 并取消注释 gbm-format。 您还可以尝试在 Weston systemd 服务中添加一个预启动步骤，以便在 Weston 初始化之前清除显示内容： echo 1 > /sys/class/graphics/fbx/blank 顺祝商祺！ Re: Coloured/Old Screen with IVI-SHELL 你好， 谢谢你的更新。 这个问题之前在 weston-imx-10.0.1 版本中已经报告过，并通过以下补丁解决了： diff --git a/libweston/renderer-g2d/g2d-renderer.c b/libweston/renderer-g2d/g2d-renderer.c index 245a50de..d9df8b4e 100644 --- a/libweston/renderer-g2d/g2d-renderer.c +++ b/libweston/renderer-g2d/g2d-renderer.c @@ -2199,6 +2199,7 @@ drm_create_g2d_image(struct g2d_surfaceEx* g2dSurface, buffer->buf_vaddr = vaddr; buffer->buf_size = size; g2dSurface->base.planes[0] = buffer->buf_paddr; + memset(buffer->buf_vaddr, 0x00, size); g2dSurface->base.left = 0; g2dSurface->base.top = 0; g2dSurface->base.right = w; 获取缓冲区时添加 memset，可以在 weston 启动时清除缓冲区。 在最新的 weston-imx-15.0.1 版本中，情况发生了变化，需要一个端口。 内部团队已确认 gl-renderer 不存在此问题，因此，请您帮忙检查一下使用 gl-renderer 是否能避免此问题？（# use-g2d=1）。 另外，请分享您在屏幕上看到的内容，以便我们更好地了解问题所在。 顺祝商祺！ Re: Coloured/Old Screen with IVI-SHELL 你好， 请查找图片。 是的，使用use-g2d=1 可以避免出现彩色屏幕。但我发现出现了丢帧现象，而且视频也无法播放。 还有一点，如果我使用`use-g2d=1`，这是为了软件加速，对吗？但我们需要硬件加速来避免丢帧。请检查并确认。 谢谢，此致敬礼！ VKS

丹佛哪家移动应用开发公司提供端到端服务？ 如果您正在丹佛寻找一家提供端到端服务的移动应用开发公司， JPLoft值得考虑。JPLoft 拥有 16 年以上的经验，已交付 1250 多个项目，提供完整的移动应用开发解决方案，包括 UI/UX 设计、iOS 和 Android 开发、AI 集成、测试、部署和发布后支持。 该公司帮助初创企业和大型企业构建可扩展、用户友好的移动应用程序，以满足其业务需求。  

S32k322マイクロコントローラにHSEファームウェアをインストールします。 NXPサポートチームの皆さん、こんにちは。 私は S32K322 マイクロコントローラのセキュリティ実装に取り組んでおり、AESのセキュリティ運用と乱数生成(TRNG)のためにHSE(ハードウェアセキュリティエンジン)モジュールを活用する必要があります。 以下の情報を提供していただけますか: S32K322 （2MBフラッシュメモリ搭載）専用に構成された、公式HSEファームウェアインストール例プロジェクト。 S32K322 HSEファームウェアのセットアップに必要な標準リンカスクリプト（.ld）、IVTオフセット、およびメモリ境界設定。 S32K322派生製品と互換性のある正確なHSE-Bファームウェアのバイナリパッケージバージョンの確認。 Re: HSE Firmware install in S32k322 microcontroller . こんにちは、 @Ranjith_kumar HSEデモ事例をご紹介します。 https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples プロジェクト S32K344_HSE_FW_INSTALL は他の S32K3 派生モデルに簡単に移植可能です。 しかし、どのプロジェクトでもHSEファームウェアをインストールできます。以下の手順を実行するだけで済みます。 - OTP UTEST メモリの 0x1B00_0000 に HSE 機能フラグをプログラムします。これは通常のフラッシュプログラミングで「手動」で行うこともできます(前述のS32K344_HSE_FW_INSTALLで示されています)。または、ブート設定ワードでビットを設定しFW_USAGE_FLAG_PROGRAM SBAFによって自動的に行うこともできます。この自動プログラミング機能は、SBAFバージョン0.15.0以降でのみ利用可能ですのでご注意ください。非常に古い機器をお持ちの場合は、動作しない可能性があり、手動でのプログラミングが必要になります。 ピンク色のファイルをフラッシュメモリのどこかに書き込み、オフセット0x2CにあるIVTにピンク色のファイルへのポインタを追加する。 その後、MCUをリセットするだけです(FULL_MEMファームウェアの場合は2回、AB_SWAPファームウェアなら3回)で完了です。 低レベルでは、次のようになります。 これは、いくつかのアプリケーションのIVTであり(複数の場所が使用可能で、この場合はデータフラッシュが使用されます)、FW_USAGE_FLAG_PROGRAMが設定され、FWイメージへのポインタが含まれています。 ピンク色のファイルには0x480000がプログラムされています。 リセット後、UTESTでフィーチャーフラグが自動的にプログラムされ、HSEファームウェアがインストールされます（HSE GPRレジスタのビット0（アドレス0x4039_C028）が設定されます）。 S32K344_HSE_FW_INSTALLでは、機能フラグはソフトウェアによってプログラムされます(main.cファイルを参照)。 ポインタは、ファイル boot_header.c 内の IVT に追加されます。 ピンク色のファイルは、S32K344_flash_full_mem.ld または S32K344_flash_ab_swap.ld 内のプロジェクトにリンクされています。必要な構成によって異なります。 詳細については、HSE-Bファームウェアリファレンスマニュアルの以下のリソースをご覧ください。2.8: 表17.BCWコンテンツ 表119。BCWビットマッピング 表118。IVT構造 表143。HSE_CONFIG_GPR3 (0x4039C028) のステータスビット 標準RTDプロジェクトをお持ちの場合、プロジェクトにこれを実装する方法は次のとおりです。 - startup_cm7.s を開くファイルと、オフセット0x2Cにあるピンク色のファイルへのポインタを追加します。 - オフセット0x4のIVT内にあるブート構成ワードのビット9を設定します。 そして、リンカーファイル（例えば「linker_flash_s32k322.ld」）に移動します。そしてProject S32K344_HSE_FW_INSTALLで見られるのと同じ方法でピンクファイルをリンクしてください。 それだけです。プロジェクトをビルドしてMCUに読み込み、デバイスを何度かリセットするだけです。 S32K322用HSEファームウェアの最新製品版を入手する方法： S32K3標準ソフトウェアへ進む: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-STDSW-D 「オートモーティブ SW - S32K3 - HSEファームウェア」を選択してください ここでS32K3x2およびS32K3x4の0.2.55.0を検索してください: HSE_FW_S32K342_0.2.55.0_D2512.exe をダウンロードしてください。このバージョンは S32K322 にも対応しています。 最後に、LauterbachのTrace32を使うと、添付スクリプトを使ってファームウェアをインストールできます。デフォルトの位置情報方法を使っています。 よろしくお願いいたします。 ルーカス Re: HSE Firmware install in S32k322 microcontroller . こんにちは、 @lukaszadrapa さん。 サポートありがとうございます。ご指示いただいた通り、S32K322デバイスにHSEファームウェアを正常にインストールすることができました。 新しいピンク色のファイルを使用してHSEファームウェアを新しいバージョンにアップデートする必要があるのですが、問題が発生しています。私のコードはHSEファームウェアアップデートフロー（HSE_SRV_ID_FIRMWARE_UPDATE）に基づいており、サービスは以下を返します。 HSE_SRV_RSP_VERIFY_FAILED (0x55A5A164) 設定の詳細： - デバイス:S32K322 - ファームウェアバリアント: FULL_MEM - 現在インストールされているHSE FWバージョン：添付画像 - 新しいピンク色のファイル: リンカーファイルに追加 - 更新モード: ONE_SHOT - 新しいピンク色の画像の位置: 0x00400000 HSEファームウェアを更新するための例コードがあれば教えてもらえますか? #define HSE_SRV_RSP_VERIFY_FAILED ((hseSrvResponse_t)0x55A5A164UL)

モーター制御の書籍 この内容がこのサブredditに合わない場合は、遠慮なく教えてください。削除します。 特にFOCを使ったPMSMモーターのモーター制御を理解するための本を探しています。センサーレス制御方法があればなお良いです。現在はR・クリシュナン氏の著書を参考にしていますが、もっと良いものが欲しいと思っています。 Re: Motor control books こんにちは、 おすすめできるのは: DRM148 AN14616 PMSMMCXN10UG AN4642 内部EMEA6モーター制御基礎デッキ NXPコミュニティPMSM & FOC理論の記事 1. ここから始めてください:DRM148 センサーレスPMSM制御設計(DRM148) トピック： PMSM数学モデル クラーク・トランスフォーム パークトランスフォーム 現在のFOC スピードFOC 逆起電力推定 センサーレスローター位置推定 スタートアップ戦略 観察者理論 https://www.nxp.com/docs/en/reference-manual/DRM148.pdf 2. MCAT(運動識別と調整)を学ぶ モーター制御アプリケーションチューニング(MCAT)ツール(3相PMSM、AN4642) トピック： 運動パラメータの識別 電流ループチューニング スピードループチューニング FOCパラメータ生成 FreeMASTERの統合 リンク： https://www.nxp.com/docs/en/application-note/AN4642.pdf 3. 現代のMCXセンサーレスアプリケーションノートを読む AN14616: MCX E24xにおけるセンサレスPMSMの磁界指向制御(FOC) トピック： 周辺実装 PWM の同期化 ADCサンプリング センサーレスオブザーバーの統合 実際のファームウェア構造 リンク： https://docs.nxp.com/bundle/AN14616 4. 完全な作業用ソフトウェアの学習 MCUXpresso SDK 3相PMSMおよびBLDCモーターのフィールド指向制御(FOC) これは、ソフトウェアスタック全体の構成方法を説明しているため、実用的な文書の中でも特に優れたものの一つです。 5. リファレンスデザイン MCX A153を使用したPMSMセンサーレスFOC 内容物： リファレンス・デザイン ソフトウェアパッケージ ドキュメント ハードウェアのセットアップ 支援図書館（RTCESL） NXPはこれを、完全なPMSMセンサーレスFOCの出発点と表現している。 リンク： MCX A153を使用したPMSMセンサレスFOC 6. NXPコミュニティワークショップ モジュール2:PMSMとFOC理論 NXPコミュニティ記事 よろしくお願いいたします。 ピーター

i.MX 8M Plus 定制板：在 U-Boot 2024 中，ums 和 fastboot 命令失败，并显示“USB 初始化失败：-22”错误。 我在基于i.MX 8M Plus 的自定义硬件平台上启动 USB 外围设备功能（ums 和 fastboot）时遇到问题，该平台运行的是U-Boot v2024.04 （通过 Yocto 构建）。 尝试将 eMMC 导出为大容量存储或调用 fastboot 时，控制器初始化失败并抛出无效参数错误 (-22)：   u-boot=> ums 0 mmc 2 UMS：LUN 0，设备 mmc 2，硬件分区 0，扇区 0x0，计数 0x3a3e000 USB控制器初始化失败。 u-boot=> fastboot 0 USB 初始化失败：-22 环境和设置上下文： U-Boot 版本： 2024.04 (PV="2024.04"已通过 BitBake 环境检查确认）。 硬件：定制板。与参考 i.MX 8M Plus EVK 不同，该设计在 I2C 总线上没有采用标准的 Type-C 端口控制器 (TCPC) 芯片。 当前软件调整：我们目前包含一个补丁，用于绕过 板/freescale/imx8mp_evk/imx8mp_evk.c 中的错误。因此，当 TCPC 函数无法找到 I2C 设备时，引导加载程序不会完全中止初始化。 问题： 即使绕过了启动中止，USB 协议栈也会拒绝初始化命令，错误代码为 -22 (EINVAL)。 我们想验证此故障是否与缺失的 TCPC 状态如何处理动态角色分配直接相关，或者当偏离参考 EVK 设计时，自定义 i.MX 8M Plus 布局上的 USB 外设操作是否需要基本的驱动程序模型/设备树框架配置不匹配。 问题： 在 U-Boot 2024.04 下，在 i.MX 8M Plus 平台上调用 fastboot 或 ums 时出现 -22 (EINVAL) 错误的常见结构或配置原因是什么？ 没有参考 EVK 的 Type-C 设置的定制板应该如何正确配置其板文件或设备树属性，以安全地启用独立的 USB 设备/外设功能？ 任何见解或调试建议都将不胜感激。

NXP Kinetis KM35 Metering Libraries I am working on a metering application with the kinetis KM35 series, and I am having some trouble understanding the Low-power metering library. I have been using the application note AN13259 "Low-Power Real-Time Algorithm for Metering Applications." While trying to integrate this library, I have found that there are actually many versions of this library in addition to multiple versions of the digital-filter and FFT-based versions. The examples in the SDK (imported through MCUExpresso) seem to have versions of these libraries that I cannot even find. My questions is this: What is the best way to determine what version of the library to use? What is the best way to find the most up-to-date information about the LPRT metering library? Am I working form the most recent and up-to-date application notes (AN13259)? Kinetis M Series MCUs Re: NXP Kinetis KM35 Metering Libraries Hi, This got me where I needed to be. I was looking at an old application note about the low-power algorithm itself, AND I was using an older version of the library itself. It seems the library interface was majorly overhauled (and simplified!) since that note was relevant. Using the SDK provided version, and following the in-code documentation was the right way to go. -o7

i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C Hi, I have designed a custom PCB using the MIMXRT1064 processor and the SGTL5000 audio codec. For the SGTL5000 circuit, I followed the standard/reference SGTL5000 schematic. The connections between the RT1064 and SGTL5000 are as follows: LPI2C1_SCL → GPIO_AD_B1_00 LPI2C1_SDA → GPIO_AD_B1_01 SAI1_MCLK → GPIO_AD_B1_09 SAI1_RXD → GPIO_AD_B1_12 SAI1_TXD → GPIO_AD_B1_13 SAI1_RX_BCLK → GPIO_AD_B1_11 SAI1_RX_LRCLK → GPIO_AD_B1_10 I have attached the relevant part of my schematic as well. My main problem is that after flashing the firmware, I am not receiving any I2C ACK from the SGTL5000. I measured the following voltages: SCL = approximately 3.3 V SDA = approximately 3.3 V MCLK = approximately 1.6 V For debugging, I wrote a function that temporarily changes the I2C pins to GPIO, generates 9 clock pulses, performs a bit-banged I2C address scan, and then restores the pins back to LPI2C1. static void i2c_hw_debug(void) { gpio_pin_config_t in = { kGPIO_DigitalInput, 0, kGPIO_NoIntmode }; IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_00_GPIO1_IO16, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_01_GPIO1_IO17, 0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_00_GPIO1_IO16, 0x00B0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_01_GPIO1_IO17, 0x00B0U); gpio_pin_config_t out_init = { kGPIO_DigitalOutput, 1, kGPIO_NoIntmode }; GPIO_PinInit(GPIO1, 16, &out_init); GPIO_PinInit(GPIO1, 17, &in); for (int i = 0; i < 9; i++) { GPIO_PinWrite(GPIO1, 16, 0U); SDK_DelayAtLeastUs(10U, SystemCoreClock); GPIO_PinWrite(GPIO1, 16, 1U); SDK_DelayAtLeastUs(10U, SystemCoreClock); } PRINTF("Scanning I2C addresses...\r\n"); for (uint8_t addr = 0x03; addr <= 0x77; addr++) { if (bb_probe(16, 17, addr)) { PRINTF("ACK found at 0x%02X\r\n", addr); } } IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_00_LPI2C1_SCL, 1U); IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_01_LPI2C1_SDA, 1U); } How can I initialize the SGTL5000 codec with the MIMXRT1064, and why am I not receiving an ACK from the codec even though all the hardware connections and configurations appear to be correct? Thanks. Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C Hi @Anushka_SS, I would suggest basing your application on the evkmimxrt1064_sai example code instead. This code exemplified the integration of the RT1064 and a WM8960 codec. That said, we do also provide the fsl_sgtl5000.c/.h driver files, which can be imported as a component to the project, and enabled by simply changing the codec used by undefining CODEC_WM8960_ENABLE and defining CODEC_SGTL5000_ENABLE instead. The SGTL5000 driver files have the necessary routines to properly initialize and use this codec. Let me know if this helps, and if you require any further assistance. BR, Edwin. Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C Thank you. I have already done this: a fresh project using the SDK's fsl_sgtl5000 driver with CODEC_SGTL5000_ENABLE. The problem occurs before the driver initializes: the SGTL5000 NAKs its address (0x0A and 0x2A, LPI2C status 902). Verified at run time: Audio PLL = 786.432 MHz, SAI1 MCLK = 12.288 MHz (read back from the CCM registers), LPI2C clock = 10 MHz. I am using GPIO_AD_B1_00/01 for LPI2C1 and GPIO_AD_B1_09 for MCLK. The SGTL5000 module is connected to my custom RT1064 board with jumper wires. Can you suggest what else to check on the hardware side (pad settings, MCLK signal integrity, anything specific to the RT1064)? Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C I have both the RT1064 and the SGTL5000 codec on my custom board. I tested each chip independently: the SGTL5000 with a Teensy 4.1, and the RT1064 with an external PJRC SGTL5000 audio shield. Both work fine on their own, but when I connect them together by soldering their pins, it doesn't work, and I get this output: === SGTL5000 bring-up test === I2C scan (Teensy style)... Scan done: 0 device(s) Audio PLL = 786432000 Hz SAI1 mux=2 prediv=3 div=15 -> MCLK = 12288000 Hz (expect 12288000) LPI2C clock = 10000000 Hz (expect 10000000) -- try 1 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 -- try 2 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 -- try 3 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 SGTL5000 not answering. Stop. The voltages I'm measuring are: SCL: 3.2 V SDA: 3.2 V MCLK: 1.5–1.6 V Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C Update: MCLK testing results The RT1064 board and the codec board are two separate boards, connected with jumper wires. I tested the codec using MCLK from two different sources, with the same RT1064 I2C firmware. Test 1: MCLK from the RT1064 (SAI1_MCLK, GPIO_AD_B1_09, 12.288 MHz) A DC multimeter on the MCLK pin reads about 1.57 V (supply about 3.1 V). Slow bit-bang I2C (~1 kHz): the codec ACKs, but CHIP_ID reads 0xBFFF / 0xA01F instead of 0xA011. LPI2C at 5, 10, 20, 50 and 100 kHz: NAK at every speed (status 902). With a weak MCLK pad setting (0x1008), the codec doesn't answer at all and the MCLK pin reads about 0 V. Different MCLK pad drive settings made no difference. Test 2: MCLK from a Teensy 4 (pin 23) RT1064 MCLK jumper wire disconnected from the codec board. Teensy MCLK connected to the codec board's MCLK pad, Teensy GND connected to the codec board's GND. RT1064 still drives I2C (SCL/SDA) through jumper wires. RT1064 LPI2C at 100 kHz: CHIP_ID = 0xA011 and CODEC_Init OK. A DC multimeter on the Teensy MCLK reads about 1.7 V (3.3 V supply). Conclusion so far The codec board, its power supplies, the I2C wiring and the I2C firmware all work. The problem is only the MCLK coming from the RT1064 board. The DC level looks normal on a multimeter, but the codec behaves as if the 12.288 MHz clock arriving from the RT1064 is not usable. Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C Can you please help me understand why the RT1064 is not providing a proper clock signal to the codec on the MCLK pin? Could this be a hardware-related issue, or is it more likely to be a configuration problem in my RT1064 program, such as the MCLK clock source, Audio PLL configuration, clock divider, pin mux configuration, or SAI settings?

デンバーのモバイルアプリ開発会社はどこでエンド・ツー・エンド・サービスを提供していますか? デンバーでエンドツーエンドのサービスを提供する モバイルアプリ開発会社 をお探しなら、 JPLoft は検討する価値があります。16+年の経験と1,250+件のプロジェクトを手がけ、JPLoftはUI/UXデザイン、iOSおよびAndroid開発、AI統合、テスト、展開、リリース後のサポートを含む完全なモバイルアプリ開発ソリューションを提供しています。 同社はスタートアップや企業がビジネスニーズに合わせたスケーラブルで使いやすいモバイルアプリの開発を支援しています。  

i.MX 8M Plus Custom Board: ums and fastboot commands fail with "USB init failed: -22" in U-Boot 2024 I am experiencing an issue bringing up USB peripheral functions (ums and fastboot) on a custom hardware platform based on the i.MX 8M Plus running U-Boot v2024.04 (built via Yocto). When trying to export the eMMC as mass storage or invoke fastboot, the controller fails to initialize and throws an invalid argument error (-22):   u-boot=> ums 0 mmc 2 UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000 Couldn't init USB controller. u-boot=> fastboot 0 USB init failed: -22 Environment & Setup Context: U-Boot Version: 2024.04 (PV="2024.04" confirmed via BitBake environment check). Hardware: Custom board. Unlike the reference i.MX 8M Plus EVK, this design does not feature a standard Type-C Port Controller (TCPC) chip on the I2C bus. Current Software Adjustments: We currently include a patch to bypass errors inside board/freescale/imx8mp_evk/imx8mp_evk.c so the bootloader does not completely abort initialization when the TCPC functions fail to locate the I2C device. The Problem: Even with the boot abort bypassed, the USB stack rejects the initialization commands with error code -22 (EINVAL). We want to verify whether this failure is directly related to how the missing TCPC state handles dynamic role assignment, or if there is a fundamental driver model / device tree framework configuration mismatch required for USB peripheral operation on custom i.MX 8M Plus layouts when deviating from the reference EVK design. Questions: What are the common structural or configuration causes for the -22 (EINVAL) error when invoking fastboot or ums on an i.MX 8M Plus platform under U-Boot 2024.04? How should a custom board without the reference EVK's Type-C setup correctly configure its board file or device tree properties to safely enable standalone USB device/peripheral functionality? Any insights or debugging pointers would be appreciated