S32K3 高速スタンバイ起動失敗 こんにちは、 高速スタンバイのサンプルプロジェクトで、配列を定義しました。 到着 で .standby_data セクションにありますが、この配列はコードのどこにも使用されていません。ただし、この配列の定義をコメントアウトすると、デバイスは高速スタンバイから復帰できません。そのままにしておくと、ウェイクアップは期待どおりに動作します。さらに、最適化レベルも動作に影響することに気づきました。 -O0 最適化、ウェイクアップ失敗、しかし変更して -オス するとうまくいく。なぜ変数を定義するとうまくいくのか .standby_data このセクションはウェイクアップ機能に影響を与えますか？また、最適化レベルがこれほど大きな影響を与えるのはなぜですか？ S32K312 RTD400 S32DS BR、 ジェイソン Re: S32K3 fast standby wake up fail こんにちは、@Senlent ご返信いただき、誠にありがとうございます。住所を0x20408000に変更したことで、以前は失敗していたケースが正常に動作するようになりました。 ちなみに、私の別のThread(S32K3 ADC Optimize DMA Streaming)については、会社のメールアドレスに登録した新しいアカウント(Jason07)で返信しましたが、返信時にアカウント変更を忘れていました。 Re: S32K3 fast standby wake up fail こんにちは、@ Jason22 プログラム内で「arr」配列をコメントアウトするかどうかは、高速ウェイクアップ後のMSPの初期値として使用される__BSS_SRAM_STARTの値に影響します。 この値が小さすぎるとスタックオーバーフローを引き起こすことがあります。 このサンプルプロジェクトでは、この値をスタンバイRAMの終了アドレスである0x20408000に設定することをお勧めします。

GPIO 唤醒由睡眠期间的短噪声脉冲触发。 您好，NXP团队： 我们在定制板上使用 i.MX8MP，并搭载 Linux 电路板支持包。LF-6.12.20。多个 GPIO 引脚配置为唤醒源。 问题：在 EMC 瞬态测试 (ESD) 期间，这些 GPIO 线路上的短噪声脉冲会错误地唤醒已挂起的系统。 我们已经确认软件防抖无法解决这个问题：唤醒决定是由硬件在 CPU 挂起时做出的，而 GPIO 中断处理程序（包括 gpio-keys 防抖）只有在系统恢复后才会运行，因此软件无法阻止唤醒本身。 我们还查看了 Linux 驱动程序 (LF-6.12.20) 和 i.MX8MP 参考手册，但没有找到任何用于 GPIO 唤醒路径的硬件过滤器。请确认我的理解是否正确。 问题： 1. i.MX8MP 是否有任何硬件选项（在 GPIO、GPC 或可通过 ATF 配置）来忽略唤醒引脚上的极短脉冲——例如毛刺滤波器或最小脉冲宽度设置？这包括电平触发模式：是否需要按住电平至少一段时间，还是任何瞬时脉冲都能触发唤醒？ 2. 如果没有这样的硬件选项，NXP 针对这种错误唤醒推荐的解决方案是什么？如有关于GPIO唤醒输入端ESD保护的应用笔记，敬请提供。 3. NXP 是否有任何参考设计，其中 Cortex-M7 检查/过滤唤醒信号，而 A53 保持挂起状态？ 平台：i.MX8MP 定制板，BSP：LF-6.12.20 顺祝商祺！ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: GPIO wakeup triggered by short noise pulses during suspend 你好@Leo_dev 希望你一切都好。 Q1. 你的理解是正确的。i.MX8MP GPIO/GPC 唤醒路径没有硬件毛刺滤波器、最小脉冲宽度设置或消抖寄存器。 Q2. 由于没有片上解决方案，建议的设计是在 PAD 中添加滤波器。 Q3. 是的，您可以查看AN13400 “i.MX 8M 低功耗设计，M 内核在系统挂起状态下运行”，这是 NXP 针对此类架构的主要参考文档。 顺祝商祺！ 萨拉斯。

SJA1110経由のPTP こんにちは、 私たちはSJA1110スイッチを介して接続されたPolarFire SoC GEMでPTPをデバッグしています。 我々は以下のことを観察した。 Layer 2上のPTP(ptp4l -2)はスイッチで受信されます(入力カウンターが増加します)が、転送はされません(出口カウンターが増加しません)。 PTP over UDP (ptp4l) は、同じブリッジパスを介して正しく転送されます。 通常のイーサネットトラフィック(ICMP/ARP)も正しく転送されます。 SJA1110で、レイヤ2 PTPフレーム（宛先MACアドレス01:1B:19:00:00:00）をブリッジポート経由で転送するために、特別な処理や追加の設定が必要ですか？レイヤ2 PTPの転送に関して、既知の制限事項はありますか？ また、PolarFire SoC GEMでは、UDP over PTP（ptp4l）は完全にサポートされ推奨されているのでしょうか、それともレイヤー2のみがサポート/推奨されているトランスポートなのでしょうか？ 何かアドバイスをいただければ幸いです。 Re: PTP over SJA1110 こんにちは、 @Ankur_pixl さん、 典型的なgPTPや時間認識ブリッジのケースでは、スイッチがすべてのgPTPフレームを通常のマルチキャストトラフィックとして透過的に転送することは期待されません。 通常の流れは、スイッチがグランドマスターからgPTPフレームを受け取り、内部Cortex-M7上で動作するgPTPスタックを通じて処理し、接続された下流デバイスに向けて適切なタイムスタンプを持つ独自のgPTPフレームを生成するというものです。   SJA1110通常、レイヤー2オートモーティブプロファイル向けに設定されており、PTP宛先MACアドレスは01:80:C2:00:00:0Eです。このアドレスは802.1AS/gPTPスタイルのレイヤー2トランスポートに使用され、そのようなフレームは通常、単にブリッジされる通常のマルチキャストトラフィックではなく、スイッチのPTP/gPTP機能によって処理されます。   イングレスカウンターが増加する一方で、エグレスカウンターが増加しないというあなたの観察は、レイヤー2のPTPフレームがスイッチに受信されているものの、通常のブリッジパスを経由して転送されていないことを示唆しています。一つの考えられる説明としては、使用されるPTPマルチキャストMACアドレスがSJA1110設定(例えばGeneral Parametersテーブル、DPI構成、L2ルックアップテーブル、その他のPTP/トラップ関連設定項目)によってマッチングされ、フレームが期待される外部エグレスポートに転送されるのではなく、ホストポート、特に内部Cortex-M7ホストにトラップされるというものがあります。   これにより、PTP over UDPや通常のイーサネットトラフィック(ICMP/ARP)が正しく転送される理由も説明できます。これらのフレームは、同じレイヤ2 PTP/gPTP分類ルールに一致しないため、通常のブリッジトラフィックとして処理されます。   SJA1110の設定において、以下の点を確認してください。   1. スイッチでどのPTP宛先MACアドレスが設定されているか、特に一般パラメータテーブルで。 2. PTP/gPTPフレームがホストポートにトラップされるように設定されているかどうか。 3. 内部Cortex-M7ホストがgPTPスタックを実行しているか、トラップされたPTPフレームを受信しているか。 4. 使用される宛先MACアドレスが01:1B:19:00:00:00か01:80:C2:00:00:0Eか。 5. L2ルックアップテーブルまたはマルチキャスト転送設定に、この宛先MACアドレスを必要な外部ポートに転送するエントリが含まれているかどうか。 6. このトラフィックに関して、入力ポートと出力ポートが同じ VLAN および転送ドメインに属しているかどうか。   SJA1110をgPTP/時間認識ブリッジとして使用する場合、通常想定される構成は、元のgPTPフレームを単純に透過的に転送するものではありません。スイッチはgPTPタイミングドメインに参加し、接続されたデバイスに対して対応するgPTPメッセージを生成します。   もしSJA1110を生のレイヤー2 PTPフレームの単純なイーサネットブリッジとしてのみ使用する意図であれば、このトラフィックに対してPTPトラップや特殊処理を無効化または回避し、対応するマルチキャスト宛先MACアドレスをL2転送設定で明示的に許可する必要があります。   PolarFire SoC GEMについては、推奨または完全にサポートされているPTPトランスポートモードについて断言することはできません。SJA1110の観点からすると、ブリッジパスが許可する場合、UDP上のPTPは通常のIP/UDPトラフィックとして転送される可能性があります。しかし、これは必ずしもPolarFire GEMドライバーがハードウェアタイムスタンプでUDPトランスポートをサポートしたり推奨されたりしているという意味ではありません。対応するPTPトランスポートおよびタイムスタンプモードについては、PolarFire SoC GEMドキュメントまたはMicrochipサポートで確認してください。   よろしくお願いいたします。 パベル Re: PTP over SJA1110 こんにちは、 宛先MACアドレスは01:1B:19:00:00:00です。私たちはLinux DSAブリッジでスイッチを使っており、Cortex-M7コアを操作したり設定したりすることはできません。 L2構成でこのトラフィックを通過させるにはどうすればよいでしょうか？ブリッジmdbを使用しましたが、うまくいきません。エントリはインストールされ、オフロード済みとして表示されますが、フレームはポート間で転送されません。これはCortex-M7コアで明示的に設定する必要がありますか? 当社のシステムに関する追加情報： 当社のMACアドレス／ポート構成は以下のとおりです。 bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent これらは bridge -d mdb show ではオフロードされていると表示されますが、一方のポートに到着した L2 PTP フレームはもう一方のポートには転送されません。 重要なのは、スイッチのポートの一つに動作するCPUポートがないことです。これは純粋に2つのポート間のルート(ポート間転送)として動作し、そのパスにはホストやCPUポートは含まれません。予約済みマルチキャスト01:1b:19:00:00:00はデフォルトでマネジメント/CPUルートに閉じ込められているようで、そのルートはここでは利用できないため、フレームは転送ではなくドロップされているのではないかと推測しています。 CPUや管理ポートに頼らずに、この予約済みPTPマルチキャストMACをハードウェア内で2つのユーザーポート間で転送するスイッチの設定方法についてアドバイスいただけますか? -- アンクル Re: PTP over SJA1110 こんにちは、 @Ankur_pixl さん、 宛先MACアドレス01:1B:19:00:00:00は、IEEE 1588レイヤ2 PTPマルチキャストアドレスです。これは、通常、SJA1110 gPTPオートモーティブプロファイル構成で使用される802.1AS / Automotive Profile gPTP宛先MACアドレス01:80:C2:00:0Eとは異なります。   あなたの説明からすると、これは標準的なLinuxブリッジMDBの問題とは思えません。MDBエントリが正しくインストールされ、オフロードされたと報告されていても、フレームが通常のマルチキャスト転送パスに到達しない場合があります。   おそらく、SJA1110ハードウェアやSJA1110 DSAドライバーが、通常のL2マルチキャスト転送決定が適用される前に、この宛先MACをPTP/制御フレームとして分類しているのが考えられます。その場合、フレームは2つのユーザーポート間で直接転送されるのではなく、CPUやマネジメントパスにリダイレクトされることがあります。   これは、観察された挙動を説明するだろう。   - 入力カウンターが増加し、フレームがスイッチに受信される、 - MDBエントリがインストールされ、オフロード済みとして表示されます。 - しかし、通常のポート間転送が適用される前にフレームがCPUやマネジメントルートに閉じ込められている可能性が高いため、エグレスカウンターは増加しません。   ポート間転送パスにCPUやマネジメントルートが存在しない場合、トラップされたフレームは事実上ドロップされる可能性があります。   Cortex-M7についてですが、Linux DSAブリッジ経由でスイッチを使用し、内部Cortex-M7上でgPTPスタックを実行・制御していない場合、通常はCortex-M7アプリケーションから設定するものではありません。このユースケースでは、関連する構成はLinux DSAドライバーと、そのドライバーによってプログラムされたスイッチハードウェア構成によって所有されます。   ただし、01:1B:19:00:00:00 に対して専用の PTP/制御フレームトラップ ルールがアクティブになっている場合は、「bridge mdb」だけでは不十分な場合があります。このトラフィックをハードウェア上で2つのユーザーポート間で直接転送するには、スイッチの設定で以下を満たす必要があります:   1. 01:1B:19:00:00:00 の PTP/制御フレームトラップはこのトラフィックに対して無効化またはバイパスされており、 2. 必要なユーザーポートに向けて有効なL2マルチキャスト転送エントリが01:1B:19:00:00:00に存在します。   現時点では、SJA1110 DSA構成でそのようなルールが有効になっている場合、標準の`bridge mdb`コマンドだけでは、下位レベルのPTP/制御フレームトラップルールを上書きすることはできないと考えられます。   次のステップとして、SJA1110 DSAドライバーまたはBSPがPTPハードウェアのタイムスタンプを有効にしているか、01:1B:19:00:00:00のMACフィルター/PTPトラップルールをインストールしているか確認してください。そのようなルールが存在する場合、解決策は単に実行時のLinuxブリッジMDBコマンドだけでなく、ドライバーレベルの変更やスイッチの静的設定変更を必要とする可能性が高いです。   以下の情報を教えていただけますか?   - Linux BSP/カーネル版 - SJA1110 DSAドライバのソースベースライン、 - 「bridge -d mdb show」の完全な出力、 - 関与するDSAポート名および物理スイッチポート番号、 - SJA1110 DSAドライバーでPTPハードウェアのタイムスタンプが有効かどうか、 - 可能であれば、DSAマスター/CPUインターフェース上でパケットキャプチャを行い、レイヤー2のPTPフレームがCPUパスにトラップされているかどうかを確認すること。   この情報をもとに、フレームがPTP/コントロールトラップパスに消費されているか、あるいは別のL2マルチキャスト転送制限があるかをさらに確認できます。 よろしくお願いいたします。 パベル

PNEV5190B 无法工作 从 NFC Cockpit 的“附加”选项卡上的“加载辅助固件”选项加载 Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 后，我的 PNEV5190B 不再响应，也无法通过 NFC Cockpit 进行操作。 根据更新日志，固件下载已成功完成，未报告任何错误。更新完成后，主板才停止响应。 我在这个帖子里找到了类似的问题，但我想要了解根本原因。 固件更新成功后，什么原因会导致主板无响应？ 我是否有可能使用了与我的主板不匹配的备用固件镜像或固件版本？ 为什么加载辅助固件会导致 NFC Cockpit 无法再与板通信？ 感谢您的支持。 Re: PNEV5190B does not work 你好@Miyazaki001 希望你一切都好。 请问您能否提供更多关于您设备配置的详细信息？你们遵循的是什么步骤？ 我尝试了以下设置： -PNEV5190B-FW v2.0b-NFC Cockpit v9.0.0 -" Extra " 选项卡 > " 辅助固件 > 加载辅助固件 ——选择 nxpnfccockpit_v9.0.0 \ 固件\ Secondary_pn5190\ k8x\ nfcrdlib_Simplified api_emvco_secondary.nc.bin " NFC Cockpit 应该提示关闭 COM 端口并重新打开： 重新打开 COM 端口后，您应该能够在“附加”选项卡中启动辅助固件。 问候， 爱德华多。 Re: PNEV5190B does not work 嗨@EduardoZamora ， 感谢您的回复。 我的配置如下： - PNEV5190B（B1芯片） - PN5190 固件版本 v02.05 - NFC Cockpit v7.4 - 额外选项卡 → 辅助固件 → 加载辅助固件 已选： -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次固件更新似乎已成功完成。根据日志显示，固件下载已完成，未报告任何错误。 下面显示的是日志的相关部分。 更新后，NFC Cockpit 提示我手动关闭并重新打开 板连接。我按照这个步骤操作了，我还尝试手动断开并重新连接 COM 端口。 但是，重新连接后，电路板不再响应任何命令。日志显示 NFC Cockpit 尝试与板通信时超时。 我已附上相关日志供您参考。 请问您能否提供以下建议： - PN5190 FW v02.05 与此辅助固件兼容吗？ - NFC Cockpit v7.4 与此辅助固件之间是否存在已知问题？ 我在这个帖子里找到了类似的问题，但我想要了解根本原因。 感谢您的支持。 顺祝商祺！ Re: PNEV5190B does not work 您好， 我找不到任何关于使用此特定配置时出现意外行为的已记录案例。 NFC Cockpit v7.4.0 已过时；请更新到最新版本 (v9.0.0) 并对 PN5190 执行固件更新。之后，请将你的发现告诉我。 如果在更新设置后此问题仍然存在，请告知您的跳线配置和电源连接（最好能提供一张电路板的照片）。 问候， 爱德华多。

MINISASTOCSI 最新回路図 こんにちは、チームのみなさん。 MINISASTOCSIの最新の設計図を共有していただけませんか? Re: MINISASTOCSI Latest Schematics こんにちは、 @ramkrish さん。 MINISASTOCSI ボードの最新版は A1 です。 ご参考までに、ファイルをあなたのメールアドレスに送信しました。 受信に問題があった場合、または今回のボード改訂に関して追加情報が必要な場合は、お知らせください。 よろしくお願いします、 チャビラ Re: MINISASTOCSI Latest Schematics こんにちは、 @Chaviraさん 受け取りました、ありがとうございます

S32K314 CAN 问题 我正在使用 S32K314，最近在通过短路振荡器进行测试时遇到了 CAN 问题； 恢复后，我监测了SPI和ADC模块，这些模块工作正常，但CAN模块无法正常工作。 调试器显示以下信息：在此状态下，CAN 总线无法接收或发送任何帧。 这是怎么回事？如何通过软件修复这个故障？   Re: S32K314 CAN issue 你好， 谢谢你的回复。 我尝试在“Mcu_ClockSourceFailure_Notification”中添加一些测试代码，但此通知没有被触发； 那么从软件方面来说，我们如何才能注意到这个问题并重置CAN模块呢？ 谢谢！ 以下是您提到的寄存器的值： MCR CTRL1 认知行为疗法： FDCBT： ECR ESR1 Re: S32K314 CAN issue 您好， 从提供的屏幕截图来看，接收错误计数器 (RXERRCNT) 正在增加，而 TXERRCNT 保持为 0，这与典型的发送相关问题并不完全吻合，即使 ESR1 指示正在进行传输尝试。 振荡器短路可能会影响时钟，例如导致恢复后 CAN 位时序不正确。然而，目前的信息不足以证实这一点。 请问您能否提供以下信息： 更全面地了解 FlexCAN 寄存器（包括 MCR/CTRL1/CBT/FDCBT、ECR 和 ESR1）， 恢复后模块和CAN协议时钟配置， 故障期间是否捕获了TX、RX和CAN总线测量数据？ 如果 FlexCAN 模块时钟和 CAN 协议时钟正在运行且频率符合预期，您还可以尝试执行 FlexCAN 模块软件重置，然后完全重新初始化模块，并检查通信是否恢复。 BR，彼得 Re: S32K314 CAN issue 您好， 如果没有进入 Mcu_ClockSourceFailure_Notification()，我的第一个假设是项目中没有配置或启用相应的 MCU 中断/通知路径。 请您核查一下： 是否对受影响的时钟源启用时钟监控（CMU）。 CMU中断是否已启用。 MCU 模块是否配置为在检测到时钟故障时调用 Mcu_ClockSourceFailure_Notification()。 在振荡器短路事件发生后，检查 CMU 和 RGM 状态寄存器也可能很有用，以验证是否确实检测到了时钟故障。 从 FlexCAN 寄存器转储可以看出，该模块似乎已启用并与总线同步 (SYNCH=1)，而 RXERRCNT 增加，TXERRCNT 保持 0，现在没有总线活动。我看到显示的位定时寄存器（CTRL1、CBT、FDCBT）不包含有效的 CAN 定时配置，尽管如果使用增强型 CAN 位定时并且实际定时是通过相应的增强型 CAN 位定时寄存器配置的，这是可以预期的。 因此，在实施 CAN 复位策略之前，最好先验证是否检测到时钟故障事件以及通知机制是否已正确配置。 BR，彼得

ddr_stress_tester一部のDDRでは動作しません 私は長年ddr_stress_testerこのツールを使ってきましたが、今年、新しい製造プロセスのDDR(20nmや25nmのDDR)ではうまく動作しないことに気づきました。CPUの周波数を選択するとバイナリがフリーズすることがありました。例えば、winbond w631gu6rbやISSI IS43TR166640C-125JBLI-TRなどです。ちなみにCPUモデルはmx6solo/dlです i.MX6DL Re: ddr_stress_tester cannot work on some DDRs この症状は、DDRダイのプロセスノード自体というよりも、DDRの初期化/MMDC設定、あるいはボードレベルのマージンに関連している可能性が高い。NXPのドキュメントで、i.MX6Solo/DL ddr_stress_testerが20nm/25nmだからハングするという問題は見つかりませんでしたし、NXPのライブラリやコミュニティパスで部品番号、プロセスノード、「CPU周波数」のハング表現で確認してもWinbond W631GU6RBやISSI IS43TR166640C特有の情報も見つかりませんでした。 まず最初に確認すべきこと： 古い固定スクリプトではなく、i.MX6/7 DDRツールフローを使用してください。 i.MX6/7 DDRツールは、実際のデバイス構成（密度、チップセレクト、バス幅、ボードレイアウト/スウィズリングなど）に基づいてカスタムDRAM初期化を生成およびテストすることを目的としており、 i.MX6DL/Sデバイスを明示的にサポートしています。 DDRベンダーまたはDDRのジオメトリ/タイミングを変更した場合は、DRAMレジスタプログラミング支援ツール/DDRツールフローを使用して.inc初期化スクリプトを再生成してください。NXPは、スクリプトは「カスタムボードとメモリに合わせて変更する必要がある場合がある」と述べています。 古い校正値が依然として適用されると想定しないでください このストレスツールは、i.MX6ボードに対して、書き込みレベリング、DQSゲーティング、読み書き遅延キャリブレーション、およびストレステストを実行します。 周波数選択直後にハングすると、キャリブレーション完了前にDDRがすでに限界になっている可能性があります。NXPコミュニティのガイドラインでは、類似のi.MX6 DDRストレスハングは、MMDCパラメータの誤り、電力のブラウンアウト、基板ノイズ、レイアウトの問題にポイントを挙げます。 DDR電圧/モードおよび周波数選択を確認してください i.MX6Solo/DualLite DDRパッドはLPDDR2およびDDR3/DDR3Lモードをサポートしています。 DDR3/DDR3L I/O電源については、i.MX6Solo/DLのデータシートの抜粋によると、DDR3は1.425–1.575 V、DDR3Lは1.283–1.45 Vとされています。 i.MX6 DDRストレスツールは135 MHzから672 MHzまでのDDRストレステストをサポートします。まず保守的なDDR周波数を選択し、キャリブレーションが完了した後に上位に進めます。 更新タイミングを確認する i.MX6のケースでは、低周波ハングがMMDC0_MDREFを補正することで解決され、tREFIが3.9μsから7.8μsに変化しました。 NXPのドキュメントでは、MMDCx_MDREFがDDRリフレッシュ動作を制御するレジスタとして示されており、一部のDDR3デバイスでは温度依存のリフレッシュ変更が必要であることも指摘されています。85℃以下の場合は64ms、85℃を超える場合は32msのリフレッシュ周期。 既知のツール環境のハングアップ原因を排除する U-Bootから動作する場合は、スプラッシュ画面やIPU、またはDRAMにアクセスできる可能性のあるDMAを無効にしてください。NXPは、アクティブなIPU/スプラッシュアクセスがDDRストレスフロー中にシステムがハングする可能性があると指摘しています。 ウォッチドッグヒューズや設定が有効かどうか確認してください。NXPは、i.MX6Soloではウォッチドッグがキャリブレーションやストレステスト中にデバイスをリセットできるDDR_Stress_Tester指摘しています。 JTAG版を使っている場合、DDRの周波数選択後にi.MX6のケースが停止したと報告され、その際のガイダンスはJTAGモード/接続を確認し、簡単なSDKのDDRテストと信号・電力プロービングを使うよう指示されていました。 私の推奨事項は、新しいDDR部品ごとにDDR初期化スクリプトを再生成し、低いMMDC/DDR周波数から開始し、MDREF/タイミング値をDDRデータシートと照合して確認してから、キャリブレーションを再実行することです。それでもCPU/DDR周波数選択の段階で処理が停止する場合は、その移行中にDDRの電源レールとクロックをオシロスコープで測定し、正常に動作していた古いDDRと新しいWinbond/ISSI製部品のMMDCレジスタ値を比較してください。 この問題は、まず i.MX6Solo/DL DDR の初期化とマージンの問題として対処する必要があります。NXP が 20 nm/25 nm DDR3 プロセス自体を ddr_stress_tester の非互換性として認識しているという証拠は見つかりませんでした。

S32K3 FS26 新 WDG 周期无法工作 你好， 在我的板上，上电复位后，我将 FS26 看门狗周期配置为 无限 在初始化期间。然后我退出调试模式并进入正常模式（读取的值来自 SBC_FS26_FS_STATES_ADDR 是 0xB ）。 之后，我将监视程序周期更改为 64毫秒 （如屏幕截图所示），执行一次看门狗刷新（馈送），返回值表示成功。 WD_RFR_CNT 增加 1，阅读 SBC_FS26_FS_WDW_DURATION_ADDR 给予 0xB0CD ，确认周期已成功更新为 64 毫秒。 但是，如果我之后停止喂养看门狗， 没有发生错误或RESET。 相反，如果我将看门狗周期配置为 64 毫秒 初始化期间 然后，在退出调试模式后，不再向看门狗提供数据。 做 按预期触发重置。 为什么在正常模式下，即使寄存器写入和刷新都成功，当周期从无限变为 64ms 时，看门狗仍然不起作用？ S32K344 RTD7.0.0 FS26 6.0.0 S32DS3.6.4 EB30.0 BR， 杰森 Re: S32K3 FS26 new WDG period not work 你好， 哦！回复时我忘记切换账号了——Jason07是我的另一个账号。 BR， 杰森 Re: S32K3 FS26 new WDG period not work 你好， 非常感谢您的回复。 我将监视周期设置为 无限 在初始化期间，根据驱动程序代码，某些操作仅在周期为 INFINITE 时执行——例如，在执行期间关闭 INIT_FS。 Sbc_fs26_InitDevice() 函数，并调用 Sbc_fs26_WdRefresh 里面 Sbc_fs26_清除故障错误计数器 清除故障错误计数器。 如果我将周期设置为有限值，则 Sbc_fs26_WaitFailsafeRelease 在 Sbc_fs26_FsxbRelease 中返回 E_NOT_OK ，并且 FS26 会一直处于待处理状态。 FS_STATES_FS0B_ASSERT 状态，无法过渡到 FS_STATES_NORMAL_FS 。 BR， 杰森 Re: S32K3 FS26 new WDG period not work 你好， 由于在 INIT_FS 关闭时监视程序已被禁用，因此监视程序不会启动。 配置 WDW_PERIOD[3:0] = 0000 选择无限打开窗口。根据 FS26 看门狗规范，看门狗窗口只能在初始化阶段禁用，并且禁用会在初始化阶段结束后生效。以这种方式禁用的看门狗随后不能通过向 FS_WDW_DURATION 写入有限值而在正常模式下启用。 寄存器读取成功确认新的 WDW_PERIOD 字段已写入，递增的 WD_RFR_CNT 确认刷新已被接受。这些观察结果表明，看门狗超时监控功能并未重新启用。 如果在初始化期间启用了有限周期的看门狗，则支持运行时周期更改。因此，在 INIT_FS 期间配置有限的看门狗周期，例如，如果需要较长的初始化间隔，则最大有限周期为 1024 毫秒。进入正常模式后，周期可以更改为 64 毫秒。新的有限期限将在下一次监控程序刷新后生效。 这种行为也解释了为什么在初始化期间配置 64 毫秒时会发生 RESET：在这种情况下，当 INIT_FS 关闭时，看门狗将被启用。 从功能安全角度来看，禁用看门狗会导致无限状态，因为比较是在硬件中进行的，匹配成功时标志位总是会上升。 顺祝商祺！ Peter Re: S32K3 FS26 new WDG period not work 你好， 根据观察到的行为，在 NORMAL_FS 中将 WDW_PERIOD 从无限打开窗口更改为 64 毫秒后，FS26 看门狗监控似乎没有启动。 寄存器写入成功，读取值 (0xB0CD) 证实了这一点，并且看门狗刷新命令继续被接受，WD_RFR_CNT 递增表明了这一点。然而，在刷新停止后没有任何看门狗超时反应，这表明看门狗的监督本身并未激活。 当看门狗周期配置为无限打开窗口时，Sbc_fs26_NormalFSSequence() 通过发出立即看门狗刷新来关闭 INIT_FS。同样，Sbc_fs26_ClearFaultErrorCounter() 使用连续的看门狗刷新来清除故障错误计数器，因为在无限模式下没有看门狗窗口时间限制。 当配置了有限的监视周期时，驱动程序会遵循不同的路径。看门狗刷新必须与有效的看门狗窗口同步，驱动程序使用看门狗定时机制（pfWdgNotification、定时器同步和 Sbc_fs26_TimeWaitClearFault()），而不是发出连续的立即刷新。

S32DS5.5のライセンス更新にご協力ください。 チームの皆さん、こんにちは。 私のS32DS5.5のライセンスは期限切れになりましたが、古いプロジェクトでまだ必要です。更新手続きを手伝ってください。 ご回答をお待ちしています。 BR、ホアキン

NVMキーカタログに保存されているECC公開鍵のSHA-512に関する質問 NXPエキスパート様、 HSEの鍵マネジメント機能について質問があります。 私たちは HSE-B を搭載した S32K312 を使用しており 、 ECC公開鍵 を NVMキーカタログ に 保存しています 。 私たちのアプリケーションでは、NVMキーカタログに保存されているECC公開鍵の SHA-512ハッシュ を取得する必要があります。 キーを保存した後、 SHA-512ハッシュ を比較することで、キーが正しく保存されていることを検証します 。 例： Kを NVMキーカタログに格納されているECC公開鍵とする 。 SHA-512(K) の値を取得したいです 。 HSEは、NVMキーカタログに保存されているキーのSHA-512ハッシュを取得するためのAPIまたはメカニズムを提供していますか？ そうでない場合、カタログに保存されているキーのSHA-512(K)を計算または検証するための推奨される方法はありますか？ 再開まで今しばらくお待ちください。 Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog わかった。サポートありがとうございます Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog こんにちは、@NghiaLX308さん ユーザーがSHA-512をキーマテリアルに直接実行できるAPIはありません。 回避策として、ECC公開鍵をエクスポート(サービスHSE_SRV_ID_EXPORT_KEYを使い)、その後SHA-512操作(サービスHSE_SRV_ID_HASHを使って)実行できます。ECC公開鍵は秘密ではないため、平文でエクスポート可能です。暗号化または認証された形式でエクスポートする必要はありません。 よろしくお願いいたします。 ルーカス

PNEV5190Bは動作しません NFC CockpitのExtraタブにある「Load Secondary Firmware」オプションからNfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.binをロードした後、PNEV5190Bが反応せず、NFC Cockpitから操作できません。 アップデートログによると、ファームウェアのダウンロードはエラー報告もなく正常に完了しました。アップデートが完了した後、ボードが応答しなくなった。 このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 ファームウェアのアップデートが成功したにもかかわらず、なぜ基板が反応しなくなるのでしょうか? 私のボードまたはファームウェアのバージョンに対して、間違ったセカンダリファームウェアイメージを使用した可能性はありますか？ なぜセカンダリファームウェアをロードすると、NFCコックピットがボードと通信できなくなる状態になるのでしょうか? 再開まで今しばらくお待ちください。 Re: PNEV5190B does not work こんにちは、 @Miyazaki001さん あなたの調子が良いといいのですが。 あなたのセットアップについてもう少し詳しく教えていただけますか?どのような手順に従っていますか？ 私は以下の設定を試してみました。 - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - 「追加」タブ > 「セカンダリファームウェア」タブ > セカンダリファームウェアのロード - NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin を選択してください NFC Cockpitは、COMポートを閉じてから再度開くように指示するはずです。 COMポートを再度開いた後、「Extra」タブでセカンダリファームウェアを起動できるようになります。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 私のシステム構成は以下のとおりです。 - PNEV5190B（B1チップ） - PN5190 FW v02.05 - NFC Cockpit v7.4 - 追加タブ → セカンダリファームウェア → セカンダリファームウェアのロード 選択済み: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次ファームウェアアップデートは正常に完了したようです。ログによると、ファームウェアのダウンロードはエラー報告なしに完了した。 ログの該当箇所を以下に示します。 アップデート後、NFC Cockpitからボード接続を手動で閉じてから再度開くように指示されます。私はこの手順に従い、さらにCOMポートを手動で切断して再接続することも試しました。 しかし、接続を再開した後、ボードはどのコマンドにも応答しなくなった。ログには、NFC Cockpitがボードとの通信を試みた際にタイムアウトが発生したことが記録されている。 参考までに、関連するログファイルを添付しました。 何かアドバイスをいただけますか: PN5190 FW v02.05は、このセカンダリファームウェアと互換性がありますか？ NFC Cockpit v7.4とこのセカンダリファームウェアに関して、既知の問題はありますか？ このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、 この特定のセットアップで予期せぬ挙動が記録された例を見つけることはできませんでした。 NFC Cockpit v7.4.0は旧バージョンです。最新バージョン（v9.0.0）にアップデートし、PN5190のファームウェアアップデートを実行してください。その後、あなたの調査結果を教えてください。 設定を更新した後もこの症状が続く場合は、ジャンパーの設定と電源接続についてお知らせください（基板の写真も添付していただけると助かります）。 よろしくお願いいたします。 エドゥアルド。

PTP over SJA1110 您好， 我们正在调试通过 SJA1110 交换机连接的 PolarFire SoC GEM 上的 PTP。 我们观察到： 交换机接收到二层 PTP (ptp4l -2) 数据包（入口计数器增加），但未转发（出口计数器不增加）。 通过 UDP 的 PTP（ptp4l）通过同一桥接路径正确转发。 正常的以太网流量（ICMP/ARP）也能正确转发。 SJA1110 是否需要特殊处理或额外配置才能通过桥接端口转发第 2 层 PTP 帧（目标 MAC 01:1B:19:00:00:00）？对二层点对点传输协议（PTP）的转发是否存在任何已知的限制？ 另外，PolarFire SoC GEM 是否完全支持并推荐使用 PTP over UDP (ptp4l)，还是只支持/推荐使用 第 2 层 传输？ 任何指导都将不胜感激。 Re: PTP over SJA1110 你好@Ankur_pixl ， 在典型的 gPTP/时间感知桥接应用场景中，交换机无需将所有 gPTP 帧透明地转发为普通组播流量。通常的流程是，交换机从主控服务器接收 gPTP 帧，通过运行在内部 Cortex-M7 上的 gPTP 协议栈进行处理，然后生成带有相应时间戳的 gPTP 帧，发送给连接的下游设备。   SJA1110 通常配置为第 2 层汽车配置文件，其中 PTP 目标 MAC 地址为 01:80:C2:00:00:0E。此地址用于 802.1AS/gPTP 风格的第 2 层传输，此类帧通常由交换机的 PTP/gPTP 功能处理，而不是简单地作为常规组播流量进行桥接。   你观察到入口计数器增加，而出口计数器没有增加，这表明交换机接收到了第 2 层 PTP 帧，但没有通过正常的桥接路径转发。一个可能的解释是，所使用的 PTP 组播 MAC 地址与 SJA1110 配置相匹配，例如在通用参数表、DPI 配置、L2 查找表或其他与 PTP/trap 相关的配置项中，因此帧被捕获到主机端口，很可能是内部 Cortex-M7 主机，而不是转发到预期的外部出口端口。   这也解释了为什么 PTP over UDP 和 ICMP/ARP 等普通以太网流量能够正确转发。这些帧不符合相同的第 2 层 PTP/gPTP 分类规则，因此按普通桥梁交通处理。   请检查您的 SJA1110 配置中的以下几点：   1. 交换机中配置了哪个 PTP 目标 MAC 地址，尤其是在常规参数表中。 2. PTP/gPTP 帧是否配置为捕获到主机端口。 3. 内部 Cortex-M7 主机是否正在运行 gPTP 协议栈或接收捕获的 PTP 帧。 4. 使用的目标 MAC 地址是 01:1B:19:00:00:00 还是 01:80:C2:00:00:0E。 5. L2 查找表或组播转发配置中是否包含将此目标 MAC 转发到所需外部端口的条目。 6. 此流量的入口端口和出口端口是否在同一个 VLAN 和转发功能域中。   如果您打算将 SJA1110 用作 gPTP/时间感知桥接器，那么预期的配置通常不是简单地透明转发原始 gPTP 帧。交换机应参与 gPTP 时序域，并向连接的设备生成相应的 gPTP 消息。   如果您打算仅将 SJA1110 用作普通的以太网桥，用于原始的二层 PTP 帧，则必须禁用或避免此流量的 PTP 捕获/特殊处理，并且必须在二层转发配置中明确允许相应的组播目标 MAC 地址。   关于 PolarFire SoC GEM，我无法就该设备推荐或完全支持的 PTP 传输模式做出明确的声明。从 SJA1110 的角度来看，如果桥接路径允许，则 PTP over UDP 可以作为普通的 IP/UDP 流量转发。然而，这并不一定意味着 PolarFire GEM 驱动程序支持或推荐使用 UDP 传输进行硬件时间戳。请参考 PolarFire SoC GEM 文档或咨询 Microchip 支持部门，确认支持的 PTP 传输和时间戳模式。   顺祝商祺！ 帕维尔 Re: PTP over SJA1110 你好， 目标 MAC 地址为 01:1B:19:00:00:00。我们正在使用带有 Linux DSA 桥接器的交换机，并且无法控制或配置 Cortex-M7 内核。 在 L2 配置中，我们如何允许此流量通过？我们使用了桥接 mdb，但它不起作用；条目已安装，甚至显示为已卸载，但帧仍然无法在端口之间转发。这是否需要在 Cortex-M7 内核上显式设置？ 关于我们设置的其他信息： 我们的MAC地址/端口配置如下： bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent 这些在 bridge -d mdb show 中显示为已卸载，但到达一个端口的 L2 PTP 帧不会从另一个端口转发出去。 重要的是，其中一个交换机端口没有可用的 CPU 端口；它纯粹作为两个端口之间的路由（端口到端口转发）运行，该路径上没有主机/CPU 端口。由于保留的多播 01:1b:19:00:00:00 默认似乎被捕获到管理/CPU 路由，而该路由在此处不可用，因此我们怀疑帧被丢弃而不是转发。 请问如何配置交换机，使其能够在两个用户端口之间通过硬件转发此保留的 PTP 组播 MAC 地址，而无需依赖 CPU/管理端口？ ——安库尔 Re: PTP over SJA1110 你好@Ankur_pixl ， 目标 MAC 地址 01:1B:19:00:00:00 是 IEEE 1588 二层 PTP 组播地址。这与 802.1AS / 汽车配置文件 gPTP 目标 MAC 地址 01:80:C2:00:00:0E 不同，后者通常用于 SJA1110 gPTP 汽车配置文件。   根据您的描述，这看起来不像是一个标准的 Linux 网桥 MDB 问题。MDB 条目可能已正确安装，甚至报告为已卸载，但帧仍然可能无法到达正常的组播转发路径。   一个可能的解释是，SJA1110 硬件或 SJA1110 DSA 驱动程序在应用正常的 L2 组播转发决策之前，将此目标 MAC 分类为 PTP/控制帧。在这种情况下，帧可能会被重定向到 CPU/管理路径，而不是直接在两个用户端口之间转发。   这可以解释观察到的现象：   - 入站计数器增加，表示交换机已接收到该帧。 MDB条目已安装并显示为已卸载， 但出口计数器不会增加，因为帧很可能在应用正常的端口到端口转发之前就被困在了 CPU/管理路由中。   如果 CPU/管理路由在端口到端口的转发路径中不可用，则捕获的帧可能会被有效地丢弃。   关于 Cortex-M7：如果您通过 Linux DSA 网桥使用交换机，并且您没有在内部 Cortex-M7 上运行或控制 gPTP 协议栈，那么这通常不应该是 Cortex-M7 应用程序配置的内容。在这种情况下，相关的配置由 Linux DSA 驱动程序和该驱动程序编程的交换机硬件配置所有。   但是，如果针对 01:1B:19:00:00:00 激活了专用的 PTP/控制帧陷阱规则，则“桥接 mdb”可能不够用。要通过硬件直接在两个用户端口之间转发此流量，交换机配置需要确保：   1. 针对此流量，01:1B:19:00:00:00 的 PTP/控制帧陷阱已被禁用或绕过，并且 2. 存在指向所需用户端口的 01:1B:19:00:00:00 的有效 L2 组播转发条目。   此时，如果 SJA1110 DSA 配置中存在激活的较低级别的 PTP/控制帧陷阱规则，我预计仅使用标准的 `bridge mdb` 命令无法覆盖该规则。   下一步，请检查您的 SJA1110 DSA 驱动程序或 BSP 是否启用 PTP 硬件时间戳，或者是否为 01:1B:19:00:00:00 安装任何 MAC 过滤器/PTP 陷阱规则。如果存在这样的规则，则解决方案可能需要驱动程序级别的更改或交换机静态配置更改，而不仅仅是运行时 Linux 网桥 MDB 命令。   请问您能否提供以下信息？   - Linux 电路板支持包。/内核版本， - SJA1110 DSA 驱动程序源基线， - “bridge -d mdb show”的完整输出， - 相关DSA端口名称和物理交换机端口号， - SJA1110 DSA 驱动程序中是否启用了 PTP 硬件时间戳功能， - 如果可能的话，在 DSA 主/CPU 接口上进行数据包捕获，以确认第 2 层 PTP 帧是否被捕获到 CPU 路径。   有了这些信息，我们可以进一步检查帧是否被 PTP/控制陷阱路径消耗，或者是否存在其他 L2 组播转发限制。 顺祝商祺！ 帕维尔

AB_SWAPアップデート失敗時のフォールバックメカニズム こんにちは、 私たちは、S32K342のHSEファームウェアのAB_SWAPメカニズムを利用してOTAアップデートを行うアプリケーションを開発しています。現在、フラッシュメモリのパッシブ領域への書き込みが完了した時点で、パッシブブロックをアクティブ化するように設定しています。 起動元イメージが破損していないか確認できるフォールバックの仕組みがあるのか、またリセット後にパッシブ領域になった「既知の有効」領域にフォールバックできるのか知りたいです。 これは、時にはリセットを出さずにパッシブ領域を上書きし、途中でプロセッサをリセットしてしまい、フラッシュの映像が破損してしまうことがあるためです。 Re: Fallback mechanism for failed AB_SWAP update やあ、 @lukaszadrapa 、 ご説明ありがとうございます。私たちはまだ、アプリケーションでどのタイプのセキュアブート戦略を使うべきかを理解しようとしています。高度なセキュアブートは、SMRとCRをインストールする必要があるため、少し複雑に思える。 一方、ベーシックセキュアブートはインストールがやや容易なようだが、具体的な実装方法やインストール手順は不明瞭なようだ。 これらの選択肢について何かアドバイスをいただけませんか?私はHSE Bリファレンス・マニュアルを指しており、これに関して参照すべき追加ドキュメントがあるかどうかも知りたいです。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update こんにちは、 @Shiv_peak さん。 数日前に非常によく似た質問に回答しましたので、そちらをご覧ください。 https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125 さらに詳しい情報が必要な場合は、遠慮なくお申し付けください。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update 下記の私のコメントをご覧ください。 イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 はい。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 はい。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 UTESTは、設定属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDサービスを呼び出す際にHSEによってプログラムされます。共通の問題は、フラッシュブロック0とUTESTが同じ読み取りパーティション内にあることに注意することです。この属性をプログラムする際、フラッシュブロック0からはコードが実行できません。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 はい。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 はい。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? はい、ADKPが設定されるまでライフサイクルを進めることはできません。ライフサイクルが進んだらセキュアデバッグが有効になるので、接続を確立するためにデバッガの設定が必要です。この投稿をご覧ください: https://community.nxp.com/t5/S32K/S32K3-HSE/m-p/2066312/highlight/true#M47070 ライフサイクルの状態はDCMモジュールのレジスタDCMLCCから読み取ることができます。 AppBLは、Basic Secure BootにおけるIVTと同じものですか？ AppBLとIVTは同じ方法で署名・検証されます。IVとGMACもIVTに付録されています。それは「表118」で見ることができます。 HSEファームウェアリファレンスマニュアルの「IVT構造」と記載されています。 IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか？ IVTを検証する場合は、前述のとおりIVとGMACをIVTに追加する必要があります。セキュアリカバリイメージを使用する場合は、イメージへのポインタとイメージの長さをIVTに追加する必要があります。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update ルカスさん、返信ありがとうございます。おかげでよく分かりました！Basic Secure Bootの実装を始め、ご質問やご不明点があればご連絡いたします。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 「2.6.1.3」の項をご覧ください。HSEファームウェアのリファレンスマニュアルに記載されている「リカバリーモード」と記載されています。2.7. つまり、2つのモードがあります。 JTAGベースのリカバリーモードでは、デバイスはRAM上で無限ループにハングする(このコードはSBAFによってRAMにロードされます)。ユーザーがデバッガに接続していくつかのリカバリーステップを実行できます。 セキュアリカバリーモード - これは属性 HSE_SECURE_RECOVERY_CONFIG_ATTR_ID によって有効にする必要があります。これはUTESTメモリにプログラムされたOTP属性であることに注意してください。これによりリカバリイメージが起動しますが、まずこれを検証する必要があります。つまり、基本的なセキュアブートに似ています。検証に失敗した場合は、JTAGリカバリモードに移行します。 セキュアリカバリモードは実行時のリカバリーやロールバックに使用できます。しかし、パッシブパーティションからこれを実行することはお勧めしません。すべてのコードはアクティブパーティションから実行される必要があります。ABスワップモードでは、いずれにせよ両方のパーティションにセキュアリカバリイメージのコピーが存在します。 別の選択肢としては、十分な空き容量があれば、このコードをデータフラッシュメモリに保存する方法もあります。 Re: Fallback mechanism for failed AB_SWAP update 私たちはこのアプリケーションノートを提供します: https://www.nxp.com/webapp/Download?colCode=AN13465   Secure Bootアプリケーションノートの最新バージョンv0.1.1.0です(AN744511)2021年にリリースされ、以下からダウンロード可能です: https://www.nxp.com/products/S32K3 申請書はこちらでご覧いただけます: ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511) 関連するデモプロジェクトはこちらからダウンロードできます: Design Resources - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310) ソフトウェアは更新されていないので、 興味があれば前述SW745310を使ってください。 セキュアブートの他の例は、HSEデモ例(推奨)で見つけることができます: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 高度なセキュアブート、基本的なセキュアブート、およびSHEセキュアブートの3つのモードすべてについて例があります。 一般的に、高度なセキュアブートモードが推奨されます。はい、このモードでセキュアブートを設定するのは簡単な作業ではありません。しかし、最高の保護性能と設定の柔軟性を提供します。利点は、好きな署名方式を選べ、複数の地域をカバーでき、セキュアブートが失敗した場合に異なる制裁を設定できることです。 一方、基本的なセキュアブートモードは常にGMACタグのみを使用し、これはADKPから派生したキーで計算され、1つの地域のみをカバーできます。失敗した場合、デバイスは直接リカバリーモードに移行します。 HSE DemoExamplesに掲載されている以下のプロジェクトを学習することをお勧めします。 S32K344_アドバンストセキュアブート S32K344_ベーシックセキュアブート これらは、それらにリンクされたアプリケーションS32K344_SecureBootBlinkyを保護するための構成プロジェクトです。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update なるほど、これでよく分かりました。ありがとうございます！ 私の理解では: イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? AppBLは、Basic Secure BootにおけるIVTと同じものですか？ IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか？ 実装と基板上でのテストを開始する前に、これらの点についてもう少し明確な情報を得たいと思っています。ご連絡いただき、疑問を解消してくださり本当にありがとうございます! よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update ルーカスさん、分かりやすく説明してくれてありがとう。 I will look into the アプリケーションノート and the HSE demo examples and revert back in case of any queries. よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 基本的なセキュアブートが失敗した場合に「デバイスがリカバリーモードに入る」とはどういう意味か、もう少し詳しく教えてもらえますか?これはつまり、コアはリセットから解放されず、フォールバックやリカバリーも存在しないということですか? セキュアブートが失敗した場合に、別のイメージ（おそらくパッシブバンクにあるイメージ）を起動する機能を持たせたいので、この質問をしています。

S32K3 快速备用唤醒失败 你好， 在一个快速备用示例项目中，我定义了一个数组 编曲 在 .standby_data 虽然代码中包含这个数组，但它在代码中并没有被使用。然而，如果我注释掉这个数组定义，设备就无法从快速待机状态唤醒；如果我保留它，唤醒功能就能正常工作。此外，我还注意到优化级别也会影响设备的行为： -O0 优化失败，唤醒失败，但正在更改为 -Os 这样就能解决问题。为什么在……中定义变量会起作用？ .standby_data 该部分是否会影响唤醒功能？为什么优化级别会产生如此大的影响？ S32K312 RTD400 S32DS BR， 杰森 Re: S32K3 fast standby wake up fail 嗨@Senlent 非常感谢您的回复。将地址更改为 0x20408000 后，之前失败的案例现在可以正常工作了。 顺便说一下，关于我的另一个帖子（S32K3 ADC Optimize DMA Streaming），我用公司邮箱注册的新账号（Jason07）回复了你——回复的时候我忘记切换账号了。 Re: S32K3 fast standby wake up fail 嗨@ Jason22 程序中是否注释掉“arr”数组会影响__BSS_SRAM_START的值，该值将用作快速唤醒后MSP的初始值。 如果这个值太小，可能会导致堆栈溢出。 在我们的示例项目中，我们建议将此值设置为 0x20408000，这是备用 RAM 的结束地址。

S32K144のPWM周波数が周期的に変化する問題について。 現在、NXP S32K144 の開発を行っており、問題が発生しました。EB 構成ツールを使用して、FTM0 の 4 つの出力チャネルを構成し、コード内で `PWM_Init();setdutycycle(8129)` を呼び出しました。構成では、中央揃えモード、デッドタイムなし、他のチャネルとのバインディングなしを選択しました。周期は 0.00125 に設定され、各チャネルは独立モードとなり、結果として 250µs%的方波，这显然不对，我希望是25% のデューティサイクルが 20% になりました。そこで、デューティサイクルを `setdutycycle(16339)` に変更しましたが、結果として波形が正しくなくなりました。チャネルは、デューティサイクル 66% の 150µs の矩形波と、デューティサイクル 50% の 100µs の矩形波を交互に出力します。なぜこのようなことが起こるのでしょうか。これが実際の波形です。 実際、私には2つの問題があることは明らかです。1. なぜPWMデューティサイクルが正しく動作しないのか？ 2. なぜPWMサイクルが常に変化するのか？ Re: 关于S32k144的pwm频率会周期变化的问题 こんにちは S32K1用リアルタイムドライバのどのバージョンをテストしているのか、またはS32K1デバイス用AUTOSAR MCALのどの以前のバージョンをテストしているのか教えてください。 MPC5xxxおよびS32K1xxデバイスに対するMCALのサポートは終了いたしましたのでご注意ください。今後のサポートにはマーケティングチームの承認が必要となりますので、NXPの営業担当者までお問い合わせください。 よろしくお願いします、 ロビン Re: 关于S32k144的pwm频率会周期变化的问题 お使いのソフトウェアのバージョンがわからないのですが、読み込みポイントの設定に注意してください。以下の2つのディスカッションを参照してください。 FTM_PWMの周期とデューティサイクルを変更する S32K116のPWM出力の問題

Feedback on UI editor bugs in GUI Guider v2.0.0 I encountered several bugs while using GUI Guider v [your version number] that affected development efficiency, and I would like to report them to the development team: Drag and drop layouts, resulting in layout loss: When I drag controls in the UI editor to adjust the layout, the operation occasionally fails, and the latest layout changes are lost, causing the interface to revert to its previous state. Duplicate and unremovable control names: During operation, sometimes multiple controls with identical names may appear, and these controls cannot be deleted via the right-click menu or the Delete key. The only solution is to log back into the software; only then will these "ghost" controls disappear.

无法下载 S32K3 标准软件 无法下载 Re: Not able to Download S32K3 Standard Software 你好， 我刚刚下载好了，没有任何问题。尝试使用不同的浏览器，清除cookies等等…… 下载本身在NXP端运行正常。 顺祝商祺！ Peter

LPC5514JBD64E 用于 WS2812。 您好， LPC5514JBD64E 适合初学者使用 WS2812 吗？如果适合，我可以在哪里找到代码和其他详细信息？ 谢谢！ LPC55xx Re: LPC5514JBD64E Use for WS2812. 嗨@Kishore02 感谢您的帖子！ 目前尚无关于 LPC551x 上 WS2812 实现的信息，您可以使用可编程逻辑单元 (PLC) 来实现。在其他设备中，有使用 FlexIO 模块的示例，例如 MCXA366 的应用代码中心： https://mcuxpresso.nxp.com/appcodehub ?search=an-emulating-ws2812-bus-with-flexio-on-mcx366 此外，一位同事还发布了一篇关于如何在 Kinetis 开发板上实现该协议的文章： NXP FlexIO Generator for the WS2812B LED Stripe Protocol 希望这些信息对您有所帮助。

S32DSライセンスのアクティベーションID こんにちは。S32DSを開いたところ、以下の情報が表示されました。 Arm用のS32 Design Studio アクティベーションID: 1A99-90A8-2F06-339B 評価期間：14日間 機能バージョン: 2.2 機能ステータス：評価中（14日間） 免許証の有効期間を延長するには、どのような手続きが必要ですか？ビジネスの成功をお祈りしています！

S32K3標準ソフトウェアをダウンロードできません ダウンロードできません Re: Not able to Download S32K3 Standard Software こんにちは、 問題なくダウンロードできました。別のブラウザを試したり、Cookieを削除したりするなどしてみてください。 ダウンロード自体はNXP側で正常に動作しています。 よろしくお願いいたします。 ピーター