MC33777B データシート BMSを設計しているのですが、 MC33777BのデータシートがNXPのウェブサイトの公開ファイルとセキュアファイルの両方に見当たりません。MC33777Bの完全なデータシートを提供していただけないでしょうか？ Re: MC33777B Datasheet 私の回答は以下のとおりです。   1: MC33777B データシート：   これは、機密保持契約（NDA）に基づき、安全なファイルを通じてのみ提供されます。 セキュリティファイルは製品ページからアクセスできます。   https://www.nxp.com/products/MC33777   LinaHou_0-1780285320974.png 2：弊社のセキュアファイルシステムで確認したところ、お客様はセキュアファイルへのアクセス権を取得済みです。こちらのガイドを参照して、お客様側からダウンロードしてください： https://www.nxp.com/docs/en/user-guide/nxp-docstore-migration-guide.pdf 申請が完了すると、docstore が申請をサポートします。 MC33777B [DS1110110]のデータシートは、製品マネージャーの承認後、お客様向けに提供されます。 ダウンロードリンクが記載されたメールが届きますので、そこからデータシートを直接ダウンロードできます。 手順を理解するには、よくある質問（FAQ）をご確認ください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS もし あなた は 直面している どれでも 問題 に アクセス の 安全な ファイル または さらに遠く 支援 必要、 お願いします ただ 使用 あなたの 会社 メール、提供 あなたの NDA# または 秘密保持契約 コピー、 プロジェクト 詳細、 接触 私たちの ドキュメントストア チーム 直接 で これ メール 住所： [email protected] 彼らはきっと喜んであなたをサポートしてくれるでしょう。 この情報が少しでもお役に立てば幸いです。   ありがとうございました。良い一日をお過ごしください。

Booting a Non-XIP Application from SEMC NAND on MIMXRT1170-EVKB Software Prerequisites MCUXpresso IDE Tera Term (serial terminal) Secure Provisioning Tool 1 Introduction This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB. Because NAND memory is block-oriented and cannot be executed in place, the application image must be linked to internal or external RAM (ITCM, DTCM, OCRAM, or SDRAM) and copied from NAND into RAM by the i.MX RT1170 BootROM prior to execution. The guide covers the required board rework, hardware validation using the MCUXpresso SDK, project configuration for RAM-linked builds, bootable image generation using the MCUXpresso Secure Provisioning Tool (SEC), one-time fuse programming for ECC, image programming to NAND, and final boot verification. Readers are strongly encouraged to review Section 2 (Bootable Image Layout) of application note AN14069 before proceeding, as familiarity with the image layout is essential for understanding the steps that follow. swetha_v_0-1779206877689.png RT1170 Bootable image layout 2 Hardware Rework The EVKB ships with the SEMC NAND data-line 0-ohm resistors depopulated (DNP) because those SoC pins are muxed with other functions on the board. You must solder them in before NAND is usable. 2.1 Resistors to Populate Solder R1872 through R1879 (eight 0-ohm resistors) on NAND data lines DATA0-DATA7. Before soldering, cross-check against your specific EVKB revision’s schematic. Open the board schematic PDF and search for the SEMC NAND section, the reference designators can shift by a digit or two between revisions. The relevant schematic is downloadable from the NXP product page. swetha_v_0-1779205885596.png 2.2 Hardware Validation via SDK Examples After populating the resistors, validate the rework by running the SDK example mentioned below in the default QSPI NOR boot configuration (no changes to SW1/SW2 from factory settings yet). This isolates hardware issues from boot-configuration issues and gives clean signal before attempting SEC flashing. 2.3 Recommended Validation Sequence Run the semc_nand component example. Path: \boards\evkbmimxrt1170\component_examples\flash_component\semc_nand. Import via File → Import → MCUXpresso SDK Examples → MIMXRT1170-EVKB → component_examples\flash_component\semc_nand Build and flash to QSPI NOR (default boot configuration). Open a serial terminal on the MCU-Link VCOM port at 115200 baud 8N1. Press reset. The example will read the NAND ID, erase a block, program a page, read it back, and print the results. Pass criteria: all operations complete without errors and the read-back data matches the written data. If this passes, the hardware rework (R1872–R1879) is electrically correct and the NAND software layer that SEC depends on works. Please proceed to SEC flashing. swetha_v_1-1779205885702.png   3 Build a NAND-Bootable Application in MCUXpresso IDE NAND is block-oriented; the CPU cannot execute directly from it. The application must be RAM-linked (non-XIP), and the ROM will copy it into RAM before jumping. 3.1 Import the SDK Example Install SDK_26.03.00_MIMXRT1170-EVKB into MCUXpresso IDE (drag the ZIP into “Installed SDKs”). File → Import → MCUXpresso SDK Examples. Board: MIMXRT1170-EVKB; core: CM7. Select the iled_blinky example for initial bring-up. Click Finish. 3.2 Configure Project for RAM-Linked (Non-XIP) Build Right-click project → Properties → C/C++ Build → MCU settings: In Memory details, set default RAM to ITCM/OCRAM/SDRAM as shown in below images. Move the corresponding RAM to the lower line of the Flash item, below BOARD_FLASH using the arrows on the right. Since the BootROM uses the first 8K of the linked RAM during image copying, in this step, the start address is offset by 0x2000 and the size is modified accordingly. Setting default RAM to ITCM: swetha_v_2-1779205885730.png Setting default RAM to OCRAM: swetha_v_3-1779205885759.png Note: There is no limitation when linking the image text section to ITCM, DTCM, or SDRAM for non-XIP boot. However, when linking the image text section to OCRAM (0x2020_0000 – 0x203F_FFFF), one limitation applies: the region 0x2024_0000 – 0x2024_BFFF must be reserved as this is the ROM RW region. If the image text section is linked into the ROM RW region, the ROM routine will be corrupted during image copying. swetha_v_4-1779205885777.png Setting default RAM to SDRAM: swetha_v_5-1779205885807.png Note: This option requires an XMCD (External Memory Configuration Data) block in the boot image. Then C/C++ Build → Settings → MCU C Compiler → Preprocessor, add or change: XIP_BOOT_HEADER_ENABLE=0 XIP_EXTERNAL_FLASH=0 In the project’s Settings tab (project root), check “Link application to RAM”. swetha_v_6-1779205885863.png   4 Build the Bootable Image in the SEC Tool 4.1 Create the SEC Workspace Launch MCUXpresso Secure Provisioning Tool File → New workspace → choose a folder Processor: MIMXRT1176 (RT1170-EVKB) Boot type (toolbar): Unsigned Boot device (toolbar): SEMC NAND LC: Open, HAB disabled swetha_v_7-1779205885887.png 4.2 Configure SEMC NAND device parameters for Micron MT29F2G08ABAGAH4-IT:G Select Target → Boot Memory … to open Boot Memory Configurations swetha_v_8-1779205885915.png Based on MT29F2G08ABAGAH4 datasheet, its default ECC is off, so we need to do the below ECC settings: swetha_v_9-1779205886059.png 4.3 Build the bootable image Go back to the MCUXpresso IDE and build the iled_blinky project. Upon successful build, an axf file will be generated. You may find it in …\MCUXpressoIDE_25.6.136\workspace\evkbmimxrt1170_iled_blinky_cm7\Debug Navigate back to Secure Provisioning Tool → Build image Source executable image → Browse → …\MCUXpressoIDE_25.6.136\workspace\evkbmimxrt1170_iled_blinky_cm7\Debug\evkbmimxrt1170_iled_blinky_cm7.axf Start address: Needs to correspond to the start address set in Memory Configurations in Part 3.2 If linking the application to SDRAM, check XMDC → SEMC SDRAM DCD (binary): None Click Build Image Status of the command is shown in the log and the bottom of the screen: swetha_v_10-1779205886160.png   5 Put the Board in Serial Downloader Mode Before SEC can write to NAND, the RT1176 ROM must be in SDP mode. 5.1 Boot Mode for Serial Downloader SW1 = OFF-OFF-OFF-ON (BOOT_MODE[1:0] = 01) The boot mode is selected based on the binary value stored in the internal BOOT_MODE register, and switch SW1-3 and SW1-4 are used to select the boot mode on the MIMXRT1170 EVKB board. SW1-1 SW1-2 SW1-3 SW1-4 BOOT_MODE Mode OFF OFF OFF ON 01 Serial Downloader OFF OFF ON OFF 10 Internal Boot   5.2 Connect and Verify Power off the board (SW5 OFF). Set SW1 as shown above. Connect a USB cable to J20 (USB OTG1, primary USB per the schematic) Power on (SW5 ON) and press SW4 (reset). Windows Device Manager should show an HID device with VID=0x1FC9, PID=0x013D. This is the RT1176 ROM’s SDP interface.   6 Burn Fuse for the EVKB’s NAND This step is NAND-specific. Per RM Table 10-20 (Fuse definition for Parallel NAND over SEMC), for the RT117x ROM to load an image from this NAND with ECC protection and valid bad-block detection, one fuse must be burned for reliable NAND boot on the EVKB’s Micron NAND. 6.1 The Fuse Attribute Value Register BOOT_CONFIG_MISC2[31:0] Offset 0x0C80 Bit to burn Bit 24 Bit value 1 Value to burn for EVKB 1 (register = 0x01000000) Without this burn, the ROM reads pages without ECC correction. Because the Micron NAND writes ECC-protected data only when ECC is enabled, any data written via the SDK with ECC enabled would appear as uncorrected bytes + parity. With ECC off, even small bit-errors become uncorrectable read failures, and bad-block detection via ECC status is unreliable. 6.2 Test Connection Click Test connection. The expected result is shown in the screenshot below. swetha_v_11-1779205886273.png 6.3 How to Burn the Fuse via SEC Ensure the board is in SDP mode, with USB connected to J20. In the SEC workspace, open Build image → OTP configuration. Read the current values from the processor. Locate BOOT_CONFIG_MISC2[31:0] at offset 0x0C80. In the Required value column, enter 0x01000000. Ensure there is no “*” (unknown) in any bit of the current or required value. Select Advanced Mode → Generate script, to confirm that only MISC2 bit 24 will be written. Select Advanced Mode → Burn to execute the burn. Read the fuses back and verify that BOOT_CONFIG_MISC2 = 0x01000000 and that other fuses remain unchanged. Click OK. swetha_v_0-1779206602330.png swetha_v_13-1779205886328.png swetha_v_14-1779205886431.png   7 Write the Bootable Image to NAND via SEC At this stage, every item in the Build image tab should be checked green. swetha_v_15-1779205886625.png Switch to the “Write image” view. Use built image: checked. Connection type: USB (ensure that the device remains in SDP mode and is connected). Click Write image. swetha_v_16-1779205886676.png   8 Configure Boot Switches for Internal Boot from SEMC NAND 8.1 Power Off Slide SW5 to OFF. 8.2 Set BOOT_MODE to Internal Boot SW1 = OFF-OFF-ON-OFF (BOOT_MODE[1:0] = 10) 8.3 Set BOOT_CFG1 for SEMC Parallel NAND SW2 = OFF-OFF-OFF-OFF-ON-OFF-OFF-OFF SW2 position BOOT_CFG1 bit Value SW2-1 BOOT_CFG[0] 0 (OFF) SW2-2 BOOT_CFG[1] 0 (OFF) SW2-3 BOOT_CFG[2] 0 (OFF) SW2-4 BOOT_CFG[3] 0 (OFF) SW2-5 BOOT_CFG[4] 0 (OFF) SW2-6 BOOT_CFG[5] 1 (ON) SW2-7 BOOT_CFG[6] 0 (OFF) SW2-8 BOOT_CFG[7] 0 (OFF) SW2-9 BOOT_CFG[8] 0 (OFF) SW2-10 BOOT_CFG[9] 0 (OFF) This is the EVKB-specific setting that selects SEMC Parallel NAND as the boot device.   9 Boot and Verify Slide SW5 to ON. Press SW4 (reset). The on-board user LED should blink, confirming that the application has booted successfully from SEMC NAND.   References AN14069 — How to Enable Non-XIP Boot on i.MX RT Series EVK Board. IMXRT1170RM — i.MX RT1170 Reference Manual. MIMXRT1170-EVKB Hardware Development User Guide and Board Schematic. Micron MT29F2G08ABAGAH4 NAND Flash Datasheet. MCUXpresso Secure Provisioning Tool User Guide. This article describes the end-to-end procedure for booting a non-XIP application from SEMC parallel NAND flash on the MIMXRT1170-EVKB.

S32K314 FreeRTOS Standby Transition and Return to Run Mode I am developing a project that combines interrupts and tasks using the S32K314, RDT 7.0.0, and FreeRTOS 7.0.0. The interrupts and tasks are functioning properly. I have implemented code that transitions from Run mode to Standby mode and returns to Run mode after a specified time has elapsed as measured by the RTC. I have confirmed that the system transitions from Run mode to Standby mode, and that a reset occurs afterward, causing the MCU bootloader to run again.　 However, an error occurs during the process of distributing the clock to the MCU peripherals after the MCU initialization begins and the PLL locks. Since it works during P.O.R., I believe there is some error in the process that transitions the system to Standby mode. Could you please help me? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Additional Information: This project defines Standby RAM. The RAM is allocated as a 32-kilobyte region starting from the beginning of the BSS. This region stores the necessary data after resuming from Standby. /*--- Transition to Standby Mode ---*/ /* Set the timeout for the RTC timer to wake up WKPU0 */ Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds); /* Suspend all OS tasks */ vTaskSuspendAll(); /* Initialize the clock mode to Standby */ Mcu_InitClock(McuClockSettingConfig_Standby); /* Set the clock mode */ Mcu_SetMode(McuModeSettingConf_Standby); ..... (Reset Occur) /*--- MCU Initialization ---*/ /* Set the Standby RAM area to non-cacheable */ MpuConfigurator_AllocateStandbyRamToNonCacheable(); /* Enable non-cacheable mode */ MpuConfigurator_Enable(); /* Initialize the MCU module */ Mcu_Init(NULL_PTR); /* Initialize clock settings in Run mode */ if (E_OK == Mcu_InitClock(McuClockSettingConfig_Run)) { /* Wait for PLL lock via polling */ while (MCU_PLL_LOCKED != Mcu_GetPllStatus()) { /* Wait until the PLL locks */ } /* Distribute the PLL clock to the system */ Mcu_DistributePllClock();　　← An error occurs here Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi @Teruhiko, Could you find more information about the error? What type of fault exception is it? https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259 https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570 https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 You could also step through the code to identify the exact location where the exception is triggered. Check the DCM_GPR registers for any error. RM, Table 231. DCM controlled features and availability in product family. It could be because of incorrect SRAM initialization after the reset. There is ERM that monitors that, but the clock of the module is gated of by default. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi danielmartynek-san, I apologize for the delayed response. Since communication with J-TAG is lost when the system transitions to Standby mode, I have not yet been able to obtain the detailed error information. I am currently writing debugging code. I would like to share what we currently know. I have investigated the reset causes under the following conditions: ・ Automatic reset recovery after an RTC timeout following a transition to Standby mode 　→ Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt while in Standby mode after entering Standby 　→ Reset cause: MCU_WAKEUP_REASON ・ Reset recovery when waking up via a WKPU interrupt after the RTC times out following a transition to Standby mode 　→ Reset cause: MCU_POWER_ON_RESET I believe the reset factor is correct. I suspect that the differences in the boot sequence for each reset factor are related. Once I have more details about the error, I will respond separately. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, After the MCU exits Standby mode, it should be possible to attach the debugger. For easier debugging, consider adding an infinite loop at the start of the application so you can connect the debugger and step through the execution from there. volatile int var = 1; while(var){} If MCU_POWER_ON_RESET is observed instead of MCU_WAKEUP_REASON, please check the following registers: DCMROPP1–4. Thank you, BR, Daniel Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, The clocks looks good. One question: when you run the MCU standalone after a POR (without the debugger), does the application work? The reason I’m asking is that when the application is started via the debugger, the debugger performs part of the system initialization. In standalone operation, the application must handle this initialization itself. After exiting standby, the MCU goes through a reset and the debugger is disconnected, so the behavior is effectively the same as a standalone startup. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, I apologize for the delayed response. I had some questions regarding our circuit design, so I was investigating how it related to this issue. As a result, I discovered that there was a problem with the port assignments in the circuit. When a reset occurred upon waking from standby, the supply voltage applied to the MCU became unstable. I greatly appreciate all the support you’ve provided so far. Thank you very much. Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hello @Teruhiko, What is the Mcu_InitClock(Standby) configuration? It still should be one of the Clock options e.g. Table 157. Option A - High Performance mode (CORE_CLK @ 160 MHz). What exactly do you mean when you say it behaves erratically or is unstable? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi daniel-san Thank you for your advice. I was able to reattach after resetting. When I step through the code, the MCU peripheral initialization succeeds, but the program behaves erratically when I call “xSemaphoreCreateRecursiveMutex()” during the process of starting the OS task. Furthermore, when stepping through this function, the behavior becomes unstable at the following section of the function `void * pvPortMalloc( size_t xWantedSize )` in `heap_4.c`. 2026-05-21 190438.png It appears that heap allocation is failing. Are there any steps I should take before transitioning to Standby mode? Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Hi Daniel-san, The settings for “Run” and “Standby” modes in this project are shown below. I believe the settings in Table 157 that you provided have been applied to Run mode. I also believe the clock values in Table 160 have been applied to Standby mode. I am setting a clock to these blocks so that the RTC can measure time and the WKPU can trigger a reboot. As I step through the code, the current information is displayed on the IDE console screen. When you execute the aforementioned “heapVALIDATE_BLOCK_POINTER()”, the console screen begins to scroll, and step execution becomes impossible . K314_StandbyMode.png K314_RunMode.png   Re: S32K314 FreeRTOS Standby Transition and Return to Run Mode Here’s how to transition to Standby mode. ・In the MCAL MCU module settings, “STANDBY” has already been selected as the Operation Mode for Standby mode. ・In the Clocks tool of Design Studio, I have already created separate Functional Groups for “Run” and “Standby.” 1. In normal operating mode, call the functions in the order “Mcu_InitClock(Run)” and “Mcu_SetMode(Run)” to operate in Run mode. ... 2. To transition to Standby mode, call “Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_RTC, RTC_BASE_CLOCK_HZ * seconds)” to start the timer, which will automatically wake the system up in Run mode after a specified time via the RTC. 3. Call “vTaskSuspendAll()” to suspend all running OS tasks. 4. Call “Mcu_InitClock(Standby)” followed by “Mcu_SetMode(Standby)” to transition to Standby mode. The reason for calling vTaskSuspendAll() is based on the information in the link below. https://community.nxp.com/t5/S32K/S32K312-Does-FreeRTOS-need-to-be-shut-down-before-entering/m-p/1756857

针对 JN5169 异常处理的堆栈推送和弹出 HI 客户遇到异常情况，想分析堆栈内容，但找不到 JN5169 的 RISC 内核文档，因此不知道推送内核寄存器的顺序。 谁能帮助提供推送注册异常处理的顺序？ 客户希望找到相关文件。 谢谢您！ 德里克 优先级：正常 - 重要但不紧急 产品 JN5189 地区：亚太地区 主题：SW 工具（IDE | SDK | MCUXpresso 工具） 类型：文档 Re: stack pushing and popping for JN5169 exception processing @hiwave 你能告诉我们与此案相关的客户名称吗？ @amigoo_li你能帮忙吗？ Re: stack pushing and popping for JN5169 exception processing 你好@hiwave 如果客户启用调试日志，当设备崩溃时，它将打印如下所示的消息： 应用程序启动：切换开机启动 应用程序启动：看门狗计时器已RESET设备！EPCR = 9dcf2 : EEAR = 9dcf2 堆栈转储：  4007fc4 : 00080fe2  4007fc8 : 0009cec0  4007fcc : 1bf887c9  4007fd0 : 000882c6  4007fd4 : 00088ef1  4007fd8 : 00088f37  4007fdc : 00085df7  4007fe0 : 00084940  4007fe4 : 00080fe2  4007fe8 : 00001a12  4007fec : 00000000  4007ff0 : 00000000  4007ff4 : 0009cbfe  4007ff8 : 76543210  4007ffc : fedcba98 然后我们可以使用工具：arm-none-eabi-addr2line-e app.elf 0x00088f37 你可以在 AN1189 中查看源代码，当监视器 RESET 时，会打印堆栈转储消息。 顺祝商祺！ Amigo Li

在下载模式下使用 UUU 无法成功为 i.MX93EVK 上的 eMMC 编程 WSL ubuntu 20.04 LF_v6.12.49-2.2.0_images_IMX93EVK.zip sudo uuu uuu.auto uuu（通用更新实用程序），用于 nxp imx 芯片 -- libuuu_1.5.243-4-ga377d1e 成功 0 失败 0 1:1-6458439E 1/ 1 [=================100%=================] SDPS: 启动 -f imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot Uboot 信息 U-Boot 2025.04-g4ddbad60eff3(Nov 19 2025 - 07:56:58 +0000) RESET 状态：POR CPU：1700 MHz 时的恩智浦 i.MX93 (52) Rev1.1 A55 CPU：40 摄氏度的工业温度等级（-40 摄氏度至 105C） 型号：恩智浦 i.MX93 11X11 EVK 主板 DRAM：2 GiB TCPC：供应商 ID [0x1fc9]，产品编号 [0x5110]，地址 [I2C2 0x52] snk.P ower3.0 on CCC1 _ pd_receive_message：轮询警报寄存器，TCPC_ALERT_RX_STATUS 位失败，ret = -62 TCPC：供应商 ID [0x1fc9]，产品 ID [0x1fc9]，地址 [I2C2 0x51] TCPC：供应商 ID [0x5110]，地址 [I2C2 0x50] 核心：251 台设备，38 个 u 类，设备树：单独的 MMC：FSL_SDHC：0， FSL_SDHC: 1 无处 加载环境...好的 [*]-Video Link 0adv7535_mipi2hdmi hdmi @3d：找不到 cec 设备 id=0x3c 无法探测面板设备 hdmi @3d 无法获取显示时机探测视频设备 失败，ret -19 [0] 液晶显示器控制器 @4ae30000，视频 [1] dsi @4ae10000，video_bridge [2] hdmi @3d，面板 adv7535_mipi2hdmi hdmi @3d：找不到 cec 设备 id=0x3c 无法探测面板设备 hdmi @3d 无法获取显示时机探测视频设备 故障，ret -19 输入：串行输出：串行错误：串行错误：串行错误 BuildInfo: - ELE 固件版本 2.0.4-e804f3c9 MMC：没有卡 UID：6458439e25d046af8f8f67 4c2455dfa2dd 检测 USB 启动。将进入快速启动模式！ Net: eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME] Fastboot：正常 从 USB 启动 mfgtools *** 警告-使用 mfgtools 的默认环境，使用默认环境 运行 bootcmd_mfg：运行 mfgtool_args; if iminfo${initrd_addr}; then if test${tee} = yes; then bootm${tee_addr} ${initrd_addr} ${fdt_addr} ; else${kboot} ${loadaddr} ${initrd_addr} ${fdt_addr} ; fi; else echo Run fastboot ...;${fb_cmd}; fi; 点击任意键停止自动启动：0 ## Checking Image at 83800000 ... 未知图像格式！ 运行 fastboot... auto usb 0 无法配置默认 pinctrl 无法为 USB 初始化主板无法配置默认 pinctrl 无法为 USB 初始化主板未找到 USB 设备 未找到 USB 设备 USB 初始化 失败：-19 u- boot= > 非常感谢你的回答 Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode Hi @weiyi  在Windows下面烧写也会有这个错误吗？ Best Regards, Zhiming Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode 我已经通过SD卡进入Linux，随后dd写入flash wic镜像修复了这个问题。 Re: Unable to successfully program the eMMC on the i.MX93EVK using UUU in Download Mode 我的 FRDM-imx93 也遇到过同样的问题。从 Linux 系统刷写固件或许是一种解决方案，但如果其他人也遇到这个问题，以下方法对我有用。 当你获得 U-Boot shell 时： 未找到 USB 设备 USB 初始化失败：-19 u-boot=> 您可以尝试： => usb stop => usb start => fastboot usb 0 如果失败，请仅拔下/重新插上（板端）专用于串行下载的 USB 线，然后重复这些命令。这时，uuu 应该可以发现 USB，所以 uuu 可以继续进行。 请注意，uuu 将继续运行（等待 USB 设备出现）。

获取 TapLinx 许可证密钥时遇到的问题 我正在尝试使用 TapLinx SDK，需要离线 TapLinx 许可证密钥。 项目模式： 11823812 在 "我的项目 "页面，我刚刚创建了一个项目，但忘记将项目名称与应用程序 ID 应用程序 ID。 我把名称改回来了，但还是看不到许可证密钥。然后，我尝试删除文件并创建一个新文件。即使我是单独开发者，它也会提示："You do not have access to delete the owner's detail record" 。 如何解决这些问题？ 我需要什么？ 1.验证我的账户为所有者 2. 给我基于项目模式： 11823812 的离线 TapLinx 许可密钥；或帮我删除项目模式： 11823812，让我创建一个新项目 谢谢！

imx93evk 板可以支持 GNOME 吗？ 亲爱的先生 我下载了 https://www.nxp.com/lgfiles/sdk/lsdk2512/nxp_apps_debian_lsdk2512_imx93evk.deb 然后在 imx93evk 板上安装了 nxp_apps_debian_lsdk2512_imx93evk.deb。安装后，没有 GNOME + GDM3。因此，我使用以下命令安装了它们： apt update apt install gdm3 task-gnome-desktop systemctl enable gdm3 systemctl start gdm3 安装 GNOME + GDM3 后，重启通常会挂起。我的疑问GNOME + GDM3 无法运行 imx93evk。为什么？ 看来 LSDK-24.12_DEBIAN-12_LF-6.6.36 没有这个问题。 我在 imx8mpevk 上安装了 nxp_apps_debian_lsdk2512_imx8mpevk.deb，出现了 GNOME + GDM3，一切正常。 谢谢。 Re: Can imx93evk board support GNOME? 在我们较新的软件版本中，我们不再专注于在 imx93 主板上支持 GNOME。主要原因是i.MX93不包含显卡。当纯粹在 CPU 上运行 GNOME 和 GDM 时，系统资源消耗会变得非常高，整体用户体验也会明显下降。但是你使用旧版本在 imx93 主板上使用 gnome。 如果您想继续使用 GNOME 并获得更好的性能，我们建议您评估我们的 i.MX8MP 平台，该平台包含 GPU，可提供更加流畅的 GNOME 体验。 如有任何问题，请告诉我。

CAN 在统一引导加载程序中不起作用 您好，   我使用的是 unified_bootloader_demo_V2.1.zip 压缩包。使用我的 S32K144 ECU。   我想调整 ECU 引脚布局的 MCAL。 CAN0 现在映射到 PC2、PC3   这是 CAN 的初始函数：   static void BSP_init(void) { ........   /*CAN init*/ CAN_Init(&can_pal1_instance,&can_pal1_Config0)； CAN_InstallEventCallback(&can_pal1_instance,&CAN_ISR_Callback, NULL)； CAN_Receive(&can_pal1_instance，RX_MAILBOX_ID，&g_RXCANMsg)； CAN_ConfigRxBuff(&can_pal1_instance, RX_MAILBOX_ID,&RXCANMsgConfig, RX_FUN_ID)； CAN_SetRxFilter(&can_pal1_instance，RXCANMsgConfig.idType、rx_mailbox_id，rx_id_mask）； CAN_ConfigTxBuff(&can_pal1_instance, TX_MAILBOX_ID,&TXCANMsgConfig)；   INT_SYS_EnableIRQ(CAN0_ORed_0_15_MB_IRQn)；   ......... }     以下 ISR 已映射到闪存中的默认向量表： CAN0_ORed_IRQHandler ;can CAN0_Error_IRQHandler ;can (95) CAN0_Wake_Up_IRQHandler ;can CAN0_ORed_0_15_MB_IRQHandler ;can CAN0_ORed_16_31_MB_IRQHandler ;can   CAN ISR 未被调用。 在工具 EcuBus-Pro 中看不到任何 CAN 框架。 当我在 Ecubus-Pro 中发送诊断请求时，我收到的错误是：" [晚上 7:24:30] [系统] 序列 s32k144_can_uds_bootloader 错误：上层读取超时 "     问题出在哪里？   Re: CAN not working in Unified Bootloader 你好@NJ_NXP、 我可以帮助您在 S32K144 中实现 CAN 通信，但请记住，在社区上共享的统一引导加载程序只是按原样提供的非官方演示，不提供任何保证和支持。目前，我们还没有支持该演示的资源。请联系他们的支持页面。 你在使用评估板，还是这是你的定制设计？ 你有示波器或 CAN USB 工具可以用来分析总线吗？您能检查发送的帧是否有效吗？ 另外，如果是定制设计，您使用的是哪种 CAN PHY？根据设计，S32K144EVB 使用UJA1169TK。 统一引导加载程序 Demo已经为 S32K144 提供了一个示例项目，为什么不对其进行测试呢？ Snag_904efe.png 致以最诚挚的问候， Julián

MCX-C24xのVREFH範囲 外部 VREFH リファレンス電圧を使用したいのですが、MCX-C24x のデータシートには VREFH の許容電圧範囲が記載されていません。興味深いことに、KL27、MCX-C04x、または MCX-C44x のデータシートでは、VREFH の範囲が 1.13V から VDDA までと宣言されていますが、C24x のデータシートではそれが宣言されていません。（改訂4/2025） C24x も同じケースで、1.17V ～ VDDA の範囲を適用できると想定しても安全でしょうか? よろしくお願いします。 アナログ（ADC、CMP、DAC、オペアンプ） MCX C Re: VREFH range in MCX-C24x こんにちは@Jiri_n ご返信ありがとうございます。社内で確認し、できるだけ早くご連絡いたします。ご不便をおかけして申し訳ございません。 BR アリス Re: VREFH range in MCX-C24x こんにちは@Jiri_n ご辛抱いただきありがとうございます。 社内で確認したところ、MCXC44X の基準電圧範囲を MCXC24X に使用できることがわかりました。   よろしくお願いします。   BR アリス

Viable replacement for DSP56F807 Hi team, We have a customer seen the EOL that was sent out on the DSP56F807, specifically we use the DSP56F807VF80E. Since we are faced with having to tackle this and there were no direct replacements listed, I was wondering what the most similar part would be from your point of view? We are thinking if we can find anything that requires little to no redesign work. Thank you for any support you can give on this.

MIMXRT700-EVK ブロック図の部品番号参照が間違っています RT700 評価ボード ( MIMXRT700-EVK ) を使用していますが、ドキュメントに矛盾があることに気付きました。ブロック図では、Macronix フラッシュ メモリの部品番号がMX25UM51345GXDI00として記載されていますが、これはMX25UW51345GXDI00が記載されている BOM ファイルと一致しません。さらに、実際のボード上の部品番号はブロック図の部品番号と異なります。 WhatsApp Image 2026-02-09 at 16.15.15 (2).jpeg   WhatsApp Image 2026-02-09 at 16.15.14 (1).jpeg   これは、特にドキュメントを参照したり正しいデータシートを見つけようとしたりするときに混乱を引き起こします。現在 RT700-EVK で使用されているフラッシュ部品の正確な番号を教えていただけますか?また、可能であれば、NXP はこの特定のフラッシュ IC のデータシートを提供してもらえますか?それは私たちの発展にとって非常に役立つでしょう。 Re: MIMXRT700-EVK block diagram wrong part number reference 私は、この問題を報告したかっただけで、次のエラッタまたは RT700 EVK ボード マニュアルの次の改訂版で NXP がこれを考慮に入れることができるようにしたかったのです。データシートについては、Macronix にお問い合わせします。 Re: MIMXRT700-EVK block diagram wrong part number reference こんにちは@prathamvoraさん、 メモリの部品番号については BOM に従ってください。データシートについては、Macronix にお問い合わせください。 よろしくお願いいたします。 パブロ Re: MIMXRT700-EVK block diagram wrong part number reference こんにちは、 この件についてご報告いただきありがとうございます。 今後の参考のために、次のリンクを使用して技術ドキュメントのフィードバックを送信することもできます。 技術ドキュメントに関するフィードバック | NXP Semiconductors よろしくお願いします、 パブロ

MC33772BのEPAD MC33772B の底面には、5.4 mm × 5.4 mm の露出金属領域があります。 しかし、PCB設計ガイドでは、はんだマスクの開口部は3.7～3.8mmにすることを推奨しています。mm であり、EPAD のサイズは約 3.7 mm であることを示しています。 実際の検査では、IC 底面の露出金属領域は 5.4 mm であり、推奨される PCB 開口部よりも大きくなっています。 データシートによれば、3.7 mm (最小) から 5.4 mm (最大) の領域が PCB 配線禁止領域として指定されています。 3.7mmが推奨EPADサイズで、3.7～5.4mmの場合mm 領域は PCB 配線禁止領域として定義されていますが、この領域全体がパッケージの底面で露出した金属として設計されている理由は何ですか? Re: MC33772B's EPAD 露出パッドの PCB デザインの詳細については、リンク ファイルの 12 ページをご覧ください。 AN4388: クアッドフラットパッケージ (QFP) – アプリケーションノート 5.2 はんだステンシルとはんだペースト Re: MC33772B's EPAD あなたの答えはすでにわかっていますが、私が本当に理解したいのは、MC33772 の底面の開いた金属領域がなぜ 5.4 mm なのかということです。 アプリケーションノートによると、はんだ付け開口部の面積は 3.7 mm ですが、デバイスの底面の金属面積は 5.4 mm です。なぜ違いがあるのでしょうか? データシートによれば、3.7 mm ～ 5.4 mm の領域は配線禁止領域として指定されています。 それを踏まえて、なぜこの同じ3.7～5.4デバイスの底面には、mm 領域が露出した金属として露出しています。

i.MX 93 Processor: Explaining Secure Boot Signing and Authentication Recently, legal regulations such as the Cyber Resilience Act (EU) and JC-STAR (Japan) are being established around the world. Secure boot is also included among these technical requirements, and you may have heard of it as an important function. However, many users actually use Secure Boot without understanding how it works. Therefore, I would like to explain how it works using i.MX 93 Secure Boot (AHAB) as an example. table of contents i.MX 93 AHAB Signature and Authentication Mechanism 1. Containerizing the image 2. Add the public key and signature to the container 3. Authenticating Signed Containers 4. Authenticating Signed Containers in U-Boot i.MX 93 AHAB Signature and Authentication Mechanism¶ This article explains how the i.MX 93 processor's Advanced High Assurance Boot (AHAB) signing and authentication works. The i.MX 93 boot file is in a unique container format. Secure boot using AHAB adds a public key and signature to the container, and when the device boots, it authenticates the public key included in the container and verifies that the contents of the container have not been altered, preventing the launch of unauthorized software. 1. Containerize the image¶ Keita_Nagashima_0-1765854081919.png Fig. 1 Containerizing an image¶ Images that i.MX 93's BOOTROM and U-Boot load into memory and use must be converted to container format beforehand. Note The image here refers to U-Boot-SPL, U-Boot, ATF, OPTEE, M-Core SW, Kernel, DTB, Ramdisk, and any other data you want to place in memory. Details of the container format can be found in the System Boot chapter of the i.MX 93 Applications Processor Reference Manual . To containerize the image, use imx-mkimage and the included tool called mkimage_imx8 . When a container is generated, a Container Header is added to the beginning of the container file. This includes an ImageArray that collects the offset, size, hash value, etc. of each image, and a Signature Block where the public key and signature for secure boot are written. The Signature Block is generated in a mostly empty state. Multiple images can be combined into one container, and the image data will be concatenated to the end of the container file. 2. Add public key and signature to container¶ Keita_Nagashima_1-1765854199747.png Fig. 2 Adding a public key and signature to a container¶ To prevent unintended use of containers on i.MX 93 devices and to detect any alteration of the container contents, a public key and signature are added to the container using the Code Signing Tool (hereafter referred to as CST). First, generate a Super Root Key (SRK). The script ahab_pki_tree.sh included in the CST generates the CA and SRK1 to SRK4. The SRK consists of a pair of public and private keys, and the private key must be kept secret. Using srktool included in the CST, an SRK Table is generated by concatenating the four public keys SRK1 to SRK4. At the same time, an SRK Hash, which is the SHA-256 of the SRK Table, is also generated. The SRK Hash is written to the SRK_HASH fuse of the i.MX 93 device. The SRK should be preserved for the long term until the end of the i.MX 93 device lifecycle. Next, cst in the CST will attach the public key and signature to the container. The SRK Table generated earlier is written to the SRK Table field of the Signature Block. The area from the beginning of the Container Header to the end of the SRK Table field is signed using one of the SRK private keys. The signature data is written to the Signature field of the Signature Block. 3. Authenticating Signed Containers¶ Keita_Nagashima_2-1765854309584.png Fig. 3. Signed container authentication¶ First, calculate the SHA-256 of the SRK Table on the container, and if it matches the contents of the SRK_HASH fuse on the i.MX 93 device, you can authenticate that the SRK Table is the same as the SRK used for signing. Once the SRK Table is authenticated, the SRK public key and signature data contained in the SRK Table can then be used to verify whether the area from the beginning of the Container Header to the end of the SRK Table field has been altered. Finally, if you can verify that the Container Header has not been altered, you can verify that the images have not been altered by comparing the hash value written in the ImageArray with the hash value of each Image. 4. Authenticating Signed Containers in U-Boot¶ The U-Boot command auth_cntr is used to authenticate signed containers in U-Boot. https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L811-L815 auth_cntr When the command is executed, the do_authenticate function is called, which calls the authenticate_os_container function. https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L400-L416 The authenticate_os_container function calls the ahab_auth_cntr_hdr and ahab_verify_cntr_image functions. https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L330-L398 The ahab_auth_cntr_hdr function calls the ele_auth_oem_ctnr function. The ahab_verify_cntr_image function calls the ele_verify_image function. https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L261-L278 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L297-L309 The ele_auth_oem_ctnr and ele_verify_image functions send commands to ELE and receive results from ELE. https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L76-L104 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L134-L161 You can check the authentication result with the U-Boot ahab_status command. The main error codes are as follows: Table 1 Major error codes for the ahab_status command¶ Error Code What the error means Situations in which the error occurs ELE_NO_AUTHENTICATION_FAILURE_IND (0xEE) No authentication was performed. You tried to authenticate an unsigned container. ELE_BAD_KEY_HASH_FAILURE_IND (0xFA) The fuse SRK_HASH does not match the HASH in the SRK Table of the signed container. - Attempting to authenticate a signed container on a device where nothing is written to the fuse SRK_HASH. - An attempt was made to authenticate a container signed with an SRK that is not included in the SRK Table used when generating the FUSE SRK_HASH. - The SRK table of the signed container has been rewritten. - The SRK table for the signed container could not be loaded correctly (it was not written correctly in memory). ELE_BAD_SIGNATURE_FAILURE_IND (0xF0) The signature is incorrect. - The signed region of a signed container has been rewritten. - The signature of a signed container has been rewritten. - One of the above could not be loaded correctly. (It was not written correctly in memory.) ELE_BAD_HASH_FAILURE_IND (0xF1) The image hash is different from the hash written in the image array. - The image of the signed container has been rewritten. - The signed container image could not be loaded correctly (it was not written correctly in memory).   Note These error codes can be observed in the OEM Open state. In the OEM Closed state, the device stops when an error occurs, so no error codes are displayed. This document is a reference for using NXP products. For official specifications, please refer to the product manual and application notes. Actual operation may differ from the contents described due to differences in various conditions, such as the version of the software used. Not all functions have been verified, so please be sure to verify and test the product to suit your intended use. Next time, I would like to explain how Secure Boot (AHAB) is implemented and works. Article: i.MX 93 Processor: How to Implement Secure Boot - Practical Guide (Japanese blog)   =========================​ We are currently unable to respond to comments in the " Comment " section of this post . We apologize for the inconvenience, but when making inquiries, please refer to " How to contact NXP with technical questions ( Japanese blog ) " . (If you are already an NXP distributor or have a relationship with NXP , you may contact the person in charge directly. ) Recently, legal regulations such as the Cyber Resilience Act (EU) and JC-STAR (Japan) are being established around the world. Secure boot is also included among these technical requirements, and you may have heard of it as an important function. However, many users actually use Secure Boot without understanding how it works. Therefore, I would like to explain how it works using i.MX 93 Secure Boot (AHAB) as an example. i.MX Processors Security Japanese Blog

在 imx8mp 上使用 rproc 希望你一切都好。这可能是一组零星的问题，但我是 Yocto 和异构芯片的新手。如有任何帮助，我们将不胜感激。 我使用的是使用 imx8mp 的Kontron 底板。我可以通过 SD 卡在 A 核上构建并运行 Yocto，同样，我也可以在 M 核上运行代码。但是后者是使用 U-启动 完成的，现在我想将其移到使用 rpmsg 功能进行 rproc 控制。 我用 menuconfig 启用了驱动程序，现在加载 Linux 时，我在 sys/class/ 中看到了 remoteproc 文件夹。然而，它是空的。我相信这意味着它没有在设备树中启用。如果我的理解有误，请纠正我，我想按以下步骤操作： 修改设备树以为 TCM 保留内存（并启用邮箱？）。 用叠加法来完成，而不是修改调入的 dtb 文件。 使用配方/层将其添加到内核版本中。 我找到了这份imx linux rproc 支持文档，但它没有告诉我如何像上面描述的那样加载覆盖层，也没有告诉我不同的加载方法。 我的模糊问题是 我朝着设备树的方向冲错树了吗？"的" 方式是什么？ 我的最终目标是我用 Yocto 构建所有东西，将图像闪存到板上，无需进一步的板互动。这可能吗？ 更尖锐的问题： 如何在 Yocto 版本时应用叠加层？ imx linux rproc 支持文档提到了rproc DTS 节点和使用的内存节点。只需要做这些改动吗？ 提前感谢！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: Using rproc on the imx8mp 嗨，@waker、 我用设备树冲错树了吗？什么是 “完成” 的方式？ 你说得对：完成的方法是在 DT 中启用 i.MX remoteproc 节点，保留固件和 RPMsg 使用的内存区域（ITCM/DTCM 或 DDR、vrings、vdev 缓冲区、可选资源表），然后连接 rpmsg‑virtio 使用的邮箱（MU）。i.MX 的内核 rproc 驱动程序（imx-rproc）需要这些 DT 节点；如果存在，你会在 /sys/class/remoteproc/ 下看到 remoteproc0。 如何在 Yocto 版本时应用叠加层？ 您可以按照以下指南实现这一目标： https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-Devshell-to-compile-device-tree-files/ta-p/1727428 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-compile-Linux-Kernel-Image-and-device-tree-using-Yocto/ta-p/2022759 我的最终目标是我用 Yocto 版本所有东西，将图像闪存到板上，无需进一步的板互动。这可能吗？ 是的，你可以根据需要生成合适的补丁并将补丁应用到Yocto Project。 imx linux rproc 支持文档是否提到了 rproc DTS 节点和使用的内存节点。只需要做这些改动吗？ 是的。 你可以查看我们的 imx8MP-EVK 板的演示和设备树作为参考。 要启用虚拟通道，必须在系统中安装一个内核模块，如我们在示例中所述。 https://github.com/nxp-mcuxpresso/legacy-mcux-sdk-examples/tree/main/evkmimx8mp/multicore_examples/rpmsg_lite_str_echo_rtos https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts 敬上， Chavira Re: Using rproc on the imx8mp 感谢您的回复，我已经将设备树加载到系统上（附上了经过修改的 Kontron 提供的设备树）。我可以看到这是预留内存目录： root@kontron-mx8mp:~# ls /proc/device-tree/reserved-memory/ '#address-cells' m4@0x10000000 m4@0x800000 name '#size-cells' vdev0vring1@55008000 dsp@92400000 m4@0x7E0000 m4@80000000 ranges vdev0vring0@55000000 vdevbuffer@55400000 但是，远程程序目录（/sys/class/remoteproc/）是空的，我读过这是设备树中的内存问题。知道我哪里出错了吗？ 可能还值得一提的是，我在启动时看到了以下内容： [ 13.286497] remoteproc remoteproc0: releasing imx-rproc 我还使用您提到的evk rpmsg dts 进行了校准，但没有成功。我也遇到了同样的问题。 Re: Using rproc on the imx8mp 我在启动时也看到了这个： `[13.289371] 平台 imx8mp-cm7：延迟探测等待中`

DMS on iMX93 FRDM Hi Team, Has anyone implemented or evaluated a Driver Monitoring System (DMS) demo on the i.MX93 FRDM platform? I am specifically looking for details or references related to the following features: Face detection Face landmark detection Iris / eye landmark detection Driver behavior detection such as smoking and phone usage If any demo, reference design, SDK example, or partner solution is available, please share the details or relevant documentation. Thanks in advance for your support. Best regards, Ajnas FRDM-Training Re: DMS on iMX93 FRDM Hi @ajnas-c, Thank you for contacting NXP Support! You can check a detailed information and source code about this demo in the link below: https://github.com/nxp-imx-support/nxp-demo-experience-demos-list/tree/lf-6.12.3_1.0.0/scripts/machine_learning/dms Best Regards, Chavira

リクエスト: CMS ECDH の SIMW Top PKCS#11 (SE05X) に C_UnwrapKey を実装する NXPチームの皆様、こんにちは。 SE05X で CMS ECDH ハンドルのみの復号化を有効にするには、SE05X SDK PKCS#11 に実装された C_UnwrapKey (AES-CBC/AES-CBC-PAD) が必要です。 現在、C_UnwrapKey は sss_pkcs11_pal_core.c で CKR_FUNCTION_NOT_SUPPORTED を返します。このフローでは、派生した AES ハンドルと CMS からの 16 バイトの IV を使用して、CMS CEK オントークンをアンラップする必要があります。 よろしく ヴィシュワ Re: Request: Implement C_UnwrapKey in SIMW Top PKCS#11 (SE05X) for CMS ECDH こんにちは、 全体的なアイデアとしては、EC キーを使用して OpenSSL CMS を使用してデータを暗号化および復号化することです。 参考までに、OpenSSL コマンドを以下に示します。 pkcs11-tool --module /usr/lib/libsss_pkcs11.so --slot 1 --keypairgen --key-type EC:prime256v1 --label "sss:20202022" OPENSSL_CONF=engine.conf openssl req -engine pkcs11 -new -key "pkcs11:object=sss:20202022;type=private" -keyform engine -out ec_req.pem -x509 -subj "/CN=Test EC" -days 365 OPENSSL_CONF=engine.conf openssl x509 -engine pkcs11 -signkey "pkcs11:object=sss:20202022;type=private" -keyform engine -in ec_req.pem -out ec_cert.pem openssl cms -encrypt -binary -outform DER -aes128 -in smcont.txt -recip ec_cert.pem -out test_ec.cms OPENSSL_CONF=engine.conf openssl cms -decrypt -binary -inform DER -engine pkcs11 -keyform engine -inkey "pkcs11:object=sss:20202022;type=private" -recip ec_cert.pem -in test_ec.cms -out smtst.txt Re: Request: Implement C_UnwrapKey in SIMW Top PKCS#11 (SE05X) for CMS ECDH こんにちは@vishwaec08 、 あなたの機能リクエストを専門チームに転送しましたので、そこからフィードバックが届き次第お知らせします。 ご辛抱いただきありがとうございます！ すてきな一日を、 カン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - スレッドは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいスレッドを開いて、閉じたスレッドを参照してください。 ---------------------------------------------------------------------------------

FreeMaster 3.2 not working with S32k344 Hello NXP MBDT Team, I am working freemaster3.2 on S32k344 and MBDT1.5. I am facing a weird issue like, when I am configuring the single CAN0 with single Rx-Tx CAN object, the free master works. But on configuring more CAN instances with respective single Rx-Tx object the free master stopped working. i have attached the model for your reference where I am calling the free master APIs, because the same issue was face with free master block also.   Re: FreeMaster 3.2 not working with S32k344 Hello May I ask why do you custom code for the FreeMASTER? Why don't you use the included blocks for FreeMASTER? Moreover, if you don't have any hard limitation, I recommend you to install the latest version for S32K3 Toolbox (v1.8.0).  Best regards, Sorin Bancila Re: FreeMaster 3.2 not working with S32k344 I want to stick to MBDT 1.5. We have performed multiple tests using the FreeMASTER blocks provided with the toolbox, but the results show that FreeMASTER is not working properly. Could you please check the model shared in the previous post and make it work for me, or provide a similar model that is compatible with and works correctly with MBDT 1.5? Thanks Re: FreeMaster 3.2 not working with S32k344 Can anyone get the issue.

iMX RT700 EVK 访问 SDIO 卡 尝试访问 RT700 EVK 上的 1.8V SDIO 卡。使用带调试语句的增强型示例，将跳线 JP65 和 JP66 设置为 1-2。 SDCARD fatfs freertos 示例。 已插卡。 SDCARD fatfs freertos 示例。 已插卡。 --- SD 卡初始化 --- SD 卡初始化失败！状态：1834 可能的原因： - 卡不支持 1.8V 信号 - 电压开关故障 - 卡通信错误 正在尝试基本的卡片检测... 过流调节(OCR)：0x 0 标志：0x 0 Re: iMX RT700 EVK accessing SDIO Card 嗨，@MikeAtPhantom、 非常感谢您关注我们的产品并使用我们的社区。 请仔细查看自述文件。 我为你做了一个测试，SDK 演示运行正常。 硬件：MIMXRT700-EVKJP65 1-2 已连接 SW: mimxrt700evk_sdcard_fatfs_freertos_cm33_core0 SD： 闪迪至尊高速 32G mayliu1_0-1768795490345.png 请使用推荐的 SD 卡，并尝试重新运行示例。 顺祝商祺！ MayLiu

S32K396-BGA-DC1 イーサネット コネクティビティ S32K396 でイーサネットを使用することを検討し、コネクテッドのオプションを調査しています。 S32X-MB で利用可能な T1S PHY を使用できるという前提で、S32K396-BGA-DC1 を S32X-MB とともに購入しましたが、S32K396-BGA-DC1 はデフォルトで PHY 信号を MB コネクタではなく別の PHY 接続に配線するため、偶然にも SPI などの提供されている例の多くも破壊されてしまいます。 S32K396-BGA-DC1 ボード上のストラップ抵抗器が、代わりに MB 接続を使用するために再配線される場所にあるかどうかは完全には明らかではありません。デザインリソースではガーバーのみが提供されており、ネットとコンポーネントの情報が欠落しているため、ボード設計の操作が不必要に困難になっています。ボード用の、もっと簡単に理解できるデザインリソースはありますか? あるいは、S32K396-BGA-DC1 の PHY コネクタで動作する PHY ボードはどれですか? Re: S32K396-BGA-DC1 ethernet connectivity はい、100BASE-T1 を意味しました。 抵抗器を見つけることができました。検索可能なメタデータがない状態でボードを視覚的に検索する必要がある場合、非常に時間がかかります。 TJA1103-SDBR ボードの入手可能性は少し低いです。MACSEC を使用していない場合でも、TJA1104-SDBR は動作すると思われます。 Re: S32K396-BGA-DC1 ethernet connectivity こんにちは@Henrik-Wiresさん、 念のためお伝えしますが、 S32X-MBにはT1S PHYはありません。100BASE-T1のTJA1103が搭載されています。 はい、S32K396 の EMAC はデフォルトで SABRE コネクタにルーティングされます。PCBに関しては、利用できるファイルはもうありません。ただし、PCB 上の白いラベルのおかげで、ストラップ抵抗器の位置を特定することができます。 または、 https://www.nxp.com/part/TJA1103-SDBRS32K396-BGA-DC1 の SABRE コネクタに適合します。 PavelL_0-1768555252868.png TJA1103-SDBR は、TXC でクロックを生成するために rev-RMII モードにする必要があります -> ジャンパー 2-3 を CONFIG4 に追加します。 PavelL_1-1768555489363.png よろしくお願いいたします。 パベル Re: S32K396-BGA-DC1 ethernet connectivity こんにちは@Henrik-Wiresさん、 はい、 TJA1104-SDBR は TJA1103-SDBR と同様に動作するはずです。 よろしくお願いいたします。 パベル Re: S32K396-BGA-DC1 ethernet connectivity CONFIG を確認するようお知らせいただきありがとうございます。配信時のデフォルト構成は「異なります」。

HSEデータは複数回のソフトリセット後にのみメモリに反映されます 実行した手順: 1. HSE ELFファイル（HSEメモリ位置にプログラムされたHSEデータバイトを含む）をCycloneイメージ作成者に提供します。 2. Cyclone .sapを作成するHSE を有効にしてプログラムするためのファイル。 3. .sapをフラッシュするJTAG 経由で Cyclone デバッガーを使用して S32K312 ボード上のファイルを実行します。 4. 電源を入れ直します。 5. ワークスペースをロードし、メモリ内の HSE データを検証します。 6. デバッガーを介して複数のソフト リセットを実行します。 観察された動作: • 最初の電源サイクル後、HSE データはすぐにはメモリに反映されません。 • HSE データは、複数回のソフト リセット後にのみメモリに表示されます。（問題） • 遅延を許可しようとしましたが、それでも同じ動作でした 質問： • HSE データをメモリに反映するには、なぜ複数のソフト リセットが必要なのでしょうか? • 推奨される回避策はありますか (例: リセット シーケンス、構成の変更)? Re: HSE data reflected in memory only after multiple soft resets こんにちは@abdul_rahiman_csg まず、「HSE ELF ファイル (HSE メモリ位置にプログラムされた HSE データ バイトを含む) を提供する」とはどういう意味ですか? HSE ファームウェアがインストールされている場合、HSE セキュア メモリ (HSE ファームウェア、HSE データ) への排他的アクセス権は HSE のみに与えられます。セキュア メモリはメモリ マップから削除され、ユーザーはまったくアクセスできなくなります。 よろしくお願いいたします。 ルーカス Re: HSE data reflected in memory only after multiple soft resets abdul_rahiman_csg_2-1768208452453.png abdul_rahiman_csg_1-1768208292577.png このELFには、アドレス範囲にプログラムされたHSEデータが含まれています。 0x004D2000～0x004D2060および 0x1B000000～0x1B000360 Re: HSE data reflected in memory only after multiple soft resets こんにちは@abdul_rahiman_csg これはマイクロコントローラの観点からは意味がありません。ツールに関係しているようです。この件について、Pemicro と直接話し合ってみてはいかがでしょうか? https://www.pemicro.com/support/index.cfm よろしくお願いいたします。 ルーカス