Where can I obtain the AN12064 document？ Where can I obtain the AN12064 document？ Evaluation Board

S32K3 浮動小数点設定ファイル こんにちは、チームの皆さん、 私のプロジェクトでは、浮動小数点数データを使用して算術演算を行おうとしていますが、計算が期待どおりに行われません。 #define macro -31.374 UTILS PRINTF を使用してマクロ値を表示しようとすると、 -32.374 になります。同様に他の値についても、値は1ずつ増加します。 そのため、計算結果が期待通りにならなかった。 これに関して何か設定ファイル（cfg）を作成する必要はありますか？ 現在の目標設定 nirmal_masilamani_0-1790009448678.pngnirmal_masilamani_0-1790009448678.png Re: S32K3 Floating point cfg こんにちは、 @nirmal_masilamani さん。 「UTILS PRINTF」とは具体的に何を指しているのか教えていただけますか? どのように計算を行っていますか？結果は浮動小数点変数に格納されますか？はいの場合、デバッガーで確認した時点で既に変数に誤った値が含まれているのでしょうか、それとも問題はそれを印刷した時のみ発生するのでしょうか？ BR、VaneB Re: S32K3 Floating point cfg こんにちは、 @VaneB さん。 サポートありがとうございます。はい、問題はPRINTF関数にありました。デバッグ中に正しいデータを読み取ることができました。

AN12064書類はどこで入手できますか? AN12064書類はどこで入手できますか? 評価ボード

インラインECC検証方法 こんにちは、 私はiMX8M Plusの外部DDRメモリ向けにインラインECCの実装に取り組んでいます。 ECCは動作しているようです(U-Bootの修正完了、LinuxにEDACドライバーが表示され、/sys/devices/system/edac/mc/mc0/仮想ファイルも存在します)。 保護機能をテストし、検証する方法を探しています。 私の理解では、データ自体にエラーを注入することは不可能であり、代わりにECCパリティビットを破損させる必要があるということです。 AN 13566 セクション 3.2.9同社は「この機能に関する詳細情報は、ご要望に応じて提供いたします」と述べている。 この情報はどのように依頼すればよいのでしょうか?この件に関して特定のNXPの連絡先やチャネルはありますか? よろしくお願いします、 Re: Inline ECC validation method こんにちは、 私は外部DDRを搭載したi.MX 8M PlusにインラインECCを実装しています。ECCは正常に動作しているようです:U-Bootの設定済み、LinuxのEDACドライバが有効、/sys/devices/system/edac/mc/mc0/が存在します。 次に、意図的に訂正可能なエラーと訂正不可能なエラーを生成することで、ECC保護機能を検証したいと思います。 AN13566、セクション3.2.9、インラインECCエラーは、ECC_REGION_PARITY_LOCKを用いてECC領域を解除し、ECCパリティビットを上書きすることで注入できると述べています。また、この機能に関する詳細情報はリクエストに応じて提供されるとも記載されている。 Re: Inline ECC validation method こんにちは、 もちろん提供は可能ですが、この件にはサポートチケットを作成する必要があります https://support.nxp.com/s/?language=en_US リクエストの本文に私の名前を記載していただければ、チケットの追跡や資料の提供ができます。 よろしくお願いいたします。 アルド。

ls1043a - should thermal_zone5 be active in the Linux BSP? I work on with the reference board for ls1043 processor ls1043ardb and having an issue with the thermal subsystem. The error I see is:  [ 116.704475] thermal thermal_zone5: critical temperature reached (104 C), shutting down It seems a bit sporadic but when it comes it comes quite soon after boot. It does not come all the time. When the system is stable the temperature from thermal_zone5 is always 0. The dts file fsl-ls1043a.dtsi have thermal_zone0 - thernal_zone5 active. (fsl-ls1043a.dtsi\freescale\dts\boot\arm64\arch - qoriq-components/linux - Linux Tree for QorIQ support ) The question is if ls1043 should have thermal_zone5 active? Looking in to the "QorIQ LS1043A Reference Manual, Rev. 5, 04/2019" chapter 35.1.1 "Local temperature sensor placement" I can read a table saying that the ls1043 have Temperature sensor ID 0-4 while ID 5-15 is marked as reserved. Is it correct that hte dtsi file enables thermal_zone5 and is it available in ls1043? Thanks, /Peter Re: ls1043a - should thermal_zone5 be active in the Linux BSP? Hello, We are seeing a similar issue on an LS1043A platform running Linux 4.19.68. The system occasionally reports: thermal thermal_zone5: critical temperature reached (104 C), shutting down   One observation is that thermal zones 0-4 generally track each other closely, while thermal_zone5 often reports significantly different values and behaves differently from the other zones.   Prior to shutdown, the thermal zones report values similar to: thermal_zone0: 75000 thermal_zone1: 76000 thermal_zone2: 76000 thermal_zone3: 75000 thermal_zone4: 74000 thermal_zone5: 0 In a previous reply, NXP mentioned that thermal_zone5 values were indeterminate and that a fix would be provided in a future LSDK release. Could you please confirm whether this issue was ever fixed, and if so, which LSDK/kernel release contains the fix? Thanks. Re: ls1043a - should thermal_zone5 be active in the Linux BSP? I am also facing the similar issue on the latest LSDK 20.12, Kernel 5.4.47.  [ 2115.927267] thermal thermal_zone1: critical temperature reached (85 C), shutting down [ 2116.951246] thermal thermal_zone1: critical temperature reached (85 C), shutting down [ 2117.975285] thermal thermal_zone1: critical temperature reached (85 C), shutting down Could you please let me know if any workaround is available to fix this? What is the root cause of this issue? Re: ls1043a - should thermal_zone5 be active in the Linux BSP? We acknowledge the issue, currently the values reported by thermal zone 5 are indeterminate and can cause such issue at any random point We will be providing an official fix in our upcoming LSDK releases. For now you can remove thermal zone 5 from your dtsi  and see if it helps

FRDM-i.MX95の外部JTAGデバッガ接続で、期待されるJTAG信号が出力されない。 こんにちは、 FRDM-i.MX95ボードに外部JTAGデバッガを接続しようとしています。 基板の回路図によると、JTAG/DAP信号はPCB上のテストポイントに配線されているようで、関連する一部の部品はDNP（未実装）とマークされている。 これに基づき、基板を以下のように改造しました。 テストポイントからのJTAG信号をコネクテッド JTAG/DAP信号経路に関連するDNP抵抗器を取り付けました 外部デバッガ用のコネクタを追加しました VTref、GND、TCK、TMS、TDI、TDO、RESETを外部デバッガにコネクテッド しかし、デバッガやボード側からの期待されるJTAG信号の出力は観測できません。 例えば、デバッガ接続シーケンス中にTCK/TMS/TDIが期待どおりに表示されない。 以下の点を確認していただけますか? 上記の改造方法は、外部JTAGデバッガをFRDM-i.MX95ボードに接続するのに正しいのでしょうか? 外部JTAG/DAPインターフェースを有効にするために追加の抵抗、ジャンパー、はんだブリッジ、基板の改造などが必要ですか? 外部デバッガがJTAG信号の駆動を開始する前に、VTref電圧レベルや電源シーケンスに関する要件はありますか？ FRDM-i.MX95上のi.MX95は、JTAG/DAPインターフェースにアクセスできるようになる前に、ブートモード、ヒューズ設定、セキュリティ設定、ソフトウェア初期化が必要ですか? 外部JTAGデバッガはこのボード上でCortex-A55、Cortex-M33、Cortex-M7コアに直接アクセスできますか?それともブートローダーやファームウェアによる追加の初期化が必要ですか? FRDM-i.MX95で外部デバッガを使用する際に推奨されるコネクタピンの割り当てや、参照変更ガイドはありますか？ FRDM-i.MX95ボードで外部JTAGデバッグを有効にするためのガイダンスや回路図の参考、必要な改造の詳細を教えていただけるとありがたいです。 よろしくお願いいたします。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. あなたの修正方法は正しいですか？ 原則的には、そうです。 FRDM回路図に以下が含まれている場合： TCK TMS TDI TDO nTRST または RESET VTref GND テストポイントやDNP（デジタルノイズプロテクタリング）オプションを通して信号を取り出し、それらの信号をコネクタにルーティングするのが、一般的に正しいアプローチです。 しかし、回路図自体が検索結果に返ってこなかったため、 必要なDNP抵抗 がすべて入力されているかは確認できません。ユーザーマニュアルにはJTAG回路は含まれていません。 2. なぜTCK/TMS/TDIの活性が見られないのでしょうか？ 通常、JTAGプローブが接続されると: TCK/TMS/TDIはデバッガによって駆動されます。 ターゲットボードはそれらを生成しません。 TCK/TMSで全く切り替えが見られない場合： 最も一般的な原因その1：VTrefが検出されない 多くのプローブ（Lauterbach、J-Link、PE Micro、ULINKなど）は、VTrefが存在し、かつ有効な範囲内にあるまでJTAGピンを駆動しません。 確認： コネクタにおけるVTref電圧。 共通接地接続。 プローブソフトウェアは目標電圧を報告します。 FRDM-i.MX95の場合、DAP I/O電源は3.3Vドメイン（NVCC_CCM_DAP）に関連しているようです。ボードのドキュメントには、このドメインがVDD_3V3から電源を供給されていることが示されています。 最も一般的な原因その2：ボードに電源が供給されていない ほとんどのデバッガは、センシングのためだけにVTrefを使用します。 それらは標的に電力を供給しない。 確認する： 基板はJ25から給電されます。 PMICが起動しました。 VDD_3V3が存在します。 基板のLEDが点灯しています。 この基板には外部PD電源が必要です。 最も一般的な原因その3：信号ルーティングの再作業の不足 JTAGパスに以下が含まれる場合： 0Ω DNP抵抗器 絶縁抵抗 代替の詰め物オプション 抵抗が1つでも欠けていると、TCK/TMSが切断されることがあります。 回路図は検索結果に含まれていないため、正確な抵抗数リストを検証できません。 最も一般的な原因その4：ピンマッピングの間違い オームメーターで確認してください。 プローブピン → コネクタピン → 抵抗器 → テストポイント → i.MX95 ボール。 テストポイントラベルが標準的なARM 20ピンの順序と一致しているとは限りません。 3. 特別な起動モードが必要ですか？ セキュリティ保護されていないデバイスの場合： JTAGクロックの動作を監視するだけであれば、ブートモードは必要ないはずです。 TCK/TMSは、デバッガがVTrefを検出してスキャンシーケンスを開始するとすぐに切り替わるはずです。 ブートスイッチは以下に影響します: eMMCブート SDブート シリアルダウンローダー そして、これらはデバッガがTCKを生成するかどうかとは無関係です。 4. セキュリティ設定やヒューズは関係していますか? 可能性はある。 i.MX95は認証済みデバッグおよびデバッグアクセス制御を実装しています。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] しかし： セキュリティ設定は通常、デバッグアクセスを妨げます。 通常、それらはデバッガがTCK/TMS自体を生成することを妨げるものではありません。 TCK活性が全く見られないとの報告ですので、まずは以下を調査します。 VTref プローブ構成 ケーブルのピン配列 人口に関する選択肢が不足しています セキュリティを疑う前に。 5. A55、M33、M7はデバッグ可能か? i.MX95デバッグアーキテクチャは以下をサポートしています: コルテックス-A55 Cortex-M33 Cortex-M7 CoreSight/DAPインフラストラクチャを通じて。[i.MX95RM_Rev2 | PDF] 、 [i.MX95RM_Rev5 | PDF] シリコンの能力の観点から見ると、はい、そうです。 すべてのドメインがすぐに表示されるかどうかは、以下の要因によって決まります。 システムの状態、 セキュリティ構成、 デバッガのサポート。 しかし、デバッガがDAP自体を検出するために、通常は追加のブートローダー初期化は必要ありません。 推奨寸法 基板の再加工を行う前に、以下の点を確認します。 パワー VTref = ?V VDD_3V3 が存在する ボードは正常に起動しています 連続 TCKコネクタ ↔ SoCパス TMSコネクタ↔SoCパス TDIコネクタ↔SoCパス TDOコネクタ↔SoCパス リセットコネクタ ↔ SoCパス プローブ側 デバッガソフトはターゲット電圧を報告しますか? 「ターゲット検出」と表示されますか？ JTAGチェーンスキャンが試行されたと報告されますか？ オシロスコープ プローブを直接以下へ： デバッガーコネクタピン SoC側テストポイント 接続試行中。 デバッガーコネクタにTCKが存在するのに、SoCテストポイントにTCKが存在しない場合、問題はほぼ間違いなく基板の再加工にある。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 再開まで今しばらくお待ちください。 外部JTAGデバッガー接続を見直したところ、 問題は、FRDM-i.MX95 ボードと 外部JTAGデバッガ。 JTAG信号線を短くして再配置した後、デバッガは ターゲットを正しく検出することができ、JTAG信号は次のように観測された。 期待される。 そのため、この問題はJTAG配線の改良によって解決されました 長さと接続品質。 ご協力いただき、改めて感謝申し上げます。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals @kuni1こんにちは。デバッガーをアタッチできた方法について、何か最新情報や情報を提供していただけますか？リセット線は基板のどこに、どのように接続しましたか？どのデバッグコネクタを使用していますか？(J-Link、MCU-Linkなど) 現在、FRDMボードにデバッガーを接続しようとしていますが、同様の問題に直面しています。どなたかご助言いただけると大変助かります。 よろしくお願い申し上げます。

Inline ECC validation method Hello,  I am working on Inline ECC implementation for iMX8M Plus on external DDR memory. ECC appears to be working (U-Boot modifications done, EDAC driver showing up in Linux, /sys/devices/system/edac/mc/mc0/ virtual files are present). I'm looking for ways to test and validate the protection. My understanding is that error injection is not possible into the data itself, and that ECC parity bits must be corrupted instead. AN 13566 section 3.2.9 states : "Further information on this feature is available on request." How can I request this information ? Is there a specific NXP contact/channel for this ? Thank you in advance, Re: Inline ECC validation method Hello, I am implementing Inline ECC on an i.MX 8M Plus with external DDR. ECC appears to be working correctly: U-Boot has been configured, the Linux EDAC driver is active, and /sys/devices/system/edac/mc/mc0/ is present. I would now like to validate the ECC protection by deliberately generating correctable and uncorrectable errors. AN13566, section 3.2.9, states that Inline ECC errors can be injected by unlocking the ECC region using ECC_REGION_PARITY_LOCK and overriding the ECC parity bits. It also mentions that further information on this feature is available on request.  Re: Inline ECC validation method Hello, Sure we can provide it, but for this I would require you to create a support ticket https://support.nxp.com/s/?language=en_US You may mention me in the body of the request so I can track the ticket and provide the material. Best regards/Saludos, Aldo.

S32K3 浮点配置 各位团队成员，大家好！ 在我的项目中，我尝试使用浮点数据进行算术运算，但计算结果并未按预期进行。 #define 宏 -31.374 当我尝试使用 UTILS PRINTF 函数在宏中打印值时，我得到的是 -32.374。类似地，其他值的值也递增 1。 正因如此，我的计算结果才没有按预期进行。 我需要为此修改什么配置文件吗？ 我目前的目标设定 nirmal_masilamani_0-1790009448678.pngnirmal_masilamani_0-1790009448678.png Re: S32K3 Floating point cfg 你好@nirmal_masilamani 请问您能否解释一下“UTILS PRINTF”是什么意思？ 你是如何进行计算的？结果是否存储在浮点变量中？如果是，那么在调试器中查看变量时，该变量是否已经包含错误的值，还是只有在打印该变量时才会出现问题？ BR，VaneB Re: S32K3 Floating point cfg 你好@VaneB ， 感谢您的支持，是的，问题出在 PRINTF 函数上，调试时我能够读取到正确的数据。

FRDM-i.MX95 上的外部 JTAG 调试器连接未输出预期的 JTAG 信号 你好， 我正在尝试将外部 JTAG 调试器连接到 FRDM-i.MX95 板。 根据板原理图，JTAG/DAP 信号似乎被连接到 PCB 上的测试点，一些相关元器件被标记为 DNP。 基于此，我对电路板进行了如下修改： 连接测试点的 JTAG 信号 安装与 JTAG/DAP 信号路径相关的 DNP 电阻器 添加了外部调试器的连接器 将 VTref、GND、TCK、TMS、TDI、TDO 和 RESET 连接到外部调试器 但是，我无法从调试器/电路板端观察到预期的 JTAG 信号输出。 例如，在调试器连接序列期间，TCK/TMS/TDI 没有按预期出现。 请您确认以下几点？ 上述修改方法是否适用于将外部 JTAG 调试器连接到 FRDM-i.MX95 板？ 要启用外部 JTAG/DAP 接口，是否需要额外的电阻器、跳线、焊桥或板修改？ 外部调试器开始驱动 JTAG 信号之前，VTref 电压等级或电源时序是否有任何要求？ FRDM-i.MX95 上的 i.MX95 在 JTAG/DAP 接口可访问之前是否需要任何启动模式、熔丝设置、网络安全设置或软件初始化？ 外部 JTAG 调试器能否直接访问该板上的 Cortex-A55、Cortex-M33 和 Cortex-M7 内核，还是需要引导加载程序/固件进行额外的初始化？ 在使用 FRDM-i.MX95 时，是否有推荐的连接器引脚分配或参考修改指南，以便将外部调试器与 FRDM-i.MX95 配合使用？ 如果您能提供在 FRDM-i.MX95 板上启用外部 JTAG 调试的任何指导、原理图参考或所需修改细节，我将不胜感激。 顺祝商祺！ Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. 你的修改方法是否正确？ 原则上，是的。 如果 FRDM 原理图显示： TCK TMS TDI TDO nTRST 或 RESET VTREF GND 通过测试点和 DNP 填充选项，然后将这些信号路由到连接器通常是正确的方法。 但是，由于搜索结果中没有返回原理图，因此我无法确认所有必需的 DNP 电阻器是否都已安装到位。用户手册中不包含 JTAG 电路图。 2. 为什么检测不到 TCK/TMS/TDI 活性？ 通常情况下，当连接 JTAG 探针时： TCK/TMS/TDI 由调试器驱动。 目标板不会生成它们。 如果您在 TCK/TMS 上完全看不到任何切换： 最常见原因 1：未检测到 VTref 许多探针（Lauterbach、J-Link、PE Micro、ULINK 等）只有在 VTref 存在且在有效范围内时才会驱动 JTAG 引脚。 检查： 连接器处的 VTref 电压。 共用接地连接。 探针软件会报告目标电压。 对于 FRDM-i.MX95，DAP I/O 电源似乎与 3.3 V 功能域 (NVCC_CCM_DAP) 有关。板文档显示该功能域由VDD_3V3供电。 最常见原因二：电路板未通电 大多数调试器仅使用 VTref 进行检测。 它们不会为目标提供动力。 核实： 电路板由 J25 供电。 PMIC启动。 VDD_3V3 存在。 电路板上的LED指示灯亮起。 该板需要外部PD电源。 最常见原因#3：缺少信号路由重构 如果 JTAG 路径包含： 0Ω DNP电阻器 隔离电阻器 其他馅料选择 即使缺少一个电阻，也可能导致 TCK/TMS 断开连接。 由于搜索结果中没有原理图，我无法核实电阻器的确切配置。 最常见原因#4：引脚映射错误 用欧姆表验证： 探针引脚 → 连接器引脚 → 电阻器 → 测试点 → i.MX95 球。 不要假设测试点标签与标准的 ARM 20 引脚顺序一致。 3. 是否需要特殊的启动模式？ 对于不安全的设备： 观察 JTAG 时钟活动不应该需要启动模式。 一旦调试器检测到 VTref 并开始扫描序列，TCK/TMS 就应该切换。 启动开关会影响： eMMC启动 SD启动 序列号下载器 这与调试器是否生成 TCK 无关。 4. 是否涉及安全设置/熔丝？ 有可能。 i.MX95 实现了认证调试和调试访问控制。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] 然而： 网络安全设置通常会阻止成功的调试访问。 它们通常不会阻止调试器生成 TCK/TMS 本身。 由于您报告完全没有 TCK 活性，我首先会调查以下问题： VTREF 探针配置 电缆引脚排列 缺失的人口选项 在怀疑网络安全之前。 5. A55、M33 和 M7 可以调试吗？ i.MX95调试架构支持： Cortex-A55 Cortex-M33 Cortex-M7 通过 CoreSight/DAP 基础设施。[i.MX95RM_Rev2 | PDF] ， [i.MX95RM_Rev5 | PDF] 所以从硅芯片的性能角度来看，是的。 所有功能域是否立即可见取决于： 系统状态， 网络安全配置， 支持调试器。 但调试器通常不需要额外的引导加载程序初始化即可检测到 DAP 本身。 推荐测量方法 在进一步修改电路板之前，我会检查以下几点： 电源 VTref = ?V VDD_3V3 存在 板正常启动 连续性 TCK 连接器 ↔ SoC 路径 TMS连接器↔SoC路径 TDI 连接器 ↔ SoC 路径 TDO 连接器 ↔ SoC 路径 RESET 连接器 ↔ SoC 路径 探针侧 调试软件是否报告目标电压？ 它是否显示“检测到目标”？ 它是否报告尝试进行 JTAG 链扫描？ 示波器 直接探测： 调试器连接器引脚 SoC侧测试点 连接尝试期间。 如果调试器连接器处存在 TCK，但 SoC 测试点处不存在 TCK，则问题几乎肯定出在电路板返工上。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 感谢您的支持。 我们检查了外部 JTAG 调试器连接，发现 问题是由FRDM-i.MX95板和电路板之间的线路长度引起的。 外部 JTAG 调试器。 缩短并重新排列 JTAG 信号线后，调试器…… 能够正确检测到目标，并观察到了JTAG信号。 预期的。 因此，通过改进JTAG接线方式，这个问题已经得到解决。 长度和连接质量。 再次感谢您的帮助。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals @kuni1你好，请问你能否提供一些关于如何附加调试器的最新进展或信息？你是如何将 RESET 线连接到电路板上的？你使用的是哪种调试连接器？（J-Link、MCU-Link 等） 我目前也遇到了同样的问题，无法将调试器连接到我的FRDM板，非常感谢您的帮助。 谢谢

ls1043a - Linux BSPでthermal_zone5アクティブであるべきですか? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私はLS1043プロセッサのリファレンスボード、LS1043ardbで作業していますが、サーマルサブシステムに問題が発生しています。表示されるエラーは以下のとおりです。 [ 116.704475] thermal thermal_zone5: 臨界温度に達しました (104 ℃)、シャットダウンします 発生頻度はやや不規則ですが、発生する場合は起動後すぐに起こります。いつも起こるわけではない。システムが安定している場合、thermal_zone5 の温度は常に 0 になります。 dtsファイルfsl-ls1043a.dtsiでは、thermal_zone0～thernal_zone5が有効になっています。(fsl-ls1043a.dtsi\freescale\dts\boot\arm64\arch - qoriq-components/linux - QorIQサポート用のLinuxツリー) 問題は、ls1043でthermal_zone5を有効にするべきかどうかです。「QorIQ LS1043A Reference Manual, Rev. 5, 04/2019」の第35.1.1章「ローカル温度センサの配置」を調べてみると、LS1043の温度センサID 0-4で、ID 5-15は予約済みと記されている表が読めます。dtsiファイルによってthermal_zone5が有効になり、ls1043で利用可能になるというのは正しいでしょうか？ ありがとう、 ピーター Re: ls1043a - should thermal_zone5 be active in the Linux BSP? こんにちは、 Linux 4.19.68を搭載したLS1043Aプラットフォームでも同様の問題が発生しています。 システムは時折、以下のことを報告します。 thermal thermal_zone5: 臨界温度（104℃）に達したため、シャットダウンします   観察されたことの一つは、熱ゾーン0～4は概ね互いに近い値を示すのに対し、熱ゾーン5はしばしば著しく異なる値を報告し、他のゾーンとは異なる挙動を示すということである。   シャットダウン前に、熱ゾーンは次のような値を報告します。 thermal_zone0: 75000 熱ゾーン1: 76000 熱ゾーン2: 76000 熱ゾーン3: 75000 熱ゾーン4: 74000 熱ゾーン5: 0 以前の返信でNXPはthermal_zone5値は不確定であり、将来のLSDKリリースで修正を提供すると述べていました。 この問題が修正されたかどうか、もし修正されたならどのLSDK/カーネルリリースに修正が含まれているのか確認していただけますか? ありがとうございます。 Re: ls1043a - should thermal_zone5 be active in the Linux BSP? 私も最新のLSDK 20.12、カーネル5.4.47で同様の問題に直面しています。 [ 2115.927267] thermal thermal_zone1: 臨界温度に達したため、シャットダウンします (85℃) [ 2116.951246] thermal thermal_zone1: 臨界温度に達したため、シャットダウンします (85℃) [ 2117.975285] thermal thermal_zone1: 臨界温度に達したため、シャットダウンします (85℃) この問題を解決する回避策があれば教えていただけませんか? この問題の根本原因は何ですか？ Re: ls1043a - should thermal_zone5 be active in the Linux BSP? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 問題を認識しています。現在、サーマルゾーン5で報告される値は不確定で、任意のランダムなタイミングで問題を引き起こす可能性があります。今後のLSDKリリースで公式な修正を提供する予定です。 今のところ、DTSIからサーマルゾーン5を外してみて、改善するか試してみてはどうでしょうか

External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Hello, I am trying to connect an external JTAG debugger to the FRDM-i.MX95 board. According to the board schematic, the JTAG/DAP signals appear to be routed to test points on the PCB, and some related components are marked as DNP. Based on this, I modified the board as follows: Connected the JTAG signals from the test points Mounted the DNP resistors related to the JTAG/DAP signal path Added a connector for an external debugger Connected VTref, GND, TCK, TMS, TDI, TDO, and RESET to the external debugger However, I cannot observe the expected JTAG signal output from the debugger/board side. For example, TCK/TMS/TDI do not appear as expected during the debugger connection sequence. Could you please confirm the following points? Is the above modification method correct for connecting an external JTAG debugger to the FRDM-i.MX95 board? Are there any additional resistors, jumpers, solder bridges, or board modifications required to enable the external JTAG/DAP interface? Is there any requirement for VTref voltage level or power sequencing before the external debugger starts driving JTAG signals? Does the i.MX95 on FRDM-i.MX95 require any boot mode, fuse setting, security setting, or software initialization before the JTAG/DAP interface becomes accessible? Can the external JTAG debugger access the Cortex-A55, Cortex-M33, and Cortex-M7 cores directly on this board, or is additional initialization by the bootloader/firmware required? Is there any recommended connector pin assignment or reference modification guide for using an external debugger with FRDM-i.MX95? I would appreciate it if you could provide any guidance, schematic references, or required modification details for enabling external JTAG debugging on the FRDM-i.MX95 board. Best regards, Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. Is your modification approach correct? In principle, yes. If the FRDM schematic exposes: TCK TMS TDI TDO nTRST or RESET VTref GND through test points and DNP stuffing options, then routing those signals to a connector is generally the correct approach. However, I cannot confirm that all required DNP resistors have been populated because the schematic itself was not returned by the search results. The user manual does not contain the JTAG circuitry. 2. Why would no TCK/TMS/TDI activity be seen? Normally, when a JTAG probe is connected: TCK/TMS/TDI are driven by the debugger. The target board does not generate them. If you see absolutely no toggling on TCK/TMS: Most common cause #1: VTref not detected Many probes (Lauterbach, J-Link, PE Micro, ULINK, etc.) will not drive JTAG pins until VTref is present and within a valid range. Check: VTref voltage at the connector. Common ground connection. Probe software reports the target voltage. For FRDM-i.MX95, the DAP I/O supply appears related to the 3.3 V domain (NVCC_CCM_DAP). The board documentation shows this domain powered from VDD_3V3. Most common cause #2: Board not powered Most debuggers use VTref for sensing only. They do not power the target. Verify: Board powered from J25. PMIC started. VDD_3V3 present. Board LEDs active. The board requires external PD power. Most common cause #3: Missing signal routing rework If the JTAG path contains: 0-Ω DNP resistors isolation resistors alternative stuffing options then missing even a single resistor can leave TCK/TMS disconnected. Since the schematic is not available in the search results, I cannot verify the exact resistor population list. Most common cause #4: Wrong pin mapping Verify with an ohmmeter: Probe pin → connector pin → resistor → test point → i.MX95 ball. Do not assume the test point labels match standard ARM 20-pin ordering. 3. Is a special boot mode required? For a non-secure device: No boot mode should be required just to observe JTAG clock activity. TCK/TMS should toggle as soon as the debugger detects VTref and starts a scan sequence. The boot switches affect: eMMC boot SD boot serial downloader and are unrelated to whether the debugger generates TCK. 4. Are security settings/fuses involved? Potentially. The i.MX95 implements authenticated debug and debug access control. [i.MX95RM_Rev4 | PDF], [i.MX95RM_Rev2 | PDF], [i.MX95 Sec...2026-final | PowerPoint] However: Security settings would usually prevent successful debug access. They would not normally prevent the debugger from generating TCK/TMS itself. Since you report no TCK activity at all, I would first investigate: VTref Probe configuration Cable pinout Missing population options before suspecting security. 5. Can A55, M33, and M7 be debugged? The i.MX95 debug architecture supports: Cortex-A55 Cortex-M33 Cortex-M7 through the CoreSight/DAP infrastructure. [i.MX95RM_Rev2 | PDF], [i.MX95RM_Rev5 | PDF] So from a silicon capability perspective, yes. Whether all domains are immediately visible depends on: system state, security configuration, debugger support. But no additional bootloader initialization is generally required for the debugger to detect the DAP itself. Recommended measurements Before further board rework, I would check: Power VTref = ? V VDD_3V3 present Board booting normally Continuity TCK connector ↔ SoC path TMS connector ↔ SoC path TDI connector ↔ SoC path TDO connector ↔ SoC path RESET connector ↔ SoC path Probe side Does the debugger software report target voltage? Does it show "target detected"? Does it report JTAG chain scan attempted? Oscilloscope Probe directly at: debugger connector pin SoC-side test point during connect attempt. If TCK is present at the debugger connector but absent at the SoC test point, the issue is almost certainly in the board rework. Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Thank you for your support. We reviewed our external JTAG debugger connection and found that the issue was caused by the wiring length between the FRDM-i.MX95 board and the external JTAG debugger. After shortening and rearranging the JTAG signal wires, the debugger was able to detect the target correctly and the JTAG signals were observed as expected. Therefore, this issue has been resolved by improving the JTAG wiring length and connection quality. Thank you again for your assistance. Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals @kuni1 Hi there, would you be able to provide any updates or information on how you were able to attach the debugger? Where/how did you attach the RESET wire to the board? What debugging connector are you using? (J-Link, MCU-Link, etc) I am currently facing the same issues trying to attach a debugger to my FRDM board, and any help would be greatly appreciated.  Thank you

S32K3 Floating point cfg Hello Team, In my project, i am trying to do arithmetic operation using float data, but calculation is not happening as expected. #define macro -31.374 when i try to print in macro value using UTILS PRINTF, i am getting -32.374, similarly for other values, value get incremented by 1. Because of this, my calculations not happening as expected. Is there any cfg i need to do for this?  My current target setting nirmal_masilamani_0-1790009448678.pngnirmal_masilamani_0-1790009448678.png Re: S32K3 Floating point cfg Hi @nirmal_masilamani  Could you please clarify what you mean by "UTILS PRINTF"? How are you performing the calculations? Are the results stored in a float variable? If yes, does the variable already contain the wrong value when viewed in the debugger, or is the issue only observed when printing it? BR, VaneB Re: S32K3 Floating point cfg Hello @VaneB , Thank you for your support, yes issue was in PRINTF function, while debugging i was able to read the proper data.

Question about Pins Tool and Blinking LED Knowledgebase HOWTO I have a few questions in regards to the Pins Tool and the Knowledge Base LED entry for the S32K1xx. The Entry in question can be found here: HOWTO: Create a Blinking LED example project using S32K1xx RTD with AUTOSAR  The Entry says to disable the Pins Tool. The MCAL Port User Manual however mentions that it is perfectly fine to use the Pins Tool for configurating the controller. Which information is correct? Is there a way to add Pins to the Pins Tool and have them automatically added to the respective MCAL entries (Port, Dio)? Or do I always have to add each pin three times (Pins Tool, Port, Dio)? What is the recommended workflow for this admittedly most basic of functionalities? Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO @VaneB  Thanks for clarifying the process. I highly recommend adding a way to synchronize the pins between the Pins Tool and the MCAL Port and Dio tools. The Pins Tool is very intuitive and easy to use while the MCAL settings section is tedious and unclear. Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO Hi @daniel_meier  This article was published quite some time ago, and the relationship between the Pins Tool and the PORT driver has changed across RTD releases. In the latest versions, when using MCAL drivers, the Pins Tool and PORT driver work closely together. This means the pins should be configured in the Pins Tool and also added to the PORT driver so the pin initialization structures are generated correctly. So, with MCAL, you will need to configure the pins in both the Pins Tool and the PORT driver (Peripheral Tool). The DIO driver only needs to be configured if those pins will be used as GPIOs. BR, VaneB

请求书面许可，以便在商业智能产品中使用您的 API/数据 你好， 我正在开发一款商业机会情报 SaaS 产品，我想咨询如何获得书面许可，以便以编程方式使用 NXP 产品变更通知/产品停产/生命周期结束信息。 预期用途： 自动检索已授权的 NXP PCN/EOL 数据； 在商业SaaS产品中使用； 用于溯源和变更检测的历史数据存储； 处理成衍生信号和分析； 仅向已认证用户显示注明来源的事实信息； 禁止将 NXP 原始数据作为独立组网 \\(SA\\) 数据集进行转售。 我们特别想知道 NXP 是否提供 API、数据源、授权数据访问方法或商业协议来允许这种用途。 NXP 的公开使用条款似乎要求对网站内容进行商业复制/分发前获得书面同意，因此我不想在未经明确授权的情况下自动访问。 请问您能否指引我联系相关的API/数据许可或法律部门的联系人/团队？ 谢谢你， 达里乌斯·西图

Request for Written Permission to Use Your API/Data in a Commercial Intelligence Product Hi, I’m building a commercial opportunity-intelligence SaaS product and I would like to request guidance on obtaining written permission to use NXP Product Change Notifications / Product Discontinuation / End-of-Life information programmatically. Intended use: automated retrieval of authorized NXP PCN/EOL data; use inside a commercial SaaS product; historical storage for provenance and change detection; processing into derived signals and analytics; limited display of factual, source-attributed information to authenticated users; no resale of NXP raw data as a standalone dataset. We would specifically like to know whether NXP offers an API, feed, licensed data access method, or commercial agreement that permits this use. NXP’s public Terms of Use appear to require prior written consent for commercial reproduction/distribution of website content, so I do not want to automate access without explicit authorization. Could you please direct me to the appropriate API/data licensing or legal contact/team? Thank you, Darius Citu

S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 亲爱的NXP，你好：         我们公司K148上有一个bootloader和app两个分区，在app里面有关闭jtag的功能，当在app中把jtag关了之后reset后bootloader起不来导致芯片变砖。经调查，bootloader有32K，从0x00到0x8000，关闭jtag是在0x408地址处写入了0xFFu, 0xFFu, 0xFFu, 0xFFu, 0xFCu, 0x7Fu, 0xFFu, 0xFFu，导致flash内容变化，reset后CSEc计算bootloader的boot_mac的值和原先的不一致导致变砖。请问NXP官方有没有什么成熟的方案来解决此问题？谢谢。 Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 K148的key槽.png  Hi,@lukaszadrapa  根据上面的手册，BOOT_MAC是一次性不可逆写入的。还是说有官方专门的API能变更它的值？如果是 ，能提供这个API接口吗？ Re: 晶振波形异常 使用贵公司的FS32K144HFT0MLHT这款MC， IMG_20260718_141710.jpg 晶振为AV08000009这款8MHz的无源晶振，波形异常。请问这样的晶振波形 贵公司的MCU可以接受吗 是否会影响正常使用 Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 嗨@vurtual 通常的做法是在生产过程中禁用调试接口，而不是之后在应用程序中禁用。在这种情况下，该过程可以在一个生产步骤中完成：重新编程 Flash 配置字段 (FCF) 以禁用调试端口，然后配置正确的 BOOT_MAC 值（或者允许 CSEc 在下次 RESET 后自动计算该值）。 如果在产品生命周期的后期需要禁用调试接口，也是可以的。但是，一旦 FCF 被重新编程，BOOT_MAC 也必须更新，因为安全启动计算包括修改后的 FCF 内容。否则，安全启动验证将失败。 BOOT_MAC 可以使用标准的 SHE 内存更新协议进行更新，就像 CSEc 密钥的更新方式一样。在将 BOOT_MAC 更新为与新的 FCF 内容匹配后，禁用调试端口后，安全启动应该可以正常工作。 问候， 卢卡斯 Re: 晶振波形异常 你好，@ lukaszadrapa 我们公司使用贵公司的FS32K144HFT0MLHT这款MCU， 配合晶振为AV08000009这款8MHz的无源晶振，波形异常。请问这样的晶振波形，贵公司的MCU可以接受吗，是否会影响MCU的正常使用，谢谢 IMG_20260718_141710.jpg Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 嗨@vurtual 你从哪里看出这是一项不可逆的操作？那不正确。BOOT_MAC 可以更新。 正如我之前提到的： “BOOT_MAC 可以使用标准的 SHE 内存更新协议进行更新，就像 CSEc 密钥的更新方式一样。” 这意味着您可以使用 CMD_LOAD_KEY 命令，该命令与用于导入和更新常规 SHE/CSEc 密钥的命令相同。 要更新 BOOT_MAC，您需要按照标准 SHE 密钥更新程序生成 M1–M5 值。密钥计数器必须递增，并且可以使用 MASTER_ECU_KEY 或 BOOT_MAC_KEY 授权更新。 因此，更新 BOOT_MAC 是受支持的操作，并且不是不可逆的。 此致， Lukas Re: 晶振波形异常 请为此另开一个帖子。谢谢。 Re: 晶振波形异常 好的，谢谢。 Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 我也在secure boot开启的状态下实现关闭jtag的功能。 在开始正式工作之前，我进行了一项实验，流程是： 实验1： 1. secure boot设定为并行模式，BOOT_DEFINE时size设为0x8000 2. 手动计算CMAC并通过master key将CMAC导入BOOT_MAC，重启后板子启动正常BOK=1 3. 关闭watch dog（WDOG_DRV_Deinit） 4. 改写0xFFF0起的8个字节 5. 重新计算CMAC后通过secure boot key将CMAC导入BOOT_MAC 6. 开启watch dog (WDOG_DRV_Init) 再次上电时能看到BOK=1 在这一流程调试OK的情况下，我将第4步的修改内容改为改写0x408起的8个字节(实现关闭JTAG)，即 实验2： 1. secure boot设定为严格模式，BOOT_DEFINE时size设为0x8000 2. 手动计算CMAC并通过master key将CMAC导入BOOT_MAC，重启后板子启动正常BOK=1 3. 关闭watch dog（WDOG_DRV_Deinit） 4. 改写0x408起的8个字节实现关闭JTAG的功能 5. 重新计算CMAC后通过secure boot key将CMAC导入BOOT_MAC 6. 开启watch dog (WDOG_DRV_Init) 执行这一流程时，发生了reset。执行后板子电流直接掉到0.0102A，并且第5步起始时我添加的log“calculate start"没有看到打印。所以我猜测是在第5、第6步之间发生了reset，导致flash确实发生了变化但是boot cmac还是旧值。  之后我改进了这一流程 实验3： 1. secure boot设定为严格模式，BOOT_DEFINE时size设为0x8000 2. 手动计算CMAC并通过master key将CMAC导入BOOT_MAC，重启后板子启动正常BOK=1 3. WDOG_DRV_Trigger 4. DISABLE_GLOBAL_IRQ 5. 改写0xFFF0起的8个字节 6. ENABLE_GLOBAL_IRQ 7. WDOG_DRV_Trigger 8. 重新计算CMAC后通过secure boot key将CMAC导入BOOT_MAC 这个流程成功了，没有发生reset 我想知道方案2中发生reset的原因..确保方案3中添加的关于中断禁止、WDOG_DRV_Trigger的步骤是有效的。

Pins Toolと点滅LEDに関する質問 ナレッジベース HOWTO Pins Toolと、S32K1xxに関するナレッジベースのLEDエントリについて、いくつか質問があります。 問題のエントリーはこちらでご覧いただけます:HOWTO: S32K1xx RTDを使ってAUTOSARで点滅LED例プロジェクトを作成  エントリには、ピンツールを無効にするように記載されています。 しかし、MCALポートのユーザーマニュアルには、コントローラの設定にピンツールを使うのは 全く問題 ないと書かれています。 どちらの情報が正しいですか？ Pins Toolにピンを追加して、それらを対応するMCALエントリ（Port、Dio）に自動的に追加する方法はありますか？ それとも、ピンを毎回3回（ピンツール、ポート、Dio）追加する必要があるのでしょうか？ この、確かに最も基本的な機能について、推奨されるワークフローは何ですか？ Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO @VaneBプロセスを明確にしていただきありがとうございます。 Pins ToolとMCAL PortおよびDioツール間でピンを同期させる機能を追加することを強くお勧めします。 Pins Toolは非常に直感的で使いやすい一方、MCALの設定セクションは煩雑で分かりにくい。 Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO こんにちは、 @daniel_meier さん。 この記事はかなり前に公開されており、ピンツールとPORTドライバーの関係はRTDのリリースごとに変化しています。 最新バージョンでは、MCALドライバーを使用する際、Pins ToolとPORTドライバーが密接に連携して動作します。つまり、ピンはピンツールで設定され、PORTドライバにも追加されてピンの初期化構造が正しく生成されるべきです。 SO、MCALではピンツールとPORTドライバー(周辺ツール)の両方でピンを設定する必要があります。DIOドライバーは、そのピンがGPIOとして使われる場合にのみ設定すればよいです。 BR、VaneB

The S32K148 has secure boot functionality, but the bootloader fails to start after JTAG is disabled. Dear NXP, hello: Our company's K148 has two partitions: a bootloader and an application partition. The application partition has a function to disable JTAG. When JTAG is disabled in the application, the bootloader fails to start after a reset, causing the chip to become bricked. Investigation revealed that the bootloader is 32KB, ranging from 0x00 to 0x8000. Disabling JTAG involved writing 0xFFu , 0xFFu , 0xFFu , 0xFFu , 0xFCu, 0x7Fu , 0xFFu , 0xFFu at address 0x408 , causing a change in the flash content. After a reset, the CSEc calculates a different boot_mac value for the bootloader, resulting in the bricking. Does NXP have any mature solutions to resolve this issue? Thank you. Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 K148的key槽.png Hi, @lukaszadrapa According to the manual above, BOOT_MAC is a one-time, irreversible write. Is there an official API that allows changing its value? If so, could you provide this API? Re: 晶振波形异常 Using your company's FS32K144HFT0MLHT MC IMG_20260718_141710.jpg The crystal oscillator is an 8MHz passive crystal oscillator (AV08000009), and the waveform is abnormal. Is this waveform acceptable for your company's MCU, and will it affect normal operation? Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 Hi @vurtual  The common approach is to disable the debug interface during manufacturing, rather than later from the application. In that case, the process can be done in a single production step: reprogram the Flash Configuration Field (FCF) to disable the debug port and then provision the correct BOOT_MAC value (or allow the CSEc to calculate it automatically after the next reset). If you need to disable the debug interface later in the product lifecycle, that is also possible. However, once the FCF is reprogrammed, the BOOT_MAC must be updated as well, since the secure boot calculation includes the modified FCF contents. Otherwise, the secure boot verification will fail. The BOOT_MAC can be updated using the standard SHE memory update protocol, in the same way that CSEc keys are updated. After updating the BOOT_MAC to match the new FCF contents, secure boot should operate correctly with the debug port disabled. Regards, Lukas Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 Hi @vurtual  Where do you see that this is an irreversible operation? That is not correct. BOOT_MAC can be updated.  As I mentioned previously: "The BOOT_MAC can be updated using the standard SHE memory update protocol, in the same way that CSEc keys are updated." This means you can use the CMD_LOAD_KEY command, which is the same command used to import and update regular SHE/CSEc keys. To update BOOT_MAC, you need to generate the M1–M5 values according to the standard SHE key update procedure. The key counter must be incremented, and the update can be authorized using either the MASTER_ECU_KEY or the BOOT_MAC_KEY. Therefore, updating BOOT_MAC is a supported operation and is not irreversible. Regards, Lukas Re: 晶振波形异常 Hello,@ lukaszadrapa Our company uses your FS32K144HFT0MLHT MCU with an 8MHz passive crystal oscillator (AV08000009), and the waveform is abnormal. Is this crystal oscillator waveform acceptable for your MCU? Will it affect the normal operation of the MCU? Thank you. IMG_20260718_141710.jpg Re: 晶振波形异常 Please create new thread for this. Thank you.  Re: 晶振波形异常 OK ,Thank you. Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 I also implemented the function to disable JTAG while Secure Boot is enabled. Before starting formal work, I conducted an experiment. The procedure was as follows: Experiment 1: 1. Secure boot is set to parallel mode, and size is set to 0x8000 during BOOT_DEFINE. 2. Manually calculate CMAC and import it into BOOT_MAC using the master key. After restarting, the board boots normally with BOK=1. 3. Disable watchdog (WDOG_DRV_Deinit) 4. Rewrite the 8 bytes starting at 0xFFF0 5. After recalculating CMAC, import CMAC into BOOT_MAC using the secure boot key. 6. Enable watchdog (WDOG_DRV_Init) When powered on again, BOK=1 can be seen. With this process debugged successfully, I changed the modification in step 4 to rewrite the 8 bytes starting from 0x408 (to disable JTAG), that is... Experiment 2: 1. Secure boot is set to strict mode, and size is set to 0x8000 during BOOT_DEFINE. 2. Manually calculate CMAC and import it into BOOT_MAC using the master key. After restarting, the board boots normally with BOK=1. 3. Disable watchdog (WDOG_DRV_Deinit) 4. Modify the 8 bytes starting from 0x408 to disable JTAG. 5. After recalculating CMAC, import CMAC into BOOT_MAC using the secure boot key. 6. Enable watchdog (WDOG_DRV_Init) A reset occurred during this process. After execution, the board current dropped directly to 0.0102A, and the log "calculate start" that I added at the beginning of step 5 was not printed. Therefore, I suspect that a reset occurred between steps 5 and 6, causing the flash memory to change but the boot cmac value to remain the old one. I then improved this process. Experiment 3: 1. Secure boot is set to strict mode, and size is set to 0x8000 during BOOT_DEFINE. 2. Manually calculate CMAC and import it into BOOT_MAC using the master key. After restarting, the board boots normally with BOK=1. 3. WDOG_DRV_Trigger 4. DISABLE_GLOBAL_IRQ 5. Rewrite the 8 bytes starting at 0xFFF0 6. ENABLE_GLOBAL_IRQ 7. WDOG_DRV_Trigger 8. After recalculating CMAC, import CMAC into BOOT_MAC using the secure boot key. The process was successful; no reset occurred. I want to know why the reset occurred in Solution 2... Please ensure that the steps added in Solution 3 regarding interrupt disabling and WDOG_DRV_Trigger are effective.

关于引脚工具和闪烁 LED 知识库操作指南的问题 关于引脚工具和 S32K1xx 的知识库 LED 条目，我有一些问题。 相关条目可在此处找到： HOWTO：使用 AUTOSAR 和 S32K1xx RTD 创建闪烁 LED 示例项目 该说明要求禁用图钉工具。 然而，MCAL 端口用户手册中提到，使用引脚工具配置控制器是完全可以的。 哪个信息是正确的？ 是否有办法将引脚添加到引脚工具中，并使其自动添加到相应的 MCAL 条目（端口、二极管）中？ 还是说我必须每次都添加三次每个引脚（引脚工具、端口、Dio）？ 对于这项最基本的功能，推荐的工作流程是什么？ Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO @VaneB谢谢你解释清楚流程。 我强烈建议在引脚工具和 MCAL 端口及二极管工具之间添加同步引脚的功能。 引脚工具非常直观易用，而 MCAL 设置部分则繁琐且不清晰。 Re: Question about Pins Tool and Blinking LED Knowledgebase HOWTO 嗨@daniel_meier 这篇文章发表已有一段时间了，引脚工具和端口驱动程序之间的关系在 RTD 的各个版本中都发生了变化。 在最新版本中，使用 MCAL 驱动程序时，引脚工具和端口驱动程序紧密配合使用。这意味着应该在引脚工具中配置引脚，并将其添加到端口驱动程序中，以便正确生成引脚初始化结构。 因此，使用 MCAL 时，您需要在引脚工具和端口驱动程序（外设工具）中配置引脚。只有当这些引脚将用作 GPIO 时，才需要配置 DIO 驱动程序。 BR，VaneB

S32K148はセキュアブート機能を備えているが、JTAGを無効にするとブートローダーが起動しない。 NXP様、こんにちは。 弊社のK148には、ブートローダーとアプリケーションパーティションの2つのパーティションがあります。アプリケーションパーティションには、JTAGを無効にする機能があります。アプリケーションでJTAGを無効にすると、リセット後にブートローダーが起動せず、チップが動作不能になります。調査の結果、ブートローダーは32KBで、アドレス0x00から0x8000の範囲であることが判明しました。JTAGを無効にするには、アドレス0x408に0xFFu 、0xFFu 、 0xFFu 、 0xFFu 、 0xFCu 、 0x7Fu 、 0xFFu 、 0xFFuを書き込む必要があり、これによりフラッシュメモリの内容が変更されます。リセット後、CSEcがブートローダーに対して異なるboot_mac値を計算してしまうため、チップが動作不能になります。NXPは、この問題を解決するための成熟したソリューションを提供していますでしょうか？よろしくお願いいたします。 Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 K148的key槽.png こんにちは、 @lukaszadrapa 上記のマニュアルによると、 BOOT_MACは一度だけ書き込まれる不可逆的な値です。この値を変更できる公式APIはありますか？もしあれば、そのAPIを提供していただけますか？ Re: 晶振波形异常 御社のFS32K144HFT0MLHT MCを使用しています IMG_20260718_141710.jpg水晶発振器は8MHzの受動型水晶発振器（AV08000009）ですが、波形が異常です。この波形は貴社製MCUにとって許容範囲内でしょうか？また、正常な動作に影響はありますか？ Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 こんにちは@vurtual 一般的な方法は、デバッグインターフェースを製造時に無効にすることであり、アプリケーションから後から無効化するのではなく、その場合、このプロセスは単一の生産ステップで完了します:フラッシュ構成フィールド(FCF)を再プログラムしてデバッグポートを無効化し、正しいBOOT_MAC値をプロビジョニングするか(または次のリセット後にCSEcが自動的に計算できるようにします)。 製品ライフサイクルの後半でデバッグインターフェースを無効化する必要がある場合も可能です。しかし、FCFが再プログラムされると、セキュアブートの計算には変更されたFCFの内容が含まれるため、BOOT_MACも更新する必要があります。そうしないと、セキュアブートの検証が失敗します。 BOOT_MACは標準的なSHEメモリ更新プロトコルを用いて更新可能で、CSEcキーの更新と同じ方法で行えます。BOOT_MACを新しいFCFの内容に合わせて更新した後、デバッグポートを無効にした状態でセキュアブートが正しく動作するはずです。 よろしくお願いいたします。 ルーカス Re: 晶振波形异常 この件のために新しいThreadを作成してください。ありがとう。 Re: 晶振波形异常 こんにちは、@ ルカシャドラパ 弊社では、貴社製FS32K144HFT0MLHTマイコンを8MHzのパッシブ水晶発振器（AV08000009）と組み合わせて使用していますが、波形が異常です。この水晶発振器の波形は貴社製マイコンにとって許容範囲内でしょうか？また、マイコンの正常な動作に影響はありますか？よろしくお願いいたします。 IMG_20260718_141710.jpg Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 こんにちは@vurtual これが不可逆的な操作であると、あなたはどこにお考えですか？それは正しくありません。BOOT_MAC更新可能です。 以前にも述べたように： 「BOOT_MACは標準的なSHEメモリ更新プロトコルで更新できます。CSEcキーの更新と同じ方法です。」 つまり、通常のSHE/CSEcキーのインポートや更新に使われるCMD_LOAD_KEYコマンドを使えます。 BOOT_MACを更新するには、標準のSHEキー更新手順に従ってM1～M5の値を生成する必要があります。キーカウンターは増分されなければならず、更新はMASTER_ECU_KEYまたはBOOT_MAC_KEYのいずれかで承認できます。 したがって、BOOT_MACの更新はサポートされている操作であり、元に戻せない操作ではありません。 よろしくお願いいたします。 ルーカス Re: 晶振波形异常 はい、ありがとうございます。 Re: S32K148有secureboot功能，但是bootloader在jtag关闭后起不来 セキュアブートが有効になっている間はJTAGを無効にする機能も実装しました。 正式な作業を開始する前に、私は実験を行った。その手順は以下のとおりである。 実験1： 1. セキュアブートはパラレルモードに設定され、BOOT_DEFINE 中にサイズが 0x8000 に設定されます。 2. マスターキーを使用してCMACを手動で計算し、BOOT_MACにインポートします。再起動後、ボードはBOK=1で正常に起動します。 3. ウォッチドッグを無効にする (WDOG_DRV_Deinit) 4. 0xFFF0から始まる8バイトを書き換える 5. CMACを再計算した後、セキュアブートキーを使用してCMACをBOOT_MACにインポートします。 6. ウォッチドッグを有効にする (WDOG_DRV_Init) 再び電源を入れると、BOK=1と表示される。 このプロセスのデバッグが成功したので、ステップ4の変更点を0x408から始まる8バイトを書き換えるように変更しました（JTAGを無効にするため）。つまり... 実験2： 1. セキュアブートは厳格モードに設定され、BOOT_DEFINE 中にサイズが 0x8000 に設定されます。 2. マスターキーを使用してCMACを手動で計算し、BOOT_MACにインポートします。再起動後、ボードはBOK=1で正常に起動します。 3. ウォッチドッグを無効にする (WDOG_DRV_Deinit) 4. 0x408から始まる8バイトを変更してJTAGを無効にします。 5. CMACを再計算した後、セキュアブートキーを使用してCMACをBOOT_MACにインポートします。 6. ウォッチドッグを有効にする (WDOG_DRV_Init) この処理中にリセットが発生しました。実行後、ボード電流は0.0102Aまで急激に低下し、ステップ5の冒頭に追加したログ「calculate start」は出力されませんでした。したがって、ステップ5とステップ6の間でリセットが発生し、フラッシュメモリの内容は変更されたものの、ブート時のcmac値は古いままだったと考えられます。 その後、私はこのプロセスを改善しました。 実験3： 1. セキュアブートは厳格モードに設定され、BOOT_DEFINE 中にサイズが 0x8000 に設定されます。 2. マスターキーを使用してCMACを手動で計算し、BOOT_MACにインポートします。再起動後、ボードはBOK=1で正常に起動します。 3. WDOG_DRV_Trigger 4. グローバル割り込みを無効にする 5. 0xFFF0から始まる8バイトを書き換える 6. ENABLE_GLOBAL_IRQ 7. WDOG_DRV_Trigger 8. CMACを再計算した後、セキュアブートキーを使用してCMACをBOOT_MACにインポートします。 処理は正常に完了しました。リセットは発生しませんでした。 解決策2でリセットが発生した理由を知りたいです。解決策3で追加された割り込み無効化とWDOG_DRV_Triggerに関する手順が有効であることを確認してください。