Capturing CPS with CRANK, mpc5775e Hi, I am using the NXP eTPU CRANK function with a 36-2 crank wheel. The CPS signal is generated with an increasing RPM (acceleration profile). The CRANK parameters (gap_ratio, win_ratio_normal, win_ratio_across_gap, win_ratio_after_gap, and win_ratio_after_timeout) are calculated using the Excel sheet provided with the Function Selector. After the engine position reaches FS_ETPU_ENG_POS_PRE_FULL_SYNC, I call fs_etpu_crank_set_sync() once to synchronize TCR2. I verified that synchronization is applied correctly by checking the TCR2 value before and after the call; it changes by the expected amount. To calculate RPM, after the CRANK state changes from FS_ETPU_CRANK_TOOTH_AFTER_GAP, I copy the tooth period log using fs_etpu_crank_copy_tooth_period_log(), calculate the average tooth period, and then calculate RPM. The first RPM value is calculated correctly. However, after one or a few revolutions, the CRANK function reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL. Once these errors occur, synchronization is lost and I can no longer calculate RPM. The confusing part is that if I reset the debugger and run the application again with exactly the same CPS signal and configuration, sometimes it continues running correctly and I can capture RPM values for a much longer time, while other times the errors appear almost immediately. Because the input signal and configuration are unchanged, I do not understand why the behavior is inconsistent. Could this be related to the window ratio parameters? If so, which parameter should I adjust first for an accelerating crank signal (win_ratio_normal, win_ratio_after_timeout, gap_ratio, etc.)? Is there a recommended procedure for tuning these parameters for rapidly accelerating signals? Thanks! Re: Capturing CPS with CRANK, mpc5775e Hello, My current assessment is that the most likely causes are either window margins that are too tight for the applied acceleration profile, or an incomplete reinitialization that results in different starting conditions after a debugger reset. At this point, I would not consider the root cause confirmed. Based on the information provided, the CRANK function initially achieves synchronization and produces valid RPM values, indicating that the basic configuration is functional. The issue appears later, when the function loses timing acceptance and eventually reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL. To efficiently narrow down the root cause, I would start with two simple experiments: Increase the relevant window ratios and observe whether the timeout/stall condition is delayed or eliminated. Repeat the test with a reduced acceleration slope and compare the behavior to the original profile. If the issue improves with wider windows or a slower acceleration ramp, this would strongly suggest that the failure is related to timing margins rather than a fundamental configuration issue. Best regards, Peter

NXPキーを使用したi.MX93のセキュアデバッグ SPSDKに含まれるnxpdebugmboxツールの現行バージョンには、「ROM NXPキーを使用して認証する」と説明されているパラメータ--nxp-keysがあります。 これはNXPがすべてのデバイスでセキュアデバッグをアンロックできるということでしょうか? はいの場合、OEM SRKキーへのセキュアデバッグを制限するヒューズはありますか？ Security Re: Secure debug on i.MX93 with NXP keys しかし、ELEを制御できればDDRメモリにアクセスでき、OEMドメインがELEドメインから要求するすべての暗号操作の入出力を監視できます。すべてのELEブロブをCAN復号できるため、デバイスに保存されているすべての秘密データにアクセスできます。DDRメモリへの書き込みが禁止されていなければ、OEMドメインにコードを注入することも可能です。 Re: Secure debug on i.MX93 with NXP keys こんにちは、 いいえ、NXPは--nxp-keysでOEMデバイスでセキュアデバッグをアンロックできません。 --nxp-keysフラグは、NXP/ELE内部デバッグドメイン（ROMに組み込まれたNXPキーを使用）のみを認証します。OEMのSoCデバッグドメイン(Cortex-A55、M33など)は完全に別個で、OEM自身のSRKキーでしかアンロックできません。 これを強化するための追加のヒューズは必要ありません。これは設計上、建築的な設計です。デバイスがOEM_CLOSEDライフサイクルに入り、OEM SRKハッシュが統合されると、ELEハードウェアはNXPキーがOEMデバッグドメインに対して一切の権限を持たないことを強制します。 よろしくお願いいたします。 アルド。

使用 CRANK 捕获 CPS，mpc5775e 您好， 我正在使用 NXP eTPU CRANK 功能，搭配 36-2 曲柄轮。CPS 信号随着 RPM 的增加而产生（加速我的）。使用函数选择器提供的 Excel 表格计算 CRANK 参数（gap_ratio、win_ratio_normal、win_ratio_across_gap、win_ratio_after_gap 和 win_ratio_after_timeout）。 当发动机位置达到 FS_ETPU_ENG_POS_PRE_FULL_SYNC 时，我调用 fs_etpu_crank_set_sync() 一次来同步 TCR2。我通过检查调用前后的 TCR2 值来验证同步是否正确应用；它的变化量符合预期。 为了计算转速，在曲轴状态从 FS_ETPU_CRANK_TOOTH_AFTER_GAP 改变后，我使用 fs_etpu_crank_copy_tooth_period_log() 复制齿周期日志，计算平均齿周期，然后计算转速。第一个转速值计算正确。 然而，在转动一两圈后，CRANK 函数会报告 FS_ETPU_CRANK_ERR_TIMEOUT 和 FS_ETPU_CRANK_ERR_STALL 错误。一旦出现这些错误，同步就会丢失，我将无法再计算转速。 令人困惑的是，如果我 RESET 调试器并使用完全相同的 CPS 信号和配置再次运行应用程序，有时它会继续正确运行，我可以捕获 RPM 值更长时间，而有时错误几乎立即出现。由于输入信号和配置均未改变，我不明白为什么会出现不一致的行为。 这是否与窗口比例参数有关？如果是这样，对于加速曲轴信号，我应该首先调整哪个参数（win_ratio_normal、win_ratio_after_timeout、gap_ratio 等）？对于快速加速的信号，是否有推荐的参数调整方法？ 谢谢您！ Re: Capturing CPS with CRANK, mpc5775e 你好， 我目前的评估是，最可能的原因要么是窗口边距对于所应用的加速我的来说太窄，要么是不完整的重新初始化，导致调试器RESET后起始条件不同。 目前，我认为根本原因尚未得到确认。根据提供的信息，CRANK 功能最初实现了同步并产生了有效的 RPM 值，表明基本配置是有效的。问题随后出现，当函数失去定时接受能力时，最终会报告 FS_ETPU_CRANK_ERR_TIMEOUT 和 FS_ETPU_CRANK_ERR_STALL。 为了有效地缩小根本原因的范围，我会先做两个简单的实验： 增加相关窗口比率，观察超时/停滞情况是否被延迟或消除。 以减小的加速度斜率重复测试，并将结果与原始我的进行比较。 如果通过扩大窗口或减缓加速斜坡来改善问题，则强烈表明故障与时间裕度有关，而不是与基本的配置问题有关。 顺祝商祺！ Peter

Zephyrにおけるi.MX95 FRDM EVK向けHDMI構成サポート こんにちは、NXP チームの皆様、 現在、Zephyr RTOSを使って i.MX95 FRDM EVK ボードを開発中です。 Linux側ではHDMI出力がすでにサポートされていて正常に動作しています。しかし、ZephyrでHDMIを有効にする方法や設定方法を知りたいです。 以下の点について教えていただけませんか? Zephyrはi.MX95 FRDM EVKのHDMI出力に対応していますか? もしそうなら、どんなドライバーやデバイスツリーの設定が必要ですか? ZephyrのHDMI用の参考実装やサンプルアプリケーションはありますか? どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK AEチームに確認しました。 現在、IMX95 ZephyrではHDMIはサポートされていません。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXP チームの皆様、 IT6263のリファレンスマニュアルかレジスタプログラミングマニュアルを探しています。 IT6263 HDMIブリッジの詳細なレジスタ説明(ビットレベルの定義付きレジスタマップ)を教えていただけるか、このドキュメントを入手する方法を教えていただけますか? 注:私は特にチップレベルのレジスタのドキュメント自体を探しており、Linuxカーネルドライバーのソースではありません。 ありがとう、 カルティケヤン M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263はNXP製品ではないため、NXPはこの装置のリファレンスマニュアルを提供していません。設定や初期化の詳細については、IT6263 Linuxドライバのソースコードをご参照ください。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK ご回答ありがとうございます。 Armサポートの具体的なお問い合わせメールアドレスやサポートポータルを教えていただけますか?もし直接の連絡先や適切なメールアドレスがあれば、とても助かります。この件については彼らに連絡してみます。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK アームサポートハブ: https://support.arm.com/support-cases   サポートお問い合わせフォーム:https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 私はZephyr OSでHDMIを成功裏に移植でき、現在CPU上で動作しています。次の目標はGPUで動かすように移植することです。 そのためにArm Mali-G310の技術リファレンスマニュアル、特にCSF/ファームウェアインターフェースのセクションが必要です。この書類はNXPサポートに依頼すべきでしょうか、それとも直接Armサポートにお問い合わせする必要がありますか? このリファレンスマニュアルにアクセスできれば、ZephyrのGPUポートを実装するのに非常に役立ちます Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Armサポートに直接お問い合わせください。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK ご回答とArmサポートリンクの提供に感謝します。 Arm Mali-G310技術リファレンス・マニュアルとCSF/ファームウェアインターフェースのドキュメントについてArmサポートにお問い合わせします。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 以下の情報がお役に立つかどうかご確認ください。もし違うなら、AEチームに連絡する必要があります。 Arm Mali-G310技術リファレンス・マニュアルはArmのドキュメントポータルから入手可能です:「Arm Developer / Arm ドキュメント」で「Mali-G310 Technical Reference Manual」または「Mali-G310 TRM」を検索してください。アクセスレベルに応じて、ArmアカウントやArmのドキュメント条件の承認が必要になる場合があります。 NXP i.MX95の作業に関しては、NXPの公開ドキュメントではMali-G310 GPUについてi.MX グラフィックスユーザーガイドを示しており、FRDM-i.MX95の起動ページはGPU使用状況の詳細についてそのガイドにリンクしています。FRDM-i.MX95のページには、このボードがMali-G310 GPU搭載と記載されており、詳細は i.MX グラフィックスユーザーガイドへのリンクがあります:https://www.nxp.com/docs/en/user-guide/UG10159.pdf  ここから始めましょう： Armのドキュメントポータル:https://developer.arm.com/documentation NXP i.MX グラフィックスユーザーガイド:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Armポータルと i.MX グラフィックスユーザーガイドへのリンクをありがとうございます。両方とも検討しましたが、私たちのニーズを満たしていませんでした。そのガイドにはLinuxでのGPUの使い方が説明されており、私たちはi.MX95(ベアメタルで、LinuxではなくZephyr使用)で自分たちの低レベルのGPUドライバーを書いています。ですから、これらの文書が提供するよりも低レベルのレジスターレベルの情報が必要です。 ARMポータルでTRMを検索しましたが、利用できません。 簡単に言うと、私たちの状況は以下のとおりです。   Mali-G310 GPUはある程度動作しています。GPUは正しく検出され、電源を入れてリセットされ、GPUファームウェアも正常にメモリに読み込みました。この段階までは全て正常に動作し、検証済みです。   私たちは一段階で行き詰まっています。GPUのファームウェアマイクロコントローラ(MCU)を起動することです。有効化しても、そのステータスは「無効」のままで、決して実行されません。エラーも割り込みも発生せず、単に起動しないだけです。   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXPチームの皆さん、 必要なドキュメントを求めてArmサポートにお問い合わせしたところ、以下の返信がありました。 「シリコンに障害が発生しているのを見かけたら、NXPサポートに連絡してください。繰り返しますが、これらの文書はシリコンベンダーのお客様に提供されるべきではありません。" 彼らの回答に基づき、NXPに支援を要請することにしました。 Zephyr OSでHDMIを有効にすることに成功し、現在CPUで動作しています。次の目標はGPUベースのレンダリングを有効にすることです。 進めるには、Arm Mali-G310技術リファレンスマニュアル、特にCSF/ファームウェアインターフェースのドキュメントが必要です。 Mali-G310 GPUはNXP i.MX95プラットフォームに統合されているため、このドキュメントへのアクセス方法を教えていただけますか?もしドキュメントを共有できない場合は、ZephyrでのGPU起動を続けるための代替のガイダンスや参考文献があれば教えていただけるとありがたいです。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK こんにちは、NXPチームの皆様。 必要なドキュメントを求めてArmサポートにお問い合わせしたところ、以下の返信がありました。 「シリコンに障害が発生しているのを見かけたら、NXPサポートに連絡してください。繰り返しますが、これらの文書はシリコンベンダーのお客様に提供されるべきではありません。" 彼らの回答に基づき、NXPに支援を要請することにしました。 Zephyr OSでHDMIを有効にすることに成功し、現在CPUで動作しています。次の目標はGPUベースのレンダリングを有効にすることです。 進めるには、 Arm Mali-G310技術リファレンスマニュアル、特に CSF/ファームウェアインターフェース のドキュメントが必要です。 Mali-G310 GPUはNXP i.MX95プラットフォームに統合されているため、このドキュメントへのアクセス方法を教えていただけますか?もしドキュメントを共有できない場合は、ZephyrでのGPU起動を続けるための代替のガイダンスや参考文献があれば教えていただけるとありがたいです。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK AEチームからの以下のアップデートをご参照ください。 Arm Mali-G310 TRMに関しては、この文書はArmの機密知的財産(IP)です。NXPはエンドお客様への転送が許可されていないため、NXPのチャネルを通じて実質的に利用できません。正式な申請は直接Armを経由しなければならず、時間がかかり、承認される可能性は低いです。さらに、i.MX95 GPUはまだ試作段階にあり、現時点で公式に検証されたベアメタル/Zephyrのリファレンスはありません。 有効化後にMCUが「無効化」のままになることについては、このステップにはTRMは必要ありません。完全なブートフローは、以下の2つの公開ソースで確認できます。どちらもGitHubから直接アクセス可能です。 Panthor — メインラインのドライバで、主に注目すべきもの(実際にMCUを起動し、i.MX95をサポートしています): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Armの公式ドライバ、クロスチェック用: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

S32K311 RTD 5.0 - 链接器错误：.non_cacheable_bss与 .int_results 溢出和重叠 您好，NXP团队： 我正在使用以下环境开发一个S32K311项目： MCU： S32K311 IDE： S32 设计工作室 3.6.7 RTD： S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR： 4.7 问题 项目初期进展顺利。 随着项目的推进，我启用并配置了多个 RTD 驱动程序，包括 ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCL 以及我的应用程序所需的其他外设。 集成这些驱动程序后，项目在链接阶段失败，并出现以下错误： .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status 存储器布局 默认链接器脚本包含以下 SRAM 区域： int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 链接器报告.non_cacheable_bss该部分超出分配的 int_sram_no_cacheable 区域约440 字节。 问题 在 S32K311 上启用多个 RTD 驱动程序时，这种内存使用量是否正常？ 是否有推荐的方法来减小 .non_cacheable_bss 的大小？ 是否建议修改链接器脚本并增加 int_sram_no_cacheable 区域？如果是这样，S32K311 的推荐内存布局是什么？ 是否有任何 RTD 配置选项可以减少分配给不可缓存部分的内存？ 有人在集成多个RTD外设时遇到过类似的问题吗？ 任何指导或建议都将不胜感激。 谢谢！ Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results 嗨@Esakki 以下讨论帖可能对您有所帮助，因为它们讨论了类似的问题，并提供了一些有用的故障排除建议。 int_sram_no_cacheable 问题 S32K312 的 SRAM 溢出 此外，还有一份 S32K3 应用笔记，更详细地解释了链接器文件和启动代码，包括如何修改和自定义内存区域。 AN14893 ：S32K3xx 链接器文件和启动代码 最后一个帖子包含了与代码优化技术相关的一些建议。 S32K3xx 如何优化 APP 代码以获得更高性能 BR，VaneB

Schematics of MPC5775B BMS & VCU Reference Design Unit Hey, I wanted to look into which pins in the MPC5775B MCU is connected to the digital and analog outputs available via the BMS & VCU reference design. But could not find schematics on that. Can I get it or possibly the link to it ? I am trying to figure out which of the Inputs pins exposed through the reference unit can do interrupt handling. Re: Schematics of MPC5775B BMS & VCU Reference Design Unit Hello, Schematic is available at our web page: https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png On page 12 are analog inputs and on page 14 digital inputs. Best regards, Peter

MPC5775B 电池管理系统 & 整车控制器VCU 参考设计单元原理图 嘿， 我想了解 MPC5775B MCU 中的哪些引脚连接到电池管理系统和整车控制器VCU参考设计中提供的数字和模拟输出。但找不到相关的原理图。我可以得到它或者它的链接吗？我正在尝试弄清楚参考单元暴露出的哪些输入引脚可以进行中断处理。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit 你好， 原理图可在我们的网页上找到： https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png 第 12 页是模拟输入，第 14 页是数字输入。 顺祝商祺！ Peter

Zephyr 中对 i.MX95 FRDM EVK 的 HDMI 配置支持 您好，NXP团队： 我目前正在使用 Zephyr RTOS 在i.MX95 FRDM EVK板上进行开发。 Linux 系统方面，HDMI 输出已经得到支持，并且运行正常。但是，我想知道如何在 Zephyr 中启用和配置 HDMI。 请问您能否指导我完成以下事项？ Zephyr 是否支持 i.MX95 FRDM EVK 的 HDMI 输出？ 如果需要，需要哪些驱动程序和设备树配置？ Zephyr 上是否有 HDMI 的参考实现或示例应用程序？ 任何指导或文件都将不胜感激。 谢谢！ Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已向AE团队确认过。 IMX95 Zephyr 目前不支持 HDMI。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队： 我正在寻找IT6263参考手册或寄存器编程手册。 请问您能否分享 IT6263 HDMI 桥接器的详细寄存器描述（带有位级定义的寄存器映射），或者告诉我如何才能获得这些文档？ 注意：我需要的是芯片级寄存器文档，而不是 Linux 内核驱动程序源代码。 谢谢你， 卡尔蒂凯扬·M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 不是 NXP 的产品，因此 NXP 不提供该设备的参考手册。有关配置和初始化的详细信息，您可以参考 IT6263 Linux 驱动程序源代码。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复。 请问能否提供Arm技术支持的具体联系邮箱或支持门户网站？如果您有直接联系人或合适的电子邮件地址，那将非常有帮助。我会就此事与他们联系。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您的回复以及提供的 Arm 支持链接。 我将联系 Arm 支持部门，以获取 Arm Mali-G310 技术参考手册和 CSF/固件接口文档。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm 支持中心： https://support.arm.com/support-cases   支持咨询表单： https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已经成功地将 HDMI 移植到 Zephyr 操作系统上，目前它正在 CPU 上运行。我的下一个目标是将其移植到GPU上运行。 为此，我需要Arm Mali-G310技术参考手册，特别是其中的CSF/固件接口部分。我应该向NXP技术支持索取这份文档，还是需要直接联系Arm技术支持？ 如果能查阅这份参考手册，对于在 Zephyr 上实现 GPU 移植将非常有帮助。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请直接联系Arm 支持团队。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 感谢您提供的 Arm 门户网站和 i.MX 图形用户指南的链接。我们两种都看过，但它们都不能满足我们的需求。这些指南解释了如何在 Linux 下使用 GPU，而我们正在 i.MX95 上编写我们自己的底层 GPU 驱动程序（裸机，使用 Zephyr，而不是 Linux）。因此，我们需要比这些文件提供的更低层级、登记级别的信息。 我们在 ARM 门户网站上搜索了 TRM，但找不到。 简而言之，我们的情况是这样的：   我们已经让 Mali-G310 GPU 运行到一定程度。GPU 已正确检测、通电、RESET，并且我们已成功将 GPU 固件加载到内存中。到目前为止，一切运行正常，并且已经过验证。   我们卡在了其中一个步骤：启动 GPU 的固件微控制器（MCU）。启用后，它的状态始终为“已禁用”，并且永远不会开始运行。没有错误提示，也没有中断提示——就是无法启动。   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK NXP团队您好， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP技术支持。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要 Arm Mali-G310 技术参考手册，特别是 CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请查看以下信息是否对您有所帮助。如果没有，我需要联系AE团队。 Arm Mali-G310 技术参考手册可从 Arm 的文档门户获取：在 Arm Developer / Arm Documentation 中搜索“Mali-G310 技术参考手册”或“Mali-G310 TRM” 。根据访问级别，可能需要 Arm 帐户或接受 Arm 文档条款。 对于 NXP i.MX95 的工作，NXP 的公开文档通过i.MX 图形用户指南指向 Mali-G310 GPU，而 FRDM-i.MX95 入门页面链接提供了有关 GPU 使用详情的指南。FRDM-i.MX95 页面显示该板配备Mali-G310 GPU ，并提供了i.MX 图形用户指南的链接，以便了解更多详情： https://www.nxp.com/docs/en/user-guide/UG10159.pdf 从这里开始： Arm 文档门户： https://developer.arm.com/documentation NXP i.MX 图形处理器用户指南： https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 您好，NXP团队， 我联系了 Arm 技术支持索取所需文档，他们回复如下： “如果您发现NXP芯片出现任何问题，请联系NXP支持部门。”再次强调，这些文件不应该提供给芯片供应商的客户。 根据他们的回复，我正在联系恩智浦半导体寻求帮助。 我已经成功在 Zephyr OS 上启用了 HDMI，它目前正在使用 CPU 运行。我的下一个目标是启用基于GPU的渲染。 要继续进行，我需要Arm Mali-G310 技术参考手册，特别是CSF/固件接口文档。 由于 Mali-G310 GPU 集成在 NXP i.MX95 平台中，请问我如何才能获得该文档？如果无法共享该文档，我希望得到任何其他指导或参考，引用，以帮助我继续在 Zephyr 上启动 GPU。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 请参考AE团队的以下更新。 关于 Arm Mali-G310 TRM，本文档属于 Arm 机密知识产权。NXP 不允许将其转发给最终客户，因此基本上无法通过 NXP 渠道获得。正式请求必须直接通过 Arm 公司提出，这需要很长时间，而且不太可能获得批准。此外，i.MX95 GPU 仍处于预生产阶段，因此目前还没有官方验证的裸机/Zephyr 参考，引用。 关于启用后 MCU 保持“禁用”状态的问题，此步骤不需要 TRM。完整的启动流程可在以下两个公开来源中找到，这两个来源均可直接在 GitHub 上访问： Panthor — 主线驱动程序，主要关注的驱动程序（它实际上启动了 MCU 并支持 i.MX95）： https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm 的官方驱动程序，用于交叉检查： https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

BMSおよびVCUリファレンスデザインユニットMPC5775B回路図 こんにちは、 MPC5775B MCUのどのピンがBMSやVCUのリファレンス・デザインで利用可能なデジタルおよびアナログ出力にコネクテッドされているかを調べたかったのです。しかし、その設計図は見つかりませんでした。入手できますか?もしくはリンクも教えてもらえますか?参照ユニットを通して露出している入力ピンのうち、どのピンが割り込み処理に使えるのかを調べようとしています。 Re: Schematics of MPC5775B BMS & VCU Reference Design Unit こんにちは、 回路図は当社のウェブページでご覧いただけます。 https://www.nxp.com/design/design-center/development-boards-and-designs/mpc5775b-bms-and-vcu-reference-design:RDVCU5775EVM?gad_source=1&gad_campaignid=24081577422&gclid=CjwKCAjwj7HTBhBiEiwA8s35OtHxPgln7wwf_p2BF5JDZ9GfWkdapC4yCnvxXk9Tp2NOHHSZHxyrSRoCk8IQAvD_BwE petervlna_0-1785481916968.png 12ページにはアナログ入力、14ページにはデジタル入力があります。 よろしくお願いいたします。 ピーター

バーストレジスタを使用したSPI伝送 こんにちは、NXPさん。 ターゲットMCU:S32K388 私はeDMAを使用したSPI伝送に、バーストレジスタTCBRおよびTDBR0-127を使用しています。 現在のフレームサイズは32ビットで、すべて期待どおりに動作しています。 さて、32ビット未満のSPIフレームサイズの場合、DMA転送サイズを変更せずにバーストレジスタをどのように使えるでしょうか。 TCBRは16ビットまたは8ビット単位で書くことができますか? TDBRnは16ビットまたは8ビット単位で書けますか? もしなければ、16ビットと8ビットのフレームサイズのDMAチャネルの設定方法についてヒントを教えてもらえますか? 前もって感謝します Re: Spi transmission using burst registers はい、 TCBR と TDBRn の両方が16ビットおよび8ビットの書き込みをサポートしており、DMAの転送サイズ変更は必要ありません。 TDBRn（16ビットまたは8ビット書き込み）：書き込みデータをゼロ拡張し、直ちに送信FIFOにプッシュします。LPSPIは TCR[FRAMESZ] で定義されたビットのみをクロック出力します。 TCBR (16ビット書き込み[15:0]): 1つのコマンドエントリをFIFOにプッシュします。注: [7:0] への8ビット書き込みはデータをステージングするだけであり、プッシュをトリガーするには [15:8] への2回目の8ビット書き込みが必要です。 RM参照 — S32K3xxリファレンスマニュアル、Rev. 12、2025-11-11: セクション70.6.1.17— データ送信 (TDR)：   「このレジスタには32ビット、16ビット、8ビットの書き込みを使って書き込むことができます。8ビットおよび16ビットの送信データ書き込みはいずれも、書き込まれたデータをゼロ拡張し、送信FIFOにデータを送り込みます。8ビットおよび16ビットの書き込みをゼロ拡張（32ビットに拡張）するとは、8ビットおよび16ビットの書き込みの上位（最上位）の空き部分をゼロで埋めることを意味します。 セクション70.3.6.1 — DMAサポートレジスタ(TCBR / TDBR0–TDBR127): 8ビット、16ビット、または32ビットのDMA書き込みアクセスを増分するために設計されたバーストエイリアス領域を文書化します。   Re: Spi transmission using burst registers Reg TCBR、16ビットの[15:00]への書き込みや2回目の8ビット書き込みが[15:8]へのデータを送信すると、TCR全体をどうやって更新できるのでしょうか。下半分の単語では、フレームサイズの選択のみが可能です。CPOL、CPHA、PCSなどのその他の設定は、単語の上半分に含まれます。

S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi NXP Team, I am working on an S32K311 project using the following environment: MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 Issue Initially, the project was building successfully. As the project progressed, I enabled and configured several RTD drivers, including ADC, eMIOS, LCU, ICU, PIT, PORT, LPUART, LPSPI, TRGMUX, MCL, and other required peripherals for my application. After integrating these drivers, the project now fails during the linking stage with the following errors: .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status Memory Layout The default linker script contains the following SRAM regions: int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 The linker reports that the .non_cacheable_bss section exceeds the allocated int_sram_no_cacheable region by approximately 440 bytes. Questions Is this memory usage expected when multiple RTD drivers are enabled on the S32K311? Is there a recommended method to reduce the size of .non_cacheable_bss? Is it recommended to modify the linker script and increase the int_sram_no_cacheable region? If so, what is the recommended memory layout for the S32K311? Are there any RTD configuration options that can reduce the memory allocated to non-cacheable sections? Has anyone encountered a similar issue when integrating multiple RTD peripherals? Any guidance or recommended solution would be greatly appreciated. Thank you. Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results Hi @Esakki  You may find the following discussion threads helpful, as they discuss similar issues and provide some useful troubleshooting suggestions. int_sram_no_cacheable issue S32K312's SRAM is overflow Additionally, there is an S32K3 application note that explains the linker file and startup code in more detail, including how memory regions can be modified and customized. AN14893: S32K3xx Linker File and Startup Code This last thread includes some suggestions related to code optimization techniques. S32K3xx How to optimization APP code for get more high performance BR, VaneB

S32K344 RTD 3.0.0:空の.slewRateCtrlSelLPSPI4ピン用に生成されました - ビルドが失敗します こんにちは、 私は、NXP RD33772C14EVMリファレンス・デザインに従ってSPI配線をしたS32K344(172ピンMQFP)カスタムボード上のバッテリー・マネジメントアプリケーションを紹介しています。私はS32 Design Studio 3.5とRTD 3.0.0を使っています(プラットフォーム、ポート、SPIモジュールはすべてSWバージョン3.0.0を報告しています)および FS26 SBC CDD 2.0.0 (Sbc_fs26)。私の出発点は、S32K344 用の Sbc_fs26_example_HLD サンプルです。 私のシステムではLPSPI0はFUTUREの2チャネルデイジーチェーン用に予約されており、他のSPIインスタンスはすでに使用中なので、FS26のSBCはLPSPI4上で動作しなければなりません。RD33772C14EVM回路図に従い、4つのLPSPI4信号をリファレンス・デザインで使われている同じパッドにルーティングしました:lpspi4_pcs0はPTB8、lpspi4_soutはPTB9、lpspi4_sckはPTB10、lpspi4_sinはPTB11に。ペリフェラル側ではSPIの物理ユニットマッピングをLPSPI_4に設定し、SpiHwUnitをCSIB0に残し、MCUコンポーネントのLPSPI_4ペリフェラルクロックゲートを有効にしました。 「Update Code」を実行してビルドすると、生成されたファイルgenerate/src/Siul2_Port_Ip_VS_0_PBcfg.cでエラーが発生してコンパイラが停止します。ジェネレーターは右辺のない代入式を生成しました。 ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: エラー: ',' トークンの前に式が必要です 118 | .slewRateCtrlSel= 、 同じ空の.slewRateCtrlSel= は、158行目、198行目、238行目に現れます。これは、4つのLPSPI4ピンそれぞれに対応しています。手動でその4行にPORT_SLEW_RATE_NOT_AVAILABLEを入力すると、ビルドは少し進みますが、.inputMuxRegで同じように失敗します。= { (空の初期化子、「ISO C では空の初期化子の括弧は禁止されています」)。つまり、これら4つのパッドのピン構成構造は、有効なCではない空のフィールドで生成されます。 PTB8–PTB11のピンツール「ルーティング詳細」を見ると、スリューレートコントロール列(および入力フィルター列)に該当なしが表示され、スリューレートセルを選択するとツールチップが表示されます:「選択したピンはこの機能の設定をサポートしていません。スルーレート制御を選択します。SO、これらのパッドにはスルーレート制御ハードウェアが搭載されていないのです。私の理解では、そのCASEジェネレーターは他のサポートされていないパッド機能に対して*_NOT_AVAILABLE値を使うのと同様に、PORT_SLEW_RATE_NOT_AVAILABLEを放出するはずです(その値はこのデバイスのSiul2_Port_Ip_PortSlewRateControl枚数に存在します)。しかし実際には何も発信せず、ビルドが壊れます。 これがピンの選択の誤りではなくツールやドライバの問題だと確信する理由は、NXP自身のLVBMS_RD_Bring_up_ExampleがFS26 SBC用にまったく同じ4つのLPSPI4パッド(PTB8/PTB9/PTB10/PTB11)を使っていて、きれいに組み立てられることです。その例と私のプロジェクトで唯一の違いはRTDバージョンです。LVBMSの例はRTD 2.0.0(プラットフォーム/Port/Spi SW 2.0.0)に基づいて構築されているのに対し、私のプロジェクトはRTD 3.0.0を使っています。基板のピン配置は同じで、ピンも4本とも同じ、ピンの電気的特性も同一です（方向のみが両者で設定されています）。SO、スルーレート対応しないパッドのSiul2_Port_Ipコード生成がRTD 2.0.0とRTD 3.0.0の間で逆行したように見えます。 私の質問： これはRTD 3.0.0の既知の問題ですか？修正版／パッチ適用済みのRTDリリースはありますか？ RTD 3.0.0環境下で、PTB8～PTB11（RD33772C14EVMピン配置）においてLPSPI4を正しく、かつサポートされている方法で構成するにはどうすればよいでしょうか？つまり、ピンツールが有効なコードを生成するようにするためです。つまり、slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLEと有効なinputMuxRegを生成し、空欄ではなく? 設定レベルでの修正がない場合、生成された Siul2_Port_Ip_VS_0_PBcfg.c を手動で編集することが唯一の回避策でしょうか (「コードの更新」のたびに上書きされます)、それともプロジェクトを Port/RTD 2.0.0 に移行することが推奨される方法でしょうか？ もし役に立つなら、完全なビルドログ、ピンの「ルーティング詳細」スクリーンショット(ツールチップ付き)、そして2つのプロジェクトのモジュールバージョンを並べて添付CAN。 ありがとう、 ソン・ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、VaneBさん。 どうもありがとうございました。まさにそれが問題だったのです。ピンツールはLPSPI4(PTB8–PTB11)に更新されていましたが、 ポート コンポーネントのポートピンエントリは元のLPSPI0パッドを指していたため、PortPin Pcr(Mscr)の値は古くなっていました。 ポート設定内の4つのPortPin Pcr値を、新しいピン割り当てに合わせて更新しました。 PCS0 → PTB8 (PCR 40) SOUT → PTB9 (PCR 41) SCK → PTB10 (PCR 42) SIN → PTB11 (PCR 43) Update Codeを実行して再構築した後、空の .slewRateCtrlSel/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c のエラーは解消され、プロジェクトは正常にビルドされます。 迅速かつ的確なご回答、本当にありがとうございました。おかげで大変時間を節約できました。これを解決策としてマークします。 よろしくお願いします、 ヒョンシク Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails こんにちは、 @hyunsiksong この問題は、RTD自体にも、S32DS構成ツールによって生成されたコードにも関係ありません。むしろ、それは設定に関係している。 ペリフェラルツール内のポートドライバ構成では、PortPin Mscrパラメータに割り当てられた値は元のプロジェクト構成に対応しています。例えば、プロジェクトは以前、PTB1をLPSPI0_PCS0として使用するように構成されており、これはPortPin Mscr = 33に対応します。 ただし、更新された構成ではLPSPI4が使用され、PCS0はピン8に再割り当てされています。したがって、対応するPortPin Mscrの値は33ではなく40になります。 すべてのピンについてPortPin Mscrを確認し、現在のピン割り当てと一致していることを確認してください。これらの値を新しい構成に合わせて更新することで、問題は解決するはずです。 BR、VaneB

使用突发寄存器的SPI传输 您好，NXP， 目标微控制器：S32K388 我正在使用突发寄存器 TCBR 和 TDBR0-127 进行 eDMA SPI 传输。 当前帧大小为 32 位，一切运行正常 对于小于 32 位的 SPI 帧大小，如何在不改变 DMA 传输大小的情况下使用突发寄存器？ TCBR 可以用 16 位或 8 位单位写入吗？ TDBRn 可以用 16 位还是 8 位单位写入？ 如果不行，能否提供一些关于如何设置帧大小为 16 位和 8 位的 DMA 通道的提示？ 提前致谢 Re: Spi transmission using burst registers 是的， TCBR和TDBRn都支持 16 位和 8 位写入——无需更改 DMA 传输大小。 TDBRn（16 位或 8 位写入）：将写入的数据零扩展，并立即将其推入发送 FIFO。LPSPI 只会输出由 TCR[FRAMESZ] 定义的位。 TCBR（16 位写入 [15:0]）：将一条命令条目推入 FIFO。注意：向 [7:0] 写入 8 位数据只是暂存数据——需要向 [15:8] 写入第二个 8 位数据才能触发信号推送。 RM 参考，引用 — S32K3xx 参考手册，修订版 12，2025-11-11： 第 70.6.1.17 节— 传输数据（TDR）：   “您可以使用 32 位、16 位或 8 位写入操作向此寄存器写入数据。”8 位和 16 位发送数据的写入都会对写入的数据进行零扩展，并将数据推入发送 FIFO。将 8 位和 16 位写入数据零扩展（扩展至 32 位）意味着将 8 位和 16 位写入数据中最高有效位（即空位）的部分填充为零。 第 70.3.6.1 节 — DMA 支持寄存器（TCBR / TDBR0–TDBR127）：记录了为递增 8 位、16 位或 32 位 DMA 写入访问发送 FIFO 而设计的突发别名区域。   Re: Spi transmission using burst registers 寄存器 TCBR，如果对 [15:00] 的 16 位写入或对 [15:8] 的第二次 8 位写入将数据作为命令条目推入 FIFO，如何更新整个 TCR？下半部分文字仅提供边框尺寸选择。其他设置，如 CPOL、CPHA、PCS 等，都位于单词的上半部分。

S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hello, I am bringing up a battery-management application on an S32K344 (172-pin MQFP) custom board whose SPI wiring follows the NXP RD33772C14EVM reference design. I am using S32 Design Studio 3.5 with RTD 3.0.0 (the Platform, Port and Spi modules all report SW version 3.0.0) and the FS26 SBC CDD 2.0.0 (Sbc_fs26). My starting point is the Sbc_fs26_example_HLD example for S32K344. In my system LPSPI0 is reserved for a future two-channel daisy-chain and the other SPI instances are already in use, so the FS26 SBC has to run on LPSPI4. Following the RD33772C14EVM schematic, I routed the four LPSPI4 signals to the same pads the reference design uses: lpspi4_pcs0 on PTB8, lpspi4_sout on PTB9, lpspi4_sck on PTB10 and lpspi4_sin on PTB11. On the peripheral side I set the SPI physical-unit mapping to LPSPI_4, left SpiHwUnit at CSIB0, and enabled the LPSPI_4 peripheral-clock gate in the Mcu component. After running "Update Code" and building, the compiler stops with errors in the generated file generate/src/Siul2_Port_Ip_VS_0_PBcfg.c. The generator has produced an assignment with no right-hand side: ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: error: expected expression before ',' token 118 | .slewRateCtrlSel = , The same empty .slewRateCtrlSel = , appears at lines 158, 198 and 238 — one for each of the four LPSPI4 pins. If I manually fill those four lines with PORT_SLEW_RATE_NOT_AVAILABLE, the build gets a little further and then fails the same way on .inputMuxReg = { (empty initializer, "ISO C forbids empty initializer braces"). In other words, the pin-configuration structures for these four pads are generated with empty fields that are not valid C. When I look at the Pins tool "Routing Details" for PTB8–PTB11, the Slew Rate Control column (and the Input Filter column) shows n/a, and selecting the Slew Rate cell shows the tooltip: "The selected pin does not support the configuration of this feature. Selects the slew rate control." So these particular pads simply have no slew-rate-control hardware. My understanding is that in that case the generator should emit PORT_SLEW_RATE_NOT_AVAILABLE (that value does exist in the Siul2_Port_Ip_PortSlewRateControl enum on this device), the same way it uses *_NOT_AVAILABLE values for other unsupported pad features — but instead it emits nothing, which breaks the build. What convinces me this is a tool/driver problem rather than a wrong pin choice is that NXP's own LVBMS_RD_Bring_up_Example uses the exact same four LPSPI4 pads (PTB8/PTB9/PTB10/PTB11) for the FS26 SBC and builds cleanly. The only difference I can find between that example and my project is the RTD version: the LVBMS example is built on RTD 2.0.0 (Platform/Port/Spi SW 2.0.0), while my project uses RTD 3.0.0. Same board pinout, same four pins, and the pin electrical features are identical (only direction is set in both). So it really looks like the Siul2_Port_Ip code generation for slew-rate-unsupported pads regressed between RTD 2.0.0 and RTD 3.0.0. My questions: Is this a known issue in RTD 3.0.0, and is there a fixed / patched RTD release? What is the correct, supported way to configure LPSPI4 on PTB8–PTB11 (the RD33772C14EVM pinout) under RTD 3.0.0 so that the Pins tool generates valid code — i.e. slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE and a valid inputMuxReg, instead of empty fields? If there is no configuration-level fix, is editing the generated Siul2_Port_Ip_VS_0_PBcfg.c by hand the only workaround (it is overwritten on every "Update Code"), or is moving the project to Port/RTD 2.0.0 the recommended path? I can attach the full build log, the Pins "Routing Details" screenshot with the tooltip, and a side-by-side of the two projects' module versions if that helps. Thank you, Hyunsik Song Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi VaneB, Thank you very much — that was exactly the problem. The Pins tool had been updated to LPSPI4 (PTB8–PTB11), but the Port component's PortPin entries were still pointing at the original LPSPI0 pads, so the PortPin Pcr (Mscr) values were stale. I updated the four PortPin Pcr values in the Port configuration to match the new pin assignment: PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10 (Pcr 42) SIN → PTB11 (Pcr 43) After running Update Code and rebuilding, the empty .slewRateCtrlSel / .inputMuxReg errors in Siul2_Port_Ip_VS_0_PBcfg.c are gone and the project builds cleanly. I really appreciate the quick and precise answer — it saved me a lot of time. Marking this as the solution. Best regards, Hyunsik Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails Hi @hyunsiksong  This issue is not related to the RTD itself, nor with the code generated by the S32DS Configuration Tools. Instead, it is related to the configurations. In the Port driver configuration within the Peripheral Tool, the values assigned to the PortPin Mscr parameters still correspond to the original project configuration. For example, the project was previously configured to use PTB1 as LPSPI0_PCS0, corresponds to PortPin Mscr = 33. In the updated configuration, however, LPSPI4 is being used and PCS0 has been reassigned to pin 8. Therefore, the corresponding PortPin Mscr value should be 40 instead of 33. Review the PortPin Mscr for all the pins and ensure they match the current pin assignments Updating these values to reflect the new configuration should resolve the issue. BR, VaneB

S32K311 RTD 5.0 - リンカーエラー: .non_cacheable_bss.int_resultsとのオーバーフローおよび重複 こんにちは、NXP チームの皆様、 私は以下の環境を使用してS32K311プロジェクトに取り組んでいます。 MCU: S32K311 IDE: S32 Design Studio 3.6.7 RTD: S32K3_RTD_5.0.0_D2408_ASR_REL_4_7_REV_0000_20241002 AUTOSAR: 4.7 問題 当初、プロジェクトは順調にビルディングされていました。 プロジェクトが進むにつれて、ADC、eMIOS、LCU、ICU、PIT、PORT、LPUART、LPSPI、TRGMUX、MCLなど、いくつかのRTDドライバを有効化・設定し、アプリケーションに必要なその他のペリフェラルを活用しました。 これらのドライバを統合した後、プロジェクトはリンク段階で以下のエラーで失敗します。 .non_cacheable_bss will not fit in region 'int_sram_no_cacheable' section .int_results overlaps section .non_cacheable_bss region 'int_sram_no_cacheable' overflowed by 440 bytes collect2.exe: error: ld returned 1 exit status メモリレイアウト デフォルトのリンカスクリプトには、以下のSRAM領域が含まれています。 int_sram : ORIGIN = 0x20400000, LENGTH = 0x00003F00 int_sram_fls_rsv : ORIGIN = 0x20403F00, LENGTH = 0x00000100 int_sram_no_cacheable : ORIGIN = 0x20404000, LENGTH = 0x00003B00 int_sram_results : ORIGIN = 0x20407B00, LENGTH = 0x00000100 int_sram_shareable : ORIGIN = 0x20407C00, LENGTH = 0x00000400 リンカーは、 .non_cacheable_bssがこのセクションは、割り当てられた int_sram_no_cacheable 領域を約440 バイト超過しています。 質問 複数のRTDドライバがS32K311で有効になっている場合、このメモリ使用は予想されますか? .non_cacheable_bssのサイズを減らすための推奨方法はありますか? リンカースクリプトを修正してint_sram_no_cacheable領域を増やすことは推奨されますか？もしそうなら、S32K311の推奨メモリ配置はどうなっていますか? キャッシュできないセクションに割り当てられるメモリを減らすRTDの設定オプションはありますか? 複数のRTDペリフェラルを統合する際に同じような問題に遭遇した方はいらっしゃいますか? 何かご助言や解決策をご提案いただければ大変ありがたいです。 よろしくお願いします。 Re: S32K311 RTD 5.0 - Linker error: .non_cacheable_bss overflow and overlap with .int_results こんにちは、 @Esakkiさん 以下のディスカッションThreadは、似たような問題を扱い、有用なトラブルシューティングの提案を提供してくれるので役立つかもしれません。 int_sram_no_cacheable の問題 S32K312のSRAMがオーバーフローする さらに、S32K3のアプリケーションノートには、リンカーファイルやスタートアップコードについてより詳しく説明されており、メモリ領域の変更やカスタマイズ方法も含まれています。 AN14893 : S32K3xx リンカーファイルとスタートアップコード この最後のThreadでは、コード最適化技術に関するいくつかの提案が含まれています。 S32K3xxでAPPのコードを最適化してパフォーマンスを向上させる方法 BR、VaneB

Spi transmission using burst registers Hello NXP, Target uC : S32K388 I am using the burst registers TCBR and TDBR0-127 for SPI transmissions using eDMA. Current frame size is 32 bits and everything works as expected Now for an SPI frame size which is less than 32 bits, how can the burst registers be used without changing the dma transfer size, in between. Can TCBR be written in 16 or 8 bit units. Can TDBRn be written in 16 or 8 bit units If not, could you give hints as to how to setup the dma channel for frame sizes 16 and 8 bits. Thanks in advance  Re: Spi transmission using burst registers Yes, both TCBR and TDBRn support 16-bit and 8-bit writes — no DMA transfer size change is needed. TDBRn (16-bit or 8-bit write): Both zero-extend the written data and immediately push it into the transmit FIFO. LPSPI will clock out only the bits defined by TCR[FRAMESZ] . TCBR (16-bit write to [15:0]): Pushes one command entry into the FIFO. Note: an 8-bit write to [7:0] only stages the data — a second 8-bit write to [15:8] is required to trigger the push. RM reference — S32K3xx Reference Manual, Rev. 12, 2025-11-11: Section 70.6.1.17 — Transmit Data (TDR):   "You can write to this register using 32-, 16-, or 8-bit writes. Both 8-bit and 16-bit writes of transmit data zero-extend the data written and push the data into the transmit FIFO. To zero-extend 8-bit and 16-bit writes (to 32 bits) means that the higher order (most significant) empty parts of the 8-bit and 16-bit writes are filled with zeroes." Section 70.3.6.1 — DMA support registers (TCBR / TDBR0–TDBR127): Documents the burst alias region designed for incrementing 8-bit, 16-bit, or 32-bit DMA write accesses to the transmit FIFO.   Re: Spi transmission using burst registers Reg TCBR, if the 16 bit write to [15:00] or the second 8-bit write to [15:8] pushes the data into the FIFO as a command entry, how can the entire TCR be updated. Only the frame size selection is available on the lower half word. The other settings like CPOL,CPHA,PCS etc comes in the upper half word.

HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am currently working on the i.MX95 FRDM EVK board using Zephyr RTOS. On the Linux side, HDMI output is already supported and working correctly. However, I would like to know how to enable and configure HDMI in Zephyr. Could you please guide me on the following? Does Zephyr support HDMI output on the i.MX95 FRDM EVK? If yes, what drivers and Device Tree configurations are required? Is there any reference implementation or sample application available for HDMI on Zephyr? Any guidance or documentation would be greatly appreciated. Thank you. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I confirmed with the AE team. HDMI is not supported in IMX95 Zephyr currently.  Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi NXP Team, I am looking for the IT6263 Reference Manual or Register Programming Manual. Could you please share the detailed register descriptions (register map with bit-level definitions) for the IT6263 HDMI bridge, or let me know how I can obtain this documentation? Note: I am specifically looking for the chip-level register documentation itself, not the Linux kernel driver source. Thank you, Karthikeyan M Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK IT6263 is not an NXP product, so NXP does not provide a Reference Manual for this device. For configuration and initialization details, you can refer to the IT6263 Linux driver source code. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response and for providing the Arm Support links. I will contact Arm Support regarding the Arm Mali-G310 Technical Reference Manual and the CSF/Firmware Interface documentation. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK I have successfully ported HDMI on Zephyr OS, and it is currently running on the CPU. My next goal is to port it to run on the GPU. For this, I need the Arm Mali-G310 Technical Reference Manual, specifically the CSF/Firmware Interface section. Should I request this document from NXP Support, or do I need to contact Arm Support directly? Having access to this reference manual would be very helpful for implementing the GPU port on Zephyr Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please contact Arm Support directly. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for your response. Could you please share the specific contact email or support portal for Arm Support? If you have a direct contact or the appropriate email address, it would be very helpful. I will contact them regarding this issue. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Arm Support Hub: https://support.arm.com/support-cases   Support Inquiries Form: https://www.arm.com/company/contact-us/support-inquiries Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Thank you for the links to the Arm portal and the i.MX Graphics User's Guide. We looked at both, but they don't cover what we need. Those guides explain how to use the GPU under Linux, and we are writing our own low-level GPU driver on i.MX95 (bare-metal, using Zephyr, not Linux). So we need lower-level, register-level information than those documents provide. In the ARM portal, we have searched for the TRM, but it is unavailable. Here is our situation in short:   We have got the Mali-G310 GPU working up to a certain point. The GPU is detected correctly, powered on, reset, and we have loaded the GPU firmware into memory successfully. Everything up to this stage works and is verified.   We are stuck at one step: starting the GPU's firmware microcontroller (the MCU). After we enable it, its status stays "disabled" and it never starts running. There is no error and no interrupt - it simply does not boot.   Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please check whether the following information would be helpful. If no, I need to contact the AE team. The Arm Mali-G310 Technical Reference Manual is available from Arm’s documentation portal: search Arm Developer / Arm Documentation for “Mali-G310 Technical Reference Manual” or “Mali-G310 TRM” . It may require an Arm account or acceptance of Arm documentation terms, depending on access level. For NXP i.MX95 work, NXP’s public documentation points to the Mali-G310 GPU through the i.MX Graphics User’s Guide , and the FRDM-i.MX95 getting-started page links that guide for GPU usage details. The FRDM-i.MX95 page states that the board has a Mali-G310 GPU and links the i.MX Graphics User’s Guide for more details: https://www.nxp.com/docs/en/user-guide/UG10159.pdf  Start here: Arm documentation portal:https://developer.arm.com/documentation NXP i.MX Graphics User’s Guide:https://www.nxp.com/docs/en/user-guide/UG10159.pdf Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Hi   NXP Team, I contacted Arm support to request the required documentation, and they replied with the following: "Please reach NXP support if you see obstacles developing on their silicon. Again, these documents are NOT supposed to be available for silicon vendor's customers." Based on their response, I am reaching out to NXP for assistance. I have successfully enabled HDMI on Zephyr OS, and it is currently running using the CPU. My next objective is to enable GPU-based rendering. To proceed, I require the Arm Mali-G310 Technical Reference Manual, particularly the CSF/Firmware Interface documentation. As the Mali-G310 GPU is integrated into the NXP i.MX95 platform, could you please advise how I can obtain access to this documentation? If the document cannot be shared, I would appreciate any alternative guidance or references that would help me continue the GPU bring-up on Zephyr. Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK Please refer to the following update from the AE team. Regarding the Arm Mali-G310 TRM, this document is Arm confidential IP. NXP is not permitted to forward it to end customers, so it is essentially unavailable through NXP channels. A formal request would have to go through Arm directly, which takes a long time and is unlikely to be granted. In addition, the i.MX95 GPU is still in the pre-production stage, so there is no officially validated bare-metal/Zephyr reference at this time. Regarding the MCU staying "disabled" after enable, this step does not require the TRM. The complete boot flow is available in the following two public sources, both accessible directly on GitHub: Panthor — mainline driver, the main one to look at (it actually boots the MCU and supports i.MX95): https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/panthor kbase — Arm's official driver, for cross-checking: https://github.com/JeffyCN/mirrors/blob/kernel/drivers/gpu/arm/bifrost/csf/mali_kbase_csf_firmware.c

S32K344 RTD 3.0.0：空 .slewRateCtrlSel为 LPSPI4 引脚生成 — 版本失败 你好， 我正在 S32K344（172 引脚 MQFP）定制板上开发一个电池管理应用程序，该板的 SPI 布线遵循 NXP RD33772C14EVM 参考设计。我正在使用 S32 Design Studio 3.5 和 RTD 3.0.0。（平台、端口和 Spi 模块均报告软件版本为 3.0.0）以及 FS26 SBC CDD 2.0.0 (Sbc_fs26)。我的出发点是 S32K344 的 Sbc_fs26_example_HLD 示例。 在我的系统中，LPSPI0 已预留给未来的双通道菊花链，而其他 SPI 实例已被使用，因此 FS26 SBC 必须在 LPSPI4 上运行。按照 RD33772C14EVM 原理图，我将四个 LPSPI4 信号连接到参考设计使用的相同焊盘：lpspi4_pcs0 连接到 PTB8，lpspi4_sout 连接到 PTB9，lpspi4_sck 连接到 PTB10，lpspi4_sin 连接到 PTB11。在外围设备方面，我将 SPI 物理单元映射设置为 LPSPI_4，将 SpiHwUnit 设置为 CSIB0，并在 Mcu 元器件中启用了 LPSPI_4 外围时钟门。 运行“更新代码”并构建后，编译器停止运行，生成的文件 generate/src/Siul2_Port_Ip_VS_0_PBcfg.c 出现错误。生成器生成的赋值语句没有右侧等式： ../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: 错误：应在逗号 (,) 前插入表达式 118 | .slewRateCtrlSel=， 同样的空 .slewRateCtrlSel等号出现在第 158、198 和 238 行——分别对应四个 LPSPI4 引脚。如果我手动将这四行填充为 PORT_SLEW_RATE_NOT_AVAILABLE，版本会继续进行下去，然后在 .inputMuxReg 处以相同的方式失败。= {（空初始化器，“ISO C 禁止空初始化器大括号”）。换句话说，这四个焊盘的引脚配置结构生成的字段为空，这不是有效的 C。 当我查看 PTB8–PTB11 的“引脚”工具“布线详情”时，“转换速率控制”列（以及“输入滤波器”列）显示为“n/a”，选择“转换速率”单元格时，工具提示显示：“所选引脚不支持此功能的配置。”选择转换速率控制。所以这些特殊的垫子根本没有转换速率控制硬件。我的理解是，在这种情况下，生成器应该发出 PORT_SLEW_RATE_NOT_AVAILABLE（该值确实存在于此设备的 Siul2_Port_Ip_PortSlewRateControl 枚举中），就像它对其他不支持的 pad 功能使用 *_NOT_AVAILABLE 值一样——但它却什么也没发出，这导致版本失败。 让我确信这是工具/驱动程序问题而不是引脚选择错误的原因在于，NXP 自己的 LVBMS_RD_Bring_up_Example 使用了完全相同的四个 LPSPI4 焊盘（PTB8/PTB9/PTB10/PTB11）来构建 FS26 SBC，并且版本构建顺利。我发现该示例与我的项目之间唯一的区别是 RTD 版本：LVBMS 示例基于 RTD 2.0.0（平台/端口/Spi 软件 2.0.0），而我的项目使用 RTD 3.0.0。电路板引脚排列相同，四个引脚相同，引脚的电气特性也相同（两者仅方向设置不同）。所以看起来，RTD 2.0.0 和 RTD 3.0.0 之间，Siul2_Port_Ip 代码生成对于不支持压摆率的 pad 确实出现了倒退。 我的问题： 这是RTD 3.0.0中的已知问题吗？是否有已修复/已打补丁的RTD版本？ 在 RTD 3.0.0 版本下，配置 PTB8–PTB11（RD33772C14EVM 引脚排列）上的 LPSPI4 的正确且受支持的方法是什么？这样，引脚工具就能生成有效的代码——例如，slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE 和一个有效的 inputMuxReg，而不是空字段？ 如果没有配置级别的修复，手动编辑生成的 Siul2_Port_Ip_VS_0_PBcfg.c 是唯一的解决方法吗（每次“更新代码”都会覆盖它），还是将项目迁移到 Port/RTD 2.0.0 是推荐的方案？ 如果需要，我可以附上完整的构建日志、带有工具提示的引脚“布线详情”屏幕截图，以及两个项目模块版本的并排对比图。 谢谢你， 宋炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 嗨 VaneB， 非常感谢——问题果然出在这里。Pins 工具已更新为 LPSPI4 (PTB8–PTB11)，但Port元器件的 PortPin 条目仍然指向原始的 LPSPI0 焊盘，因此 PortPin Pcr (Mscr) 值已过时。 我已将端口配置中的四个 PortPin Pcr 值更新为与新的引脚分配相匹配： PCS0 → PTB8 (Pcr 40) SOUT → PTB9 (Pcr 41) SCK → PTB10（Pcr 42） SIN → PTB11 (Pcr 43) 运行更新代码并重新构建后，.slewRateCtrlSel 文件为空。/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c 中的错误已消失，项目可以顺利构建。 我非常感谢您快速而准确的答复——这为我节省了很多时间。标记为解决方案。 此致， 炫植 Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails 你好@hyunsiksong 这个问题与 RTD 本身无关，也与 S32DS 配置工具生成的代码无关。相反，它与配置有关。 在外设工具的端口驱动程序配置中，分配给 PortPin Mscr 参数的值仍然与原始项目配置相对应。例如，该项目之前配置为使用 PTB1 作为 LPSPI0_PCS0，对应于 PortPin Mscr = 33。 然而，在更新后的配置中，使用的是 LPSPI4，并且 PCS0 已重新分配给引脚 8。因此，相应的 PortPin Mscr 值应为 40 而不是 33。 检查所有引脚的 PortPin Mscr，确保它们与当前的引脚分配匹配。更新这些值以反映新的配置应该可以解决问题。 BR，VaneB

MCUXpresso Secure Provisioning ToolからFCBデータを構築する方法 こんにちは、 現在、RT1010 EVKボードでOTFADの設定をテストしています。 MCUXpresso Secure Provisioning Tool 26.03を使用してOTFADを設定し、バイナリファイルを生成するプロジェクトをビルドしたいと考えています。 ビルド結果は以下のとおりです。 MIMXRT1011_プロジェクト.bin MIMXRT1011_Project_hab.bin otfad_keyblobs.bin unsigned_MIMXRT1010_flashloader.bin これらが4つのファイルです。 MCUXpresso Secure Provisioning Tool 26.03 を使用して書き込み操作を実行し、フラッシュメモリを読み取ると、プログラムは 0x0400 領域に FCB と思われるデータを含めます。 しかし、ビルドされたファイルの中にFCBに対応するファイルが見当たらないようです。 ビルドプロセス中にFCB情報を含むファイルを生成することは可能ですか？ i.MXRT 101x Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool ご返信よろしくお願いします。 あなたが提供してくれたリンクを参考に、FCBを作成しました。 もう一つ質問があります。 OTFAD設定のリージョン0情報のキーデータに関する説明はどのドキュメントで見られますか? 私が気になっているのは、ユーザーキーデータとカウンターデータセクションです。 説明してもらえますか? よろしくお願いします。 TnseoRnr_0-1785208042935.png Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 SPTドキュメントの以下のリンクをご覧ください。簡易設定から完全なFCBを作成する手順が明記されています:https://mcuxpresso.nxp.com/secure/26.03/05_user_interface.html#spi-nor また、FCBはペリフェラルツールを使ってMCUXpressoから作成できるとも書かれています。 最後に一つ、SPTの新しいバージョン(v26.06)が存在することを覚えておいてください。最新バージョンの開発を続けることをお勧めします。 BR、 エドウィン。 Re: how i can build FCB data from MCUXpresso Secure Provisioning Tool こんにちは、 @TnseoRnr さん。 これらのフィールドが作成中の OTFAD 構成でどのように使用されるかという意味であれば、おそらく次のリンクが参考になるでしょう: https://mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#booting-otfad-encrypted-image-unsigned-with-user-keys とはいえ、これらの鍵の内部構造やより詳細な説明を求める場合は、RT1010のセキュアファイルへのアクセスを申請し、RT1010のセキュリティ機能を詳細に説明したセキュリティリファレンスマニュアルを参照する必要があります。 このファイルのダウンロードやアクセス申請は、RT1010製品ページのドキュメントセクションの「Secure」チェックボックスをクリックすることで表示されます。 https://www.nxp.com/products/i.MX-RT1010#documentation BR、 エドウィン。

i.MX93ボードを再プロビジョニングすることは可能ですか？ すでにEdgeLock 2GOを使ってFRDM i.MX93ボードのプロビジョニングを完了しており、プロビジョニングは無事完了しています。 今は同じボードに、キーペアやX.509証明書などの新しいまたは更新されたセキュアオブジェクトセットで再プロビジョニングしたいと考えています。 すでにプロビジョニング済みのi.MX93デバイスでの再プロビジョニングはサポートされていますか? もしそうなら、推奨される手順を教えていただけますか?具体的には、以前にプロビジョニングされたセキュアオブジェクトは、再度プロビジョニングする前に削除またはリセットする必要がありますか?それともEdgeLock 2GOを通じて更新できるのでしょうか? また、再プロビジョニングを試みる前に知っておくべき制限や不可逆的な設定はありますか? ログは:-- エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_utils_write_edgelock2go_datastore L#1150 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_utils_create_self_signed_edgelock2go_certificate L#1035 mbedtls_pk_setup_opaque 失敗:0xffffc180 エラー:iot_agent_update_device_configuration_from_constants L#614 iot_agent_utils_create_self_signed_edgelock2go_certificate 失敗:0xffffffff エラー:iot_agent_update_device_configuration L#657 iot_agent_update_device_configuration_from_constants 0xffffffffで故障 Status(oem-prov-app): FAILURE(Status(oem-prov-app): FAILURE(FAILURE) FRDMトレーニング ハンズオン・トレーニング Security Yocto Project Re: Is it possible to reprovision the i.MX93 board? こんにちは、 再プロビジョニングも可能であり、EdgeLock 2GOは初期展開後の証明書や鍵の更新、ローテーション、取り消しを含む完全なライフサイクルマネジメントを目的に設計されています。 安全なプロビジョニングのためにどのような手順を踏みましたか? キーやライフサイクルなど、ヒューズ内の焼き付き構成に関わる手順について理解しておく必要があります。 よろしくお願いいたします。 Re: Is it possible to reprovision the i.MX93 board? サービスレベルでの再プロビジョニングがサポートされていることを確認していただきありがとうございます。明確にしておきますが、これは新規のプロビジョニング試行ではなく、既に一度正常にプロビジョニングされたボード（ライフサイクルOEM_OPEN、ELEファームウェア2.0.5-7a34cee、初回プロビジョニング時に既にキーと証明書オブジェクトが存在する状態）に対する再プロビジョニング試行です。 この 2 回目のパスで、oem-prov-app は iot_agent_update_device_configuration_from_constants() → iot_agent_utils_create_self_signed_edgelock2go_certificate() 内の mbedtls_pk_setup_opaque() 呼び出しで失敗し、MBEDTLS_ERR_PK_BAD_INPUT_DATA (0xffffc180) を返します。バージョン: el2go-agent 6.4.2-r0、smw 5.3-r0、mbedtls 3.6.5-r0。 2つの質問があります。 1.再プロビジョニングでは、oem-prov-appを再実行する前に、既存のキーオブジェクトを明示的に消去する必要がありますか（psa_destroy_keyまたはSMWキーストレージAPI経由）、それともエージェントが同じキーIDで上書きする必要がありますか？現在、明示的な消去手順は実行していません。 2. el2go-agent 6.4.2-r0 と smw 5.3-r0 の間には、特に再プロビジョニング/更新パスに関して既知の互換性の問題がありますか？というのも、初期起動時にも同じエラーが発生し、そこでもバージョン不一致が疑われたからです。 また、プロビジョニングされた鍵と証明書オブジェクトがELE管理のNVMに存在しているのか確認できますか?つまり、再プロビジョニングに失敗してもその鍵IDが永久に使えなくなるわけではありません。 Re: Is it possible to reprovision the i.MX93 board? こんにちは、 情報ありがとうございます。 1. はい、署名付きメッセージを使用してキーストアの再プロビジョニングを実行してください。キーストアの再プロビジョニングを行うと、HSMによって管理されているすべてのキーストアが消去されます。 2. いいえ、互換性の問題は報告されていません。 3. その通り、アプリケーション鍵や証明書はヒューズではなくELE管理のNVMに保存されます。 よろしくお願いいたします。