S32K311 中的 JTAG 网络安全关于网络安全级别和大规模擦除 你好、 我想知道锁定和解锁过程的步骤。 能否在 S32K311 微控制器中实现大规模擦除和解锁机制？ Re: JTAG security in S32K311 about Security levels and Mass erase 你好@truptikavadi1、 谢谢您的帖子。 不，S32K1xx的工作原理与您描述的完全相同，但S32K3xx 并非如此。 如果您想获得与 S32K3xx 网络安全相关的更多信息，请注意，由于这是 K32L 频道，该产品不在我的支持范围内。 我建议在S32K - 恩智浦社区上创建一个新的帖子，那里的相关支持者将能为您提供进一步的帮助。 感谢您的理解。 BR 西莱斯特   ---------------------------------------------------------------------------------------------------------------------- 注：如果本帖回答了您的问题，请点击"ACCEPT AS SOLUTION" 按钮。Thank you! ----------------------------------------------------------------------------------------------------------------------

无法调试 i.mxrt1064 自定义板。 您好， 在尝试以调试模式运行我的代码时，我收到"Break at address"0x20d102" with no debug information available" 信息。 我正在使用 i.mxrt1064 自定义板并使用 LinkServer LPC-Link2 进行编程。 这个主板以前可以正常工作了，但现在突然间，出现了这个消息。 我试过版本模式。我可以成功地用版本代码刷新我的主板，但是程序似乎无法运行。无论是从串行终端还是从显示屏，我都看不到任何输出。 我还尝试过使用安全配置工具对这个板进行编程，但它仍然无法正常工作。 有谁能帮助我们找到这个问题的重点或线索？ Re: Unable to debug i.MXRT1064 custom board. 你好，MayLiu、 感谢您的回复。 早些时候，我确实按照你的建议尝试了这种设置，但在尝试调试时，集成开发环境提示错误（未能执行 MI 命令：-target-download）。我附上了该错误的快照供你参考。 回到上一条信息，我想补充的是，当我检查当前程序的执行地址时，显示代码位于 ROM 区域（地址 0x20E35A）。因此，不知何故，代码无法到达/启动应用程序代码，并被卡在 ROM 中。我的假设正确吗？会有这种情况吗？ Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 非常感谢您关注我们的产品并使用我们的社区。 1: 请尝试选择将应用程序链接到 RAM，然后重新调试。 如果您的应用程序可以从 RAM 成功运行，请将板设置为串行下载器模式，然后使用安全配置工具通过 UART1 或 USB1 对您的板进行编程。   如果你的应用程序无法运行，我建议你使用示波器来检查主板的开机顺序。   希望它能帮到你。 顺祝商祺！ MayLiu Re: Unable to debug i.MXRT1064 custom board. Hi MayLiu, 感谢您的建议。 我想检查一下 MCUXpresso 中是否有任何可以改变或影响启动 Conf 的设置/配置？只是为了排除 IDE 的可能性。 在串行下载模式下，链接服务器能够检测目标。 Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 感谢您提供的最新信息。 根据您提供的信息，CPU 当前可能正在执行来自启动 ROM 的代码，而不是您的应用程序代码。   我建议检查启动CFG和启动模式引脚设置，确保设备配置为从用户闪存启动。   你也可以尝试将板设置为串行下载器模式，然后通过J-Link进行连接以确认调试器是否可以检测到目标并与目标通信。   顺祝商祺！ MatLiu Re: Unable to debug i.MXRT1064 custom board. 你好@nxpsachve、 我认为MCUXpresso IDE不会更改启动配置，恩智浦RT的启动行为由硬件启动配置和启动模式引脚决定。 由于可以在串行下载模式下检测到目标，这表明 ROM 仍在正常运行。下一步，您可以 执行全芯片擦除、 将板切换到内部启动模式，然后 尝试重新连接 MCUXpresso IDE 进行调试。 或者，您也可以使用 MCUXpresso 安全配置工具对应用程序映像进行编程。 顺祝商祺！ MayLiu

QSPI 1 で MGC アクセス制御を無効にするにはどうすればよいでしょうか? 私は、カスタム ドライバを使用して S32E2 評価ボードで QSPI を動作させることに取り組んでいます。EMMC からのブートから QSPI からのブートに切り替えるプロセス中であるため、JTAG を使用してコードをロードし、RAM が不足しています。評価ボードには、QSPI フラッシュが QSPI1 B に接続されています。主に SFAR などの特定のレジスタへの書き込みに問題があります。SFAR は MGC によって保護されているようなので、ビット 31 (GVLD) をクリアしてアクセス制御を無効にしたいと思います。ただし、リファレンス・マニュアルによると、MGC にアクセスできるのはバス・マスタ 0x1F のみであり、これが HSE コアです。QSPI0 のこれらのレジスタにアクセスできるバス マスターを変更できる HSE_QSPI0_DAT0 の形式で QPSI0 のバイパス メカニズムがあるようですが、QSPI1 に相当するものを見つけることができませんでした。 誰か助けてくれませんか？ Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 NXP サポートにお問い合わせいただきありがとうございます。ご質問に関してですが、おっしゃったレジスタにアクセスするための正しい方法を検索するのに少し時間が必要です。 現時点では、S32ZE RTD 2.0.1 で提供しているQspi_Ip_Example_S32Z2XX_R52またはMemAcc_Example_S32E2XX_R52サンプル プロジェクトを確認することをお勧めします。これらのプロジェクトでは RTD が使用されていますが、S32Z/E ファミリで QSPI を使用するために必要な手順を把握することができます。 よろしくお願いします。 Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 返信が遅くなり申し訳ありません。セクション65.1.6 QuadSPI_0とセキュリティレジスタの相互作用[ページ3349、S32Z2リファレンス・マニュアル、Rev. 5、2025-01-28]、セクション121.2.1.5 QuadSPI_0データ0 (HSE_QSPI0_DAT0) [ページ6674] の表もご確認ください。表の最初の行では、HSE_QSPI0_DAT0の値に応じて、MGCレジスタにアクセスできるマスターIDを設定する方法について説明しています。 問題を解決できたかどうか教えてください Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 混乱させてしまい申し訳ございません。さて、私が理解しているのは、元々の問題は克服されたということですが、それで正しいでしょうか? IP コマンドを送信するための最適なフローをチェックするには、サンプル プロジェクトMemAcc_Example_S32E2XX_R52を確認してください。特に、関数Qspi_Ip_StatusType Qspi_Ip_IpCommand ()と、それが静的 Qspi_Ip_StatusType Qspi_Ip_InitReset()およびQspi_Ip_StatusType Qspi_Ip_RunCommand() でどのように呼び出されるかを確認してください。 他にご質問があればお知らせください。 Re: How do you disable MGC access control on QSPI 1? 私はその部分をすでに見ていましたが、それは QuadSPI 0 のみをカバーしているようで、私はこれを QuadSPI 1 で実行しようとしています。その間に、MDAD および FRAD レジスタをプログラムしてすべてのアクセスを許可する方法を見つけ、IP コマンドを開始すると SFAR にデータが設定されるようですが、現在はビジー状態になっているため、MGC ですべてを無効にする必要はないかもしれません。 Re: How do you disable MGC access control on QSPI 1? MDAD/FRAD を設定し、LUT をプログラミングした後、IP コマンドを開始できるようになりました。フラッシュ通信の最初のステップとして、S32E288-975EVB 評価ボード上の Micron MT25QL256ABA8E12 からシリアル フラッシュ検出パラメータを読み取ろうとしています。スロット 8 に次の LUT シーケンスを設定しました。 コマンドパッド1 0x5A アドレスパッド1 24 ダミーパッド1 8 パッド1 16を読み取り 停止パッド1 0 シーケンスは開始しているようですが、その後、無限にビジーな状態に陥ってしまうようです。SFAR は 0x10000000 (設定された開始アドレス) に設定され、IPCR は 0x08000008 (スロット 8、8 バイト) に設定されます。BUFXCR レジスタは、バッファ 3 を除いてすべてサイズ 0 に設定し、バッファ 3 はすべてのマスターに設定しました (値 0x80004000)。金曜日に、オシロスコープで CS0/D0/D1 ピンを調べることができ、IP コマンドが開始されると CS がアサートされるものの、デアサートされないことが分かりました。コマンドとアドレスが送信され、その後にダミー サイクルが続き、その後 D1 がアクティブになってデータに応答するように見えます。しかし、読み取りは完了せず、ただノンストップでデータをクロックし続けているように見えます。フラッシュ チップが SFDP バッファを何度も繰り返して循環するため、D1 に繰り返しパターンが表示されます (少なくとも私はそう推測します)。 実行を一時停止すると、次の画面が表示されます。 読み取りが完了しない原因が何なのかはわかりません。QSPI 読み取りに関するデータシートのセクションを読みましたが、この動作を説明するものは見つかりませんでした。クロックを下げてみました (ビット タイミングを見ると最初は約 100 MHz のようでしたが、その後 CGM に /10 分周器を追加したところ、D1 のビット パターンが遅くなりましたが、ビジー動作は変わりませんでした)。 Re: How do you disable MGC access control on QSPI 1? こんにちは@AdamH_work 、 メモリのデータシートを見ると、SFDP (0x5A) は「通常の」操作ではなく、コントローラが通信フローを意図的に停止する必要があるようです。 これにより、読み取りが完了しない理由を説明できます。私の見るところでは、QSPI ペリフェラルは動作しており、少なくとも通信は行われているので、現時点での問題は操作の種類にある可能性があります。もっと簡単な操作を試してみませんか？例えば、私が言及した例では、 Qspi_Ip_Cfg.c の MemCfg_0_SPI3ByteAddress_paInitOperations_0 と MemCfg_0_SPI3ByteAddress_paLutOperations_0 という LUT シーケンスが見つかります。初期化操作については、 Qspi_Ip.c の Qspi_Ip_InitOperation () でどのように使用されているかを確認してください。 別の操作を実行して、異なる動作が表示されるかどうかを教えてください。 よろしくお願いします。 Re: How do you disable MGC access control on QSPI 1? 結局、問題は DLL を適切に設定していなかったことにありました。私は S32DS の例に従って DLL バイパス モードの初期化シーケンスを実行し、それをコードに再実装したところ、読み取り操作が正しく完了するようになりました。次の課題は書き込み操作ですが、この問題はCANとして解決済みとしてマークできます。

先进的电机控制协处理器 我希望对高级电机控制协处理器有更深入的技术了解。 能否请您向我提供详细描述该外围设备的相关文件和技术介绍？ 特别是，如果能说明该模块与双 eFlexPWM / NanoEdge PWM 模块（2×，各 8 个通道）的区别或连接，包括任何功能重叠、交互机制或预期用例，我将不胜感激。 由于高级电机控制协处理器被强调为提供 16 通道可编程 I/O 定时器，而 eflexPWM 代表一组专用的电机控制 PWM 定时器，我想更好地了解这两个子系统在整个电机控制架构中是如何相互补充的。 Re: Adv. MotorControlCo-Processors 你好 通常，参考手册中描述了诸如eTPU、flexPWM、eMIO之类的电机控制定时器的操作。 在S32K39/37/36设备上，恩智浦包括eTPU：一种可编程的微编码定时引擎，具有自己的指令和数据RAM，旨在减轻实时I/O定时任务（PWM波形整形、换向调度、传感器解码、捕获/测量等）。这就是恩智浦材料中所说的 "高级电机控制协处理器"。 在更广泛的 S32K3 系列中，恩智浦重点推出 eMIOS（增强型模块化 I/O 子系统）和 LCU 作为标准电机控制定时器/逻辑组合。eMIOS 是一个高度灵活的 16 位定时器子系统，具有多种通道和模式（缓冲 PWM、中心对齐、死区互补、单脉冲/DAOC、输入捕获等）。由于 eMIOS 每通道占用空间小，边缘处理灵活，因此许多社区文档将其非正式地称为 "NanoEdge PWM "式模块。 如果您使用的是 S32K39 并需要最大限度的确定性或复杂的时间表（解析器、多电机换向、自定义波形），请使用 etPU 作为监控器；将 eflexPWM 连接到功率级；使用 emIO 进行辅助定时/捕获；为 ADC 窗口连接 TRGMUX/BCTU。 如果你使用的是 S32K344/358（没有 eTPU），请为反向器选择 eflexPWM，然后使用 emiOS + LCU/TRGMUX/BCTU 来管理捕获/触发信号/辅助 PWM。RTD 的 PWM 驱动程序可让您在一个配置中混合 eFlexPWM 和 eMIOS 通道。 具体实施可参考以下文献： S32K3xx DS（Rev.13，2025-11-12），设有& 区块。[nxp.com] 用于 eTPU/eMIOS/LCU 的 S32K39/37/36 DS 时序部分。[nxp.com.cn] S32K396 LV MC 套件（明确的 "eTPU 电机控制协处理器"）。[nxp.com] S32K3 电机控制手册（名为 eMIOS、LCU、触发信号、ADC/CMP）。[nxp.com]、 S32K3 系列手册（注明 16 位 emiOS 计时器）。[nxp.jp] RTD PWM 驱动器讨论（eFlexPWM 包含在统一 PWM 中）。[community.nxp.com] emiOS 使用指南 & 示例（OPWMB/OPWMCB/DAOC/OPWFMB，捕获模式）。[community.nxp.com] 使用 eMIOS 的单脉冲 PWM（DAOC/OPWMB 示例）。[community.nxp.com] 致以最诚挚的问候， Peter

S32K358 基于 AUTOSAR 驱动程序的 HSE 随机数生成器 亲爱的支持者 客户 Aptiv 与 S32K358 合作 RTD 版本：Crypto_43_HSE_TS_T40D34M60I0R0 HSE FW 版本：HSE_FW_S32K358_9_2_72_0 在尝试在微控制器上集成加密RTD并刷新HSE固件后生成随机数时，我们观察到一个问题，即固件似乎停留在HSE_IP_ServiceRequest () 函数上，特别是在等待 mu_IP_isResponseReady () 时。请查看随附的调用堆栈屏幕截图以参考。 请您帮助我们理解： 固件卡在这一点上的可能原因是什么？ 解决此问题的建议方案或调试步骤？ PS: 我已在 BSWM 配置中配置了 CSM_Init、CriIf_Init 和 Crypto_Init 在 Vector Davinci 中配置的 CSM、CryIf，从 BSWM_Init 调用中调用的 CSM、CryIF、Crypto 的初始函数。使用 Demo APP 安装了 HSE，并通过读取版本号和 MU 状态寄存器进行了验证，如下图所示： 客户要求提供基于 AUTOSAR xdm 配置 CSM、CriIf 和 Crypto 驱动程序的 AUTOSAR 示例（而不是 DEMOAPP 的代码）。附上他们的 Crypto xdm 文件。 (到目前为止，恩智浦方面的 Sunny X 和 Dhan Raj 参与了一次调试呼叫，但我们尚未找到最终的根本原因......）。 顺祝商祺！ 维克托 板：S32K358 优先权：紧急 SW 变体：标准 Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 你好 Cuong、 我们得到了帮助和[email protected]创建了一个例子。 让我们把这张票保留到下周客户试用时。 我会允许你访问 Sharepoint 上的示例。 顺祝商祺！ 维克托   Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 你好@viktorfellinger ，我正在为你创建一个示例。 同时，您能否告诉我： 1.您多久会遇到这个问题？是经常发生还是偶尔发生 2.pRequest 的值 pRequest 和 pHseSrvDesc 的 值。 Hse_Ip_ServiceRequest() 时的 pRequest 和 pHseSrvDesc 值。 您能否尝试增加 pRequest中的超时值 ，看看能否解决这个问题？ Re: S32K358 HSE Random Number Generation based on AUTOSAR drivers 您好@viktorfellinger ，您收到反馈了吗？ 如果没有更新，我想关闭这个话题。 客户稍后可以提出另一个问题，然后您可以再次提及此主题

KW45 硬件设计建议 亲爱的恩智浦团队， 我想知道，如果我不将下图中给出的外部迹线从 CDD_CORE / VOUT_CORE 连接到 VDD_CORE，会出现什么问题。 我以为是一样的，所以没有从外部电路连接。会有问题吗？ 我遇到了一个奇怪的问题，能告诉我是什么原因吗？ 当电压从 3.1V 降到 3V 时，射频下降。 MCU 似乎能正常工作，因为我们实现了 LED 闪烁。 在某些情况下，如低于 2.5V 时，MCU 可以工作，但射频输出是错误的。 在某些情况下，例如电压低于 2.5V 时，MCU 会完全停止发送数据，我们可以看到大约 7/8/9/12mA 的持续功耗。 我无法理解，因为当我们降低电压或低电压时，总是会出现这种情况。 KW45B41Z-EVK KW45 BLE-NFC   如果两个引脚都是内部连接的，会有问题吗？ Kinetis K系列MCU Re: KW45 HW Design Recommendation 你好 希望你一切顺利。 您在设计中使用的电源配置是什么？您是如何为 VDD_RF 供电的？ 有关最常见的电源配置和注意事项，请参阅 AN13831 KW45/K32W148-电源管理单元硬件第 3 节 " KW45/K32W148 电源配置 "。 请注意，您的应用程序要求的任何电源配置都必须符合每个功率域的直流电压要求，该要求在第 2.2 节 " 电源域速率 " 中规定 内部稳压器输出由 VDD_CORE/VOUT_CORE 提供，稳压器输入由 VDD_CORE 提供。强烈建议在外部连接引脚以及适当的去耦电容，以提供反馈路径并保持电压稳定性。 您可以在这篇文章中找到我们的最低物料清单演示文稿，了解推荐的电容值和其他硬件建议：使用 KW 45（汽车）或 K32W1/MCXW71（物联网/工业）首次版本 PCB 的最佳方式 您还可以根据我们的 KW45-EVK 原理图来 确认您的 原理图 设计。 顺祝商祺！ 安娜-索菲亚

使用 “tk (密码块链接(CBC) (aes))” 进行文件系统加密时出现 imx8mm CAAM 错误 使用CAAM写入文件系统时使用`t k (密码块链接(aes)) `进行文件系统加密时出现以下错误。 caam_jr 30902000.jr：4000141c:DECO： desc idx 20：DECO看门狗定时器超时错误 这种情况只是偶尔发生，但在启用所有内核运行时似乎更为普遍。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 很抱歉延迟回复。 我们使用的是 Phytec 公司的 `linux-imx_5.15.71_2.2.2-phy5`，并打上了https://github.com/Freescale/linux-fslc/tree/5.15-2.2.x-imx至 5.15.183 的补丁。 不幸的是，这个问题只是偶尔出现（在跨多个单元的 CI 测试中，每 500 小时左右才会出现不到 1 个实例），而且我还无法创建一个简单的重现器。 最初尝试启用 “CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG” 会阻止我们的设备启动，因为我们正在使用 CAAM 加密根文件系统和各种数据分区，这会生成过多的日志记录。 我正在考虑将日志信息添加到循环缓冲区中，并在错误发生时发出。 由于这只会导致最后 1000 条左右的记录被发出，我想知道是否有任何设置信息是我们应该始终记录的，以支持分析。 谢谢！ 丹尼尔 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 你能否分享一下你正在使用的电路板支持包 版本以及出现问题时的步骤和日志？ 此致 哈维 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 不幸的是，我无法使用其他工具进行重现 😞 我已经添加了最后 2048 条 CAAM 故障日志信息的记录，现在我们正在等待故障在 CI 中再次发生。 我收到日志后会尽快发送给您。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 看门狗超时错误是由 DECO 暂停时触发信号的，但是有多种情况可以让 DECO 暂停，例如输入/输出缓冲区地址、长度等。 你能用 "dd" 或 "fio" 工具进行压力测试来重现这个错误吗？ 如果问题能够稳定重现，就能帮助我们找到根本原因。 此致 哈维 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 最后，记录失败。 这应包括 CAAM 子系统的最后 2048 条日志记录。 与标准日志记录的唯一区别是不包括 `src` 和 `dst` 缓冲区数据。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 请注意，出于省电的考虑，我们降低了 CPU 和 DDR 的运行速度，这可能会对结果产生影响。 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 不，我无法用 dd 或 fio 进行重现。 在我捕获之前的日志的系统上，它只会偶尔发生（到目前为止每 2 个月一次）。 在另一个代码略有不同的系统上，这种情况每天至少发生一次。 我们认为这是在启动过程中加载大量共享库时造成的（在我获取日志的系统中并没有使用这些共享库）。 遗憾的是，我们无法轻易收集该版本的日志，但我们可以相对快速地测试补丁，看看问题是否得到解决。 以前的日志是否包含足够的调查信息？ 如果没有，还需要什么？ Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 简单查看我的日志后发现，在故障发生时，8 个队列请求中的第 8 个请求是产生 DECO 看门狗超时错误的原因。 在日志的早期部分，即使在处理其他偏移量序列时，似乎也很少有排队等待的请求（有时可能只有一个？ 这是线索吗？ 在此之前排队的 7 个请求似乎都能正确完成，因此可能是以下原因之一... 队列实际上只支持 7 个条目--在这种情况下，减少队列条目的数量可能会有帮助（在哪里可以更改？） DECO 看门狗超时从条目添加到队列时开始，由于处理 8 个条目所需的时间过长，超时也就结束了--在这种情况下，延长超时时间可能会有帮助（同样，如果可能的话，在哪里可以更改？） 这个具体请求实际上有问题，但在我看来，它与之前的 7 个请求等同，因此似乎不太可能出现这种情况 谢谢！ 丹尼尔 Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption 拿到日志后，我决定亲自深入研究。 当系统处于高内存负载但 DDR 仍以 400MT/s 的速度运行时（在我们的情况下有时为 100MT/s），CAAM 有时会产生看门狗错误。 eMMC 驱动程序会强制 DDR 达到 3000MT/s 的速度，但对于写入而言，这并不一定要等到加密完成后才会发生。 我们已经为我们的用例修复了这个问题，在 `caam_jr_enqueue () `中请求` BUS_FREQ_HIGH `，然后通过计划工作从 `caam_jr_dequeue () `再次将其释放。 这解决了文件系统访问问题，但在从网络堆栈调用时（例如通过 xfrm）会产生问题，因为 `request_bus_freq()` 最终会在原子上下文中被调用（从更高的网络堆栈调用），而且 `request_bus_freq()` 和 `clk_xxx()` 调用都使用了 mutex 我们已经解决了这个问题，在除文件系统之外的所有系统中禁用了 CAAM，但如果向上游推广，还需要更好的解决方案。

Latest version of AN4581 Hi, There is a AN4581 (i.MX Secure Boot on HABv4 Supported Devices) Rev. 4 from 2020: https://de.scribd.com/document/811030804/AN4581 However If I search your website or the internet, I can only find outdated versions from 2012 or 2018. Can you tell me where I can find the latest revision of AN4581? Thanks Re: Latest version of AN4581 Thank you for your support. I was able to download the 2020 version here: https://www.readkong.com/page/an4581-i-mx-secure-boot-on-habv4-supported-devices-2622907 The old versions are available without NDA here: https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/225997/1/AN4581.pdf (2012) https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/194321/1/AN4581_2018.pdf (2018) Re: Latest version of AN4581 This AN for secure boot is confidential, you need to sign an NDA with NXP. It's better to create an internal ticket from https://support.nxp.com/s/?language=en_US

BD-SL-i.MX6 运行 Qt 5.4（Qt 公司出品） <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> BD-SL-i.MX6 以前称为 SABRE Lite 板，是一种低成本的 i.MX6 开发平台。该主板的最佳特性之一是其提供的强大软件支持。这篇文章介绍了 QT 公司的 Qt5.4。下面的视频展示了Qt 公司的企业设备创建产品，这是一个针对 Qt 优化的预构建软件堆栈，可让您立即开始在真实设备上进行嵌入式 Linux 和 Android 开发的原型设计。该演示运行 Qt5.4，并且该图像可用于 BD-SL-i.MX6 以及我们的 Nitrogen 系列产品。以下是一段简短的视频，展示了部分功能： 上面的视频展示了为嵌入式 Linux 创建的图像，更具体地说，是使用Yocto 项目和飞思卡尔社区 BSP 的工具构建的。因此，您的产品可以利用这些项目提供的软件包，并且您可以使用 Yocto 构建系统来集成您的组件并定制您的构建。 有关更多详细信息，请访问http://qt.io或http://boundarydevices.com/qt-for-device-creation/ 概述

[入門] Yocto Linux BSPのビルド方法 - i.MX FRDMボード編 (日本語ブログ) *i.MX FRDMボードをベースに、Yocto Linuxのビルド方法を紹介します。 本記事ではFRDM-IMX93をベースに紹介しますが、他のi.MX FRDMボードでも同じ手順でビルドすることができます。 Yocto Linux BSPは、「Linux 6.12.49_2.2.0 (Yocto 5.2 “Walnascar”)」を例に記載しています。   Q: i.MX FRDMボードとは？   A: i.MX FRDMボードは、NXPが提供するフル機能のEVKボードに比べて、機能を絞り込み、より低価格かつコンパクトに設計された開発ボードです。基本的な評価やプロトタイプ作成を手軽に行えることを目的としています。 1. 環境＆事前準備 1.1. 環境 大項目 小項目 内容 備考 Document - IMX_YOCTO_PROJECT_USERS_GUIDE.pdf (主に使用します。BSPをビルドするための手順を記載) i.MX Linux® Release Notes  (サポート機能を一覧で確認できます) i.MX Porting Guide (実際に実装する際の注意点のまとめ) Yocto Linux全般資料のダウンロードはこちら Hardware FRDMボード FRDM-IMX8MPLUS FRDM-IMX91S FRDM-IMX91 FRDM-IMX93 FRDM-IMX95  本章では、FRDM-IMX93をベースに説明します Host PC Ubuntu環境 ・VMWare/Virtual Box等(on Windows) ・Native Linux のどちらか 推奨：Ubuntu22.04以上 SDカード＋リーダライタ 16GB以上のもの推奨   Hardware (Option) MIPI-Camera (Option) BSP対応のMIPIカメラ ( i.MX Linux® Release Notes参照) USBカメラでも代替可（遅延が発生する可能性があります） Display (Option) 表示用ディスプレイ   USB Device (Option) USBマウス、USBメモリ   Headphone (Option) 3.5mm イヤホン マイク付きイヤホン(旧iphone付属のイヤホン等)だとベター Software Yocto環境 Linux BSP (今回はLinux 6.12.49_2.2.0 (Yocto 5.2 “Walnascar”) を使用) インストール方法含め、本記事で説明します 1.2. 凡例 コマンド・プロンプトの凡例 =>           u-bootプロンプト $            BSPがインストールされているLinux PCのプロンプト 2. ホストマシン Ubuntu 22.04 Desktopを推奨します。 実運用上、ある程度快適なホストマシンのスペックは8スレッド、16GB以上です。 必要なストレージはターゲットとするレシピで変わってきますが、 小さいプロジェクトで50GB、大きなもので500GBほどかかります。 2.1. Yoctoに必要なパッケージ 以下の手順にて必要なパッケージをインストールしてください。 $ sudo apt-get install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3- jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xzutils zstd efitools curl 注釈 IMX_YOCTO_PROJECT_USERS_GUIDE.pdf に記載されている内容に加えて curl を追記しています。 2.2. スワップファイルの設定 32GBのスワップファイルを設定する場合の例です。 $ sudo fallocate -l 32G /swapfile $ sudo chmod 600 /swapfile $ sudo mkswap /swapfile $ sudo swapon /swapfile 注釈 すでに/swapfileが存在する場合は1行目のコマンドがFailします。サイズを変えて設定したい場合は、以下を実行してから再度上のコマンドを実行してください。 $ sudo swapoff /swapfile $ sudo rm /swapfile ホストマシンの起動時にスワップファイルを自動的にマウントさせるには、以下の行を/etc/fstabに追加してください。 /swapfile none swap sw 0 0 3. Yocto Linux BSP nxp.jpのEmbedded Linux for i.MX Applications Processorsから必要なLinux BSPのVersionを選択して、i.MX Yocto Project User's Guideを入手してください。 i.MX Yocto Project User's Guide (IMXLXYOCTOUG) の「4 Yocto Project Setup」の手順に沿ってイメージを作成します。 この資料は、以下の設定で生成されるイメージを前提として書いています。 　DISTRO = fsl-imx-xwayland 　MACHINE = imx93-11x11-lpddr4x-frdm 3.1. Yocto BSPのセットアップとビルド ホストマシンのセットアップは 2. ホストマシン を参照ください。 3.1.1. repoユーティリティのインストール $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo 3.1.2. repoのPATHを通す 以下の行を$HOME/.bashrcに追加します。   export PATH=~/bin:$PATH 3.1.3. Gitのセットアップ $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list 3.1.4. Yocto BSPのセットアップ $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-walnascar -m imx-6.12.49-2.2.0.xml $ repo sync 3.1.5. ビルドターゲットの設定、ビルド $ MACHINE=imx93-11x11-lpddr4x-frdm DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b build $ bitbake imx-image-full ＊ここでビルドが終了しますと、Linuxイメージが生成されます。 ＊生成されたイメージの書き込み方法については、以下ご使用のFRDMボードに合わせたスタート・ガイドのステップ１、２をご参考ください。 FRDM-IMX8MPLUSのスタート・ガイド FRDM-IMX91のスタート・ガイド FRDM-IMX91Sのスタート・ガイド FRDM-IMX93のスタート・ガイド FRDM-IMX95のスタート・ガイド 注釈 他のFRDMボード向けにLinux BSPをビルドしたい場合は、上記コマンドの"MACHINE="の部分を以下の名前に置き換えてください。 imx8mp-lpddr4-frdm   (FRDM-IMX8MPLUS) imx91-11x11-lpddr4-frdm   (FRDM-IMX91) imx91-11x11-lpddr4-frdm-imx91s   (FRDM-IMX91S) imx93-11x11-lpddr4x-frdm   (FRDM-IMX93) imx95-15x15-lpddr4x-frdm   (FRDM-IMX95) 注釈 グラフィック機能についても上記コマンドの"DISTRO="の部分にて、ディストリビューションを選択できます。 fsl-imx-wayland   (Wayland) fsl-imx-xwayland   (Wayland & X11 *EGLを使用するX11アプリには対応していません) 注釈 imx-setup-release.shスクリプトを使うセットアップは、プロジェクト1つに対して1回のみです。既存のプロジェクトに対して行うと、conf/local.confなどのファイルが新規で生成されるので、これまで設定した内容が失われます。既存プロジェクトを再度使う場合は 3.3.1. 既存のビルド・ディレクトリから作業を再開する を参照ください。 注釈 ホストマシンのスペックによりますが、ビルドには数十時間かかることも想定されます。またストレージも4~500GB消費することも想定してください。 注釈 マルチコア・マルチスレッドでのホストマシンでビルドを行う際、スレッド数に対してメモリが足りない場合にスワップが発生します スレッド数を制限するのは 3.4.2. ビルド時に走るスレッド数を制限する を参照ください。 注釈 Ubuntu22.04の初期状態だとスワップが設定されていないケースがあり、その場合は極端に遅くなったりクラッシュしたりします。スワップファイルの設定は 2.2. スワップファイルの設定 を参照ください。 ＊ここから先は参考用です。 3.2. ツールチェインのビルド、インストール クロスコンパイラなどのツールチェインをビルド、インストールすることができます。 ここで生成されるスクリプトを使うことで、クロスコンパイルのときにありがちなインクルードファイルやリンクさせるライブラリが見つからない、といった問題を避けることができます。 3.2.1. ツールチェインのビルド $ bitbake imx-image-full -c populate_sdk 3.2.2. インストール $ tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93-11x11-lpddr4x-pf0900-evk-toolchain-6.12-walnascar.sh ツールチェインの使い方については、ここでは説明しません。 3.3. よく使うYocto bitbakeコマンド、設定 3.3.1. 既存のビルド・ディレクトリから作業を再開する $ cd /path/to/imx-yocto-bsp $ source ./setup-environment build 注釈 ここでのパス、ディレクトリは 3.1.4. Yocto BSPのセットアップ 、 3.1.5. ビルドターゲットの設定、ビルド で設定したものです。 以下ではlinux-imxを例として、いくつかのコマンド例を挙げていきます。 "linux-imx"を別のパッケージ名にすれば、そのパッケージ毎に同様のことが可能です。 3.3.2. パッケージの再ビルド $ bitbake -c compile linux-imx -f $ bitbake -c install linux-imx $ bitbake -c deploy linux-imx 注釈 -fを付けない場合と手順がスキップされる可能性があります。 注釈 -c deployがエラーになるパッケージもありますが、ほとんどの場合はdo_deployコマンドが用意されていないだけですので、エラーは無視して構いません。 3.3.3. パッケージを消す あるパッケージで本来発生しないであろうエラーが発生する場合に、以下のコマンドでパッケージを消してやり直してみるとエラーが解消することがあります。 (ダウンロード時にパッケージが破損したり、ビルドを途中で強制的に終了した場合にゴミデータが残ったりしている場合があるためです。） $ bitbake -c cleansstate linux-imx 注釈 展開したソースコードごと削除されますので、編集しているファイルなどがある場合はご注意ください。 3.3.4. パッケージの展開 パッケージの展開だけを行い、コンパイルなどはまだやりたくない場合 $ bitbake -c patch linux-imx 3.3.5. configファイルの変更を反映させる configファイル（arch/arm64/configs/imx_v8_defconfigなど）を変更し、それを反映させたい場合 $ bitbake -c configure linux-imx $ bitbake -c compile linux-imx -f 3.3.6. linux-imx menuconfigを行う Linuxカーネルのビルドオプションを変更する場合 $ bitbake -c menuconfig linux-imx このようなウィンドウが起動するので、必要な変更を加えてSaveします。（十字カーソルキーで対象を選択し、スペースキーで決定） ビルド時のTIPSについては、以下の記事を併せてご参考ください。 Yocto Linux BSPのビルド時におけるTIPS集 - i.MX 8M Plus編 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） お手頃な値段で、コンパクトに組み込みLinuxを開始できるFRDM(フリーダム)ボードを用いて、Linux BSPのビルド手順を紹介します。 本記事ではFRDM-IMX93をベースに紹介しますが、他のi.MX FRDMボードでも同じ手順でビルドすることができます。 Yocto Linux BSPは、「Linux 6.12.49_2.2.0 (Yocto 5.0.4)」を例に記載しています。 i.MX Processors SW | Downloads 日本語ブログ

【恩智浦微控制器简介】【电机控制】【实践篇 2】永磁同步电机的机理及控制方法（日文博客） [实验0_2] 环境搭建 + 运行电机示例代码②   目录   5. 软件安装 5-1。启动 MCUXpresso 5-2。从 SDK 导入示例演示 5-3。从调试模式切换到发布模式 5-4. 建设项目 5-5. Flash编程 6. 连接到实时调试工具 运行演示 7. 操作检查和故障经验 8. 调试 9. 部分软件代码的解释 10. 总结与预览   5. 软件安装 接下来，我们将从工程师的角度详细解释实际设置开发环境和运行示例代码的过程。 为了帮助即使是第一次来的游客也能避免迷路，我们将介绍一些常见的陷阱和有用的技巧。 5-1。启动 MCUXpresso 首先，启动 IDE（MCUXpresso）。 安装完成后，会立即出现“欢迎屏幕”，请从这里开始。 提示 ：首次启动可能需要一些时间，请耐心等待！ 5-2。从 SDK 导入示例演示 SDK（软件开发工具包）包含许多示例项目。 这次我们将使用名为“mc_pmsm_enc”的示例来控制带编码器的永磁同步电机。 选择“MCXA156” 选择“frdmmcxa156” 点击“下一步” 在“示例”列中搜索“pmsm”，并选中“mc_pmsm_enc”。 点击“完成”以完成导入！ 提示 ：如果您不确定样品名称，请尝试搜索“pmsm”或“motor”，以便更容易地找到它。   5-3。从调试模式切换到发布模式 项目导入完成后，首先切换到“发布”版本。 调试版本也能用，但发布版本优化得更好，更适合在真机上运行。 使用 USB 电缆将 MCU-Link 连接器连接到 PC。 点击“建造”图标开始建造！ 接下来，点击“GUI Flash Tool”图标 点击 在写入闪存之前，请确保调试器已被正确识别。 故障排除 如果调试器无法识别，拔下并重新插入 USB 电缆或重新启动电脑可能会解决问题。   5-4. 建设项目 构建完成后，将在项目的“Release”文件夹中生成一个二进制文件。 如果出现错误，请再次检查 SDK 版本和导入步骤。   5-5. Flash编程 使用“GUI Flash Tool”向目标板写入数据。 编写完成后，您终于可以在实际设备上运行示例了！ 6. 连接到实时调试工具 接下来，我们将使用 FreeMASTER (MCAT) 实时观察电机状态。 在 IDE 的“项目资源管理器”中，双击 motor_control 文件夹中的 pmsm_float_enc.pmpx 以启动 FreeMASTER。 体验 当我第一次看到波形实时移动时，我惊叹不已，脱口而出“哇！”   与董事会沟通 点击左上角的绿色“开始！”按钮即可开始通讯。 如果您无法正常沟通， 在“项目”菜单→“选项”→“通信”选项卡中选择正确的 COM 端口（115200bps）。 尖端 如果您不知道 COM 端口，请尝试“COM_ALL”，它可能会自动检测！ 运行演示 演示终于开始了！ 按下主机板上的SW2按钮，电机就会开始旋转。 速度屏幕以图表形式显示实际旋转速度，以便您可以一目了然地看到运动情况。 令人印象深刻的是 ：当马达第一次转动时，我忍不住大喊：“耶！” 实时观察图表的变化也很有趣！ 7. 操作检查和故障经验 关闭演示程序，然后断开电机电源（DC24V）。 MCAT屏幕将显示故障原因，主机板上的红色LED指示灯将闪烁。 重新接通电源，LED 停止闪烁后，点击“M1 故障清除”清除故障。 重要提示 ：如果故障仍然存在，电机将无法运转，因此请务必清除故障。 自由控制电机转速！ 当您在“速度”屏幕上打开“M1应用程序开关”时， 应用程序启动后，您可以根据需要更改速度。 如果你想朝相反的方向旋转，只需输入一个负值，例如“-1000”！ 玩法说明： 您可以尝试不同的速度和反转旋转，体验电机控制的乐趣！ 如果我与董事会沟通出现问题怎么办？ 如果您无法使用 FreeMASTER 与电路板通信， 转到“项目”菜单 → “选项” → “通信”选项卡，设置正确的 COM 端口和波特率 (115200bps)。 如果您不知道 COM 端口，可以尝试“COM_ALL”！ 8. 调试 调试功能允许您详细观察程序的运行情况。 设置断点以检查变量值和处理流程。 给初学者的建议 我们建议您从行为容易理解的区域开始调试，例如“主函数”或“中断处理”。 9. 部分软件代码的解释   项目详情 接下来，我们将向工程师们解释实际的项目结构和主要源代码。 项目结构 自由大师 一款实时调试监视器和数据可视化工具，支持运行时配置和调优。通过 UART/USB 通信，并包含 MCAT 插件。 电机控制 包括电机状态机、矢量控制代码、电机识别程序和底层驱动程序。 rtcesl 一系列用于复杂实时控制应用（包括电机控制）的数学库，涵盖从高级变换到观察器等各种功能。 来源 主要处理、初始化、配置等。 主处理和中断 main.c 执行初始化、中断设置和 FreeMASTER 通信等后台任务。 中断处理程序有两种类型：高速（ADC 同步）和低速（定时器同步）。 高速回路是矢量控制算法，低速回路是速度控制和 LED 状态管理。 要点 ： “motor_control” 文件夹包含电机控制逻辑。 如果您发现感兴趣的函数或变量，请务必查看注释和文档！ 10. 总结与预览 这次，我们有机会体验使用 NXP 的开发环境运行电机控制示例。 在下一期中，我们将深入研究示例代码，并尝试修改参数来创建您自己的电机控制系统！ （预计四月发布） 如果您有任何疑问或不理解的地方，请在评论区留言！ 这是一个汇总了有关恩智浦电机控制文章的网站： NXP电机控制 - 概要页面 - （日语博客） ============================​ 进行咨询时，请同时参考“如何就技术问题联系 NXP（日语博客） ”。 （如果您已经是恩智浦的分销商或与恩智浦有业务往来，您可以直接联系负责人。） 本文将以浅显易懂的方式讲解如何使用NXP FRDM控制板“FRDM-MCXA156”进行电机控制。文章分为基础知识部分和实践部分，您可以先选择感兴趣的部分进行阅读。 ・基础知识①～⑦，实践①～③ 这次，作为实践部分的第二部分，我们将介绍从软件设置到实际运行电机控制示例代码的所有内容。 MCUXpresso 配置工具 MCUXpresso IDE MCUXpresso SDK MCX 电机控制 技术聚焦 日本博客

Import and start developping Using Visual Studio Code (VSC) on KW47 As the support for MCUXpresso IDE as GUI and toolchain will be stopped and will be replaced by MCUXpresso for Visual Studio Code, I am sharing here some essential steps to start development on Visual Studio Code and MCUXpresso plugin. Preparation: - MCUXpresso for VS Code is installed as an extension inside Microsoft VS Code - see https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-for-visual-studio-code:MCUXPRESSO-VSC - The rest of the toolchain including ARMGCC, west and other tools which work with MCUX for VS Code installation is available via MCUXpresso SDK option of the MCUXpresso Installer: https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-installer:MCUXPRESSO-INSTALLER - See also generic Getting Started Guide for MCUX SDK with MCUX for VS Code at: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/gsd/run_a_demo_using_mcuxvsc.html Here I will provide the procedure to import the loc_reader example from the repository. Import the repository: The recommended approach is to import REMOTE ARCHIVE which has a similar environment as the legacy MCUXpresso IDE. Here I will provide the procedure to import the loc_reader example from the repository From the MCUXpresso plugin, select "Import Repository", then in the "REMOTE ARCHIVE" tab, select the board, the SDK version and the location: Wait for the repository to be imported, this procedure can take several minutes. Once the import is succeed, it will appear here: Import demo projects and run: Once the repository is successfully imported, you can then import demo examples from the repo by selecting "Import Example from Repository": then select the demo example from "Template". "AppType" should be "Freestanding application" if you want a standalone project. "Location" is where the project will be located.  "Toolchain" should be the Arm GNU one that you installed in preparation steps Build and run the imported project:

高レベルの宣言型UIフレームワーク i.MX RT クロスオーバー MCU 用の高レベルの宣言型 UI フレームワークはありますか?Swift や JavaScript のような高級言語でコードを記述し、SwiftUI や React に似たものを使用して UI を作成できるようになりたいです。 Re: High level declarative UI framework こんにちは@MatthewRuzzi 、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 NXP は、LVGL を基盤フレームワークとして、お客様が UI ソフトウェアを迅速に開発できるようにするために、GuiGuider ツールを公式に提供しています。さらに、SDK には emWin および VGLite のサンプル プロジェクトが含まれています。高水準言語の実装は現在公式にはサポートされていませんが、次のアプローチを検討することをお勧めします。 1. https://doc.qt.io/QtForMCUs/qtul-zephyr-mimx1060-evk.html https://www.embeddedartists.com/wp-content/uploads/2023/06/QtMCUs_ProgramDevelopment.pdf 2 https://www.nxp.com/design/design-center/training/TIP-CREATE-USER-INTERFACE-QT 3. https://docs.microej.com/en/latest/GettingStarted/gettingStartedIMXRT1170.html 4. https://github.com/lvgl/lv_micropython 5. https://www.swift.org/blog/embedded-swift-examples/ これらのリソースがあなたの成長に刺激を与えることを願っています。 よろしくお願いします、 ギャビン Re: High level declarative UI framework 現在これに取り組んでいるプロジェクトはありますか?Swift や JavaScript のような言語を使用できるようになりたいです。将来的にこれを可能にするために私ができることはありますか?機能リクエストを送信または投票する場所、またはこれを投稿する他の場所はありますか?

i.MX93 M33 Core: How to get System Uptime (sec/nsec) for micro-ROS on Custom Board? Hi everyone, I am currently porting micro-ROS to the Cortex-M33 core of an i.MX93 (MIMX9352) using a custom SOM and the MCUXpresso SDK (v25.06.00).  have successfully established a UART transport and connected to the micro-ROS agent. My nodes and topics are created, but published data appears empty/invalid. After debugging, I’ve realized I need to provide high-resolution timestamps (seconds and nanoseconds) to the micro-ROS client to synchronize with the ROS 2 ecosystem. Screenshots, Debug terminal output, Codes are attached below. Micro-ros agent connection Micro-ros agent connectionMicro-ros agent connectionMicro-ros agent connection ROS Topic listing (Topic is emtpy (data not publishing)) ROS Topic listing (But topic is empty)ROS Topic listing (But topic is empty)ROS Topic listing (But topic is empty) Debug terminal output: Debug Console Init done Past lpuart init and custom trnsport open Past rclc support,node,publisher init Past rclc timer init Past rclc executor init, add_timer Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin Inside while loop RCSOFTCHECK Failed: rclc_executor_spin_some(&executor, RCL_MS_TO_NS(100)) | Lin0 after executor spin The Problem: I am struggling to find a reliable "System Uptime" or "Tick" function in the SDK that provides the precision required for rmw_publisher_publish. I tried using the lptmr driver examples, but the code hangs during LPTMR_Init() My Questions: Is there a recommended SDK API for getting a high-resolution (nsec) monotonic timestamp since boot on the i.MX93 M33? For those who have implemented micro-ROS on i.MX9 series: Did you use a dedicated hardware timer, or is there a standard CMSIS/SDK "GetTime" function I should be using instead? Environment Details: Hardware: Custom i.MX93 SOM + EVB Baseboard Core: Cortex-M331 SDK: 25.06.00 Toolchain: MCUXpresso IDE / VS Code Extension2 Any insights or code snippets for a 64-bit nanosecond counter implementation on this platform would be greatly appreciated! Regards, Anandhu Re: i.MX93 M33 Core: How to get System Uptime (sec/nsec) for micro-ROS on Custom Board? Hi, I have tried the tstmr.c demo program in the SDK example. It's not working as expected, tried in two different boards one custom board and avnet osm93, both of them doesn't gave any output in the terminal. Upon debugging it's the TSTMR related functions are not working, the program's not going past "TSTMR_ReadTimeStamp()". SDK Used : MCUXpresso SDK (v25.06.00).

Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Running MCUXpresso IDE V25.6.136 + evkmimxrt685 board with SDK_25_12_00. When debug starts all debug tool (resume ..) are greyed out and cannot run the project.  Works fine with older SDK_25_03_00 but same problem with SDK_25_06_00 and SDK_25_09_00.  How can i restore the debug tools Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, Posting the screenshot> It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. It never get to the main() to start the run.  I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?.   Thanks  bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?. I do have a screenshot but how do i post it. Thanks @bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Could you please share which OS your compute has? Linux, Windows 10, Windows 11? Could you please review the BOOT_SEL of the EVK to be properly selected? Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing the details about your setup. Could you please do a mass erase of the flash, and retry to debug it?  To do it please change the link server action at the QuickStart Panel after that return it to Debug using LinkServer probes. Please share a screenshot if you have any error message in the process.  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 I am running Windows 11 on a Dell Alder Lake desktop. The boot jumper (JP1) is open which is the default according to the manual (MIMXRT685-AUD-EVKUM Rev 3 - 21 July 2023). I presume this is what you meant by "review BOOT_SEL of the EVK". Thanks bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos, Thanks. Before I do this i wanted to let you know that I have always used the SEGGER J-Link probes and there is "erase flash action using SEGGER J-Link probes" menu option. Should i erase using that or using the link server probes as you mentioned above. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos,  I tried to do a mass erase with the link server but got an error message - screenshot attached.  Thanks  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos,  I deleted the Flash using the Segger J-Link Probes (not the link server probes as that firmware was overwritten by the Segger firmware).  I understand I must use the Segger probes to debug both the ARM core and HiFi4 DSP.  I also updated the Segger firmware to the latest version 8.98.  I deleted the debug launch file,  deleted the workspace to generate a new one on bootup and also power cycled the board.  Still the same problem.  It says a debug session is running but I'm not able to debug.  As i said this happens with all versions after 03 (06, 09 and 12).  It stops at the startup_mimxrt685s.c file as before.    In the debugger console I do see a warning  message but this is probably harmless.  "warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report. monitor exec SetRestartOnClose=1 Please advise next steps. Thanks bobvr. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing that you are using. The issue persists if you try to debug with link server? Please share the error message in case you get one. 

CSEC GenerateMACAddrMode アドレス範囲 メリークリスマス こんにちは CSECのGenerateMACAddrMode関数を使用していたところ、アドレス値が0x7DFFFを超えるとエラーが発生します。これは普通ですか？ Re: CSEC GenerateMACAddrMode address range 私のせい つまり512KBからCANができない CSEC_DRV_GenerateMACAddrMode(CSEC_RAM_KEY、(uint8_t *)0x0007FFFC、0x00000080、(uint8_t *)cmacout); ただし、addr = 0x0007FFFC、len = 0x00000080 を使用します エラーもありませんが、範囲外です Re: CSEC GenerateMACAddrMode address range こんにちは@SaLan これは、Addr モード（ポインター方法とも呼ばれます）の CMD_GENERATE_MAC コマンドの制限です。 パーティション（つまりブロックサイズは派生に応じて128KB、256KB、または512KBになります。 よろしくお願いいたします。 ルーカス

Understanding LPC55S6x Revisions and Tools At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                   NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will result in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:        Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1 Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer   LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect: For PRINCE encrypted region, partial erase cannot be performed Fixed Defect: For PUF based key provisioning, a reset must be performed Fixed Defect: Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect: Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect: PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:   The English and Chinese version documents are attached.   LPC Marketing LPC55xx 中国用户论坛

使用 i.MX 95 SPSDK 实现安全启动（日本博客） 介绍 本文档描述了使用 安全配置 SDK (SPSDK) 在 i.MX 95 上创建和启动签名容器镜像以进行安全启动的过程。 除了经典的 RSA 和椭圆曲线数字签名 (ECDSA) 之外，i.MX 95 还支持后量子密码 (PQC) ML-DSA 作为安全启动数字签名算法。 在这里，我们将通过一个示例来探讨如何使用混合启动来实现 ECDSA 和 PQC ML-DSA 签名认证。 安全启动过程（概念图） 创建签名图像 SRKH：超级根密钥哈希 i.MX 95 AHAB（高级高精度启动）安全启动流程 本文假设您已经为i.MX 95 构建过一次 Linux BSP。 请参考以下文章了解如何构建该项目。 构建目标必须是 i.MX 95 的机器名称，但方法类似。 【新手指南】如何构建 Yocto Linux BSP - i.MX FRDM 开发板版（日语博客） 【新手指南】如何构建 Yocto Linux BSP - i.MX 8M Plus 版 本次测试所用的环境 硬件： i.MX 95 19x19 LPDDR5 EVK开发板 软件：Linux BSP 版本 L6.18.2-1.0.0 工具：SPSDK 版本 3.9.0Linux 版本 如果您使用 eMMC/SD 启动，则可以对FRDM i.MX 95 开发板（FRDM-IMX95 / LPDDR4X 兼容）执行相同的程序。 目录 1. Linux BSP 的准备工作 2. 安装 SPSDK 3. 密钥创建 4. 准备 YAML 文件 5. 准备工作空间 6. 创建签名图像 7. 引入签名图像 8. SRKH（超级根密钥哈希）eFuse 程序 9. 将生命周期更新为 OEM 关闭。 10. 检查 ELE 事件 11. 直接对引导加载程序进行签名   eMMC/SD启动和FlexSPI NOR启动的准备步骤和命令略有不同。因此，请按照您要测试的启动设备对应的步骤进行操作。 1. Linux BSP 的准备工作 1.1 引导加载程序 FlexSPI NOR 启动 BSP 的默认引导加载程序配置为 eMMC/SD 引导。 对于 FlexSPI NOR 启动，请将以下内容添加到 / /conf/local.conf 文件中。 UBOOT_CONFIG = "fspi" eMMC/SD/FlexSPI NOR启动通用 使用启用了u-boot CONFIG_AHAB_BOOT 的引导加载程序构建。 $ cd $ source setup-environment $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c configure $ bitbake u-boot-imx -c devshell 将会打开一个单独的 shell，您可以在其中修改 u-boot 配置。 # make O=../../build/ / menuconfig 使用 O= 指定的构建目录路径应根据您的实际环境进行调整。 ../../build/ /.config然后，确认显示 CONFIG_AHAB_BOOT=y 并返回到原始 shell。 # exit 使用原始 shell 重新构建。 $ bitbake u-boot-imx -c compile -f $ bitbake imx-boot 1.2 Linux 内核和设备树 我们将直接使用用 BSP 构建的二进制文件。 构建好的二进制文件创建在 BSP 的 /tmp/deploy/images/ / 目录中。 2. 安装 SPSDK 请按照SPSDK 安装指南准备和安装 Python 虚拟环境 (venv)。 安装完成后，检查是否可以查看版本信息和帮助。 (venv) $ spsdk --version (venv) $ spsdk --help 我们还将添加 PQC 插件。 (venv) $ pip install spsdk-pqc 3. 密钥创建 我们将为 ECDSA SECP384 创建四对私钥/公钥。 (venv) $ mkdir -p keys/secp384r1 (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk0_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk1_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk2_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk3_secp384r1.pem 我们还将为 PQC ML-DSA 创建四对私钥/公钥。 (venv) $ mkdir keys/mldsa65 (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk0_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk1_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk2_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk3_mldsa65.pem 将公钥哈希（超级根密钥哈希 - SRKH）写入 i.MX 95 的内置 eFuse 后，在重建镜像时，需要使用与该公钥配对的私钥对其进行签名，因此请保存您创建的所有密钥。 我不会将我的私钥透露给任何第三方。 4. 准备 YAML 文件 在 SPSDK 中，YAML 文件指定容器头设置、私钥、公钥以及构成签名镜像的二进制文件的路径。 请同时参考本次操作验证中使用的示例 YAML 文件。 YAML 文件中的容器头部设置和键规范字段如下： 容器头部 YAML 键 内容 srk_set SRK 套装 已使用的 srk_id SRK精选 srk_revoke_mask SRK撤销面具 gdet_runtime_behavior GDET 启用 检查所有签名 请核对所有签名。 口袋 快速启动 熔丝版本 熔丝版 sw_version SW 演化 容器标头中的每个字段都在i.MX 95 参考手册的“容器标头详细信息”部分中进行了描述。 主要规格 YAML 键 内容 签名者 经典私钥 签名者#2 PQC私钥 srk_table 经典公钥表 srk_table_#2 PQC公钥表 在所有 YAML 文件中指定相同的键。 4.1 引导加载程序的 YAML 文件 创建 YAML 文件模板，并准备 spl.yaml 和 uboot.yaml。 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_template.yaml (venv) $ cp ahab_template.yaml spl.yaml (venv) $ cp ahab_template.yaml uboot.yaml spl.yaml 指定文件，直到它们被加载到 i.MX 95 的内部 SRAM 中，并执行 DRAM 初始化训练等。 YAML 键 内容 二进制容器 ELE 启动固件（特定于掩码版本） lpddr_imem LPDDR4X 或 5 初始化固件 lpddr_imem_qb LPDDR4X 或 5 初始化固件 lpddr_dmem LPDDR4X 或 5 初始化数据 lpddr_dmem_qb LPDDR4X 或 5 初始化数据 oei_ddr OEI 系统管理器 系统管理器 spl U-boot SPL cortex_m7_app（选项） M7图像 image_path（选项） FCB 复制生成 uboot.yaml U-boot SPL 指定要加载到 DRAM 中的文件。 YAML 键 内容 脚气 ARM 可信固件 uboot U-boot T恤（可选） OP-TEE OS（选项） 4.2 移除 FCB - 仅 FlexSPI NOR 启动 用于 FlexSPI NOR 启动的 YAML 文件也指定了 FCB（FlexSPI 配置块）。因此，为 FlexSPI NOR 启动构建的标准未签名引导加载程序 (flash.bin)...接下来，我们将使用 SPSDK 命令提取 FCB。 i.MX 95 内置的 eFuse 的 FCB 位于 FlexSPI_NOR_FCB_Offset（默认值为 0x400）。从该偏移量提取 512 字节以创建 fcb.bin。 (venv) $ nxpimage utils binary-image extract -b flash.bin -a 0x400 -s 0x200 -o fcb.bin 4.3 操作系统容器的 YAML 文件 根据 YAML 文件模板准备 os_cntr.yaml 文件。 (venv) $ cp ahab_template.yaml os_cntr.yaml 在 os_cntr.yaml 中，键image_path设置要使用的 Linux 内核和设备树的路径，并设置其他必要的参数。 4.4 数字签名算法的选择 这将使用 i.MX 95 的内置 eFuse 或容器标头中的标志进行选择。 eFuse 容器头部中的标志字段 通过在容器头的标志字段中设置“位 15：检查所有签名”= 0x1，无论 eFuse 中的 ELE_BOOT_CRYPTO 设置如何，容器内的所有签名都将进行身份验证。 容器标头的 Flags 部分中的“检查所有签名”字段由 YAML 键“check_all_signature”指定。 5. 准备工作空间 在 SPSDK 中创建一个工作区，并将必要的密钥文件、YAML 文件和二进制文件放置在其中。 5.1 创建工作区 (venv) $ nxpimage bootable-image get-templates -f mimx9596 -o workspace 5.2 密钥文件 我会把生成密钥时创建的整个 `keys` 文件夹导入过来。 5.3 YAML 文件示例 用于测试的 YAML 文件附加在imx95-spsdk-yaml-examples.tar.gz中。 5.4 二进制文件 如果您想从 Yocto Linux BSP 获取二进制文件， 构成引导加载程序的二进制文件 从 $ bitbake -e imx-boot | grep ^S= 显示的路径中复制位于 iMX95/ 中的二进制文件。 Linux 内核 / /tmp/deploy/images/ /Image-- - - .bin复制此内容。 设备树 复制位于 / /tmp/deploy/images/ / 目录下的 dtb 文件，选择您想要使用的其中一个。 如果您使用示例 YAML 文件， Linux内核是一个镜像。 设备树文件为 imx95.dtb 它们将被归入这些名称之下。 5.5 eMMC/SD 启动 文件结构如下： 如果使用示例 YAML 文件，请根据 DRAM 类型将 spl.yaml 从 emmc_sd/spl-lpddr4x.yaml 或 spl-lpddr5.yaml 重命名，并将其放置在正确的位置。 在上述示例中，RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img（B0 掩码）。 5.6 FlexSPI NOR 启动 文件结构如下。此外，还需要 fcb.bin 文件。 如果您想使用示例 YAML 文件，请从 fspi_nor/ 复制 bootable_image_fspi_nor.yaml。 另外，将 spl_fspi_nor-lpddr5.yaml 重命名为 spl.yaml 并将其放置在正确的位置。 在上述示例中，RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img（B0 掩码）。 6. 创建签名图像 我们将使用 SPSDK 创建已签名的引导加载程序和已签名的操作系统容器镜像。 导航至工作区准备期间创建的目录，并开始在该目录中工作。 (venv) $ cd workspace/imx_boot_flash_all/imx95-19x19-lpddr5-evk/ 6.1 签名引导加载程序 spl.yaml 和 uboot.yaml 文件分别指定密钥文件和二进制文件，它们由 bootable_image.yaml 调用。 将创建一个已签名的引导加载程序 signed_flash.bin 和一个用于 SRKH eFuse 程序的脚本 (*.bcf)。 eMMC/SD启动 (venv) $ nxpimage -v bootable-image export --config bootable_image.yaml -o output/signed_flash.bin 将显示以下信息。 FlexSPI NOR 启动 (venv) $ nxpimage -v bootable-image export --config bootable_image_fspi_nor.yaml -o output/signed_flash.bin 将显示以下信息。 与 eMMC/SD 的一个区别是，它以“FCB”开头。 您可以执行图像验证。 // eMMC / SD ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m serial_downloader // FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m flexspi_nor 6.2 已签名操作系统容器 os_cntr.yaml 的内容将用于创建已签名的操作系统容器镜像。 (venv) $ nxpimage -v ahab export -c os_cntr.yaml 将显示以下信息。 您可以执行图像验证。 (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/os_cntr_signed.bin -m serial_downloader 7. 引入签名图像 本文档解释了如何安装您创建的已签名引导加载程序和已签名操作系统容器。 7.1 签名引导加载程序 将 signed_flash.bin 写入 i.MX95 板的启动设备。 将开发板的调试端口和串口下载端口连接到您的电脑。 如果 u-boot 启动，则切换到 fastboot 模式。 u-boot=> fastboot 0 或者，您可以以串行下载模式启动系统 BOOT_MODE。 我们将使用SPSDK编写程序。 // eMMC (venv) $ nxpuuu write -b emmc -f mimx9596 output/signed_flash.bin // SD (venv) $ nxpuuu write -b sd -f mimx9596 output/signed_flash.bin // FlexSPI NOR (venv) $ nxpuuu write -b qspi -f mimx9596 output/signed_flash.bin 也可以使用标准的 uuu 或 u-boot 命令而不是 SPSDK 的 nxpuuu 命令来刷写设备。 7.2 已签名操作系统容器 将 os_cntr_signed.bin 放入已写入 BSP 映像的 eMMC 或 SD 卡的启动分区中。 u-boot 命令使 i.MX95 连接的 eMMC 或 SD 卡显示为 USB 存储设备，从而可以将其挂载到 PC 上。 串口下载端口必须连接到您的电脑。 // eMMC u-boot=> ums mmc 0 // SDカード u-boot=> ums mmc 1 将 os_cntr_signed.bin 复制到挂载到 PC 上的启动分区后，在 u-boot 中按 Ctrl-C。 或者，您可以使用另一种方法将 os_cntr_signed.bin 放入启动分区。 启动已签名的操作系统容器时，将显示以下消息： CONFIG_AHAB_BOOT 启用u-boot 后，将使用 os_cntr_signed.bin（已签名）镜像，而不是常规的 Linux 镜像（未签名）。 7.3 运行检查 在该阶段，i.MX95 的生命周期状态为 OEM Open，因此 u-boot 或 Linux 将启动，但会在ELE 事件中检测到密钥哈希验证失败。 8. SRKH（超级根密钥哈希）eFuse 程序 8.1 eFuse 写入 将公钥的哈希值写入 i.MX 95 SRKH eFuse。 一旦写入，就无法撤销。 当在写入的设备上更新已签名的引导加载程序或已签名的操作系统容器时，将使用作为写入的 SRKH 底层公钥对的私钥对其进行签名。 如果您想使用不同的密钥对，请撤销当前的 SRKH，并使用您创建的四个未使用的密钥对之一。 将 i.MX 95 板的串行下载端口连接到您的 PC，并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 SRKH eFuse 编程脚本 (*.bcf) 在创建签名映像期间创建。我们将使用此方法并使用 SPSDK 编写程序。 SRKH eFuse 编程脚本包含 i.MX 95 eFuse 的字索引。 // OEM_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk0_hash_nxpele.bcf // OEM_PQC_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk1_hash_nxpele.bcf 8.2 检查 eFuse 值 您可以使用 SPSDK 的 nxpele 命令指定 eFuse 的字索引并读取它以检查其值。 // OEM_SRKH[31:0] word index = 128 (venv) $ nxpele -f mimx9596 read-common-fuse -i 128 // OEM_PQC_SRKH[511:480] word index = 463 (venv) nxpele -f mimx9596 read-common-fuse -i 463 など 或者，您可以使用 U-boot 命令或系统管理器监视器命令通过读写操作访问 eFuse，而不是使用 SPSDK。 U-boot u-boot=> 熔丝读取 u-boot=> fuse prog 系统管理器 >$ fuse.H >$ fuse.w 8.3 运行检查 现阶段，i.MX 95 的生命周期状态为 OEM 开放，但由于它已编程为 SRKH，除非被篡改，否则不会检测到ELE 事件。 即使发生篡改，如果该部分不影响操作，它将启动 OEM Open，但身份验证失败将在ELE 事件中检测到。 9. 将生命周期更新为 OEM 关闭。 i.MX 95 在出厂后的生命周期为 OEM 开放式。 调试完成后，将 i.MX 95 生命周期更改为 OEM 关闭。 关闭OEM后需要注意的几点 您无法恢复到OEM Open 模式。 CONFIG_AHAB_BOOT=y 使用包含 u-boot 的引导加载程序启动时，未签名的镜像和签名无效的镜像将无法启动。 CONFIG_AHAB_BOOT=y 如果引导加载程序包含 u-boot 但未进行此设置，则可以使用未签名的 Linux 镜像启动。因此，为确保始终启动操作系统容器 os_cntr_signed.bin，请使用包含 u-boot 且设置了 CONFIG_AHAB_BOOT=y 引导加载程序。 验证功能后，未签名的 Linux 镜像和设备树将从启动分区中删除。 9.1 SPSDK 将 i.MX 95 板的串行下载端口连接到您的 PC，并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 使用 SPSDK 更新生命周期。 (venv) $ nxpele -f mimx9596 forward-lifecycle-update -l OEM_CLOSED Forward Lifecycle update ends successfully. (venv) $ 9.2 U-boot u-boot=> ahab_close 即使将设备标记为 OEM 关闭，使用 uuu 写入 BSP 映像（wic 文件）时，仍然需要使用签名引导加载程序。 10. 检查 ELE 事件 ELE（Edgelock Secure Enclave）是 i.MX 95 中的一个内置模块，用于在安全启动期间验证容器镜像。 您可以使用 SPSDK、U-boot 和系统管理器命令检查 ELE 状态。 10.1 SPSDK 请先将串口下载端口连接到您的电脑，并使用 U-boot 进入 fastboot 模式，然后再继续操作。 u-boot=> fastboot 0 我们将使用 SPSDK 检索 ELE 事件。 (venv) $ nxpele -f mimx9596 get-events 10.2 U-boot CONFIG_AHAB_BOOT=y 这些是可以与 U-boot 一起使用的命令。 根据设备的生命周期，还会显示它是 OEM 开放式还是 OEM 封闭式。 u-boot=> ahab_status 10.3 系统管理器 >$ ele events 10.4 显示示例 当检测到ELE事件（SRKH值不匹配）时 SPSDK U-boot（当 OEM 打开时） 系统管理器 当未检测到ELE事件时 SPSDK U-boot（OEM 闭环后） 系统管理器   11. 直接对引导加载程序进行签名 也可以使用 SPSDK 直接向现有的未签名引导加载程序二进制文件添加签名。 在这种情况下，SPSDK 会解析来自引导加载程序二进制容器的配置。 虽然不能在 YAML 文件中为每个镜像指定详细设置，但只需指定容器头设置以及私钥和公钥的路径，即可创建签名引导加载程序。 11.1 模板创建 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_sign.yaml --sign (venv) $ cp ahab_sign.yaml sign.yaml 11.2 YAML 文件 在 sign.yaml 中指定容器头部设置以及私钥和公钥的路径。 如果您使用的是示例 YAML 文件，请复制 direct_signing/sign.yaml。 11.3 添加签名 现有的引导加载程序二进制文件 flash.bin 将被签名。 // eMMC / SD (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output // FlexSPI NOR (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output -m flexspi_nor output/flash_directsign.bin 和 SRKH eFuse 编程脚本 output/*.bcf这将被创建。 综上所述 本文档介绍了如何使用 SPSDK 为 i.MX 95 安全启动创建签名镜像并启动该镜像，以保护 SoC 启动镜像。本示例演示了如何使用 PQC（i.MX 95 AHAB 中新增的功能）来完成此过程。 ========================= 即使您在本文的“评论”栏留言，我们目前也无法回复。 给您带来不便，我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 （如果您已经是NXP的代理商或与其有合作关系，可以直接向负责人咨询。） 本课程提供实践学习体验，讲解如何使用 安全配置 SDK (SPSDK) 创建和启动签名容器镜像，以便在 i.MX95 上进行安全启动。 本文档提供了一个示例，说明如何在混合启动环境中同时使用椭圆曲线数字签名密码学 (ECDSA) 和后量子密码学 (PQC) ML-DSA 来实现签名认证。 （预计工作时间：半天 *假设 i.MX 95的Linux BSP 构建已经完成一次） i.MX 处理器 安全 日本博客

DMA MUX Currently I am using, S32 Platform 3.4 programming environment, RTD is 2.0.0 During my use of DMA I found that the RM module I created does not have a Dma Mux, how to solve this situation. Re: DMA MUX Thank you. Re: DMA MUX Hi @xuanming  The example was implemented using a newer RTD version than the one you are currently working with; therefore, changes were introduced to the driver implementation. As you are working with RTD 2.0.0, you should refer to the Dma_Ip driver. Starting from RTD 3.0.0, the DMAMux Source configuration was moved to the RM module at the MCAL layer, which explains the difference you are observing. Additionally, we recommend updating to the latest RTD version whenever possible. This helps avoid known issues and ensures you benefit from the most recent fixes, enhancements, and improvements. BR, VaneB

问题使用统一引导加载程序演示在 S32K144EVB 上安装 CAN + UDS 引导加载程序 你好，恩智浦社区、 我目前正在使用 S32K144EVB 板和 S32 Design Studio v3.4。我对汽车引导加载程序还不熟悉，我想实现一个基于 CAN + UDS 的引导加载程序。 我在这里找到了 " Unified Bootloader 演示 "： （参考：在恩智浦社区发布的统一引导加载程序演示 ） 统一引导加载程序演示 我的问题 如何使用 S32DS 3.4 为 S32K144EVB 目标正确移植/构建这个 Unified Bootloader？ 演示版是否已经支持 UDS 服务，如 RequestDownload (0x34)、TransferData (0x36) 和 RequestTransferExit (0x37)，还是需要手动扩展？ 在 S32K144 上进行此演示时，推荐的 CAN 传输层是什么（ISO-TP 与自定义）？ 是否有任何通过 CAN 实现 UDS 刷新的 S32K144 的官方恩智浦引导加载程序示例或 AN（应用笔记）？ 对于初学者来说，统一引导加载程序是推荐的方法还是 S32K144 引导加载程序还有其他更简单的参考设计？ 我的目标是使用 UDS 服务，通过 CAN 从 PC 工具执行固件刷新。任何文档方面的指导、示例或设置说明都将不胜感激。 目标详情： MCU：S32K144EVB IDE：S32DS 3.4 通信：CAN 所需的协议：UDS 传输 感谢您的支持。 谢谢、 Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 在不使用统一引导加载程序演示堆栈的情况下，是否有其他资源或方法可以实现这一任务，请为我提供指导。 Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 嗨，@NagulMeera、 很抱歉，社区上分享的统一引导加载程序只是非官方演示，不提供任何保证和支持。目前，我们还没有支持该演示的资源。我将尝试通过他们的文档回答您的问题，但如果出现后续问题，请联系他们的支持页面。 Q1.统一引导加载器演示项目发布已经有一段时间了。它将 S32DS 用于 ARM 2018.R1 和 SDK 2.0.0。如果您需要将其移植到 S32DS v3.4、你需要手动操作，或者尝试 " migrate " 选项，如以下视频所示：视频：将 S32K1 项目从 ARM 和 SDK 3.0.x 的 S32DS 迁移到 S32DS 3.4 和 SDK 4.0.2。 请注意，这是针对 SDK SW 的，如果使用 RTD，该选项可能无法正常工作。 Q2. & Q3. 您是否阅读过 统一引导加载器 - 用户指南& 它们的《UDS 引导加载器实施指南》？我可以从中看到，0x34、0x36& 0x37 服务已经实现： 此外，UBLUG 还提到以下内容："TP：当前版本的 TP 包括 CAN 和 LIN。CAN TP 基于 ISO15765-2，LIN TP 基于 ISO17987-2。" 。ISO15765-2 即 ISO-TP。 Q4。& Q5。有关基于 CAN 的固件更新，您可以参考以下应用笔记：AN12323：S32K1xx 固件更新 — 应用笔记。具体而言，场景（1）显示了如何通过CANFD接收新固件来处理固件更新的步骤。 致以最诚挚的问候， Julián Re: Question: CAN + UDS Bootloader on S32K144EVB using Unified Bootloader Demo 嗨，@NagulMeera、 是的。我在上次回复中分享了它们：AN12323：S32K1xx 固件更新 — 应用笔记。 它包括第 7.1.1 节中的引导加载程序演示。 该应用笔记还附带了 S32K144 开发板的可下载软件。请阅读有关项目的应用笔记。 致以最诚挚的问候， Julián