Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
关于 RW612 OTBR 线程认证架构的问题 您好,NXP团队,   我注意到了线程组认证的元器件:   “NXP RW612 无线 MCU 集成三频 OTBR” (线程 1.4)   我还找到了以下方面的单独认证:   - NXP i.MX MPU 搭载 IW610 三频 OTBR - NXP i.MX MPU 搭载 IW612 三频 OTBR - NXP RW612 无线 MCU,集成三频 OTBR   我想更好地了解 RW612 OTBR 认证所使用的认证架构。   请问您能否澄清一下:   1. 是否使用 RW612 作为独立组网 \(SA\) 的基于 MCU/RTOS 的线程边界路由器获得认证?   2. 认证配置中是否使用了外部 RCP/NCP 设备?   3. 认证过程中使用了哪个软件平台(FreeRTOS、Zephyr 或其他平台)?   4. 是否有公开的参考设计或文档描述了经过认证的 RW612 OTBR 实现?   我们的目标是了解 RW612 OTBR 认证是否代表基于 MCU 的独立组网 \(SA\)线程边界路由器解决方案,而不是基于 Linux 主机的 OTBR 架构。   感谢您的支持。   顺祝商祺! 赵京焕   Re: Question about RW612 OTBR Thread Certification Architecture 你好, 希望你一切都好。我叫里卡多,这个案子交给了我。 A1:是的。RW612 OTBR 认证是一个真正的独立组网 (SA)单芯片解决方案。 A2:不。与 i.MX MPU + IW610/IW612 OTBR 认证(使用带有外部 IW6xx 无线电协处理器的 Linux 主机,RCP 模式)不同,RW612 认证不使用任何外部 RCP 或 NCP 设备。 A3:让我确认一下。 A4:有关测试配置、测试报告或认证范围的具体详情,请直接联系 Thread Group,网址为threadgroup.org 。 顺祝商祺! 里卡多 Re: Question about RW612 OTBR Thread Certification Architecture 你好@KyonghwanCho , 感谢您的耐心等待。 我已经确认所使用的软件平台是 FreeRTOS。 另外,请查看下方的 OTBR 用户指南和版本指南。 ot-nxp/examples/br/README-OTBR.md 位于 版本/v1.4.0.5_26.03 · NXP/ot-nxp ot-nxp/src/rw/rw612/README.md 位于 版本/v1.4.0.5_26.03 · NXP/ot-nxp 顺祝商祺! 里卡多
記事全体を表示
IMX95EVK M7 核心的刷写问题 你好, 我正在尝试运行一个 M7 应用程序 IMX95LPD5EVK-19 下列的 AN14748 ,但我无法刷机。 flash.bin 用 UUU。短暂检测到电路板后,SDPS 启动立即失败。 硬件: IMX95LPD5BB-19 修订版 A1 (2024 NXP BV) 启动开关(SW7[1:4]): 1001(序列号下载) 目标: eMMC 主持人: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 尝试过的 SDK(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 两者产生的结果相同。 命令: 光盘 IMX95LPD5EVK/版本_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo 呜呜呜 -b EMMC flash.bin   错误: 成功 0 失败 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: 启动 -f flash.bin   执行步骤(根据 AN14748): 在电路板断电的情况下,将 SW7 设置为 1001 将 USB 连接到主机 跑步 sudo uuu -b emmc flash.bin 电源循环板 每次 SDPS 启动都失败 请分享一下该版本板上 M7 内核的刷写步骤以及支持的电路板支持包。版本。 Re: Flashing Issue on IMX95EVK's M7 core 你好, A1 版本的最新支持 电路板支持包。 是 Linux 6.12.20。 另外,您还可以尝试从头开始构建整个二进制文件(Uboot+SPL+ATF+固件+M-SDK)。 ## ## Download and extract ARM GCC toolchain ## ## $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### 请注意使用最新支持的电路板支持包。版本。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin ## ## Build Uboot ## ## $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build ATF ## ## $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ## ## Build SM ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (如果关联的 mx95evk.cfg 文件已更改,则此步骤可选的) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (MCUXpresso 测试配置) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ 板=mx95lp5 oei=tcm DEBUG=1 (仅适用于 i.MX 95 A1) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept ## ## M7 SDK compilation ## ## $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For ITCM ## ## $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 ## ## For DDR ## ## $ exit(这将关闭终端,请重新打开终端) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-启动.bin ./iMX95 $ cp ../uboot-imx/spl/u-启动-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 您可以使用生成的二进制文件来刷写您的 EVK,我们已经在独立组网 \(SA\) 模式下测试过,它可以正常工作。 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core db16122_0-1785222133220.png 如果从 EMMC 启动,则根据快速入门指南,SW7-3 应为 1。 IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core 你好, 谢谢你的更新。 请尝试使用 sudo 命令。 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas 我完全按照您给出的步骤操作了。 但是仍然存在同样的闪烁错误。进度达到 60% 后,过了一段时间就失败了。 请您查看以下截图,并告诉我这些命令是否正确。 谢谢, 高拉夫 Screenshot from 2026-07-31 17-31-12.png Screenshot from 2026-07-31 17-31-20.png Re: Flashing Issue on IMX95EVK's M7 core 为什么会出现“USB 设备错误”?这种情况是否发生在启动过程进行到 60% 时? Re: Flashing Issue on IMX95EVK's M7 core 这个问题是否可以重现,即每次进程进行到 60% 时都会失败? Re: Flashing Issue on IMX95EVK's M7 core 我正在为所有仓库开发 lf-6.12 版本。下载模式的开关位置为“ 1 0 0 1” 请问能否确认一下支持的M7 SDK版本? Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas , 我也尝试过使用 sudo 命令,但没有任何改变,仍然失败。 请查看以下截图。 谢谢! 高拉夫·C. Screenshot from 2026-08-03 09-14-48.png Re: Flashing Issue on IMX95EVK's M7 core 你好, 我找到一个新资源,建议对 A1 芯片版本使用 Linux 6.12.3_1.0.0/SDK25.03.00,请尝试使用这些软件版本再试一次。 当您查看错误日志时,Cortex-A 控制台中显示了什么? 顺祝商祺! Re: Flashing Issue on IMX95EVK's M7 core 你好@db16122 , 谢谢回复。 是的,刷固件时会失败,卡在 60% 一段时间后就失败了。 谢谢! 高拉夫·C. Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas 我使用文档 AN14748 和SDK25.03.00解决了这个问题。 感谢您的建议和宝贵时间。 谢谢! 高拉夫 Re: Flashing Issue on IMX95EVK's M7 core 是的,这种情况每次都会发生。 Re: Flashing Issue on IMX95EVK's M7 core 嗨@JorgeCas 我尝试使用 SDK 25.03,但在刷写二进制文件时,/dev/ttyUSB3 上只出现了一些故障日志。 我也按如下方式复制了文件。 cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 你认为也存在名为mx95a1-ahab-container.img的文件吗? 请同时查看截图,截图显示的是 SOC IMX95(A0),而我的版本是 A1。 谢谢! 高拉夫 Screenshot from 2026-08-05 17-49-46.png
記事全体を表示
i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, I'd like to report an issue I encountered with CST regarding RSA-PSS signature verification on an i.MX93-evk platform, which I believe is a bug. Below, I describe the steps that led me to this discovery. I'm currently implementing the secure boot procedure on an i.MX93-EVK platform and successfully got it working with the standard, documented procedure using CST v4.0.1. I then wanted to sign the various binaries outside of CST, using OpenSSL directly (note: this is not a PKCS#11 setup, I'm just using my own RSA key with the OpenSSL CLI/API). I came across the following procedure, which describes exactly what I wanted to achieve: Using HSM mode for code signing in AHAB devices.pdf This works well with keys generated using the ahab_pki_tree tool provided by the Code Signing Tool (CST), with the following parameters: use an existing CA key: n key type: rsa-pss key length: 4096-bit digest algorithm: sha384 However, the reason I want to sign binaries outside of CST is that I already have an RSA key that is used for signing various other artifacts. When I use this key to sign the various bin files and then try to reintegrate the signed hashes as described in the linked procedure, I get the following error (CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid After double-checking that everything was correct, I also tested verifying my signature using OpenSSL as follows: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK Expected vs actual: since OpenSSL confirms the signature is a valid PSS signature, I expected CST to accept it during reintegration as well. Instead, CST rejects it as invalid. I started digging into the CST source code and found why it was incorrectly reporting the signature as invalid, even though it was successfully verified by OpenSSL. When CST checks the signature, it does the following: Using OpenSSL API calls, it retrieves the "Public Key Algorithm" field from the public key. Based on this field, it uses another OpenSSL API call to essentially ask: "Does the given signature file correspond to the public key algorithm used?" When generating/using what the NXP documentation calls "RSA-PSS" keys, the "Public Key Algorithm" field is equal to rsassaPss and the checks above work correctly. However, when using a generic RSA key, the "Public Key Algorithm" field is equal to rsaEncryption, and CST wrongly assumes this means the signature format is PKCS#1 v1.5, even though it's entirely possible to sign using the PKCS#1 v2.1 (PSS) format. I confirmed this incorrect assumption by hardcoding into the CST source code that my signature was a PSS one, and I was then able to get my signature successfully verified and reinserted by CST into the final binary. It then worked as expected on my closed device. I'm happy to provide more details if needed, especially regarding the various OpenSSL function calls involved. Could you confirm whether this is a known limitation of CST, or if I might be missing something in how I'm generating/using the signature with a generic RSA key? As a side question, I also tried using SPSDK, which seems to be the new tool NXP is promoting for AHAB-based platforms, but I couldn't find a way to export the binaries to be signed, sign them manually, and then reinsert them, similar to the CST procedure. Do you know if this is feasible? Thanks in advance. Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode Hello, Actually the document that you are using is correct, is the aproach we suggest for customers that are still using CST. For AHAB, and specially new i.MX9 familly we suggest customers to move to the SPSDK as this is the tool we are using for enablement on security. Even so you can share the steps you have followed and the changes you made to the tool, so I can review and share with internal team if needed. Also, for the SPSDK you may have a look to the following: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html Hope this helps, Best regards/Saludos, Aldo.
記事全体を表示
i.MX93 AHAB 安全启动、RSA-PSS 签名和 HSM 模式 你好, 我想报告我在 i.MX93-evk 平台上使用 CST 进行 RSA-PSS 签名验证时遇到的问题,我认为这是一个 bug。下面我将描述我得出这一发现的步骤。 我目前正在 i.MX93-EVK 平台上实施安全启动程序,并已使用 CST v4.0.1 按照标准、有记录的程序成功使其工作。 然后,我想在 CST 之外对各种二进制文件进行签名,直接使用 OpenSSL(注意:这不是 PKCS#11 设置,我只是使用我自己的 RSA 密钥和 OpenSSL CLI/API)。我找到了以下步骤,它恰好描述了我想要实现的目标:在 AHAB 设备中使用 HSM 模式进行代码签名.pdf 这对于使用代码签名工具 (CST) 提供的ahab_pki_tree工具生成的密钥效果很好,参数如下: 使用现有 CA 密钥:否 密钥类型:rsa-pss 密钥长度:4096 位 摘要算法:sha384 但是,我想要在 CST 之外对二进制文件进行签名的原因是,我已经有一个 RSA 密钥,该密钥用于对各种其他工件进行签名。当我使用此密钥对各种 bin 文件进行签名,然后尝试按照链接中的步骤重新集成签名哈希值时,出现以下错误(CST v4.0.1): [ERROR] CST: The signature file spl_data.sig is not valid 在仔细检查确认一切无误后,我还使用 OpenSSL 测试了签名验证,步骤如下: $ openssl dgst -sha384 -verify pubkey.pem -signature spl_data.sig -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:digest spl_data.bin Verified OK 预期与实际情况:由于 OpenSSL 确认该签名是有效的 PSS 签名,我预期 CST 在重新集成期间也会接受它。CST 却将其判定为无效并拒绝接受。 我开始深入研究 CST 源代码,并发现了它错误地将签名报告为无效的原因,即使 OpenSSL 已成功验证了该签名。 CST 检查签名时,会执行以下操作: 它使用 OpenSSL API 调用,从公钥中检索“公钥算法”字段。 根据该字段,它使用另一个 OpenSSL API 调用来询问:“给定的签名文件是否与所使用的公钥算法相符?” 当生成/使用 NXP 文档中称为“RSA-PSS”的密钥时,“公钥算法”字段等于rsassaPss ,并且上述检查工作正常。 然而,当使用通用 RSA 密钥时,“公钥算法”字段等于rsaEncryption ,CST 错误地认为这意味着签名格式为 PKCS#1 v1.5,即使完全可以使用 PKCS#1 v2.1 (PSS) 格式进行签名。 我通过在 CST 源代码中硬编码我的签名是 PSS 签名来证实了这个错误的假设,然后我成功地让 CST 验证了我的签名并将其重新插入到最终的二进制文件中。然后它在我的封闭设备上运行正常。 如有需要,我很乐意提供更多细节,特别是关于所涉及的各种 OpenSSL 函数调用。 能否确认这是否是 CST 的已知限制,或者我在使用通用 RSA 密钥生成/使用签名时是否遗漏了某些内容? 另外,我还尝试使用 SPSDK,这似乎是 NXP 为基于 AHAB 的平台推广的新工具,但我找不到导出要签名的二进制文件、手动签名,然后再重新插入的方法,类似于 CST 过程。你知道这是否可行吗? 先行致谢。 Re: i.MX93 AHAB Secure boot, RSA-PSS signature and HSM mode 你好, 实际上,您正在使用的文档是正确的,这是我们建议仍然使用 CST 的客户采用的方法。对于 AHAB,特别是新的 i.MX9 系列,我们建议客户迁移到 SPSDK,因为这是我们用于启用网络安全的工具。 即便如此,您仍然可以分享您遵循的步骤以及您对工具所做的更改,以便我进行审核,并在需要时与内部团队分享。 另外,关于SPSDK,您可以参考以下内容: https://docs.nxp.com/bundle/AN14785/page/topics/signing_with_offline_hsm.html 希望这能帮到你。 此致敬礼/Saludos, 阿尔多。
記事全体を表示
是否可以对 i.MX93 板进行重新配置? 我已使用 EdgeLock 2GO 成功配置了我的 FRDM i.MX93 板。现在我想使用一组新的或更新的安全对象(例如密钥对和 X.509 证书)重新配置同一块板。已配置的 i.MX93 设备是否支持重新配置?如果支持,请问推荐的步骤是什么?具体来说,之前配置的安全对象是否需要在重新配置之前删除或 RESET,还是可以通过 EdgeLock 2GO 进行更新?此外,在尝试重新配置之前,我是否需要注意任何限制或不可逆的设置? 日志:-- 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失败:0xffffc180 错误:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失败:0xffffffff 错误:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 失败,错误代码为 0xffffffff 状态(oem-prov-app):失败 FRDM 培训 动手实践培训 安全 Yocto Project Re: Is it possible to reprovision the i.MX93 board? 你好, EdgeLock 2GO 可进行重新配置,其设计旨在实现完整的生命周期管理,包括在初始部署后更新、轮换或撤销证书和密钥。 请问您能否分享一下您在安全配置过程中遵循了哪些步骤? 您需要了解与熔丝中烧毁的配置相关的程序,例如键、生命周期等。 顺祝商祺! Re: Is it possible to reprovision the i.MX93 board? 感谢您确认服务级别支持重新配置。澄清一下:这不是一次全新的配置尝试,而是对已经成功配置过一次的板子进行的重新配置尝试(生命周期 OEM_OPEN,ELE 固件 2.0.5-7a34cee,第一次配置时已经存在密钥和证书对象)。 在第二次尝试中,oem-prov-app 在 iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内部的 mbedtls_pk_setup_opaque() 调用处失败,返回 MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180)。版本:el2go-agent 6.4.2-r0,smw 5.3-r0,mbedtls 3.6.5-r0。 两个问题: 1.重新配置是否需要在重新运行 oem-prov-app 之前显式擦除现有密钥对象(通过 psa_destroy_key 或 SMW 密钥存储 API),还是代理应该在相同的密钥 ID 处就地覆盖它?我们目前没有执行任何显式擦除步骤。 2. el2go-agent 6.4.2-r0 和 smw 5.3-r0 之间是否存在已知的兼容性问题,尤其是在重新配置/更新路径上?因为我们在初始启动时也看到了同样的错误,并怀疑是版本不匹配导致的。 另外,能否确认已配置的密钥和证书对象位于 ELE 管理的 NVM 中,而不是熔丝中,这样即使重新配置失败,也不会导致该密钥 ID 永久无法使用? Re: Is it possible to reprovision the i.MX93 board? 你好, 谢谢你提供的信息。 1. 是的,使用签名消息执行密钥库重新配置。密钥存储重新配置会导致 HSM 处理的所有密钥存储被擦除。 2. 没有,没有报告任何兼容性问题。 3. 没错,应用程序密钥和证书存储在 ELE 管理的 NVM 中,而不是存储在熔丝中。 顺祝商祺!
記事全体を表示
IMX95EVKのM7コアにおけるフラッシュの問題 こんにちは、 IMX95LPD5EVK-19 follow AN14748 でM7アプリケーションを実行しようとしていますが、フラッシュできません flash.binUUUと共に。ボードは短時間検出されるが、その後すぐにSDPSの起動に失敗する。 ハードウェア: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) ブートスイッチ(SW7[1:4]): 1001(シリアルダウンロード) ターゲット: eMMC ホスト: Ubuntu Linux うーん: libuuu_1.5.243-0-g230f1b1 試したSDKs(MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 どちらも同じ結果を生み出す。 コマンド: CD IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo ううう -b emmc flash.bin   エラー: 成功 0 失敗 1 1:2-E3C50910 1/1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   実施された手順(AN14748に基づく): ボードの電源をオフにした状態で、SW7を1001に設定します。 USBをホストに接続します 走る sudo uuu -b emmc flash.bin 電源サイクルボード SDPSの起動に毎回失敗する このバージョンのボードにおけるM7コアのフラッシュ手順とサポートされているBSPバージョンを教えてください。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 A1版向けに最新サポートされているBSPはLinux 6.12.20です。 また、バイナリ全体を一から作るのも手です(Uboot+SPL+ATF+Firmware+M-SDK)。 #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### あなたの場合は、サポートされている最新のBSPバージョンに注意してください。 $ git clone https://github.com/nxp-imx/imx-mkimage-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei-b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx-b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ CD Uboot-IMX $ make -j $(nproc --all) きれいに $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ CD ... $ CD IMX-ATF $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ CD ... $ CD IMX-SM $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg(関連するmx95evk.cfgファイルが変更されている場合は任意) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) ## ## Build OEI ## ## $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (i.MX 95 A1 のみ) ## ## Extract Firmware ## ## $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --車載承認 $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --自動承認 #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit(これで端末が閉鎖されるSO、再開してください) ## ## Copy the resulting binaries to imx-mkimage ## ## $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all 生成されたバイナリを使用してEVKをフラッシュすることができます。スタンドアロンモードでテストしたところ、正常に動作しました。 よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core db16122_0-1785222133220.png クイックスタートガイドによると、EMMCからブートする場合、SW7-3は1になるはずです。 IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、@JorgeCasさん 私はあなたが指示した手順を正確に実行しました。 しかし、同じ点滅エラーが発生します。60%まで進んだ後、しばらくして失敗した。 CAN、以下のスクリーンショットを確認して、コマンドが正しいか教えてもらえますか? ありがとう、 ガウラヴ Screenshot from 2026-07-31 17-31-12.png Screenshot from 2026-07-31 17-31-20.png Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 最新情報のご提供ありがとうございます。 sudoコマンドを使って試してみてください。 よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core USBエラー「デバイスが見つかりません」が表示されるのはなぜですか?起動プロセスの60%の時点で発生しますか? Re: Flashing Issue on IMX95EVK's M7 core CANこの問題が常に60%のプロセスで失敗していると再現されることはありますか? Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 新しいリソースで、A1シリコンリビジョンにはLinux 6.12.3_1.0.0/SDK25.03.00を使うことを勧められました。このソフトウェアバージョンでもう一度試してみてください。 Cortex-Aコンソールでエラーログを見ると何が見えますか? よろしくお願いいたします。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 @JorgeCas さん。 sudoコマンドも試してみましたが、変化はなく、依然として失敗します。 下記のスクリーンショットをご確認ください。 ありがとうございます ガウラヴ・C Screenshot from 2026-08-03 09-14-48.png Re: Flashing Issue on IMX95EVK's M7 core そして、すべてのリポジトリ向けにlf-6.12バージョンの開発に取り組んでいます。ダウンロードモードのスイッチ位置は「1 0 0 1」です。 サポートされているM7 SDKsのバージョンも確認していただけますか? Re: Flashing Issue on IMX95EVK's M7 core こんにちは、 @db16122 さん。 ご返信ありがとうございます。 はい、ファームウェアの書き込み中にエラーが発生し、60%のところでしばらく止まった後、エラーになります。 ありがとうございます ガウラヴ・C Re: Flashing Issue on IMX95EVK's M7 core こんにちは、@JorgeCasさん ドキュメントAN14748とSDK25.03.00を使用することで、この問題を解決できます。 ご提案と貴重なお時間をありがとうございました。 ありがとうございます ガウラヴ Re: Flashing Issue on IMX95EVK's M7 core はい、毎回そうなります。 Re: Flashing Issue on IMX95EVK's M7 core こんにちは、@JorgeCasさん SDK 25.03で試しましたが、バイナリをフラッシュしている間に/dev/ttyUSB3でいくつかの失敗ログしか出ません。 以下のようにファイルをコピーしました。 cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 mx95a1-ahab-container.imgというファイルも存在すると思いますか? スクリーンショットもご確認ください。私の場合はA1リビジョンですが、SOC IMX95(A0)と表示されています。 よろしくお願いします。 ガウラヴ Screenshot from 2026-08-05 17-49-46.png
記事全体を表示
lx2080(yocto镜像和调试) 我需要了解如何使用 Yocto 配置 LX2080A NXP 镜像版本,以及如果要使用自定义板卡,应该如何进行更改。 Re: lx2080(yocto image and debug) Layerscape Yocto 电路板支持包。 v26.06: 该版本包含源代码和预编译镜像,具体内容如下: 源代码版本文件位于https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk 分支: walnascar-lsdk Linux BSP 支持的开发板、功能、已知问题,请参阅版本说明 Layerscape Yocto软件开发工具包用户指南: UG10374.pdf Layerscape Linux SDK 用户指南: UG10381.pdf 请修改 RCW、u-boot、ATF 和 Linux dts 以适应您的定制板,并重新构建镜像。 移植步骤: 修改 rcw 并重新构建 rcw: $ bitbake rcw -c patch -f 请打开 rcw 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/,并根据您的自定义板修改 XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw。 $ bitbake rcw 修改并重新编译 u-启动: $ bitbake u-启动 -c patch -f 请进入 u-启动 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/,根据您的定制板修改 u-启动 源代码。 $ bitbake u-boot 修改并重新构建 atf: $ bitbake qoriq-atf -c patch -f 请前往 atf 源代码文件夹 build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/,请根据您的定制板修改 atf 源代码。 $ bitbake qoriq-atf 修改Linux dts文件并重新构建Linux内核: $ bitbake virtual/kernel -c patch -f 请进入 Linux 内核文件夹 build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git,请根据定制板修改 dts 文件 arch/arm64/启动/dts/freescale/fsl-lx2160a-rdb.dts。 $ bitbake 虚拟/内核 Re: lx2080(yocto image and debug) 对于 lx2080a yocto(linux 24.04)镜像构建(rcw->tfa->uboot-linux 路径)并通过 sd 卡或 emmc 或 norflash 烧录镜像。我们可以使用 Code Warrior Tap JTAG 调试器吗?
記事全体を表示
SPC入力がWUUに伝わらず、デバイスが起動しない [MCXN947との連携] SPCでは、低電力モードとアクティブモードの両方で、電圧検出割り込みを有効にしています(リセットは無効)。アクティブモードはリセットを無効にし、バンドギャップを有効にしています。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a WUUでSPCをウェイクアップソースとして有効にしました(WUU->MEビットが設定されています)。 SPC割り込みはアクティブモードで動作しますが、電源オフモードでは動作しません。つまり、プロセッサはSPC割り込みを処理するためにウェイクアウトしません。 MCX N Re: SPC input to WUU not waking device おそらく動作しているとは思うが、アクティブモードとパワーダウンモードでは反応に大きな違いがある。アクティブモードでは、SPC割り込みはより迅速に応答し、繰り返し発生しますが、パワーダウンモードからは、割り込みが発生するまでに非常に時間がかかり、一度しか発生しません。 Re: SPC input to WUU not waking device こんにちは、 @robert_hines さん。 電源オフモードからのウェイクアップレイテンシは、アクティブモードの割り込み応答時間よりも長くなると予想されます。電源オフモードでは、MCUの大部分が静的状態にあります。より深い低消費電力モードに入る際のトレードオフの一つは、そのモードの入り出時にレイテンシが増えることです。 割り込みが一度だけ発生する問題については、アプリケーションコードの処理に問題があるのではないかと疑っています。SDKに含まれるpower_mode_switch例を参照し、実装とあなたのコードを比較していただけますか? それでも問題が解決しない場合は、FRDM-MCXN947ボード上で問題を再現できる簡単なプロジェクトを提供してください。喜んでさらに詳しく調査いたします。 よろしくお願いします。 BR アリス Re: SPC input to WUU not waking device 状況は以下のとおりです。 - FreeRTOSへの移植 - 低電力タイマーを使用して、PM_EnterLowPower()で電源オフモードに移行します。 - IRQHandlers は setFromISR() と portYIELD_FROM_ISR() を使用します - 高優先度タスクがISRで設定されたイベントビットを待機している場合、xEventGroupWaitBits() - 一部の割り込みはWUUを経由して電源オフモードで利用可能にしており、外部ピンの一部(正常に動作しているようです)や、SPCが遅い/応答しない点を除き、問題なく動作する内部モジュール(VBAT、LPTMR、TDET、SPC)も含まれます。 - SPC割り込みはIRQHandlerで無効化され、イベントビットの設定を待つ高優先度タスクで処理された後に再有効化されます。この待機タスクはイベント情報ビットのプロセッシング後に再び PM_EnterLowPower() を呼び出します。 問題は、SPC割り込みが他の割り込みと同じように応答しないことだ。プロセッサが起動しても再びスリープに戻り、再びトリガーされません。アクティブモードで電源が切れても、発火は続けます(PM_EnterLowPower()でプロセッサを再び電源オフモードに戻せません)。
記事全体を表示
SPC input to WUU not waking device [Working with MCXN947] I have voltage detect interrupts enabled (resets disabled) in SPC in both low-power and active modes (resets disabled, bandgaps enabled). SPC0->ACTIVE_CFG:  3f101615 SPC0->LP_CFG:      3f221515 SPC0->VD_IO_CFG:   0000000a SPC0->VD_SYS_CFG:  0000000a SPC0->VD_CORE_CFG: 0000000a I've enabled SPC as a wake-up source in the WUU (WUU->ME bit is set). The SPC interrupt works in active mode, but not in power-down mode, i.e. the processor doesn't wake to handle the SPC interrupt. MCXN Re: SPC input to WUU not waking device I think it may be working, but there's a large difference in the response between active and power-down mode.  In active mode, the SPC interrupt will respond more quickly and go off repeatedly, but from power-down mode, it takes much longer to trigger the interrupt and it only triggers once. Re: SPC input to WUU not waking device Hi @robert_hines  The wake-up latency from Power-down mode is expected to be longer than the interrupt response time in Active mode. In Power-down mode, most of the MCU is in a static state. One of the trade-offs of entering a deeper low-power mode is the increased latency when entering and exiting that mode. Regarding the issue where the interrupt only occurs once, I suspect there may be an issue in the application code handling. Could you please refer to the power_mode_switch example included in the SDK and compare the implementation with your code? If the issue still persists, please provide a simple project that can reproduce the problem on the FRDM-MCXN947 board. I will be happy to investigate it further. Thank you. BR Alice Re: SPC input to WUU not waking device The context is: - FreeRTOS port - Going into power-down mode with PM_EnterLowPower( ) using a low-power timer. - IRQHandlers use setFromISR() and portYIELD_FROM_ISR() - a high-priority task is waiting for the event bits set from ISR, xEventGroupWaitBits() - some interrupts are routed through the WUU so that they are available in powerdown mode, including some external pins (seem to work fine) and some internal modules (VBAT, LPTMR, TDET, SPC) that seem to work fine, with the exception of SPC being slow/unresponsive. - The SPC interrupt is disabled in the IRQHandler and re-enabled after being processed in the high-priority task that is waiting for event bits to be set.  This waiting task also calls PM_EnterLowPower() again after processing event bits. The "problem" is that the SPC interrupt doesn't respond like the others.  When it does wake up the processor, it goes back to sleep and doesn't trigger again.  When it goes off in active mode, it does keep firing (PM_EnterLowPower() can't put the processor back into powerdown mode).
記事全体を表示
i.MX93ボードを再プロビジョニングすることは可能ですか? すでにEdgeLock 2GOを使ってFRDM i.MX93ボードのプロビジョニングを完了しており、プロビジョニングは無事完了しています。 今は同じボードに、キーペアやX.509証明書などの新しいまたは更新されたセキュアオブジェクトセットで再プロビジョニングしたいと考えています。 すでにプロビジョニング済みのi.MX93デバイスでの再プロビジョニングはサポートされていますか? もしそうなら、推奨される手順を教えていただけますか?具体的には、以前にプロビジョニングされたセキュアオブジェクトは、再度プロビジョニングする前に削除またはリセットする必要がありますか?それともEdgeLock 2GOを通じて更新できるのでしょうか? また、再プロビジョニングを試みる前に知っておくべき制限や不可逆的な設定はありますか? ログは:-- エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 0xffffffffで故障 Status(oem-prov-app): FAILURE(Status(oem-prov-app): FAILURE(FAILURE) FRDMトレーニング ハンズオン・トレーニング Security Yocto Project Re: Is it possible to reprovision the i.MX93 board? こんにちは、 再プロビジョニングも可能であり、EdgeLock 2GOは初期展開後の証明書や鍵の更新、ローテーション、取り消しを含む完全なライフサイクルマネジメントを目的に設計されています。 安全なプロビジョニングのためにどのような手順を踏みましたか? キーやライフサイクルなど、ヒューズ内の焼き付き構成に関わる手順について理解しておく必要があります。 よろしくお願いいたします。 Re: Is it possible to reprovision the i.MX93 board? サービスレベルでの再プロビジョニングがサポートされていることを確認していただきありがとうございます。明確にしておきますが、これは新規のプロビジョニング試行ではなく、既に一度正常にプロビジョニングされたボード(ライフサイクルOEM_OPEN、ELEファームウェア2.0.5-7a34cee、初回プロビジョニング時に既にキーと証明書オブジェクトが存在する状態)に対する再プロビジョニング試行です。 この 2 回目のパスで、oem-prov-app は iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内の mbedtls_pk_setup_opaque() 呼び出しで失敗し、MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180) を返します。バージョン: el2go-agent 6.4.2-r0、smw 5.3-r0、mbedtls 3.6.5-r0。 2つの質問があります。 1.再プロビジョニングでは、oem-prov-appを再実行する前に、既存のキーオブジェクトを明示的に消去する必要がありますか(psa_destroy_keyまたはSMWキーストレージAPI経由)、それともエージェントが同じキーIDで上書きする必要がありますか?現在、明示的な消去手順は実行していません。 2. el2go-agent 6.4.2-r0 と smw 5.3-r0 の間には、特に再プロビジョニング/更新パスに関して既知の互換性の問題がありますか?というのも、初期起動時にも同じエラーが発生し、そこでもバージョン不一致が疑われたからです。 また、プロビジョニングされた鍵と証明書オブジェクトがELE管理のNVMに存在しているのか確認できますか?つまり、再プロビジョニングに失敗してもその鍵IDが永久に使えなくなるわけではありません。 Re: Is it possible to reprovision the i.MX93 board? こんにちは、 情報ありがとうございます。 1. はい、署名付きメッセージを使用してキーストアの再プロビジョニングを実行してください。キーストアの再プロビジョニングを行うと、HSMによって管理されているすべてのキーストアが消去されます。 2. いいえ、互換性の問題は報告されていません。 3. その通り、アプリケーション鍵や証明書はヒューズではなくELE管理のNVMに保存されます。 よろしくお願いいたします。
記事全体を表示
SPC 输入到 WUU 未唤醒设备 [与 MCXN947 合作] 我在 SPC 中启用了电压检测中断(禁用复位),无论是在低功耗模式还是运行模式下(禁用复位,启用带隙)。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a 我已在 WUU 中启用 SPC 作为唤醒源(WUU->ME 位已设置)。 SPC 中断在运行模式下工作,但在掉电模式下不工作,即处理器不会唤醒来处理 SPC 中断。 MCX N Re: SPC input to WUU not waking device 我觉得它可能在工作,但是工作模式和断电模式下的响应速度差异很大。在运行模式下,SPC 中断响应速度更快,会反复触发;但在掉电模式下,触发信号中断所需的时间要长得多,而且只会触发信号一次。 Re: SPC input to WUU not waking device 嗨@robert_hines 预计从断电模式唤醒的延迟时间将比运行模式下的中断响应时间长。在断电模式下,MCU 的大部分功能处于静态状态。进入更深层次的低功耗模式的弊端之一是进入和退出该模式时延迟会增加。 关于中断只发生一次的问题,我怀疑可能是应用程序代码处理方面存在问题。请您参考 SDK 中包含的 power_mode_switch 示例,并将实现方式与您的代码进行比较? 如果问题仍然存在,请提供一个简单的项目,以便在 FRDM-MCXN947 板上重现该问题。我很乐意进一步调查此事。 谢谢! BR 爱丽丝 Re: SPC input to WUU not waking device 上下文是: - FreeRTOS 移植 - 使用低功耗定时器进入关机模式,命令为 PM_EnterLowPower()。 - IRQHandlers 使用 setFromISR() 和 portYIELD_FROM_ISR() - 一个高优先级任务正在等待 ISR 中设置的事件位,xEventGroupWaitBits() - 一些中断通过 WUU 路由,以便在掉电模式下可用,包括一些外部引脚(似乎工作正常)和一些内部模块(VBAT、LPTMR、TDET、SPC),这些模块似乎工作正常,但 SPC 速度慢/无响应。 - SPC 中断在 IRQHandler 中被禁用,并在等待事件位设置的高优先级任务处理完毕后重新启用。该等待任务在处理事件位后还会再次调用 PM_EnterLowPower()。 问题在于SPC中断的响应方式与其他中断不同。当处理器被唤醒后,它会再次进入睡眠状态,并且不会再次发出触发信号。当它在运行模式下关闭时,它会继续触发(PM_EnterLowPower() 无法将处理器恢复到关机模式)。
記事全体を表示
LX2080(Yoctoイメージとデバッグ) YOCTOを使ってLX2080a NXPイメージビルドの設定方法や、カスタムBORDを使いたい場合は変更方法について情報が欲しいです Re: lx2080(yocto image and debug) Layerscape Yocto BSP v26.06: 今回のリリースには、以下に示すソースコードとビルド済みイメージの両方が含まれています。 ソースリリースファイルは、 https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdkにあります。 ブランチ: walnascar-lsdk Linux BSP対応の基板、機能、既知の問題については、リリースノートをご参照ください Yocto用レイヤースケープソフトウェア開発キットユーザーガイド: UG10374.pdf Layerscape Linux SDK ユーザーガイド: UG10381.pdf カスタムボード用にRCW、u-boot、ATF、Linux dtsを改造し、イメージを再構築してください。 移植手順: rcwを変更し、rcwを再構築する: $ bitbake rcw -c patch -f rcwのソースコードフォルダbuild_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/git/lx2160ardb_rev2/を選び、カスタムボードに合わせてXGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcwを修正してください。 $ bitbake rcw u-bootを修正して再構築する: $ bitbake u-boot -c patch -f you-bootのソースコードフォルダ build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/にアクセスし、カスタムボードに合わせてu-bootのソースコードを修正してください。 $ bitbake u-boot atfを修正および再構築する: $ bitbake qoriq-atf -c patch -f atfのソースコードフォルダ build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/にアクセスしてください。カスタムボードに合わせてatfのソースコードを修正してください。 $ bitbake qoriq-atf Linux dts ファイルを修正し、Linux カーネルを再構築する: $ bitbake virtual/kernel -c patch -f Linux Kernelフォルダ build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git にアクセスしてください。カスタムボードに合わせてdtsファイルarch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dtsを修正してください。 $ bitbake virtual/kernel Re: lx2080(yocto image and debug) LX2080A Yocto(Linux 24.04)イメージビルディング(RCW->TFA->uboot-linux path)およびSDカード、EMMC、NorFlashによる画像のフラッシュ。コード warrire tap jtag デバッガーを使えますか?
記事全体を表示
Create a new model and configure it for NXP Hardware 1 Table of Contents • Introduction • Prerequisites • Creating a New Simulink Model • Configure the Model for NXP Hardware • Add Simulink Blocks • Build the Model • Flash and Run on Hardware • References • Conclusion 2 Introduction Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects. 3 Prerequisites Before starting, ensure the following tools are installed and correctly configured: MATLAB & Simulink NXP MBDT S32 Design Studio / EB tresos NXP RTD drivers USB / JTAG debugger (e.g., PEMicro) Target hardware (e.g., S32K344, S32K358) In addition to having the required tools installed, it is important to ensure that all components are properly integrated and compatible with each other. This includes matching the MATLAB/Simulink version with the supported release of the NXP MBDT, as well as aligning the RTD package with the selected microcontroller and AUTOSAR version. Environment variables, compiler paths, and licensing (for MATLAB, Simulink, and EB tresos) should also be verified prior to starting development. From a hardware perspective, make sure that the evaluation board or target ECU is correctly powered and that the debug interface (such as PEMicro) is functioning. Installing the appropriate USB drivers and checking connection through debug tools can prevent communication issues later in the workflow. Finally, it is recommended to validate the toolchain setup by running a simple example, such as a GPIO toggle or LED blink application, either directly in S32DS or through an existing Simulink example provided by MBDT. This step helps confirm that code generation, compilation, flashing, and execution on the target hardware are all working correctly before moving on to a more complex development. 4 Creating a New Simulink Model Step 1: Launch Simulink Open MATLAB Type simulink in the command window Select Blank Model Sebastian13_0-1784719500241.png Step 2: Save the Model Save with a clear naming convention, e.g. s32k344_led_blink.mdl 5 Configure the Model for NXP Hardware Step 3: Open Model Configuration Parameters Navigate to Model Settings ( Ctrl + E ) → Hardware Implementation Step 4: Select Hardware Board Set Hardware board to the appropriate NXP target For example, NXP S32Kxx Step 5: Select a Configuration Template Set Configuration Project Template to the appropriate NXP target For example, S32K344-Q172 S32 Config Tool If the board is not visible, ensure MBDT is properly installed. Sebastian13_1-1784719557125.png 6 Add Simulink Blocks Using the Library Browser, configure hardware peripherals. Sebastian13_3-1784719625876.png Step 6: Configure GPIO for LED Add a Dio block Configure: Function: Dio_FlipChannel Channel: e.g. DioLed0 Step 7: Add Level Variable Add Data Store Memory and Data Store Write blocks Connect the Dio block to the Data Store Write This will blink an LED because the Dio_FlipChannel function toggles the logical state of the selected GPIO pin every time it is executed. By connecting it to a Data Store Write, you are effectively allowing the system to store or propagate the updated state within the model. The blinking frequency is directly controlled by the task rate of your model, which makes it easy to adjust the LED behavior simply by changing the sample time, without modifying the core logic. In the Library Browser you will find numerous example projects that may be helpful (for example, s32k3xx_dio_s32ct ). Sebastian13_4-1784719654387.png 7 Build the Model Step 8: Generate Code Click Build Model ( Ctrl + B ) Sebastian13_5-1784719707916.png When you press the build button, Simulink automatically translates your model into C code and prepares it for execution on the target microcontroller. The generated files can be found in the project folder, where you can explore how each block was converted into embedded code. After generation, the toolchain creates an executable file and attempts to deploy it directly to the target board. 8 Flash and Run on Hardware Step 9: Connect Target Board Connect via debugger (USB / JTAG) Step 10: Deploy From Simulink (External Mode or Build & Deploy) Or manually via S32 Design Studio 9 References Quick Start Guide for S32K3X4EVB Board Model-Based Design Toolbox (MBDT) – How To 10 Conclusion Creating a new model and configuring it for NXP hardware involves: Setting up the Simulink model Configuring hardware-specific parameters Adding peripheral blocks Generating and deploying embedded code This workflow enables rapid prototyping and production-ready embedded development, especially in automotive systems leveraging AUTOSAR and NXP platforms. Developing embedded applications for NXP microcontrollers—especially platforms like the S32K series—often involves using tools such as MATLAB/Simulink (MBDT – Model-Based Design Toolbox), S32 Design Studio (S32DS), and AUTOSAR tools like EB tresos. This article walks through the key steps involved in creating a new model and configuring it properly for NXP hardware, focusing on a practical workflow used in automotive and embedded systems projects.
記事全体を表示
T1024 QorIQ Bare-Metal BSP for CodeWarrior PA10.5 We need official QorIQ T10xx bare-metal BSP package matching CodeWarrior Power Architecture v10.5. Required content: 1. Complete bare-metal startup BSP for T1024 2. RCW, reset, L1/L2 cache, DDR, interrupt, PCIe low-level driver source 3. CodeWarrior PA10.5 stationary project templates 4. Reference bare-metal demo project for T10xx RDB board Background: We are developing bare-metal firmware on T1024 using CodeWarrior PA10.5, LSDK 2.0 Linux SDK only provides U-Boot & Linux source, missing official CodeWarrior bare-metal BSP. Please provide the official BSP archive or download link. Thanks. Re: T1024 QorIQ Bare-Metal BSP for CodeWarrior PA10.5 We don't have Bare-Metal BSP for T1024 platform. You could require NetComm software for other platform to have reference. https://www.nxp.com.cn/products/processors-and-microcontrollers/power-architecture/qoriq-communication-processors/p-series/netcomm-software-resources:NetComm_Software
記事全体を表示
GUI Guider 2.0におけるSpangroupウィジェットの利用可能性とFUTUREロードマップに関する問い合わせ こんにちは、NXPコミュニティの皆さん、 現在、プロジェクト開発においてGUI Guider 2.0を使用しています。 バージョン2.0への移行中に、以前のGUI Guider 1.xで利用可能だったSpangroupウィジェットが削除されていることに気づきました。基盤となるLVGLライブラリは依然としてSpangroupをサポートしているため、最新リリースでこの欠落がなぜか気になりました。 このウィジェットはUIデザインに非常に役立ちました。ぜひ教えていただけませんか: 今後のGUI Guiderのリリースで、Spangroupウィジェットを再導入する予定はありますか? もしSOなら、次のリリーススケジュールの大まかなスケジュールやロードマップを共有してもらえますか? この件に関して何かご意見やご助言をいただければ大変ありがたいです。 サポートありがとうございます! よろしくお願いいたします。 Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap こんにちは、 @mastergbc さん、 既にGUI Guider開発チームに評価を依頼しており、進展があれば随時ご報告いたします。 その間、実用的な回避策としては、主要なUI設計とコード生成にはGUI Guider 2.0を使用し、必要なLVGLネイティブspangroup実装を手動で生成プロジェクトに追加することです。 GUI Guiderウィジェットパレットに直接公開されていないLVGL機能については、カスタムコードで統合できます。 お役に立てば幸いです。 BR セレステ Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap 最新情報のご提供ありがとうございます。 私たちのユースケースについて少し説明すると、プロジェクトでは Spangroup ウィジェットを使って異なるフォントスタイルや言語をシームレスに混ぜ、特に英語と韓国語のフォントを1つのテキストブロック内で混同しています。 現在、Spangroupを使用して構築されたUIオブジェクトは約12個あります。このウィジェットは、先行する子要素のテキストや長さが変更された場合、後続の子要素のテキストが自動的に再配置され、整列を維持しながらスムーズに折り返されるため、非常に重要な役割を果たしています。 GUI GuiderでSpangroupウィジェットを再実装する長期的な計画がない場合、このマルチフォント/マルチスタイルのテキスト巻き取り動作を実現するための推奨の代替案や回避策をご提案いただけますか? ご協力いただき、改めて感謝申し上げます。 よろしくお願いいたします。 Re: Inquiry regarding Spangroup widget availability in GUI Guider 2.0 and future roadmap こんにちは、 @mastergbc さん、 投稿ありがとうございます。 現在、 SpanGroupウィジェット はGUI Guider 2.0で利用可能ではなく、近い将来に追加する計画もありません。 しかし、お客様の要望をよりよく理解し、要望を評価したいと考えています。SpanGroup Widgetで達成しようとしている機能について、もう少し詳しく教えていただけますか?例えば、具体的なユースケース、期待される動作、使用頻度、そしてこの機能がプロジェクトにとってどれほど重要かなどです。この情報は、リクエストを評価し、必要に応じてGui-Guiderチームに転送するのに役立ちます。 さらに、現在どの製品を使っているのか(MCUかMPUモデルか)教えていただけますか?これにより、あなたのアプリケーション状況をよりよく理解できます。 良い1日を。 BR セレステ
記事全体を表示
Support Period for Yocto Linux BSP Hello, Could you please provide information regarding the following? We are planning to use the Yocto Linux BSP provided by NXP for a board based on the i.MX 8M Plus. Could you please answer the following questions regarding the BSP? 1. How long are updates provided after a BSP is released? 2. When a new Yocto LTS release becomes available, how long does it typically take for the BSP to be updated to incorporate the new Yocto LTS version? 3. We understand that security updates are available through "BSP Lifecycle Maintenance: Keeping Your Linux® BSP Secure." Could you please let us know: - the maximum support period available, and - the approximate cost of this service? Thank you for your support. We look forward to your response. Best regards,
記事全体を表示
使用软件1.9.1时无法添加新图片(无法添加图片) 前几天我使用它的时候,像往常一样添加了新的图片(PNG 格式),但是加载时间很长,而且在那段时间里我无法使用其他功能。见图2。 关闭并重新启动软件后,我发现之前上传的图库中的所有图片都消失了,而且我也无法上传新图片。见图1。 当我在某次使用的时候,像往常一样添加新的图片(PNG格式),却加载了很久,期间也无法使用其他功能。请看图二 当我把软件关闭重启后,发现之前上传的图片库里面的图片全部丢失了,而且也无法上传新的图片。请看图一 huang_yingxue_1-1785210488463.png huang_yingxue_0-1785210370827.png Re: Can't add new pictures when using the software 1.9.1(无法添加图片) 嗨@huang_yingxue 请先尝试使用最新版本的 GuiGuider,并与我们联系是否可以重现该问题。如果问题仍然存在,我们可以根据以上补充信息继续进行调查。 感谢您的理解。 BR 哈里
記事全体を表示
MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 我正在使用MCUXpresso IDE v25.6.136开发FRDM-IMXRT1186,从官网下载最新的IDE安装之后,安装最新的SDK(26.06),导入一个frdmimxrt1186_rled_blinky_cm7示例工程之后点击mex无法打开,于是我升级了配置工具,这时mex文件可以打开了,但是点击调试无法连接到开发板,如图所示,怎么办? (已经尝试升级linkserver版本,没用) breeze_i_0-1785204475278.png #FRDM-IMXRT1186 #MIMXRT1180 MCUXpresso-IDE  LINKERSERVER  回复: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 感谢来信。 请您在 MCUXpresso IDE 的 Preferences → MCUXpresso IDE → Debug Options → LinkServer Options 中确认当前 IDE 实际使用的 LinkServer 路径。 请进入该路径对应的 LinkServer 安装目录,执行下面命令,确认该 LinkServer 是否可以识别板载调试器:linkserver probes 请注意,建议在该目录下执行命令,而不是直接在任意命令行窗口执行,以避免调用到系统 PATH 中其他版本的 LinkServer。 如果您单独安装了其他版本的 LinkServer,也可以尝试勾选 Custom path ,并指定到对应的 LinkServer 安装目录,避免 IDE 仍然调用旧版本或异常路径下的 LinkServer。 回复: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 都试过了,还是不行 Re: MCUXpresso IDE v25.6.136升级内置的config tools之后不能启动调试,为什么 Hi @breeze_i , 感谢您关注 NXP RT 系列产品并使用 NXP 社区。 关于您的问题我建议您检查下面几点: 1:首先检查防火墙或杀毒软件是否拦截 IDE / LinkServer / redlinkserv 的 localhost 通信; 2:不要在原 workspace 上继续试,新建一个空的 workspace,然后重新导入demo; 3:在 IDE 中执行 Clean Up Debug ,然后关闭 IDE,拔掉开发板/调试器,重新连接后再尝试 Debug。 mayliu1_0-1785219755566.png 请先按以上步骤排查。 Best  Regards May
記事全体を表示
Flexioを特殊なSPIとして、同時に20ビットMOSI出力として動作させたい。 csとclkは共有されます。 20本のMOSIラインが20本のDACチップに接続されていますが、この環境下でFlexio Muilt-BeatはCAN動作しますか? 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 私が使用したチップはMCN947です。 FlexIOを使用して、24ビットDACを20個SPI制御するシミュレーションを行う必要があります。 これら20個のDACのCSおよびCCKパラメータは共通ですが、各チップはそれぞれ独立したMOSIを備えています。MISOは存在しません。したがって、厳密に言えばSPIではなく、20個のMOSIを備えたSPIと言えます。 出力が生成されるたびに、20個のDACの値が同時に更新される。 私の考えは、20個のDACから1ビットずつSHIFBUFに格納し、8個のSHIFBUFでそれぞれ8ビットを格納するというものです。 1回のDMA転送で、20個のDACに対する8ビットデータの更新が完了する。 DMA処理では、24ビットのデータを3回同期および更新します。最後に、チップセレクト信号が立ち上がります。 アイデアはあったものの、Flexioのサンプルコードを見ても、どこからコードを書き始めればいいのか分からなかった。 関連する事例をお持ちかどうか分かりません。また、私のやり方が最適かどうかも分かりません。 Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは@justdomyself 質問についてもう少し詳しく説明していただけますか? お知らせください: どのMCUを使っているのか教えてください。 ソフトウェアの設定方法。 どのような問題が発生していますか? 問題の理解に役立つ可能性のある追加情報があれば教えてください。 中国語で問題を説明していただいても構いません。 よろしくお願いします。 BR アリス Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは@justdomyself ご返信ありがとうございます。 申し訳ありませんが、 20個のMOSI出力でDACを駆動するMCXN947のサンプルはご用意しておりません。利用可能なFlexIOの例は主に標準的なSPIインターフェースをエミュレートするよう設計されています。 あなたのアプリケーションでは、ご自身の特定の要件に基づいたカスタムFlexIOドライバを開発する必要があるでしょう。 以下の例を参考にしてください。 AN14175: FlexIOを使ってQuad SPIコントローラをエミュレートする方法 |NXP Semiconductors よろしくお願いします。 BR アリス
記事全体を表示
MC9S08QG8 I DOWNLOADED CodeWarrior(classic IDE)v6.3 ,  I can not get it to install. I using windows 11.  how do i get a compiler for mc9s08qg8 !!!! Re: MC9S08QG8 Hello, CodeWarrior v6.3 is not compatible with windows 11; To use CodeWarrior in windows 11 please update to v11.1, I look for the MC9S08QG8 device and is available in this version to use the compiler. You can download from this link: CodeWarrior® for MCUs (Eclipse IDE)        11.1 Best Regards, Luis
記事全体を表示