求助关于RT1052显示旋转问题 因为购买的屏幕是竖屏，而我需要横屏显示。我使用的是guiguider生成RT1052的基础显示代码 并且添加软件旋转 disp_drv.sw_rotate = 1; disp_drv.rotated = 1;   设置成单缓冲 SDK_ALIGN( __attribute__((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[1][DEMO_FB_SIZE], DEMO_FB_ALIGN); SDK_ALIGN( __attribute__((section("lvglDisplayBuffer"))) static uint8_t s_lvglBuffer[DEMO_DB_SIZE], DEMO_FB_ALIGN); 屏幕能够正常显示，但是刷新速度太慢，不符合我的需求。   设置成双缓冲 SDK_ALIGN( __attribute__((section("lvglDisplayBuffer"))) static uint8_t s_frameBuffer[2][DEMO_FB_SIZE], DEMO_FB_ALIGN); 只有背光亮，屏幕黑屏。 这是为什么？   #if FB_USE_SRAM static void DEMO_WaitVsync(lv_disp_drv_t *disp_drv) { s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) != pdTRUE) { PRINTF("Display flush failed\r\n"); assert(0); } #else while (s_framePending) { } #endif } static void copy_area(const lv_area_t *area, lv_color_t *color_p, uint8_t *fb, uint32_t fbStrideBytes) { uint32_t y; uint32_t areaWidth = lv_area_get_width(area); fb += (area->y1 * fbStrideBytes + area->x1 * sizeof(lv_color_t)); for (y = area->y1; y <= area->y2; y++) { lv_memcpy(fb, color_p, areaWidth * sizeof(lv_color_t)); fb += fbStrideBytes; color_p += areaWidth; } } static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { /* Wait VSYNC for each small update. */ DEMO_WaitVsync(disp_drv); /* Copy data from draw buffer to frame buffer. */ copy_area(area, color_p, (uint8_t*) s_frameBuffer, LCD_WIDTH * LCD_FB_BYTE_PER_PIXEL); SCB_CleanInvalidateDCache(); lv_disp_flush_ready(disp_drv); } #else static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { // DCACHE_CleanByRange((uint32_t)color_p, DEMO_FB_SIZE); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; #if defined(SDK_OS_FREE_RTOS) if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } #else while (s_framePending) { } /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); #endif } #endif i.MXRT 105x Re: 求助关于RT1052显示旋转问题 Hi @dsd , 感谢您的问题！ 首先，请检查以下LVGL的限制，启用了full_refresh=1时，不支持屏幕旋转。请参考： 1. https://github.com/lvgl/lvgl/issues/4060 2. https://forum.lvgl.io/t/why-cannot-rotate-a-full-refreshed-display/10490/3   另外，RT1050有硬件pxp支持旋转，这是更推荐的方案，请参考：https://docs.nxp.com/bundle/GUIGUIDERUG-1.6.1/page/topics/rotate_screen_and_widgets.html 以及SDK中的PXP旋转相关demo。   Best regards, Gavin Re: 求助关于RT1052显示旋转问题 Helllo, 在使用 NXP i.MX RT1052 结合 Guiguider (LVGL) 进行屏幕旋转开发时，你遇到的“单缓冲刷新慢、双缓冲黑屏”问题，核心原因在于软件旋转（Software Rotate）与硬件 ELCDIF 控制器、双缓冲切换机制以及内存地址索引没有适配好。 Best Regards Re: 求助关于RT1052显示旋转问题 非常感谢，pxp旋转确实可行，完美解决问题

RT1064 在线升级计划 下图是我们产品的硬件扩展示意图： 1. PC 和主板通过 TCP 连接。 2.主板通过四条SPI总线与四个子板连接，各子板的功能相同。 3.主板上的UART4可以通过串口切换芯片切换到4个子板的UART1。 foreverwlh2025_0-1789970732170.png 由于项目需要， PC需要通过TCP升级四块RT1064子板的固件程序。基于硬件扩展情况，能否提供最简单的子板固件升级方案（考虑到上位机开发、主板开发和子板开发的工作量）？ i.MX RT106x Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 ， 谢谢你的提问。 推荐方法 PC通过TCP协议与主板通信。主板充当 TCP 服务器，并实现 UART 透明桥接。主板上的 UART4 通过串行切换芯片路由到所选子板的 UART1 接口。子板运行 RT1064 ROM 引导加载程序，因此子板端不需要额外的引导加载程序或固件开发。 单个子板的逐步升级流程： 对子板 N 施加 RESET 信号；设置 BOOT_MODE[1:0] = 01（串行下载器模式） 将串口切换芯片切换为连接 UART4 和子板 N 的 UART1。 释放 RESET 按钮——子板 N 进入 RT1064 ROM 引导加载程序并等待 UART 命令。 启用 TCP↔UART4 字节转发 切换 RESET 开关并将 BOOT_MODE 恢复为正常模式——子板 N 将使用新固件启动。 将串行选择器切换到下一个子板并重复上述步骤。 硬件先决条件 请在实施前确认以下硬件条件已具备： 主板对每个子板的BOOT_MODE[1:0]引脚具有独立的 GPIO 控制。 主板对每个子板的RESET引脚具有独立的 GPIO 控制。 该串行切换芯片可通过主板GPIO控制，并支持在所有4个子板之间进行切换。 如有任何疑问或想进一步讨论实施细节，请随时联系我们。 Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 ， 以下是针对您的固件升级场景推荐的解决方案概要。 1. 电脑工具 在 PC 端，我们提供了blhost——一个开源的命令行客户端，它实现了 NXP 的 MCU 引导加载程序私有帧协议（BSD/MIT 许可证）。设备端协议由MCU片上ROM引导加载程序实现。它们共同实现了固件下载和设备配置。 该工具支持 USB 和 UART1，不支持 TCP。 开源仓库： https://github.com/nxp-mcuxpresso/spsdk blhost 和 ROM 引导加载程序使用专有的帧数据包协议进行通信，请参阅： MCU 引导加载程序 v2.5.0 参考手册 (MCUBOOTRM) 对于固件映像的生成和打包，请使用 NXP 的SPSDK（安全配置 SDK）中包含的nxpimage工具。 2. 推荐方案：通过主板实现 TCP 透明转发 对于你的场景（PC→主板→子板），最省力的方法是让主板充当透明的 TCP 到 UART 桥接器，只需对 blhost 进行少量修改，将串行数据封装在 TCP 中即可： 建筑学： PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) 关键修改点： 修改 blhost 传输层：在 blhost 源代码中添加一个新的 TCP 传输模块。现有的UART字节流（帧数据包）在发送路径上直接封装成TCP数据包，在接收路径上解封装。 主板实现了一个 TCP 服务器：从 PC 接收 TCP 数据，通过 UART1 将有效载荷逐字节地转发到子板；子板的响应以同样透明的方式通过 TCP 转发回 PC。 子板无需任何更改：子板 MCU 只需处于 ISP 模式，ROM 引导加载程序正在运行，等待标准 UART 命令即可。 Re: RT1064 Online Upgrade Plan 4.启用TCP↔UART4字节转发 -----请问，数据传输的这一步骤是否需要额外开发一台上位计算机？例如，PC应该以什么格式传输图像数据？它应该如何解析子板返回的响应数据？以及它应该如何与子板交互？

ヒューズを焼損させずにHABをテストする 私はIMXRT1024コアの開発に取り組んでおり、ヒューズを焼損させることなくHABをテストしたいと考えています。データシートによると、すべてのヒューズにはシャドウレジスタがあり、CPU/ROMはそのシャドウレジスタから読み取られます。 シャドウレジスタを書き込み、ブートROMがボードがHAB対応であると認識するようなシナリオを作成することを考えています。しかし、ブートROMの実行はまだ初期段階なので、シャドウレジスタを活用してテスト環境を作る方法を教えてもらえますか? Q.2 -> もし閉鎖されたボードでHAB認証が失敗した場合、監査報告書はどうやって入手できますか? Re: Testing HAB without burning fuses こんにちは、 @Abhay2080。 この スレッドでのカン・リーの回答を参照してください。ヒューズをプログラムせずにHABをテストするためのいくつかの方法について説明しています。 2つ目のご質問についてですが、セキュアプロビジョニングツールのご利用を強くお勧めします。HAB対応イメージの作成プロセスが大幅に簡素化されます。このツールは自動的にCSFを生成し、画像を準備してHABが起動シーケンス中に正しく認証できるようにするため、このようなアプリケーションを扱う標準的なツールとなっています。認証済み (HAB)イメージの起動 手順に従うことができます。 ヒューズの焼きは一度しかできず、その後プロセッサは認証済み画像しか実行できないことを覚えておいてください。 BR ハビブ Re: Testing HAB without burning fuses ええ、カン・リーの回答は既に読みましたが、シャドウレジスターについては何も記載されていませんでした。そこで、私の質問は単純にシャドウレジスタを使ってテストすることが可能かどうかです。 監査ログについては、記録目的でのみ必要です。SPTを適切に使用すれば、HABをうまく生成できると理解しています。 Re: Testing HAB without burning fuses こんにちは、 @Abhay2080 さん。 Kan Li氏が推奨する方法に従ってください。HAB認証は、デバイスがOpenセキュリティ構成中であっても実施されます。これはRMの第9.3.6章「ブートセキュリティ設定」に記載されています。したがって、ROMブート時に生成されたHABイベントログを確認し、HAB認証プロセスが正しく実行されているかを確認することも可能です。 シャドウレジスタの主な目的は、RMの図23-1「OCOTPシステムレベルブロック図」に示されているように、デバイスがロードするOTPヒューズ値をソフトウェアでアクセス可能な表現を提供することです。 監査ログについてですが、あなたが言っているのは起動認証プロセス中にROMが生成するHABイベントログのことです。私の理解は正しいでしょうか？もしそうなら、この コミュニティ投稿 でGavin Jiaはこのログを観察する2つの方法を説明しています。特に、質問2への回答は顧客の問い合わせに直接答えています。 BR ハビブ

jailhouse DTS for 9x9 imx.93 こんにちは。9x9 imx.93版の「Jailhouse」のDTSファイルは提供していますか？11x11用のものしか見つかりません。 よろしくお願いします。 デビッド Re: jailhouse DTS for 9x9 imx.93 こんにちは、 このデバイスツリーは、次回のBSPリリースに含まれる予定です。 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2023 NXP */ /dts-v1/; #include / { model = "NXP i.MX93 9x9 QSB"; compatible = "fsl,imx93-9x9-qsb", "fsl,imx93"; interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>; aliases { mmc0 = &usdhc1; serial1 = &lpuart2; }; cpus { #address-cells = <1>; #size-cells = <0>; A55_0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a55"; reg = <0x0>; enable-method = "psci"; #cooling-cells = <2>; }; }; psci { compatible = "arm,psci-1.0"; method = "smc"; }; gic: interrupt-controller@48000000 { compatible = "arm,gic-v3"; reg = <0 0x48000000 0 0x10000>, <0 0x48040000 0 0xc0000>; #interrupt-cells = <3>; interrupt-controller; interrupts = ; interrupt-parent = <&gic>; }; timer { compatible = "arm,armv8-timer"; interrupts = , , , ; clock-frequency = <24000000>; }; clk_dummy: clock-dummy { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; clock-output-names = "clk_dummy"; }; clk_400m: clock-400m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <200000000>; clock-output-names = "200m"; }; osc_24m: clock-osc-24m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; clock-output-names = "osc_24m"; }; pci@fd700000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &gic GIC_SPI 227 IRQ_TYPE_EDGE_RISING>, <0 0 0 2 &gic GIC_SPI 228 IRQ_TYPE_EDGE_RISING>, <0 0 0 3 &gic GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, <0 0 0 4 &gic GIC_SPI 230 IRQ_TYPE_EDGE_RISING>; reg = <0x0 0xfd700000 0x0 0x100000>; ranges = <0x02000000 0x00 0x10000000 0x0 0x10000000 0x00 0x10000>; }; soc@0 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x0 0x0 0x80000000>, <0x28000000 0x0 0x28000000 0x10000000>; aips1: bus@44000000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x44000000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; lpuart2: serial@44390000 { compatible = "fsl,imx93-lpuart", "fsl,imx8ulp-lpuart", "fsl,imx7ulp-lpuart"; reg = <0x44390000 0x1000>; interrupts = ; status = "disabled"; }; }; aips3: bus@42800000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x42800000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; usdhc1: mmc@42850000 { compatible = "fsl,imx93-usdhc", "fsl,imx8mm-usdhc"; reg = <0x42850000 0x10000>; interrupts = ; fsl,tuning-start-tap = <20>; fsl,tuning-step= <2>; status = "disabled"; }; }; }; }; &lpuart2 { clocks = <&osc_24m>; clock-names = "ipg"; status = "okay"; }; &usdhc1 { clocks = <&clk_dummy>, <&clk_dummy>, <&clk_400m>; clock-names = "ipg", "ahb", "per"; bus-width = <8>; non-removable; status = "okay"; }; よろしくお願いいたします。 Re: jailhouse DTS for 9x9 imx.93 9x9 用の qsb jailhouse に対応するルートセル設定ファイルもお持ちですか？ ありがとう

TJA1103の正誤表 TJA1103の正誤表はありますか？ Re: Errata document for TJA1103 こんにちは、ナウモワさん 良い一日！ はい、訂正書はありますが、それはセキュアファイルとして分類されています。したがって、アクセスするには当事務所とNDAに署名する必要があります。 公式ウェブサイトを訪問し、「サポート」セクションから「サポートチケット」を選択してください。そこでCASEを開いてアクセスを申請でき、適切なチームに案内されます。 ご迷惑をおかけして申し訳ありません。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。

NXP Config Tools 26.06 for i.MX 无法加载已保存的配置 你好， 在评估 i.MX95 的新版 DDR 配置时，我发现配置工具中似乎存在一个错误。 以下是我具体的操作步骤，以便可以重现该问题： 1. 安装了该工具的Linux版本。 2. 创建了一个新配置。 3. 选定处理器 MIMX9596xxxxN。 4. 将预设更改为“LPDDR4X EVK / FRDM 15x15 4000MTs 配置”。 5. 保存配置，然后关闭工具。 6. 重新打开工具并加载已保存的配置。 此时根本不显示DDR配置信息。 至少 26.03 版本启动时 MCU 未被选中（手动选择即可解决问题），现在这个问题无法解决。 非常感谢您的帮助。 此致， 埃马努埃莱 Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 该工具的 Windows 版本也存在同样的问题。 附图。 Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 你好， 感谢您报告该工具的这个漏洞。 我能看出我这边的问题所在。 我会将此事上报给内部团队，以便尽快解决。 顺祝商祺！ Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 是否有更新或变通方法？它根本无法使用。 Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 我刚刚安装并测试了 26.09 版本。按照 Emanuele 列出的步骤进行操作，但针对的是 MIMX9529xxxxx。 错误行为相同，无法加载先前创建的配置文件。 已在 Ubuntu 24.04 上测试。 顺祝商祺！

[i.MX8MQ] MIPI-DSI SSC（スペクトラム拡散クロッキング）はデフォルトで有効になっていますか、それとも無効になっていますか？ こんにちは、 i.MX8MQプラットフォーム上で、MIPI-DSI SSCのデフォルト設定が何なのか確認したいのですが、オンかオフか? Re: [i.MX8MQ] Is MIPI-DSI SSC (Spread Spectrum Clocking) enabled or disabled by default? こんにちは、 当社のテスト環境では、SSCは無効（OFF）になっています。 有効(ON) CASEがテストされたかどうかは不明です。 以下の議論が参考になるかもしれません。 https://community.nxp.com/t5/i-MX-Processors/iMX8M-Mini-Spread-Spectrum/mp/1024187 . よろしくお願いします。

NXP Config Tools 26.06 for i.MX not loading saved configuration Hello, While evaluating the new version of the DDR configuration for the i.MX95, I came across what looks like a bug in the configuration tool. Here is exactly what I did, so the behavior can be reproduced: 1. Installed the Linux version of the tool. 2. Created a new configuration. 3. Selected processor MIMX9596xxxxN. 4. Changed the preset to "LPDDR4X EVK / FRDM 15x15 4000MTs Configuration". 5. Saved the configuration, then closed the tool. 6. Reopened the tool and loaded the saved configuration. At that point the DDR configuration is not displayed at all. At least the 26.03 version was starting with MCU unselected (selecting it manually solves the problem), now there is no way to solve the problem. Thank you very much for your help. Best regards, Emanuele Re: NXP Config Tools 26.06 for i.MX not loading saved configuration Also the windows version of the tool shows the same problem. Attached screenshots. Re: NXP Config Tools 26.06 for i.MX not loading saved configuration Hello, Thank you for report this bug in the tool. I was able to see the issue on my side. I will report it with internal team to solve it as soon as possible. Best regards. Re: NXP Config Tools 26.06 for i.MX not loading saved configuration Is there an update or a workaround? It is impossible to use it Re: NXP Config Tools 26.06 for i.MX not loading saved configuration I've just installed and tested version 26.09. Followed the same steps that Emanuele listed but for MIMX9529xxxxx. The incorrect behavior is the same, impossible to load previously created config files. Tested on Ubuntu 24.04. Best regards,

监狱 DTS 适用于 9x9 imx.93 您好 - 请问你们提供适用于 9x9 imx.93 的 jailhouse 的 DTS 文件吗？我只能找到11x11尺寸的。 谢谢！ 大卫 Re: jailhouse DTS for 9x9 imx.93 你好， 该设备树将包含在下一个 电路板支持包。 版本中。 // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2023 NXP */ /dts-v1/; #include / { model = "NXP i.MX93 9x9 QSB"; compatible = "fsl,imx93-9x9-qsb", "fsl,imx93"; interrupt-parent = <&gic>; #address-cells = <2>; #size-cells = <2>; aliases { mmc0 = &usdhc1; serial1 = &lpuart2; }; cpus { #address-cells = <1>; #size-cells = <0>; A55_0: cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a55"; reg = <0x0>; enable-method = "psci"; #cooling-cells = <2>; }; }; psci { compatible = "arm,psci-1.0"; method = "smc"; }; gic: interrupt-controller@48000000 { compatible = "arm,gic-v3"; reg = <0 0x48000000 0 0x10000>, <0 0x48040000 0 0xc0000>; #interrupt-cells = <3>; interrupt-controller; interrupts = ; interrupt-parent = <&gic>; }; timer { compatible = "arm,armv8-timer"; interrupts = , , , ; clock-frequency = <24000000>; }; clk_dummy: clock-dummy { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; clock-output-names = "clk_dummy"; }; clk_400m: clock-400m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <200000000>; clock-output-names = "200m"; }; osc_24m: clock-osc-24m { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <24000000>; clock-output-names = "osc_24m"; }; pci@fd700000 { compatible = "pci-host-ecam-generic"; device_type = "pci"; bus-range = <0 0>; #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &gic GIC_SPI 227 IRQ_TYPE_EDGE_RISING>, <0 0 0 2 &gic GIC_SPI 228 IRQ_TYPE_EDGE_RISING>, <0 0 0 3 &gic GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, <0 0 0 4 &gic GIC_SPI 230 IRQ_TYPE_EDGE_RISING>; reg = <0x0 0xfd700000 0x0 0x100000>; ranges = <0x02000000 0x00 0x10000000 0x0 0x10000000 0x00 0x10000>; }; soc@0 { compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0x0 0x0 0x80000000>, <0x28000000 0x0 0x28000000 0x10000000>; aips1: bus@44000000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x44000000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; lpuart2: serial@44390000 { compatible = "fsl,imx93-lpuart", "fsl,imx8ulp-lpuart", "fsl,imx7ulp-lpuart"; reg = <0x44390000 0x1000>; interrupts = ; status = "disabled"; }; }; aips3: bus@42800000 { compatible = "fsl,aips-bus", "simple-bus"; reg = <0x42800000 0x800000>; #address-cells = <1>; #size-cells = <1>; ranges; usdhc1: mmc@42850000 { compatible = "fsl,imx93-usdhc", "fsl,imx8mm-usdhc"; reg = <0x42850000 0x10000>; interrupts = ; fsl,tuning-start-tap = <20>; fsl,tuning-step= <2>; status = "disabled"; }; }; }; }; &lpuart2 { clocks = <&osc_24m>; clock-names = "ipg"; status = "okay"; }; &usdhc1 { clocks = <&clk_dummy>, <&clk_dummy>, <&clk_400m>; clock-names = "ipg", "ahb", "per"; bus-width = <8>; non-removable; status = "okay"; }; 顺祝商祺！ Re: jailhouse DTS for 9x9 imx.93 您是否也有适用于 9x9 上 qsb jailhouse 的匹配根单元配置文件？ 谢谢

i.MX8DXL CAAM COVER 对 P-384 私钥/黑斑用例的限制 您好，NXP团队： 我们正在评估 i.MX8DXL CAAM 对 ECDSA P-384 黑键/blob 的支持情况。 观察到的结果 P-256 从外部提供的明文 P-256 私钥开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（CAAM 生成的黑键） 生成 ECDSA 私钥，颜色为 KEY_COLOR_BLACK 无需 COVER 操作即可从私钥生成黑块 从黑斑中恢复黑键 ECDSA 签名/核实 结果：通过 P-384（外部明文私钥） 从外部提供的明文 P-384 私钥（48 字节）开始： 明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：失败 补充观察 我们在NXP的补丁中注意到以下注释： https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEY 命令似乎限制为 32 字节，因此我们应该使用加载方式。 * 改为使用最多可加载 64 字节的命令。 * * TODO：KEY 命令表明它应该能够加载更大的密钥。 * 小于 32 字节，但实际上行不通 * * TODO：LOAD 命令表明它应该能够加载最多 96 个文件 * 字节键在实践中不起作用，并且限制为 64 字节。 */ 我们观察到了类似的行为。 使用 LOAD 命令而不是 KEY 命令，我们可以处理大于 32 字节的密钥，包括 48 字节的 P-384 私钥。 然而，这并不能解决上述问题。虽然可以将密钥覆盖并存储在一个块状物中，但恢复后的黑密钥不能成功用于 ECDSA 签名/验证。   我们的疑问： CAAM COVER 操作对于大于 32 字节的 ECC 私钥是否存在任何已知限制？ 通过 COVER 导入外部 P-384 明文私钥，然后将其用作 ECDSA 黑密钥，这是否是支持的用例？ 观察到的这种现象是否是由于 CAAM 硬件限制造成的？ 是否有推荐的 CAAM 方法可以导入外部生成的 P-384 明文私钥并将其用作 ECDSA 操作的黑密钥？ 任何指导都将不胜感激。 谢谢，并致以最诚挚的问候！ 霍詹姆斯。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 补充说明：   我们关注的重点不仅限于 ECDSA 用例。   即使通过 COVER 导入外部 P-384 私钥不是 ECDSA 支持的工作流程，我们仍然想了解 COVER 操作本身的局限性。   在我们的应用中，COVER 操作不仅可以用于保护 ECDSA 私钥，还可以用于保护一般敏感数据。因此，支持大于 32 字节的有效载荷大小是一个重要的考虑因素。 根据我们的测试，使用 LOAD 命令变通方法可以处理大于 32 字节的有效载荷。小于约 80 字节的有效载荷似乎可以正常工作，而更大的有效载荷则表现出不稳定的行为。我们想了解这些观察结果反映的是 CAAM 的实际局限性还是实施问题。 NXP能否也澄清一下，COVER 操作本身是否存在任何已记录的大小限制，而与 ECDSA 用例无关？   谢谢！ Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 我们需要搭建测试CAAM功能的环境。一旦有了结果，我们会立即通知您。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 王一平您好， 谢谢回复。 >>对于这一部分，您观察到了什么CAAM错误？ >>请提供错误代码？ 我们对所有与 ECDSA 相关的操作都使用以下代码补丁： " https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch " 当调用 caam_ecdsa_verify() 进行签名验证时， 它返回“ECDSA_VERIFY_FAIL (0)”。 仅当使用“P-384（外部明文私钥）”时才会出现错误。 >> 应用笔记“AN12838-使用 CAAM 安全密钥加强公钥密码学”描述了使用黑密钥的 ECDSA 签名演示，您是否正在使用类似的实现进行测试？ 对于我们成功的案例，是的，它们很相似。 但对于我们失败的案例“P-384（外部明文私钥）”， 情况略有不同：密钥来自外部。 顺祝商祺！ Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case “明文密钥 → 封面 → 黑键斑点 从黑斑中恢复黑键 ECDSA 签名/核实 结果：失败 在这一部分，你观察到了什么CAAM错误？能否提供错误代码？应用笔记“AN12838-使用 CAAM 安全密钥加强公钥密码学”描述了使用黑密钥的 ECDSA 签名演示，您是否正在使用类似的实现进行测试？谢谢。 关于KEY命令的限制，目前仍在调查中。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 对于失败的案例，您是否使用“KEY”命令和“FIFO STORE”命令根据明文私钥生成黑密钥？您能否提供故障案例中使用的 CAAM 描述符（十六进制单词）？检查命令和参数会更容易些。谢谢。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 王一平您好， >>对于失败的案例， >>您是否使用了“KEY”命令和“FIFO STORE”命令？ >>如何根据明文私钥生成黑密钥？ 不，我们使用的是 LOAD 命令而不是 KEY 命令。 在这种情况下，密钥为 48 字节 (P384)。 如 < https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch > 中所述 “KEY 命令似乎限制为 32 字节，因此我们应该使用加载 * 改为使用最多可加载 64 字节的命令。 如果使用 KEY 命令输入 48 字节的密钥，则会报告 DECO 错误： 作业环状态：0x40000106 DECO，06h - 无效的 KEY 命令 因此，我们修改了代码，使其使用与上述补丁代码相同的 LOAD 命令。 谢谢，并致以最诚挚的问候！

PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 Hi, The board I am testing is MTRCKTSPS5744P (3-Phase PMSM Motor Control Development Kit with MPC5744P MCU). For some reason, the download process doesn't go well. This window pops up after failure in downloading when I click debug button. eunwoo_lee_0-1789496057004.png An window pops up showing this error message. Error in services launch sequence PEmicro GDB Launch Failure : The GDB Server was not able to establish a connection to the target processor. Please check your connections and power. Verify that the launch settings in the Debug Configuration are accurate. Console panel displays this message. Connection from "127.0.0.1" via 127.0.0.1. Connection from port "53438" to 7224 PE-ERROR: Warning. Can't read registers while part is running. PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read registers while part is running. PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't read memory while part is running. @0 (4 bytes) PE-ERROR: Warning. Can't Write Binary while part is running. 40001000 - Length of: 0 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001000 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001460 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 400018c0 - Length of: 460 - Value of: Binary Data PE-ERROR: Warning. Can't Write Binary while part is running. 40001d20 - Length of: 2e0 - Value of: Binary Data PE-ERROR: GDB Client Processing : Exception Occured : PROGRAM EXCEPTION! EXCEPTION CLASS: EIDCONNCLOSEDGRACEFULLY MESSAGE: CONNECTION CLOSED GRACEFULLY. ADDRESS 0X0046EA89 Disconnected from "127.0.0.1" via 127.0.0.1. Disconnection by port "53438" from 7224 Target Disconnected. Is there any solution you know for this problem? Thanks. Re: PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 Hello, Is there any solution you know for this problem? As the message explains you cannot write/read registers on the fly. First stop the execution of the code in debugger and then you can modify the registers, memory, etc... The MPC5744P is running user code and the P&E probe is unable to halt the device, therefore all memory/register accesses fail and the download operation aborts. This looks less like a flash programming problem and more like a debugger failing to halt the MPC5744P before download. Is there for example SW with SWT0 enabled in the microcontroller? Or is it a fresh sample with no SW running? Best regards, Peter Re: PEmicro GDB Launch Failure in S32 Design Studio for Power Architecture v2.1 I solved this problem by replacing the flat ribbon cable. Although the cable seems good in terms of connection, it fails to connect the debugger. I guess the cable is susceptible to crosstalk or line-to-line noise. I ended up making it work by creating shorter cable.

i.MX 95：M7 和 A55 之间的动态 TRDC/系统管理器资源分配和 GPIO 共享 大家好， 我们正在开发i.MX 95 平台，希望最初使用 M7 内核的 MIPI DSI 外设，然后在运行时将资源移交给 A55 内核。 据我们了解，外围资源及其所有权最初是 在 通过 系统管理器工具 生成/配置的 mx95evk.cfg 文件中为每个逻辑机器/处理器定义的。 我们想澄清以下几点： 动态资源交接： 是否可以在运行时将 MIPI DSI 外设资源从 M7 动态转移到 A55？例如，M7 最初拥有并使用 MIPI DSI，然后释放该资源，之后 A55 接管并使用同一外设。 动态资源分配： 如果支持运行时交接，那么动态更改资源所有权或访问权限的推荐机制/API是什么？这是通过系统管理器、TRDC还是其他机制处理的？ GPIO共享： M7 和 A55 是否可以同时访问同一个 GPIO 端口/资源？如果可以，为了安全地共享 GPIO 资源，是否需要进行任何 TRDC 配置或实施任何软件同步机制？ 我们非常希望得到关于在 i.MX 95 上实现M7 和 A55 之间的动态外围设备切换和/或资源共享的推荐方法的任何指导。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 你好， 在 i.MX 95 上，MIPI DSI 资源最初可由 M7 使用，之后移交给 A55。资源访问和所有权应通过系统管理器/TRDC 配置进行配置，而实际的运行时交接应由软件处理。TRDC 控制哪些逻辑机器/功能域可以访问外围设备，但它不管理 M7 和 A55 之间的同步。因此，M7 应先完成所有 DSI 操作，停止使用外围设备，并通过 MU/IPC 等核心间机制通知 A55，然后 A55 才能接管控制权。同样，通过适当的 TRDC 配置，可以使 GPIO 资源同时供 M7 和 A55 访问，但同时访问必须通过软件进行同步。对于 DSI 用例，建议的方法是每次只让一个核心积极使用外围设备，并使用 MU/IPC 进行切换。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 我已与AE团队讨论过，请参考以下更新。 在 i.MX 95 上，资源所有权和 TRDC 权限是在构建时静态地在 SM 配置 (mx95evk.cfg) 中定义的。→ 生成的config_.h 文件，并在 MIX 设备上电时由系统管理器 (SM) 应用。*运行时，没有 SCMI/SM 消息可以将外围设备的所有权从一个逻辑机 (LM) 转移到另一个逻辑机。 然而，SM 文档将“将显示屏从一个 LM 移交给另一个 LM”列为 SM_SCMI_PERM_EXCLUSIVE 模型的确切动机用例。所以交接是可以实现的，只是不能通过“转移”所有权来实现。 Q1 & Q2 — MIPI DSI M7 → A55 交接：如何操作 LMM（逻辑机器管理）SCMI 协议仅启动/重置/关闭/挂起/唤醒 LM——它没有 RESOURCE_ASSIGN 或 OWNERSHIP_TRANSFER 消息。请改用时分交接： 在 mx95evk.cfg 中预先授予 BOTH LMs 访问权限。默认情况下，EVK 配置仅将 MIPI_DSI、MIPI_PHY、DC_DISPENG、BLK_CTRL_DISPLAYMIX、显示时钟/电源（PD_DISPLAY、CLK_DISP*）分配给 AP（LM2）的所有者——您还必须将它们添加到 M7 LM（LM1）以允许 M7 优先使用。 将 SM 管理的资源（时钟、电源、RESET）标记为 SM_SCMI_PERM_EXCLUSIVE（api=all），这样来自两个 LM 的请求就不会被静默聚合/覆盖。 在切换时， M7 使 DSI/DCIF 静默，然后通过应用层 IPC（MU 邮箱或 SCMI 通知）向 A55 发出信号。A55（Linux/DRM DSI+DPU 协议栈）随后启动相同的 IP。 交接顺序是客户软件的责任（时间划分）。SM 仅保证 HW 可以从两侧驾驶，因为两个 LM 都已预先获得访问权限。TRDC 所有权不能在运行时重写——只有 SM 可以对 TRDC 进行编程，并且只能从 MIX 上电时的静态配置进行编程。 控制此功能的 TRDC 配置（在 .cfg 文件中定义）： MDAC_am=… — 主功能域分配（将总线主控映射到功能域 ID） MBC_am=s.b— 内存块检查 —这是限制外围设备访问的地方。 MRC_am=… — 内存区域检查（大型内存区域，例如 DDR） 每个LM都绑定到一个DID，例如：SM did=2，AP(LM2) did=3，M7(LM1) did=4。 Q3 — M7 和 A55 之间共享 GPIO 是的，TRDC 可以同时授予 M7 功能域和 A55 功能域对同一 GPIO 实例的并发访问（为两个 DID 启用其 MBC 块）。但需要注意一个关键问题，并且有两种支持的模式： 注意： i.MX 95 GPIO没有硬件仲裁——PDR/DR/GDIR 寄存器是物理共享的，因此来自两个核心的非协调读-修改-写操作会相互竞争。 模式 A（不相交引脚 + SW 同步）：按照约定为每个内核分配特定引脚（配置已按 LM 分割引脚）。由于数据/方向寄存器组仍然是共享的，因此需要使用硬件信号量/MU来保护并发 RMW，或者确保内核永远不会同时访问同一个寄存器组。 模式 B（SM 仲裁，推荐用于真正共享的实例）：通过始终开启的GPIO1进行路由，该 GPIO1 由 SM 拥有，其记录的角色是“仲裁共享访问”。IOMUXC/IOMUX_GPR 同样由 SM 仲裁。Pinmux/daisy 通过 SCMI 引脚控制协议进行设置，并具有每个代理的权限；GPIO数据操作是直接 MMIO。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 大家好， 我们正在与一家公司合作 i.MX 95 19x19 EVK 并且正在尝试在以下两者之间实现 LVDS 显示切换： M7 和 A55/Linux ，预期架构如下： M7： 最初拥有并驱动LVDS显示器。 A55/Linux： Linux 启动后，它随后接管显示控制权。 当前实施情况 作为开发的初始阶段，我们已将 LVDS 显示器配置为由 M7 进行初始化和控制。M7 成功初始化显示器，并将帧缓冲区填充为蓝色，并在 LVDS 面板上正确显示。 我们将以下资源的默认所有权从 A55 更改为 M7 所有权，同时提供 A55 的通行权： DC DC0 DC1 DC_CMDSEQ DC_DISPENG DC_DISPENG_INT DC_FL0 DC_FL1 DC_INT_CTL DC_PIXENGINE DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 BLK_CTRL_DISPLAYMIX LVDS MIPI_PHY LDB_PLL CLOCK_DISP1PIX 视频_PLL1 PIN_I2C2_SCL PIN_I2C2_SDA LPI2C2 观察到的行为 目前的行为情况如下： M7 启动并成功初始化显示屏。 蓝色填充的帧缓冲区在 LVDS 面板上正确显示。 M7 运行时，显示屏始终可见。 然后A55/Linux启动过程开始。 Linux内核启动后，显示屏会变黑。 使用以下设备树时：fdtfile imx95-19x19-evk-it6263-lvds1.dtbLinux 在内核启动过程中总是停止运行。 我们没有观察到明显的内核崩溃，也没有在控制台上看到清晰的错误信息。启动过程突然停止。 资源所有权调查 根据我们的理解，资源所有权是通过以下方式静态配置的： 系统管理器配置和所有权不能通过 SCMI 消息在逻辑机器之间动态转移。 因此，我们研究了是否可以将显示资源分配给 M7 和 A55。 然而，一些关键的数据中心资源似乎不支持双重所有权，特别是： DC DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 DC_FL0 DC_FL1 DC_2DBLIT 这表明，Linux 可能正在尝试访问 M7 在其 DRM/DPU 或 IT6263/LVDS 初始化期间独占的一个或多个显示资源。 问题 请问您能否帮我们澄清以下问题？ 1. 如果资源（例如……）过多，Linux 系统是否会预期会挂起？ 华盛顿特区 DC_XPC ， DC_YUV* ， DC_FL* ，或 DC_2DBLIT 是否为M7独家所有？   2. 在 Linux 启动期间以及 DRM/DPU 和 IT6263/LVDS 初始化期间，A55/Linux 会访问哪些显示资源？ 我们尤其想了解以下用户访问的具体资源： Linux DRM/DPU 显示控制器（直流） IT6263驱动程序 LVDS/LDB驱动器 显示时钟/PLL 配置 3. 是否存在受支持的系统管理器资源所有权配置，允许执行以下顺序？ M7 初始化并驱动 LVDS 显示器。 A55/Linux 系统正常启动。 随后 A55/Linux 接管显示控制权。 两台逻辑机都可以访问交接所需的资源。 4. 如果 M7 和 A55 之间不能共享 DC 资源，那么 M7 显示和 A55/Linux 共存或显示切换的推荐架构是什么？   5. 即使 Linux 不打算在启动的初始阶段主动驱动显示器，A55/Linux 是否也需要拥有完整的 DC 资源层次结构？   6. 对于此用例，以下方面是否需要进行任何额外的配置更改？ 系统管理器资源配置 TRDC权限 SCMI 配置 Linux 设备树 显示/LVDS配置 7. Linux 启动挂起是否可能是由于 A55/Linux 尝试访问 M7 拥有的显示资源，尤其是在初始化 IT6263/LVDS 显示路径期间？     我们现阶段的主要目标是确定 确定 Linux 在早期启动期间以及 DRM/DPU 和 IT6263/LVDS 初始化期间访问的确切显示资源，并确定这些资源是否可以与 M7 所有权共存。 我们已附上 系统管理器配置文件 (.cfg) 和 Linux 启动日志 供参考。 任何关于支持的资源所有权配置、显示资源依赖关系或推荐的实现架构的指导 M7/A55 LVDS 显示屏切换 非常感谢。   谢谢！  

在ubuntu上，如何使用mcuxpresso-secure-provisioning软件来固件加密加密并烧写到芯片 首先，我使用的芯片是 MCXN947。 我已经在我的Ubuntu系统中下载并安装了mcuxpresso-secure-provisioning-26.09-1_amd64-ubuntu26.deb软件包。 那么如何使用该软件生成已签名和加密的sb格式文件呢？ 我已经观看了视频，对 bin 文件进行了签名和加密，并在 Windows 系统中成功地将 sb 文件写入了芯片。 Ubuntu系统上有视频操作软件吗？是否有关于签名和加密bin文件的命令行的相关文档？ 谢谢！ Re: 在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 嗨@justdomyself 文档： https://docs.mcuxpresso.nxp.com/secure/latest/ 描述 MCXN 设备工作流程的章节： https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#n23x-n24x-n52x-n53x-n54x-n94x-device-workflow 命令行支持： https://docs.mcuxpresso.nxp.com/secure/latest/08_command_line_operations.html 另请参阅 securep.exe 打印 - cli - 示例 Ubuntu 和 Windows 上的用户体验非常相似。如果遇到任何问题，请参阅故障排除部分： https://docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html

MIMXRT700 EVK Battery Connection and External Power Up Clarification Hi Team, We are currently working on the MIMXRT700 EVK and need clarification regarding battery connection and external board power-up. We observed that the PMIC IC has a VBAT input, but we are unable to identify the exact connector/header on the EVK where a battery can be connected directly. Could you please help us with the following: Please point us to the official battery connector/header available on the RT700 EVK. Exact connector/header location on the board Supported battery type/specification Recommended connector/part number We would also like to understand the correct procedure to power up the RT700 EVK using an external power adapter while still supporting flashing and debugging. Currently, we are powering and debugging the board through the USB debug port. We want to know: What changes/setup are required when powering the board externally for battery and adapter Whether flashing and debugging through USB/J-Link will continue to work in this setup. Thanks & Regards, Suhas Evaluation Board Re: MIMXRT700 EVK Battery Connection and External Power Up Clarification Hi @suhas1503 , Thanks for your interest in NXP MIMXRT series! The PMIC supports battery power, but on the EVK, it is set to DNP by default. You can locate J37 on the schematic. A detailed description can be found in the “MIMXRT700-EVK Board User Manual[UM12188]”. Please take a look. Gavin_Jia_0-1779932324256.pngGavin_Jia_0-1779932324256.pngGavin_Jia_0-1779932324256.png Gavin_Jia_1-1779932333707.pngGavin_Jia_1-1779932333707.pngGavin_Jia_1-1779932333707.png For the RT700, there is no specific requirement regarding the choice of battery for the PMIC; you can select one based on the PCA9422 datasheet. In addition, the RT700-EVK supports powered by an external power adapter and supports a 5V power supply. It is connected via J45, and the power source is selected by shorting pins 1 and 2 on J2. The details is in “MIMXRT700-EVK Board User Manual[UM12188]” Section 2.2 . The on-board debugger continues to function normally when powered by an external power source. Best regards, Gavin Re: MIMXRT700 EVK Battery Connection and External Power Up Clarification Hi, I am using the MIMXRT700-EVK with a Murata 2EL M.2 module connected to the M.2 socket on the RT700-EVK. I am testing different examples from the MCUXpresso SDK. Hardware setup: - Board: MIMXRT700-EVK - M.2 module: Murata 2EL M.2 module - Murata 2EL module is connected to the M.2 socket - Power is supplied through JP37 using a battery - MCUXpresso SDK: SDK_26_03_00_MIMXRT700-EVK Observed behavior: When the RT700-EVK is powered through JP37 using a battery: 1. The hello_world example works correctly. 2. The xaf_record example works correctly. 3. The edgefast_bluetooth_examples/peripheral_ht example builds and flashes successfully, but the application fails during runtime initialization. The UART log is: BLE Peripheral HT demo start... [sdio] Error: Card initialization failed [wifi_io] Error: SDIO driver init failed. ASSERT ERROR " API_SUCCESS == result ": file "middleware/wireless/ethermind/port/pal/mcux/bluetooth/controller/controller_wifi_nxp.c" Line "120" However, when I use the same edgefast_bluetooth_examples/peripheral_ht example with the J54 USB debug port and J45 port with the adapter, the example works correctly. Therefore, the EdgeFast Bluetooth example works correctly with the J54/J45 configuration but fails when the board is powered through JP37 using a battery. The hello_world and xaf_record examples work correctly with the JP37 battery configuration. Expected behavior: I expect the edgefast_bluetooth_examples/peripheral_ht example to initialize the Bluetooth controller successfully when the RT700-EVK is powered through JP37 using a battery and the Murata 2EL M.2 module is connected. Questions: 1. Is the JP37 power configuration supported for running the EdgeFast Bluetooth examples with the Murata 2EL M.2 module? 2. Does the Murata 2EL M.2 module require any additional jumper, switch, or power configuration when JP37 is used with a battery? 3. Why does the application report the following errors when using the JP37 battery configuration? [sdio] Error: Card initialization failed [wifi_io] Error: SDIO driver init failed. 4. Is there any required power sequencing or M.2 power-enable configuration for the wireless module when using battery power through JP37? 5. Is there a recommended RT700-EVK jumper and power configuration for using the Murata 2EL M.2 module with the EdgeFast Bluetooth examples and battery power? Please let me know if you need any additional information, such as the complete UART log, jumper configuration, SDK configuration, schematic details, or power measurements. Thank you. Bluetooth Example Fails with SDIO/Wi-Fi Initialization Error When Powered by Battery Through JP37 Hi, I am using the MIMXRT700-EVK with a Murata 2EL M.2 module connected to the M.2 socket on the RT700-EVK. I am testing different examples from the MCUXpresso SDK. Hardware setup: - Board: MIMXRT700-EVK - M.2 module: Murata 2EL M.2 module - Murata 2EL module is connected to the M.2 socket - Power is supplied through JP37 using a battery - MCUXpresso SDK: SDK_26_03_00_MIMXRT700-EVK Observed behavior: When the RT700-EVK is powered through JP37 using a battery: 1. The hello_world example works correctly. 2. The xaf_record example works correctly. 3. The edgefast_bluetooth_examples/peripheral_ht example builds and flashes successfully, but the application fails during runtime initialization. The UART log is: BLE Peripheral HT demo start... [sdio] Error: Card initialization failed [wifi_io] Error: SDIO driver init failed. ASSERT ERROR " API_SUCCESS == result ": file "middleware/wireless/ethermind/port/pal/mcux/bluetooth/controller/controller_wifi_nxp.c" Line "120" However, when I use the same edgefast_bluetooth_examples/peripheral_ht example with the J54 USB debug port and J45 port with the adapter, the example works correctly. Therefore, the EdgeFast Bluetooth example works correctly with the J54/J45 configuration but fails when the board is powered through JP37 using a battery. The hello_world and xaf_record examples work correctly with the JP37 battery configuration. Expected behavior: I expect the edgefast_bluetooth_examples/peripheral_ht example to initialize the Bluetooth controller successfully when the RT700-EVK is powered through JP37 using a battery and the Murata 2EL M.2 module is connected. Questions: 1. Is the JP37 power configuration supported for running the EdgeFast Bluetooth examples with the Murata 2EL M.2 module? 2. Does the Murata 2EL M.2 module require any additional jumper, switch, or power configuration when JP37 is used with a battery? 3. Why does the application report the following errors when using the JP37 battery configuration? [sdio] Error: Card initialization failed [wifi_io] Error: SDIO driver init failed. 4. Is there any required power sequencing or M.2 power-enable configuration for the wireless module when using battery power through JP37? 5. Is there a recommended RT700-EVK jumper and power configuration for using the Murata 2EL M.2 module with the EdgeFast Bluetooth examples and battery power? Please let me know if you need any additional information, such as the complete UART log, jumper configuration, SDK configuration, schematic details, or power measurements. Thank you. Re: Bluetooth Example Fails with SDIO/Wi-Fi Initialization Error When Powered by Battery Through JP3 Hi @suhas1503 , I think the most likely reason is that the power required for the M.2 on the EVK comes from other components rather than VBAT. I suggest you take a look at the schematic. In particular, Sheet 5 and Sheet 6. In Sheet 5, identify all jumper caps similar to JP33 and switch them from SYS_5V0 to VBAT. In Sheet 6, identify all jumper caps similar to JP11 and switch them from PMIC to DCDC_3V3. The ultimate goal is to enable VBAT to power the corresponding modules. From what I’ve quickly glanced at, the key is to ensure that the power sources for MCU_3V3 and WL_3V3 are correctly configured. (If you have a new question, please feel free to submit a new ticket or post. Updates in closed threads are easily overlooked. Thank you for your understanding and cooperation!) Best regards, Gavin Re: Bluetooth Example Fails with SDIO/Wi-Fi Initialization Error When Powered by Battery Through JP3 Hi, I followed the jumper changes you suggested and tested the RT700-EVK with the battery supply. I changed the jumper settings as follows: JP33 → 2–3 JP34 → 2–3 JP36 → 2–3 JP11 → 2–3 JP7 → 2–3 I connected the 3.7 V, 500 mAh Li-Po battery to JP37. With these changes, the BLE Peripheral HT demo initialises successfully, and BLE starts advertising as expected. However, after running for some time, the RT700-EVK starts resetting continuously. After each reset, the application starts again, BLE initialises, and advertising starts again. So, the jumper changes have enabled the BLE functionality on battery power, but the continuous reset issue is still present. Could you please suggest what could be causing this repeated reset during battery-powered operation and what I should check next?

I.MX6ULLのENET1は物理からデータを受信できません I.M6ULL + 4.19.35 + KSZ 8081rnb  この機器は現場に300台配備されています。ほとんどの場合、それらは正常に稼働し、事業やサービスは期待どおりに機能します。しかしながら、時折、サービスにアクセスできなくなることがあります。調査の結果、eth1（ENET1）のLINK LEDは点灯したままで、ACT LEDが時々点滅しているにもかかわらず、eth1がパケットを受信しなくなることが確認されました。 さらに、ENET1のイーサネットケーブルを一度抜き差しすると、ネットワークが正常に戻ることも確認しました。デバイスを再起動することでも復元されます。根本原因の分析を手伝ってもらえますか?それはPHYにあるのかMACなのか? そこから読み取られるレジスタ値は以下のとおりです。 読み取るレジスタのリストには、MACレジスタとPHYレジスタの両方が含まれます。かなり長いため、次のページに掲載しています。 コマンド: phy eth1 0x1は PHY レジスタ 1 を読み取ります。 memtool i.MX6UL Linux Re: I.MX6ULL ENET1 can't recv data from phy こんにちは、@240697273 読み取るレジスタのリストには、MACレジスタとPHYレジスタの両方が含まれます。かなり長いため、次のページに掲載しています。 >>>これらのレジスターが見つからなかった。もう一度送ってください。 B、R

KW45B41Z EVKが搭載デバッガーMCUリンクでプログラムされていないこと。 こんにちは、 kw45b41zevk_hello_world SDKのサンプルコードを使ってKW45B41Z-EVKをプログラムしようとしています。デバッグを開始すると、オンボードデバッガーは検出されますが、その後、次のエラーが発生します。 検出された利用可能なSWDデバイスは0個です。 デバイスを接続して、もう一度お試しください。 USBケーブルは J14 に接続し、 JP22はオン ボードデバッガでプログラムするために開いたままにしています。また、 KW45UMで述べられているように、 JP28のピン1と2は短絡されています。しかし、その後もサンプルプログラムをプログラミングしたりデバッグしたりすることができません。 kw45b41zevk_led_blinky SDKの例も試しましたが、同じように動作します。 KW45UMで説明されているように、外部デバッガを使用してJP22をショートさせてボードのデバッグも試みましたが、同じ問題が発生します。 発生している問題のスクリーンショットを添付しました。 セキュアプロビジョニングツールを使用して、フラッシュメモリを消去してイメージを書き込むことも試しました。まず、 JP25をショートさせてSW4を有効にし、次にSW4とリセット（SW3）を長押ししてISPモードに入りました。接続テストが成功した後、フラッシュメモリ（位置0x00000000 、サイズ0x100000 ）の消去に成功しました。次に、以下の画像を使用しました。 ${SPT_INSTALL_BIN} \data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 画像の構築とプログラムは無事にでき、意図した RGB LED1 も点滅しており、KW45B41Z マイクロコントローラが正常に動作していることを示しています。しかし、それでもなお、基板のプログラミングやデバッグができません。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 どのIDEを使っていますか? MCUXpresso IDEまたはMCUXpresso for VS Code? 私の方で試してみて、デフォルトのジャンパー設定をお知らせします。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 ジャンパーの設定を参照してください。ローカル側で確認済みで、hello_world例をボードに正常にフラッシュできます。 そして、MCUXpresso IDEとSDK 25.12.00を使っています。 私のジャンパー設定を試してみて、うまくいくかどうか教えてください。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. Secure Provisioning Toolはチップ上でコードを正常にフラッシュ・実行できるため、物理ハードウェアは完全に問題ありません。つまり、「0 SWD デバイスを検出」というエラーは、IDEのデバッグプローブサーバーとオンボードのMCU-Linkファームウェア間の通信ミスマッチに起因しています。これは通常、MCU-LinkファームウェアをIDEs対応の最新バージョンに更新するか、接続中に手動でリセットボタンを押し続けることで解決し、低消費電力のアプリケーション状態がデバッグインターフェースをロックしないようにします。

Experience with vendor's tools Hi guys, I am wondering what's your experience with using vendor's tools while working on their hardware? Let's say we talk about something like Layerscape series from NXP or STM32MP1 series. I've been working on a board based on one of the NXP's Layerscape SoC and I can't wrap my hand around the fact that the only tool they provide to bringup and verify eg. DDR is **bleep**ty IDE based on Eclipse. I mean, given the quality of this tool I wouldn't complain if they provided it for free but they charge hell a lot of money for a license. Want to learn how to do this or that using their IDE? Good luck, "best I can do" is, mostly not 100% accurate outdated, partial documentation, forum where you will always get an answer, that somebody will handle this and 240p video where you can barely see what's on the screen. I hope that I will only use it for DDR bringup and validation and will manage to do the rest without this tool. What's your experience with other vendors? How about TI? I've seen some tools from ST and they really looked much simpler but I don't have any practical experience. Re: Experience with vendor's tools Hello, The Eclipse base is aging, the DDR tooling (DDR Stress Test Tool) is functional but clunky, and the licensing cost vs. quality ratio is a common complaint in embedded communities. The documentation gap is real — AN (Application Notes) are often the better resource than the official tool docs. Many engineers use it purely for DDR PHY init/training as you plan, then move on.   Practical Tips for NXP Layerscape DDR Bringup Since you're stuck with it for now: The DDR Stress Test Tool standalone binary (separate from CodeWarrior) is sometimes available and lighter to use. NXP's i.MX/Layerscape community on GitHub has reference DDR configurations that can shortcut a lot of the tool-guided work. LSDK (Layerscape SDK) scripts sometimes expose DDR init parameters more transparently than the IDE. Regards

Lx2160a用のIbisモデル こんにちは、みんな LX2160A用のIBISモデルをどうやって手に入れられるのか知りたいです。どなたか助けていただけませんか? どうもありがとうございます 元 Re: Ibis model for Lx2160a IBISモデルは公開されていません。こちらでケースを作成してください: https://support.nxp.com/s/?language=en_US  そして、秘密保持契約書（NDA）の内容を共有してください。 よろしくお願いします。

freertos 系统跑不通问题（创建即跑不通） 我的项目项目程序按照规程建立后，发现freertos 系统 无法跑通 (已经调查过不是内存不足问题，应该 也不是优先级的问题)，我的S32DS编译器版本如下图  任务直接建立失败，这个版本不支持freertos 吗？还是配置有什么特殊要求吗？ Re: freertos 系统跑不通问题（创建即跑不通） 你好@sunshine88 ， 应用程序实际上并不是因为 sys_msleep(5000) 调用本身而卡住的。该行为表明 sys_now() 使用的时间基准没有递增。因此， sys_msleep() 中的超时条件永远不会达到。 在 OSIF 配置截图中， OsIfUseSystemTimer 已启用，操作系统类型设置为 FreeRTOS。但是， OsIfCounterConfig_0 下的引用（包括计数器和系统定时器时钟引用）似乎不完整或为空。仅添加 PIT 组件并不能保证 OSIF 时基已正确配置和初始化。 目前请不要修改 TCP/IP 协议栈源代码或实现其他延迟解决方法。我建议如下： 从已安装的 TCP/IP 协议栈软件包中导入原始的 lwip_FreeRTOS_s32K358 示例。 构建并运行原始示例，无需任何修改。 检查原示例中 sys_now() 是否递增。 将 FreeRTOS、BaseNXP/OSIF、PIT、时钟、中断和 TCP/IP 协议栈配置与您的自定义项目进行比较。 验证生成的初始化序列是否包含所需的 BaseNXP/OSIF 和定时器初始化。 我们仍然需要之前请求的信息才能正确分析定制项目： MCU 的确切零件编号； 精确的评估板或定制板； 用作起点的原始示例或项目类型； 未修改的 lwip_FreeRTOS_s32K358 示例是否能在相同的硬件上运行； 生成的 sys_now() 实现； xTaskGetTickCount() 返回的 FreeRTOS tick 计数是否增加。 请先检查 xTaskGetTickCount() 。如果 sys_now() 保持不变而它增加，则说明 FreeRTOS 调度程序和滴答中断正在运行，问题具体出在 OSIF 时基配置或初始化中。如果 xTaskGetTickCount() 也保持不变，则问题更加根本，必须调查 FreeRTOS 滴答中断或调度程序配置。 如果可以，请提供完整的项目存档，而不仅仅是配置截图。如果没有生成的配置和初始化代码，就无法确定 sys_now() 实际使用的是哪个定时器或时钟源。 顺祝商祺！ 帕维尔 Re: freertos 系统跑不通问题（创建即跑不通） 你好，现在我建立了一个LWIP程序例程，但是以太网mainLoopTask任务却卡在 sys_msleep(5000); 无法延时，我单步进入此函数，发现 startTime = sys_now(); sys_now()函数无法计数，现在我的配置页如下，是什么原因造成的那？感觉很迷惑。 Re: freertos 系统跑不通问题（创建即跑不通） 你好@sunshine88 ， 您截图中显示的版本应该支持 FreeRTOS。S32 设计工作室 3.5 更新 14，RTD 4.0.0FreeRTOS 4.0.0 和 TCP/IP 协议栈 1.0.4看起来是预期的软件包组合，所以这似乎不是一般的版本兼容性问题。 根据所示代码，故障直接发生在 xTaskCreate() 中。请您提供以下信息？ 具体的MCU部件号以及所使用的评估板或定制板。您之前提到过 S32K358，但请确认具体的器件型号和主板型号。 用作起点的原始示例的名称。 xTaskCreate() 返回的值。 xPortGetFreeHeapSize() 在调用 xTaskCreate() 之前和之后打印的值。 配置的 configTOTAL_HEAP_SIZE、configSUPPORT_DYNAMIC_ALLOCATION 的值，以及选定的 FreeRTOS 堆实现，例如 heap_4.c。 应用程序停止的确切位置，包括调试器调用堆栈（如果它进入断言、异常或 HardFault 处理程序）。 请注意，MCU 总 RAM 充足并不一定意味着 FreeRTOS 堆内存充足。xTaskCreate() 从 FreeRTOS 堆中动态分配任务控制块和任务堆栈。此外，1024U 堆栈深度参数通常表示堆栈元素而不是字节，因此在 Cortex-M7 上实际分配的内存大于 1024 字节。 作为基准测试，我建议导入并运行原始的 lwIP FreeRTOS 示例，不要做任何修改。一旦原始示例运行正常，请添加一个带有小堆栈、普通优先级和循环内 vTaskDelay() 调用的附加任务。这将有助于区分环境或电路板配置问题与额外任务引入的问题。 我还注意到，您的 xTaskCreate() 调用使用了 1024U 的堆栈深度，而原始工作示例使用了 256U。请恢复原始值 256U，并先测试未修改的示例。请注意，此参数指定栈元素的数量，而不是字节数，因此使用 1024U 需要更多的 FreeRTOS 堆空间。   此致， 帕维尔

熟悉供应商的工具 大家好，我想了解一下你们在使用厂商提供的工具来维护他们硬件时的经验如何？假设我们谈论的是 NXP 的 Layerscape 系列或 STM32MP1 系列之类的产品。我一直在开发一款基于 NXP Layerscape SoC 的电路板，但我无法理解他们提供的唯一用于启动和验证例如 SoC 的工具是什么。DDR 是一个基于 Eclipse 的垃圾 IDE。我的意思是，考虑到这个工具的质量，如果他们免费提供，我不会抱怨，但他们的许可证费用却高得离谱。想学习如何使用他们的 IDE 来完成这个或那个操作吗？祝你好运，“我能做的最好的就是”提供一些不太准确、过时、不完整的文档，以及一个你总能得到答案的论坛，保证有人会处理这个问题，还有一段240p的视频，你几乎看不清屏幕上的内容。我希望我只会用它来启动和验证 DDR，其余工作无需这个工具就能完成。你与其他供应商的合作经验如何？TI 的产品怎么样？我见过 ST 的一些工具，看起来确实简单得多，但我没有任何实际经验。 Re: Experience with vendor's tools 你好， Eclipse 基础架构已经老化，DDR 工具（DDR 压力测试工具）虽然功能齐全但笨拙，而且许可成本与……相比。质量与比例失衡是嵌入式社区普遍抱怨的问题。文档缺失是真实存在的——应用笔记通常比官方工具文档更有价值。许多工程师仅将其用于 DDR PHY 初始化/训练，然后按照计划进行下一步。   NXP Layerscape DDR启动实用技巧 既然你现在只能接受它了： DDR压力测试工具的独立二进制文件（与CodeWarrior分开）有时可用，而且使用起来更轻便。 NXP在 GitHub 上的 i.MX/Layerscape 社区提供了参考 DDR 配置，可以简化许多工具引导的工作。 LSDK（Layerscape SDK）脚本有时比 IDE 更透明地公开 DDR 初始化参数。 此致