使用 NXP 密钥对 i.MX93 进行安全调试 SPSDK 中的 nxpdebugmbox 工具的当前版本有一个参数 --nxp-keys，其描述为“使用 ROM NXP 密钥进行身份验证”。 这是否意味着恩智浦可以解锁所有设备上的安全调试功能？ 如果可以，是否有熔丝将安全调试功能限制在 OEM SRK 密钥范围内？ 安全 Re: Secure debug on i.MX93 with NXP keys 但是，如果您控制了 ELE，您就可以访问 DDR 内存，并可以监测 OEM 功能域从 ELE 功能域请求的所有加密操作的输入和输出。您可以解密所有 ELE 数据块，从而访问设备上存储的所有秘密数据。除非阻止写入 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 调试功能域没有任何权限。 此致敬礼/Saludos， 阿尔多。

S32K388 HSE_SWT Reboot for Fresh Chip flashing I have a fresh S32K388 which I'm trying to flash with some from-scratch firmware (this is not AUTOSAR nor RTD). I have the IVT setup to only boot core0, and I have hse_fw_header_start_address just set to zero. It appears though that this configuration is leading to resets with the MC_RGM DES reporting: 0x00000041 and the MC_RGM FES reporting 0x00010000 which, based on my reading on the S32K3XXRM, implies that HSE watchdog timeouts are leading to a destructive reset based on escalation. The interesting thing is that this behavior seems to go away when I connect with a j-link, but I can't seem to find a way to disable or service the SWT from my firmware. Do I need to download/install the standard HSE FW for the S32K388? Is there a reason this is required on the S32K388 and not on the S32K344? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing With some further testing - if I clear all the flags in MC_RGM FES/DES after reading them (so they're not sticky across boots), the boot loop starts to return: FES: 0x00010000 and occasionally DES: 0x00000040 (but most of the time DES: 0x00000000) And for clarity for the original post, I have the boot configuration word in the IVT set to 0x00000001 - which would seem to imply, in my reading, that only CM7_0_ENABLE is set and there shouldn't be any HSE/SWT_0 setting at all? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing Based on this post: https://community.nxp.com/t5/S32K/What-does-it-mean-HSE-SWT-RST-on-S32K311/m-p/1955147 And this image of S32K3xx_DCF_clients.xlxs from an older version of the S32K3XXRM: https://community.nxp.com/t5/S32K/S32K388-HSE-No-Response-Error/m-p/2090937/highlight/true?lightbox-message-images-2090937=336074i0A601700196531EB#M48394 It appears I may have solved my problem by writing: 0x40000101 0x00100006 to 0x1B000770in the UTEST memory sector (putting "2" into HSE_CLK_MODE_AND_GSKT_CTRL). In the current revision of S32K3xx_DCF_clients.xlxs, the description of HSE_CLK_MODE_AND_GSKT_CTRL is as follows: But in the S32K3XXRM, I can't find a reference to what I should be configuring in the gasket configuration (the closest looks like "HSE_B" but the table refers to an impossible 1:1 configuration): Is this just a documentation update failure? Should I have a 1:4 ratio in HSE_CLK_MODE_AND_GSKT_CTRL if I'm using Option A++ clocking (CORE_CLK at 160MHz, AIPS_SLOW_CLK at 40MHz)? Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing And just in case my other comment turns out to not be the solution: The chip I am using is labelled S32K388HHMJBS 0P39J CTAJ2507E - let me know if you need me to read some registers for specific chip information HSE Firmware has never been installed - this is a factory-fresh device which I have only flashed with my bare-metal code For the IVT: hseFwHeaderStartAddr is zero recovery_app_start_address is zero I am uncertain which fields to provide from the IVT but everything is basically zero except the header set to 0x5AA55AA5, the boot_config set to 1, and the cm7_0_start_address set to the interrupt vector table I already provided the DES and FES I was getting in the original post, but let me know if those were unclear I will try and get this uploaded - I need to get approval to post this code publicly Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing As a quick correction - I meant to write "HSE_CLK at 160MHz and AIPS_SLOW_CLK at 40MHz" for that last sentence in the above comment. Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing Could you please provide: The exact S32K388 part number and chip revision being used. Confirmation whether HSE firmware has ever been installed on the device (or whether this is a completely blank/factory-fresh device). The IVT configuration, especially the values of hseFwHeaderStartAddr, appBootAddr, and any other HSE-related IVT fields. The complete reset status register dump after the reset (MC_RGM_DES, MC_RGM_FES, and any other relevant reset registers). Whether the issue occurs on multiple devices or only on a single board. A minimal project/application that reproduces the issue, or at least the startup code sequence executed before the reset occurs. At the moment it is not clear whether the reset is caused by HSE/SBAF, an application issue, or a device configuration issue, so the above information will help identify the root cause. Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing As far as we can tell - this has solved the issue. I would like to see the documentation updated to reflect that Option A++ requires this gasket change @davidtosenovjan 

S32K388 HSE_SWT 重启以进行新芯片刷写。 我有一块全新的 S32K388，我正在尝试用一些全新的固件（不是 AUTOSAR 也不是 RTD）刷入它。我已将 IVT 设置为仅启动 core0，并且已将 hse_fw_header_start_address 设置为零。 但这种配置似乎会导致 MC_RGM DES 报告 RESET： 0x00000041 和 MC_RGM FES 报告 0x00010000，根据我对 S32K3XXRM 的了解，这意味着 HSE 看门狗超时导致基于升级的破坏性 RESET。 有趣的是，当我连接 J-Link 时，这种现象似乎就消失了，但我似乎找不到从我的固件中禁用或维护 SWT 的方法。我需要为 S32K388 下载/安装标准 HSE 固件吗？ 为什么S32K388需要这个功能，而S32K344不需要？ Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 经过进一步测试——如果我在读取 MC_RGM FES/DES 标志后将其全部清除（这样它们就不会在启动后保持不变），启动循环开始返回：FES: 0x00010000，偶尔返回 DES: 0x00000040（但大多数情况下返回 DES: 0x00000000）。 为了更清楚地说明原帖内容，我已将 IVT 中的启动配置字设置为 0x00000001 - 根据我的理解，这似乎意味着只设置了 CM7_0_ENABLE，而根本不应该有任何 HSE/SWT_0 设置？ Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 万一我的另一条评论最终证明并不能解决问题： 我使用的芯片型号为 S32K388HHMJBS 0P39J CTAJ2507E - 如果您需要我读取某些寄存器以获取特定芯片信息，请告诉我。 HSE固件从未安装过——这是一台全新出厂的设备，我只刷入了自己的裸机代码。 对于 IVT： hseFwHeaderStartAddr 为零 recovery_app_start_address 为零 我不确定应该从 IVT 中提供哪些字段，但除了头部设置为 0x5AA55AA5、boot_config 设置为 1 以及 cm7_0_start_address 设置为中断向量表之外，其他字段基本上都为零。 我在原帖中已经提供了我得到的DES和FES值，但如果这些信息不够清晰，请告诉我。 我会尽量上传这段代码——我需要获得公开发布这段代码的许可。 Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 更正一下——我上面评论中的最后一句话应该是“HSE_CLK 频率为 160MHz，AIPS_SLOW_CLK 频率为 40MHz”。 Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 根据这篇帖子： https://community.nxp.com/t5/S32K/What-does-it-mean-HSE-SWT-RST-on-S32K311/mp/1955147 这是来自旧版 S32K3XXRM 的 S32K3xx_DCF_clients.xlxs 的图像： https://community.nxp.com/t5/S32K/S32K388-HSE-No-Response-Error/mp/2090937/highlight/true ?lightbox-message-images-2090937=336074i0A601700196531EB#M48394 我似乎通过在 UTEST 内存扇区中写入 0x40000101 0x00100006 到 0x1B000770（将“2”放入 HSE_CLK_MODE_AND_GSKT_CTRL）解决了我的问题。 在当前版本的 S32K3xx_DCF_clients.xlxs 中，HSE_CLK_MODE_AND_GSKT_CTRL 的描述如下： 但在 S32K3XXRM 中，我找不到关于垫片配置中应该如何配置的参考信息（最接近的似乎是“HSE_B”，但表格中提到的是一个不可能的 1:1 配置）： 这只是文档更新失败吗？如果我使用 Option A++ 时钟（CORE_CLK 为 160MHz，AIPS_SLOW_CLK 为 40MHz），那么 HSE_CLK_MODE_AND_GSKT_CTRL 中是否应该设置 1:4 的比例？ Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 请问您能否提供以下信息： 所使用的S32K388芯片的具体零件编号和版本号。 确认设备上是否曾经安装过 HSE 固件（或者这是否是一台完全空白/出厂全新的设备）。 IVT 配置，特别是 hseFwHeaderStartAddr、appBootAddr 和任何其他与 HSE 相关的 IVT 字段的值。 RESET后的完整RESET状态寄存器转储（MC_RGM_DES、MC_RGM_FES 和任何其他相关的RESET寄存器）。 无论问题是出现在多个设备上还是仅出现在单个板上。 一个能够重现该问题的最小项目/应用程序，或者至少是 RESET 发生之前执行的启动代码序列。 目前尚不清楚重置是由 HSE/SBAF、应用程序问题还是设备配置问题引起的，因此上述信息将有助于确定根本原因。 Re: S32K388 HSE_SWT Reboot for Fresh Chip flashing 据我们所知，这已经解决了这个问题。我希望文档能够更新，以反映选项 A++ 需要更换此垫片@davidtosenovjan

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 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 第 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 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