调用 SDK 闪存 API，但 S32K144 的 D_Flash 中缺少一些数据 大家好： 我在我的项目（S32K144）中调用 SDK flash init API，然后调用 Flash erase 和 Flash write。然后我发现 Flash 中的一些数据变成了 0xFF。然后我尝试在 Flash 初始化和 Flash 擦除/写入之间添加延迟，然后数据就正常了。然后我尝试检查 while (!(FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK)); 而不是使用延迟函数。但它还是失败了。所以，我想知道是否需要延迟一段时间，等待闪存模块在硬件层完成初始化。 BR 洛基 Re: Call SDK flash API and some data in D_Flash missing of S32K144 嗨@Loky ， 你使用的是哪个驱动程序版本？ 不建议使用旧版 SDK 驱动程序；应改用 RTD 驱动程序。 Flash_Init 函数不会修改闪存内容。 擦除和写入功能已经在内部轮询 CCIF 标志，因此无需在应用程序代码中轮询它。 您观察到的现象可能与缓存或闪存预取缓冲区有关。请尝试禁用它们（PCCCR、OCMDR0），并检查问题是否仍然存在。 此致， 丹尼尔 Re: Call SDK flash API and some data in D_Flash missing of S32K144 嗨，丹尼尔： 这是我们目前使用的SDK Flash驱动程序版本。我的同事告诉我，S32K144 只有 SDK Flash 驱动程序，没有 RTD 驱动程序。能否简要解释一下SDK驱动程序出了什么问题？如果您有S32K144 RTD驱动程序，能否分享给我？ 我尝试了您提到的方法（禁用缓存），但没有成功。 当上电复位或低压检测RESET时，我会将一些信息记录到闪存中，并且同一扇区中还有一些其他数据。我将读取所有行业数据，更新信息并重写该行业相关内容。但我有一些新的发现。我发现读取闪存之前数据就已经是 0xFF 了。如果在执行擦除或写入指令时闪存意外断电，再次上电后，该扇区中的数据是否会变为 0xFF？我会继续调查这个问题，也许是我的软件出现了漏洞。 BR 洛基 Re: Call SDK flash API and some data in D_Flash missing of S32K144 嗨@Loky ， 该SDK是过时的软件。NXP 现在提供 RTD 驱动程序，其中也包括 Flash 驱动程序，包括 MCAL 层和与传统 SDK 等效的底层 IP 层。 您可以点击此处下载RTD软件包： https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K1-RTD44-D 请确保您使用的是 RTD 发行说明中指定的兼容版本的 S32 Design Studio。 你是否也禁用了预取缓冲区？ OCMDR0 – 程序闪存预取缓冲区 OCMDR1 – 数据闪存预取缓冲区 如果在擦除或编程操作进行期间闪存意外断电，NXP 无法保证数据完整性。受影响的闪存内容将变为未定义状态，并且可能包含 ECC 错误。 考虑使用模拟 EEPROM 功能。 它是为此目的而优化的。 请参阅 AN11983 – 使用 S32K1xx EEPROM 功能 https://www.nxp.com/docs/en/application-note/AN11983.pdf 第五章 S32K1xx 电压骤降检测 第六章 S32K1xx 新快速写入模式 此致， 丹尼尔 Re: Call SDK flash API and some data in D_Flash missing of S32K144 嗨，丹尼尔： 谢谢你寄来的RTD包裹，我明天会查看。 我还没试过禁用预取缓冲区。你是说在擦除并写入闪存之前，我应该同时禁用缓存和预取吗？我也会试试。 是的，我今天确实遇到了一个无法纠正的 ECC 错误，它触发了硬故障。除了在设备通电后再次擦除该扇区之外，还有其他方法可以解决这个 ECC 问题吗？我认为这种方法不适用于我目前的软件设计。 谢谢你的建议。我将与同事们讨论模拟EEPROM。 BR 洛基 Re: Call SDK flash API and some data in D_Flash missing of S32K144 嗨，丹尼尔： 我很高兴地告诉大家，我们已经找到了根本原因，因为在断电期间 VCC-5v 不稳定，MCU 在低电压下反复 RESET，导致软件在初始化期间擦除闪存，但无法写入闪存。 BR 洛基

LLCE + PFE CAN2ETHを使用した時の時間デターミニスティック(TAS)トラフィックのベストプラクティス NXPチームの皆様、こんにちは。 私たちは、HPCにコネクテッドされたゾーンコントローラとしてS32G399Aを用いる ゾーンアーキテクチャ に取り組んでいます 現在のアーキテクチャ： 現在、GMACは完全なTime-Aware Shaper(TAS / 802.1Qbv)サポートと完全なTSN機能を備えています。 DDSはこのGMACパス上で動作し、サービス指向トラフィックに関して良好な時間決定性を確保しています。 新たな探査： AN13423で説明された公式のNXP LLCE + PFEサンプルアプリケーション(CAN2ETH / ETH2CAN)を成功裏に立ち上げてテストしました。 目的は、選択された高周波・低遅延CAN信号をLLCE→PFE(IEEE1722 AVTP over UDP)を通じてECUから直接オフロードし、ゾーンコントローラのCPU負荷とレイテンシを削減することです。 コミュニティの議論から、PFEは802.1AS-Rev(時間同期)のみをサポートしており、GMACとは異なりTime-Aware Shaper(802.1Qbv / TAS)やフレームプリエンプションをサポートしていないことが分かっています。 質問／ガイダンス依頼： LLCEはPFEと密接に統合されているため（PFE_HIF3を使用）、このシナリオにおけるNXPの推奨するベストプラクティスは何ですか？ NXPが提供するPFEのソースコードを使ったりカスタマイズしたりすることで、PFEでTASサポートを有効にすることは可能でしょうか?(NXPがPFEのソースコードを提供しているのを見ましたが、これでTAS機能の追加や有効化に役立つでしょうか?) PFEでTASを有効化できない場合、LLCE + PFEトラフィックの強固な時間決定性を実現するためのNXPの推奨ベストプラクティスCAN2ETH何でしょうか? 重要な時間敏感なCAN信号は引き続きGMAC + TAS経路を使い、非クリティカルまたは大量の信号のみがLLCE + PFEを使うべきでしょうか? 推奨される方法は、PFEポートの下流にある外部TSNスイッチ(例えばSJA1110)に依存して、トンネルされたトラフィックの完全なTASスケジューリングを提供することでしょうか? 将来的にPFEでTASサポートを追加する計画やファームウェアアップデートはありますか? GMACとPFEの適切な分岐を決めつつ、セーフティに関わる決定性やハードリアルタイム信号の決定性を損なわないことを望んでいます。 公式なガイダンスやリファレンス・デザイン、構成のおすすめがあれば大変助かります。 お手数ですが、よろしくお願いいたします。 よろしくお願いいたします。 アルサル・イマーム SDVアーキテクト @ GK Automobiltechnologie (Disrupt) ゴールドVIP Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH こんにちは、アルサリマム ご連絡と詳細な情報提供をありがとうございました。 ご質問を拝受いたしました。確認のお手伝いをさせていただきます。 BR ジョーイ Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH こんにちは、arsalimam AUTOSAR_MCAL_ETH_43_PFE_UM.pdf を参照してください。PFE MCALドライバはTime Awareシェイパーをサポートしており、シェーパーは電子データ内で設定可能です。 この情報があなたの助けになれば幸いです。 BR ジョーイ Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH こんにちは、Joey_zさん。 迅速なご対応と、AUTOSAR_MCAL_ETH_43_PFE_UM.pdf をご紹介いただき、ありがとうございました。ご説明ありがとうございます。PFE MCALドライバのドキュメントを確認し、時間認識シェイパー(TAS / 802.1Qbv)の設定をEB(Elektrobit)ツールで検討します。 簡単な追加質問ですが、PFE MCALドライバーはフレームプリエンプション(IEEE 802.1Qbu / 802.3br)もサポートしていますか?もしそうなら、ユーザーマニュアルの該当セクションやTASと併用するための設定ガイダンスを共有していただければ幸いです。 GMACとLLCE+PFEのトラフィック分割を最終決定する前に、PFEパスで利用可能なTSN機能セットを完全に理解しようとしています。改めてサポートありがとうございます。 よろしくお願いいたします。 Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH こんにちは、アルサリマム 簡単な追加質問ですが、PFE MCALドライバーはフレームプリエンプション(IEEE 802.1Qbu / 802.3br)もサポートしていますか? >>>PFEはサポートしていません。 BR ジョーイ

S32k388 ブートROM リファレンスマニュアルにはBoot ROMについて言及がありますが、それ以上の情報はありません。 RMは、32KBのブートROMが5つ利用可能であるとだけ述べています。 ブートROMが重要になるのはどの時点か。sbafが実行される前にHSEによってここから実行されるファームウェアはありますか？ Re: S32k388 Boot ROM こんにちは、 @Ars_ さん。 起動はsBAFで管理されており、これは実際には内部フラッシュコードです。これらのブートROMセクションはHSE（環境・安全・衛生）用途向けです。 社内の議論から、説明の変更リクエストがあったことがわかりました。この修正がいつ適用されるか確認するためにスレッドを更新します。 よろしくお願いします、 ジュリアン

FRDM-i.MX95 EVK の Ubuntu インストール ガイド (Ubuntu 22.04/24.04) こんにちは、 現在 FRDM-i.MX95 EVK を使っていて、このプラットフォームで Ubuntu(22.04または24.04) を動かしたいと考えています。 i.MX8MPにUbuntuをインストールするための以下のガイドを見つけました： https://community.nxp.com/t5/i-MX-Processors/How-to-install-ubuntu-on-imx8mp/td-p/1744295 私の質問は以下のとおりです。 このi.MX8MPガイドで説明されている手順をFRDM-i.MX95 EVKで使ってもいいですか? i.MX95向けに公式にサポートされているUbuntuイメージやBSPはありますか？ もし直接互換性がない場合、i.MX95でUbuntuを動かす際に推奨される方法は何でしょうか? (例:Yocto + Ubuntu rootfs、またはプリビルドイメージなど) ブートローダー、カーネル、デバイスツリー、GPU/NPUのサポートなど、既知の制限や違いはありますか? i.MX95上でUbuntuを動作させるためのガイダンスや参考資料があれば、ぜひ教えていただきたいです。 事前に感謝いたします。 よろしくお願いします、 ジャック Re: Ubuntu installation guide for FRDM-i.MX95 EVK (Ubuntu 22.04/24.04) こんにちは、 @JK-IMXさん。 Ubuntu OSのサポートは終了しました。現在、私たちはDebian OSをサポートしています。Debianシステムに関する情報については、下記のリンクを参照してください。 https://www.nxp.com/design/design-center/software/embedded-software/linux-software-and-development-tools/nxp-debian-linux-sdk-distribution-for-i-mx-and-layerscape:NXPDEBIAN BR

SDKのフラッシュAPIと、欠けているデータD_Flash呼び出S32K144 チームの皆さん、こんにちは。 プロジェクト(S32K144)でSDKのflash init APIを呼び出し、その後Flash消去とFlash書き込みを呼び出します。その後、フラッシュメモリ内の一部のデータが0xFFになっていることに気づきました。そこで、フラッシュ初期化とフラッシュ消去/書き込みの間に遅延時間を追加してみたところ、データが正常になりました。そして、遅延関数を使用する代わりに、while (!(FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK)); をチェックしてみます。しかし、それでも失敗に終わった。SO、ハードウェア層でフラッシュモジュールの初期化が完了するまで待つ時間を少し遅らせなければならないのかもしれません。 BR ロキー Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、 @Loky さん。 どのドライバーバージョンを使っていますか? レガシーSDKドライバの使用は推奨されません。RTDドライバを使うべきです。 Flash_Init関数はフラッシュメモリの内容を変更しません。 消去・書き込み機能はすでに内部でCCIFフラグをポーリングしているので、アプリケーションコード内でポーリングする必要はありません。 観察された動作は、キャッシュまたはフラッシュのプリフェッチバッファに関連している可能性があります。PCCCRとOCMDR0を無効にして、問題が解決するかどうか確認してください。 よろしくお願いいたします。 ダニエル Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、ダニエルさん。 これが現在使っているSDKのFlashドライバーバージョンです。同僚によると、S32K144はSDK Flash Driverしかなく、RTDドライバーはないそうです。SDKドライバーの何が問題なのか簡単に説明してもらえますか?もしS32K144 RTDドライバをお持ちなら、共有していただけますでしょうか。 ご指摘の方法（キャッシュを無効にする）を試してみましたが、うまくいきませんでした。 電源投入リセットまたはLVDリセット時に、フラッシュメモリにいくつかの情報を記録し、同じセクターに他のデータも記録します。私はすべてのセクターデータを読み込み、情報を更新してセクター向けに書き直します。しかし、いくつか新たな発見がありました。フラッシュメモリを読み取る前に、データが既に0xFFになっていることが分かりました。消去命令または書き込み命令の実行中にフラッシュメモリの電源が誤ってオフになった場合、電源を再びオンにしたときにセクター内のデータが0xFFになるのでしょうか？この問題を引き続き調査します。もしかしたらソフトウェアのバグかもしれません。 BR ロキー Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、ダニエルさん。 RTDパッケージありがとうございます。明日確認してみます。 プリフェッチバッファを無効にしたことは一度もありません。フラッシュメモリの消去と書き込みの前に、キャッシュとプリフェッチの両方を無効にすべきということでしょうか？ それも試してみます。 はい、訂正不能なECCに遭遇し、本日ハードフォルトが発生しました。デバイスの電源を入れた後にこのセクターを再度消去する以外に、このECCの問題を解決する方法はありますか？この方法は現在のソフトウェア設計には当てはまらないと思います。 ご提案ありがとうございます。エミュレートされたEEPROMについて、同僚と話し合います。 BR ロキー Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、 @Loky さん。 SDKはレガシーソフトウェアです。NXPは現在、RTDドライバを提供しており、これにはフラッシュドライバも含まれており、MCAL層とレガシーSDKに相当する低レベルIP層の両方が含まれています。 RTDパッケージはこちらからダウンロードできます: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K1-RTD44-D RTDリリースノートに記載された互換性のあるS32 Design Studioバージョンを使用していることを確認してください。 プリフェッチバッファも無効にしましたか？ OCMDR0 – プログラムフラッシュプリフェッチバッファ OCMDR1 – データフラッシュプリフェッチバッファ 消去やプログラム操作中にフラッシュが予期せず電源が切れた場合、NXPはデータの整合性を保証できません。影響を受けるフラッシュメモリの内容は未定義となり、ECCエラーが含まれる可能性があります。 エミュレートEEPROM機能の使用を検討してください。 この目的に最適化されています。 AN11983 – S32K1xx EEPROM機能の使用を参照してください。 https://www.nxp.com/docs/en/application-note/AN11983.pdf 第5章 S32K1xx ブラウンアウト検出 第6章 S32K1xx 新しいクイックライティングモード よろしくお願いいたします。 ダニエル Re: Call SDK flash API and some data in D_Flash missing of S32K144 こんにちは、ダニエルさん： 原因が特定できて嬉しいです。VCC-5Vは電源オフ時に不安定で、MCUが低電圧で繰り返しリセットされるため、ソフトウェアは初期化時にフラッシュを消去するものの、フラッシュの書き込みはできません。 BR ロキー

S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error Dear     1、原来的工程基于S32DS3.5 + RTD5.0.0开发，Build Ok & Run OK     2、基于开发需要必须基本RTD6.0.0开发，开发环境：S32DS3.6.2 + RTD6.0.0 + TCPIP_STACK_3.0.0 + FreeRTOS_11.1.0_6.0.0    3、RTD5.0.0与RTD6.0.0变化较大，不能使用原RTD5.0.0的工程，只好参考论坛提供的例程(示例 S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600)    4、根据自己硬件平台修改相应PIN如下:           5、Debug 例程，发现部分初始化过不去，如下：    6、如果把相应代码Mask掉，虽然程序可以Run，但是PHY Address都找不到 附件是Debug的例程，不清楚是不是论坛提供的参考例程存在修改之处，是不是我仅仅修改PIN定义，是不是始终之类配置错误？ Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error Hi,Petrs    您好，你说的非常正确，我的确使用的硬件平台是自己的    在RTD5.0.0 Debug时候我也基于官网提供例程是可以ping OK    当面使用RTD6.0.0我也是基于同样的思路，主要就是修改PIN，发现Code Run不下去    附件是基于自己硬件 RTD5.0.0(S32DS3.5+RTD5.0.0+TCPIP_STACK_2.0.0)完成可以ping OK的例程，不清楚是不是时钟配置不正确，能否给协帮助？ Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error 您好， 看来你只是更改了 MDIO/MDC 引脚，而没有参考社区示例。 这是否意味着您使用的是自己定制设计的板？ 我在 S32K388EVB-Q289 上测试了您的项目，MCU 初始化成功完成。 由于 MDIO/MDC 信号连接到 EVB 上的不同引脚，因此未检测到 PHY 地址。将 MDIO/MDC 引脚改为 PTD16/PTD17 后，正确获取了 PHY 地址。 BR，彼得

S32k388 Boot ROM There is mention of Boot ROM in the reference manual, but no further information is available. RM just says five instances of 32kb boot rom is available  At what point boot rom becomes relevant. Is there a firmware that run from here by the HSE even before sbaf is ran  Re: S32k388 Boot ROM Hi @Ars_, Booting in managed by sBAF which is actually code in internal FLASH. These Boot ROM sections are for HSE use. From an internal discussion, I can see that there was a request to modify the description, I will bump the thread to see when this fix will be applied. Best regards, Julián 

S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 デバッグエラー 親愛なる 1. 元のプロジェクトは S32DS3.5 + RTD5.0.0 ビルドに基づいて開発されました。OK & 実行OK 2. 開発には基本RTD 6.0.0が必要です。開発環境：S32DS 3.6.2 + RTD 6.0.0 + TCPIP_STACK_3.0.0 + FreeRTOS_11.1.0_6.0.0 3. RTD5.0.0とRTD6.0.0には大きな違いがあるため、元のRTD5.0.0に基づいたプロジェクトは使用できません。代わりに、フォーラムで提供されているサンプルコードを参照してください（例：S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600 ）。 4. ハードウェアプラットフォームに応じて、対応するPINを以下のように変更してください。          5. サンプルコードのデバッグを行った結果、以下のような初期化手順の一部が失敗していることが判明しました。    6. 対応するコードがマスクされている場合、プログラムは実行できますが、PHYアドレスを見つけることはできません。 添付ファイルにはデバッグ用の例が含まれています。フォーラムで提供されている参照例が変更されているのか、私がPIN定義だけを変更したのか、あるいは他の設定エラーがあるのかが分かりません。 Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error こんにちは、 あなたが参照したコミュニティの例と比較すると、MDIO/MDCピンのみを変更したようですね。 これはつまり、ご自身で設計されたカスタムボードを使用しているということですか？ S32K388EVB-Q289であなたのプロジェクトをテストし、MCUの初期化は無事完了しました。 PHYアドレスは検出されませんでした。なぜならMDIO/MDC信号がEVB上の異なるピンに接続されているからです。MDIO/MDCピンをPTD16/PTD17に変更したところ、PHYアドレスが正しく取得できた。 BR、ペトル Re: S32K388 GMAC0 lwIP FreeRTOS S32DS36 RTD600 Debug Error こんにちは、ペトルス こんにちは。おっしゃる通りです。確かに私は独自のハードウェアプラットフォームを使用しています。RTD 5.0.0のデバッグ中に、公式サイトに掲載されているサンプルコードを使用してpingを正常に実行できました。 RTD 6.0.0を実際に使用した際も、主にPINを変更してコードを見つけるという同じ手順を踏みました。 プログラムの実行に失敗しました。添付ファイルは、私のハードウェアRTD 5.0.0（S32DS3.5 + RTD 5.0.0 + TCPIP_STACK_2.0.0）に基づいており、pingを実行できます。サンプルコードは問題ないのですが、クロックの設定が間違っているのではないかと考えています。何かアドバイスをいただけないでしょうか？

Ubuntu installation guide for FRDM-i.MX95 EVK (Ubuntu 22.04/24.04) Hello, I am currently working with the FRDM-i.MX95 EVK and would like to run Ubuntu (22.04 or 24.04) on this platform. I found the following guide for installing Ubuntu on the i.MX8MP: https://community.nxp.com/t5/i-MX-Processors/How-to-install-ubuntu-on-imx8mp/td-p/1744295 My questions are: Can I follow the same procedure described in this i.MX8MP guide for the FRDM-i.MX95 EVK? Are there any officially supported Ubuntu images or BSPs available for i.MX95? If not directly compatible, what would be the recommended approach to run Ubuntu on i.MX95? (e.g., Yocto + Ubuntu rootfs, or any prebuilt images) Are there any known limitations or differences (e.g., bootloader, kernel, device tree, GPU/NPU support) that I should be aware of? I would really appreciate any guidance or references for running Ubuntu on i.MX95. Thank you in advance. Best regards, Jack Re: Ubuntu installation guide for FRDM-i.MX95 EVK (Ubuntu 22.04/24.04) Hi @JK-IMX  We no longer support Ubuntu OS.  We now support Debian OS. Please refer to the link below for information about the Debian system. https://www.nxp.com/design/design-center/software/embedded-software/linux-software-and-development-tools/nxp-debian-linux-sdk-distribution-for-i-mx-and-layerscape:NXPDEBIAN B.R

FRDM-i.MX95 EVK 的 Ubuntu 安装指南 (Ubuntu 22.04/24.04) 你好， 我目前正在使用FRDM-i.MX95 EVK ，并且想在这个平台上运行Ubuntu（22.04 或 24.04） 。 我找到了以下关于在 i.MX8MP 上安装 Ubuntu 的指南： https://community.nxp.com/t5/i-MX-Processors/How-to-install-ubuntu-on-imx8mp/td-p/1744295 我的问题是： 我可以按照 i.MX8MP 指南中描述的步骤来操作 FRDM-i.MX95 EVK 吗？ 是否有官方支持的适用于 i.MX95 的 Ubuntu 镜像或 BSP？ 如果不能直接兼容，那么在 i.MX95 上运行 Ubuntu 的推荐方法是什么？ （例如，Yocto + Ubuntu rootfs，或任何预构建的映像） 是否存在我应该注意的已知限制或差异（例如，引导加载程序、内核、设备树、GPU/NPU 支持）？ 我非常感谢您能提供任何关于在 i.MX95 上运行 Ubuntu 的指导或参考资料。 提前谢谢您。 此致， 杰克 Re: Ubuntu installation guide for FRDM-i.MX95 EVK (Ubuntu 22.04/24.04) 你好@JK-IMX 我们已停止对Ubuntu操作系统的支持。我们现在支持 Debian 操作系统。有关 Debian 系统的信息，请参阅以下链接。 https://www.nxp.com/design/design-center/software/embedded-software/linux-software-and-development-tools/nxp-debian-linux-sdk-distribution-for-i-mx-and-layerscape:NXPDEBIAN BR

T Embedにはどのようなポートがありますか？ 標準モデルのTエンベッドを持っていますが、どのポートか全く分かりません(もう一つのポートで、USB-Cではありません)。公式サイトではGroveポートと書いてあり、LilygoのWikiサイトではQwiicポートと書かれています。どなたか助けていただけませんか? ブートROM|ブート|フラッシュ Re: What kind of port does the T Embed have? こんにちは、 @papaku さん、 T-EmbedはNXP製品ではないため、当社のサポート範囲外かもしれません。ご理解いただきありがとうございます。 BR セレステ

Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hello NXP Team, We are working on a zonal architecture using S32G399A as Zone Controllers connected to HPC Current Architecture: We are currently using the GMAC with full Time-Aware Shaper (TAS / 802.1Qbv) support along with complete TSN features. DDS runs over this GMAC path, and we have good time determinism for our service-oriented traffic. New Exploration: We have successfully brought up and tested the official NXP LLCE + PFE sample application (CAN2ETH / ETH2CAN) as described in AN13423. The goal is to offload selected high-frequency / low-latency CAN signals from ECUs directly via LLCE → PFE (IEEE1722 AVTP over UDP) to reduce CPU load and latency on the Zone Controller. From community discussions, we understand that PFE only supports 802.1AS-Rev (time synchronization) and does not support Time-Aware Shaper (802.1Qbv / TAS) or Frame Preemption, unlike GMAC. Question / Request for Guidance: Since LLCE is tightly integrated with PFE (using PFE_HIF3), what is NXP’s recommended best practice in this scenario? Can we enable TAS support on PFE by using / customizing the PFE source code provided by NXP? (I saw that NXP provides PFE source code – would this help us add or enable TAS functionality?) If TAS cannot be enabled on PFE, what is NXP’s recommended best practice to achieve strong time determinism for the LLCE + PFE CAN2ETH traffic? Should critical time-sensitive CAN signals continue to use the GMAC + TAS path, while only non-critical or high-volume signals use LLCE + PFE? Is the recommended approach to rely on an external TSN switch (such as SJA1110) downstream of the PFE port to provide full TAS scheduling for the tunneled traffic? Are there any plans or firmware updates that will add TAS support on PFE in the future? We want to decide the right split between GMAC and PFE paths without compromising determinism for safety-relevant or hard real-time signals. Any official guidance, reference designs, or configuration recommendations would be very helpful. Thank you in advance! Best regards, Arsal Imam SDV Architect @ GK Automobiltechnologie (Disrupt) GoldVIP Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi,arsalimam Thank you for your contacting and detail information. I have received your questions and will help you to check it. BR Joey Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi,arsalimam Refer to the AUTOSAR_MCAL_ETH_43_PFE_UM.pdf, PFE MCAL driver supports the Time Aware shaper, the shaper can be configured in the EB. Hope this information can help you. BR Joey Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hello Joey_z, Thank you for your prompt response and for pointing me to the AUTOSAR_MCAL_ETH_43_PFE_UM.pdf. I appreciate the clarification, we will review the PFE MCAL driver documentation and explore Time-Aware Shaper (TAS / 802.1Qbv) configuration through the EB (Elektrobit) tool. As a quick follow-up question: Does the PFE MCAL driver also support Frame Preemption (IEEE 802.1Qbu / 802.3br)? If yes, could you please share the relevant section in the User Manual or any configuration guidance for enabling it alongside TAS? We are trying to fully understand the TSN feature set available on the PFE path before finalizing the traffic split between GMAC and LLCE+PFE. Thank you again for your support. Best regards Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH Hi，arsalimam As a quick follow-up question: Does the PFE MCAL driver also support Frame Preemption (IEEE 802.1Qbu / 802.3br)? >>>PFE does not support it. BR Joey

Call SDK flash API and some data in D_Flash missing of S32K144 Hi team:  I call SDK flash init API in my project (S32K144), and then call Flash erase and Flash write. Then I find some data in Flash became to 0xFF. Then I try to add a Delay between Flash init and flash Erase/Write, and then the data is normal. And then I try to check while (!(FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK)); instead of using delay function. But it still failed. So, I wonder if it has to delay some time to wait for the flash module to complete initialization on hardware layer. BR Loky Re: Call SDK flash API and some data in D_Flash missing of S32K144 Hi @Loky, Which driver version are you using? It is not recommended to use the legacy SDK drivers; RTD drivers should be used instead. The Flash_Init function does not modify flash contents. The erase and write functions already poll the CCIF flag internally, so there is no need to poll it in your application code. The behavior you observe may be related to cache or the flash prefetch buffer. Please try disabling them (PCCCR, OCMDR0) and check if the issue persists. Regards, Daniel Re: Call SDK flash API and some data in D_Flash missing of S32K144 Hi Daniel: This is the SDK Flash Driver Version now we are using. My colleague told me that S32K144 only has SDK Flash Driver and no RTD Driver. Could you briefly explain what's wrong with the SDK driver? And could you please share it to me if you have S32K144 RTD driver. I tried to use the methed you mentioned(Disable cache), but it didn't work. I will record some information in flash when power on reset or LVD reset,  and some other data is in the same sector.  I will read all sector data out and update information and rewrite to the sector. But I've had some new discoveries. I found that the data was already 0xFF before reading the flash. If the flash is accidentally powered off while executing erase or write instructions, it will cause the data in the sector to be 0xFF after power on again? I will continue to investigate this issue, maybe it is a bug in my software. BR Loky Re: Call SDK flash API and some data in D_Flash missing of S32K144 Hi @Loky, The SDK is legacy software. NXP now provides RTD drivers, which also include Flash drivers, both the MCAL layer and the low-level IP layer equivalent to the legacy SDK. You can download the RTD package here: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K1-RTD44-D Please ensure that you use a compatible version of S32 Design Studio, as specified in the RTD Release Notes. Did you also disable the prefetch buffers? OCMDR0 – Program Flash prefetch buffer OCMDR1 – Data Flash prefetch buffer If the Flash is unexpectedly powered down while an erase or program operation is in progress, NXP cannot guarantee data integrity. The affected Flash contents become undefined and may contain ECC errors. Consider using the Emulated EEPROM functionality. It is optimized for this purpose. Please refer to AN11983 – Using the S32K1xx EEPROM Functionality https://www.nxp.com/docs/en/application-note/AN11983.pdf Chapter 5 S32K1xx brownout detection Chapter 6 S32K1xx new quick write mode Regards, Daniel Re: Call SDK flash API and some data in D_Flash missing of S32K144 Hi Daniel: Thanks for your RTD package, I'll check it tomorrow. I haven't tried to disable prefetch buffers yet. Do you mean I should disable both cache and prefetch before erase and write flash? I'll try it also. Yes, I did come across an uncorrectable ECC and it triggered Hardfault today. Except erasing this sector again after powering on the device, is there any way to fix this ECC issue? I think this way is not applicable to my current software design. Thank you for your suggestion. I will discuss the Emulated EEPROM with my colleagues. BR Loky Re: Call SDK flash API and some data in D_Flash missing of S32K144 Hi Daniel： I'm glad to tell you we have found the root cause, because the VCC-5v is unstable during power down and MCU reset at low voltage repeatedly, resulting in the software erasing flash during initialization but not writing flash. BR Loky

T Embed 使用的是哪种接口？ 我有一台标准的 T 型嵌入式开发板，但我不知道它用的是哪种接口（不是 USB-C 接口），因为官方网站说它是 Grove 接口，而 Lilygo Wiki 网站说它是 Qwiic 接口。请问有人可以帮帮我吗？ 启动 ROM | 启动配置 | 闪存 Re: What kind of port does the T Embed have? 你好@papaku ， T-Embed 不是 NXP 的产品，因此这可能超出我们的支持范围。感谢您的理解。 BR 塞莱斯特

S32k388 启动 ROM 参考手册中提到了启动 ROM，但没有提供更多信息。 RM 只是说有五个 32kb 的启动 ROM 实例可用。 启动ROM何时变得重要？是否有固件可以在 sbaf 运行之前，由 HSE 从此处运行？ Re: S32k388 Boot ROM 嗨@Ars_ ， 启动由 sBAF 管理，而 sBAF 实际上是内部 FLASH 中的代码。这些启动 ROM 部分供 HSE 使用。 从内部讨论来看，有人要求修改描述，我会跟进这个帖子，看看什么时候能进行修改。 此致， 朱利安

使用 LLCE + PFE CAN2ETH 时，时间确定性 (TAS) 流量的最佳实践 您好，NXP团队， 我们正在开发一种基于S32G399A的区域架构，该架构使用S32G399A作为区域控制器，并连接到高性能计算（HPC）。 当前架构： 我们目前使用的是具有完整时间感知整形器 (TAS / 802.1Qbv) 支持以及完整 TSN 功能的 GMAC。 DDS 通过此 GMAC 路径运行，我们的面向服务的流量具有良好的时间确定性。 新的探索： 我们已经成功启动并测试了 AN13423 中描述的 NXP LLCE + PFE 官方示例应用程序 (CAN2ETH / ETH2CAN)。 目标是通过 LLCE → PFE（基于 UDP 的 IEEE1722 AVTP）直接从 ECU 卸载选定的高频/低延迟 CAN 信号，以降低区域控制器的 CPU 负载和延迟。 从社区讨论中我们了解到，PFE 仅支持 802.1AS-Rev（时间同步），不支持时间感知整形器 (802.1Qbv / TAS) 或帧抢占，这与 GMAC 不同。 问题/咨询请求： 由于 LLCE 与 PFE 紧密集成（使用 PFE_HIF3），在这种情况下，NXP 推荐的最佳实践是什么？ 我们能否通过使用/定制NXP提供的PFE源代码，在PFE上启用TAS支持？（我看到NXP提供了PFE源代码——这是否能帮助我们添加或启用TAS功能？） 如果 PFE 上无法启用 TAS，NXP 推荐的最佳实践是什么，才能实现 LLCE + PFE CAN2ETH 流量的强时间确定性？ 对于关键的、时间敏感的 CAN 信号，是否应该继续使用 GMAC + TAS 路径，而对于非关键的或大容量的信号，是否应该使用 LLCE + PFE？ 推荐的做法是依靠 PFE 端口下游的外部 TSN 交换机（例如 SJA1110）来为隧道流量提供完整的 TAS 调度吗？ 未来是否有任何计划或固件更新会在 PFE 上添加 TAS 支持？ 我们希望在不损害功能安全相关或硬实时信号的确定性的前提下，确定 GMAC 和 PFE 路径之间的正确划分。 任何官方指南、参考设计或配置建议都将非常有帮助。 提前谢谢！ 顺祝商祺！ 阿尔萨尔·伊玛目 SDV架构师 @ GK Automobiltechnologie (Disrupt) 金VIP Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH 你好， arsalimam 感谢您与我们联系并提供详细信息。 我已经收到您的问题，我会帮您核实。 BR 乔伊 Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH 你好，arsalimam 请参阅 AUTOSAR_MCAL_ETH_43_PFE_UM.pdf 文件。PFE MCAL 驱动程序支持时间感知整形器，整形器可以在 EB 中进行配置。 希望这些信息对您有所帮助。 BR 乔伊 Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH 你好 Joey_z， 感谢您的及时回复，并向我指出了 AUTOSAR_MCAL_ETH_43_PFE_UM.pdf 文件。感谢您的澄清，我们将查看 PFE MCAL 驱动程序文档，并通过 EB（Elektrobit）工具探索时间感知整形器 (TAS / 802.1Qbv) 配置。 还有一个后续问题：PFE MCAL 驱动程序是否也支持帧抢占（IEEE 802.1Qbu / 802.3br）？如果可以，能否请您分享用户手册中的相关章节或任何关于如何将其与 TAS 结合使用的配置指南？ 在最终确定 GMAC 和 LLCE+PFE 之间的流量分配之前，我们正在努力充分了解 PFE 路径上可用的 TSN 功能集。再次感谢您的支持。 顺祝商祺！ Re: Best practice for time-deterministic (TAS) traffic when using LLCE + PFE CAN2ETH 你好， arsalimam 还有一个后续问题：PFE MCAL 驱动程序是否也支持帧抢占（IEEE 802.1Qbu / 802.3br）？ PFE不支持此功能。 BR 乔伊

Automotive Brake Status Monitoring Using S32K3 Microcontrollers Overview This article demonstrates how to implement a brake status monitoring system using NXP S32K3 microcontrollers. The solution is based on Application Code Hub examples for S32K344 and S32K312 platforms and showcases how real-time sensor data can be used to detect braking events and trigger visual feedback. This is based on the following Application Code Hub demonstrations: Brake-Control-Monitoring-FRDM-A-S32K312 Brake-Control-Monitoring-FRDM-A-S32K344 The application simulates braking conditions using a sensor input and provides immediate system response via an LED indicator. Such systems are commonly used in automotive environments to improve system awareness and support safety-related functionality. Learning Scope This article covers both practical implementation and core embedded concepts, including: Reading analog signals using ADC Processing real-time signals Controlling outputs using GPIO Implementing decision logic based on thresholds Understanding signal flow in embedded systems System Architecture The application is built around a simple but representative embedded system: Input: Analog sensor (force / brake simulation) Processing: S32K3 microcontroller Output: LED indicator Functional Flow The sensor generates an analog signal proportional to applied force The ADC converts the analog signal into a digital value The software evaluates the value against defined thresholds The system updates the output (LED) based on braking state Brake Monitoring Application ArchitectureBrake Monitoring Application Architecture Key Concepts Analog Signal Acquisition (ADC) Sensors typically output analog values that must be digitized for processing. The ADC periodically samples this signal and produces a digital representation used by the application logic. Typical interpretation: Low value → no braking activity High value → braking detected Real-Time Signal Processing The system continuously reads sensor data and reacts immediately. This is essential in automotive contexts where delayed responses may impact system behavior. Output Control Using GPIO The LED output reflects the system state: OFF → no braking detected ON → braking condition detected In extended implementations, multiple states or patterns can be used. Hardware and Software Setup Required Hardware FRDM-A-S32K3xx development board FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 Force Click (or similar analog sensor module) Force ClickForce Click 4x4 RGB Click (LED output) 4X4 RGB Click4X4 RGB Click USB cable / power supply The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate brake inputs and outputs Software Environment S32 Design Studio S32K3 Automotive Software Package Application Code Hub project import Implementation Guide Step 1: Import the Project Open S32 Design Studio Use “Import project from Application Code Hub” Locate the brake monitoring example Import and configure the project Expected result: Project is successfully loaded into the workspace Step 2: Build the Application Compile the project Resolve any dependency issues if needed Expected result: No compilation errors Step 3: Connect Hardware Connect the development board via USB Attach sensor and LED modules Ensure correct pin connections Expected result: Board is powered and detected by the IDE Step 4: Flash and Run Program the MCU Start execution Expected result: Application runs continuously Step 5: Functional Validation Apply pressure to the sensor Observe LED behavior Expected result: LED activates when braking condition is detected Signal Behavior and Threshold Logic The application relies on threshold-based decision logic: If ADC value < threshold → no brake If ADC value ≥ threshold → brake active Placeholder: Signal vs Threshold Diagram Figure: Brake monitoring threshold behavior. The ADC raw value is converted into millivolts using a 0–5000 mV reference range. The converted value is compared against predefined thresholds to progressively activate the green, yellow, orange, and red LED columns.Figure: Brake monitoring threshold behavior. The ADC raw value is converted into millivolts using a 0–5000 mV reference range. The converted value is compared against predefined thresholds to progressively activate the green, yellow, orange, and red LED columns. Troubleshooting Board Not Detected Verify USB cable and drivers Check debugger connection Restart IDE No Output Response Validate GPIO configuration Check LED connections Confirm code execution Incorrect Sensor Readings Verify ADC configuration Inspect sensor wiring Confirm scaling and thresholds Extending the Application The basic implementation can be extended in several ways: Multi-Level Brake Detection Define multiple thresholds: Low → normal Medium → moderate braking High → emergency braking Noise Filtering Apply software filtering to stabilize readings Avoid false triggering from sensor noise Timing-Based Logic Add debounce or delay mechanisms Require sustained input before triggering State Machine Implementation A more advanced approach is to implement a state machine: Idle Braking Emergency Placeholder: State Machine Diagram [IMAGE_PLACEHOLDER: Brake State Machine] States: Idle → Brake → Emergency Transitions based on ADC thresholds Safety Context Although simplified, this application reflects concepts used in automotive safety systems: Continuous monitoring of input signals Immediate response to changes Clear indication of system state In real systems, additional mechanisms are required: Redundancy Fault detection Compliance with safety standards (e.g., ISO 26262) Conclusion This example demonstrates how a simple embedded application can model a real-world automotive use case. By combining ADC input, real-time processing, and GPIO output, it highlights the core principles behind monitoring functions in automotive ECUs. The provided implementation serves as a foundation for more advanced designs, including multi-state logic, filtering techniques, and safety-focused extensions. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

需要 S32K342 FOTA 引导加载程序架构指南（基于 UART 的更新） 您好，NXP团队， 我们正在为 S32K342 开发定制的固件空中升级 (FOTA) 解决方案，希望获得有关推荐的闪存架构和启动流程的指导。 MCU详情 设备：S32K342 PFlash：2 MB 银行 0：1 MB 银行 1：1 MB DFlash：128 KB 当前状态 我们使用UART作为固件更新接口。 目前为止，我们已成功做到： 通过 UART 接收固件（.bin 文件）。 将完整的二进制文件存储到闪存中 确认接收到的图像已正确存储。 我们剩下的挑战是实现引导加载程序架构和应用程序切换机制。 我们希望就以下问题获得澄清： 1. 推荐的FOTA Flash布局 对于 S32K342 双镜像 FOTA 实现，推荐的内存布局是什么？ 具体来说，我们想知道以下方面的推荐地点： 引导加载程序 应用插槽 A 应用插槽 B 元数据/启动标志 版本信息 CRC 回滚信息 提供一份包含地址的内存映射示例将非常有帮助。 2. 推荐的启动流程 请问有人能解释一下NXP推荐的完整启动顺序吗？ 例如： 重置 引导加载程序启动 检查启动标志 选择活动应用程序 验证图像（CRC/签名） 跳转到应用程序 我们希望能得到流程图或对整个流程的解释。 3. 从引导加载程序跳转到应用程序 对于 S32K342，标准的 Cortex-M7 跳转序列是否足够？ 例如： 从应用程序基地址读取 MSP 从基数 + 4 读取 Reset_Handler 设置 MSP 更新 VTOR 跳转到 Reset_Handler 在转移控制权之前，是否有任何 S32K342 特有的要求或初始化步骤？ 4. 双应用图像 如果应用 A 和应用 B 位于不同的闪存地址： 每个应用程序都应该有自己的链接脚本吗？ 或者，NXP 是否有推荐的构建双槽应用的方法？ 5. 闪存库的使用 由于 S32K342 有两个 1 MB 的 PFlash 存储区： 推荐的方法是否是： 从 Bank 0 执行引导加载程序 将新固件编程到 Bank 1 中。 验证成功后切换执行 两个 PFlash 存储体之间是否存在读写限制或擦除/编程限制？ 6. 元数据存储 理想的存储地点在哪里？ 活动图像标志 图像有效性 Firmware version CRC 回滚状态 这些物品应该存放在： 保留 PFlash DFlash 另一个专用的区域？ 7. 基于UART的FOTA 由于我们的更新接口是 UART，我们想知道推荐的工作流程。 以下流程是否正确？ 个人电脑 │ UART │ 引导加载程序接收 .bin 文件 │ 将固件存储到非活动闪存插槽中 │ 验证CRC │ 更新启动元数据 │ RESET MCU │ 引导加载程序选择新映像 │ 跳转至应用程序 或者恩智浦是否推荐其他方法？ 8. AB_SWAP 与自定义引导加载程序 对于 S32K342 的生产 FOTA 而言，HSE AB_SWAP 是否是强制性的？ 或者，具有双应用程序插槽的完全自定义引导加载程序也是一种受支持且常用的架构吗？ 如果您有任何专门介绍 S32K342 FOTA、UART 固件更新或双映像引导加载程序的应用笔记、参考项目、引导加载程序示例或文档，我们将非常感谢您提供这些参考资料。 感谢您的支持。 S32K3 S32DS-ARM Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) 你好@bavinkumar_02 1.对于 S32K342，AB_SWAP 只有一种可能的设置。参见“3.5.3.2HSE固件参考手册中提供了“AB_SWAP”模式下闪存布局的图示，该手册可从“文档”->“安全文件”下载： https://www.nxp.com/products/S32K3 就您的情况而言，最方便、最常见的布局是： 必须安装 AB_SWAP 版本的 HSE 固件（交换是 HSE 的一项功能，没有 HSE 固件就无法执行此操作）。固件已安装到两个分区，并且如图所示，它占用了两个分区中最后的 176KB。 因为整个数据块都被交换了，所以两个数据块中必须有完全相同的引导加载程序副本。其余部分分配给申请。 代码始终从活动块运行，因此引导加载程序和所有应用程序都是针对活动块中的地址编译的。 当引导加载程序更新应用程序时，它会将应用程序编程为被动阻塞，因此在闪存编程期间不会出现边读边写的问题。应用程序编程完成后，即可触发 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE 服务。下次RESET后，分区将被交换，引导加载程序将像往常一样跳转到应用程序（跳转到当前活动块中的新应用程序）。 2. 流程取决于应用程序。在现代汽车应用中，简单的基于 CRC 的验证已不再被认为足够。软件的完整性和真实性通常通过安全启动机制来保证。在 S32K3 设备上，这是由硬件网络安全引擎 (HSE) 处理的，它会执行加密验证（例如）。基于签名）在启动过程中自主进行。预计量产汽车系统将利用这些硬件支持的网络安全功能，而不是仅仅依赖 CRC 验证。 我们提供安全启动应用笔记，其中包括演示项目。可从以下网址下载： https://www.nxp.com/products/S32K3 应用笔记请点击此处查看： 文档 -> 安全文件 -> 安全启动应用笔记 v0.1.1.0（AN744511） 相关演示项目可在此处下载： 设计资源 -> 软件 -> 安全文件 -> SecureBootAppNoteDemo (SW745310) 您可以在 HSE 演示示例中找到其他安全启动示例： https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 三种模式——高级安全启动、基本安全启动和 SHE 安全启动——都有相应的示例。建议启用高级安全启动。 请参阅所有项目中包含的 Readme.md 文件。 3. 是的，这是标准的跳转序列。强烈建议在跳转之前取消初始化引导加载程序初始化的所有资源。 4. 如上所述，代码始终从活动分区执行，因此应用程序始终使用相同的链接器文件。 5. 前面已经讨论过了。 6.这取决于用户。您可以将数据存储在应用程序映像后面，或者存储在数据闪存中。 7. 对于生产汽车用例而言，从数据传输的角度来看，所提出的流程总体上是正确的，但正如前面提到的，我不建议依赖 CRC 作为主要的验证机制。 在汽车应用中，接收到的图像通常会受到加密保护——例如，图像可能会被加密，并且其真实性/完整性会通过数字签名（而不仅仅是 CRC）来验证。 此外，在使用 HSE AB_SWAP 机制时，引导加载程序在 RESET 后不会简单地通过软件元数据选择新映像。新映像被编程到被动分区并成功验证后，应用程序/引导加载程序应调用 HSE 服务 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK。这将激活被动块，因此RESET后设备将从新激活的分区启动。 8. HSE AB_SWAP 并非严格强制要求，但对于 S32K342 上的量产汽车 FOTA 解决方案，强烈建议使用。 如果没有 HSE 就实施 FOTA，那就意味着您没有利用 S32K3 平台的一个关键优势。这些设备的主要优点是内置支持 HSE 处理的 A/B 交换（分区重映射）。如果没有它，引导加载程序就必须手动管理一切。 具体而言，不包括 HSE AB_SWAP： 你需要自己实现一种机制来选择 A/B 图像。 您需要仔细管理地址空间，并将每个应用程序链接到不同的固定位置。 图像之间的切换不会由硬件自动处理，而完全由您的软件处理。 除了 HSE AB 交换功能之外，没有其他硬件支持的重映射机制可用。 此外，您还将失去与 AB_SWAP 集成的安全启动的简洁性和稳健性。借助 HSE，图像激活、验证和分区之间的切换以更加可控和高效的方式进行处理，符合汽车网络安全要求。 总之，虽然不考虑 HSE 也能做到这一点，但这会大大增加复杂性，并消除该平台的关键优势。 您可以查看“S32K3XX HSE 和 OTA 高级培训 [TR744101]”，该培训文档可从以下链接下载：文档 -> 安全文件： https://www.nxp.com/products/S32K3 问候， 卢卡斯

ウィンボンドW664GG6RB-06用IMX-8M-MINI DDRコントローラのタイミング こんにちは、 DDR4タイミングセットが正常に動作しない理由について説明を求めています。簡単に言えば、 DDRツールによって生成されたタイミングは校正および応力試験に合格しましたが、 断続的なLinuxカーネルは起動時にクラッシュし、「未定義命令」エラーが発生します。 設定(生の事実): - SoCはi.MX8M Mini Solo(シングルCortex-A53)、DDR4(Winbond W664GG6RB-06)です。 1200 MHz(DDR4-2400)は1:2 DFI(DDR PHYインターフェース)周波数比モードで、 単一のx16 4 Gbデバイス(512MB、ECCなし)。 - BSPはNXP L4.14.98_2.0.0(Linux 4.14.98、U-Boot 2018.03);DDRの設定は Mscale DDR Tool v3.31(Windows版)とPHYトレーニングファームウェアで生成 v201709。同じファームウェアがYoctoでU-Bootイメージの構築に使われています。 - 3つの交換可能な4Gb x16 DDR4メモリに対して、共通のタイミングセットを1つ認定しています。 部品（Alliance AS4C256M16D4、ISSI IS43QR16256B、Winbond W664GG6RB-06）はすべて動作しています 1200MHzで。 - 最も遅い部分 (Winbond) の tRCD/tRP/tAA (2400 bin で約 14.16 ns) を満たすために、 CL=17 (17-17-17) を設定すると、ツールはそれを MR0 = 0x0864 とエンコードし、対応する CL由来レジスタ（例：DFITMG0 = 0x038C8207、DRAMTMG2 = 0x0609050D)。 - DRAMは2400設定値で静的動作(デバイス内でDVFS/バス周波数が無効化) そのため、Linuxによる実行時の周波数スケーリングはありません。 観察結果： - 17-17-17構成は、DDRツールのストレステスト（約24時間）とU-Bootのmtest（約1時間）に合格します。 エラーなし。 - Linux上(シェルプロンプトに到達した起動時)ではstressapptest +にも合格します fio(CRC32C認証済み)は、Tj = 84°Cの温度で1時間以上連続かつ一定温度で、 データエラーはゼロです。 - それにもかかわらず、Linuxは起動時に「内部エラー: 未定義命令」(破損したカーネルの.text)、カーネル開始から約1.1秒後、 コールドブートの5～7％（自動コールド電源サイクルループで測定）。 - 故障はダイに依存しない:CL=17の画像も1秒間で同じ方法でクラッシュします これらの部分(ISSI)を使い、CL=16イメージは同じISSI上でLinuxを安定して起動します パート。 - 両方のeven-CL構成がLinuxを安定して起動します:16-16-16(当社の長年にわたる本番環境) タイミング)および新たに構築された18-18-18(カーネルクラッシュは見られません)—ただし、奇数CLのみです。 17-17-17は失敗。 - CL由来のレジスタのみが失敗設定と動作設定(MR0)で異なります CASビット、DFITMG0 dfi_t_rddata_en、DRAMTMG2リードレイテンシ/rd2wr、DFITMG2 rdcslat、 ODTCFG rd_odt_delay)。 仮説: 1:2のDFI比率での奇数CASレイテンシが根本原因、すなわち読み取りデータ(リードデータ)にあると推測しています 返還レイテンシはDFIクロックでCL/2であり、CL=17の場合は整数8.5、整数8.0は非整数です / 9.0 で CL=16 / 18。読み取りFIFO(DQSが書き、コントローラが読み取り)以降 クロック(リファレンス・マニュアル§9.3.2.2.2)は定常状態と定常応力を扱います 通過し、エッジ性は読み取りバースト間遷移で表面が現れると推測します。ここで 奇数CLの半DFIクロックオフセットは、RMが直面しない初拍・最後のビートのエッジCASEに当てはまります 記録を残す。 質問: CASレイテンシは奇数です(例:CL=17) は、1:2 DFI の i.MX8M Mini DDR4 PHY でサポートされています。 モード、または奇数CLに関する既知の制約/エラーはありますか？特にDDRは ツールは独自のストレステストを通過するが限界的な奇数CL構成を生成する 実際のブートトラフィックの下で、読書を制限する推奨方法はありますか? 奇数のCLのバースト・トゥ・バーストタイミングは? 添付ファイル：カーネルクラッシュコンソールダンプ、CL=17 .dsDDRツールのスクリプト、および ddr4_timing.c が生成されました。 どんなアドバイスでもありがたいです。 Re: IMX-8M-MINI DDR Controller timings for Winbond W664GG6RB-06 申し訳ありませんが、何らかの理由で添付ファイルが添付されませんでした。それらは以下の通りです。

MCXA153：LPSPI 数据突发传输。 你好， 参考手册 MCXA153 包含了对 TDBRn 和 RDBRn LPSPI 寄存器的描述： “TDBRn 和 RDBRn 寄存器支持向发送 FIFO 发送数据进行突发传输，以便与 DMA 控制器一起使用”。 请问有人可以分享一下使用这些寄存器进行突发传输的示例代码吗？ 此致 博格丹 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCXA Re: MCXA153: LPSPI data burst transfer. 嗨@bogdan_u 抱歉，目前没有相关示例。 我找到的最接近的 MCXA153 示例使用 LPSPI_MasterTransferEDMALite() 和 eDMA，但驱动程序通过 LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() 来定位 TDR/RDR，而不是突发别名窗口。 但我认为你可以尝试使用。 typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR 哈里