将 LS1046/26 CPU 的 u-boot 从 Zeus 2019.04 +fslc 迁移到 Wrynose 2026.01 你好 我们使用的是来自“git://source.codeaurora.org/external/qoriq/”的u-boot代码版本。适用于我们基于 LS1046/26 CPU 的显卡。此 u-boot 版本为 2019.04 +fslc。我们也支持安全启动。 我们现在正在考虑将我们的 u-boot 升级到 Wrynose 2026.01。 我们现有的 U-Boot 源代码最初是从现已弃用的存储库中获取的： git://source.codeaurora.org/external/qoriq/。 请问最新代码应该使用哪个合适的 Git 仓库？ 此外，如果您能分享一些关键注意事项或最佳实践，以确保升级过程顺利进行，那就太好了。 Re: u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU 你好， 对于 LS1046/LS1026A 系列 Layerscape U-启动，已弃用的 CodeAurora QorIQ 树的替代方案是： git clone https://github.com/nxp-qoriq/u-boot.git NXP 的指导意见是替换旧的 URL，例如： 源.codeaurora.org / external / qoriq / qoriq - 元器件 / u - 启动.git 其中： github . com / nxp - qoriq / u - boot . git 或者更一般地说，替换 source.codeaurora.org/external/qoriq/qoriq-components 在版本脚本、清单和 Yocto 配方中使用 github.com/nxp-qoriq 。 对于基于 Wrynose 的 电路板支持包。 ，我会从QorIQ Yocto SDK 清单开始，而不是单独克隆 U-Boot： repo init -u https : // github . com / nxp - qoriq / yocto - sdk - b wrynose repo sync --force - sync 公开的 nxp-qoriq/yocto-sdk 仓库显示有一个活跃的 wrynose 分支。同一个仓库记录了一般的仓库初始化流程，并列出了 Yocto 分支/版本映射机制。 具体来说，对于 U-Boot，公共的 nxp-qoriq/u-boot 仓库是 QorIQ U-Boot 树；其在检索到的仓库页面中显示的默认分支是 lf_v2024.04 ，活动分支列表还显示了 lf_v2026.04 。显示的标签包括最近的 lf-* 版本标签，例如 lf-6.12.49-2.2.0 、 lf-6.18.2-1.0.0 和 lf-6.18.20-2.0.0 。因此，实际的规则是：使用 Wrynose Yocto 清单/配方选择的 U-Boot 版本，而不是手动选择任意的“最新”U-Boot 分支。 过渡期的关键考虑因素： 迁移所有 CodeAurora 引用 在版本树中搜索旧 URL： grep - rn 'source.codeaurora.org/external/qoriq' 。 替换 source.codeaurora.org/external/qoriq/qoriq-components 在清单、版本配置和配方中使用 github.com/nxp-qoriq 。 使用版本清单作为真实信息的来源 对于电路板支持包升级，请保持 U-Boot、ATF、RCW、CST、内核、设备树和配方与同一 NXP 版本流保持一致。 NXP 目前的 Layerscape 流程通常使用ATF + U-Boot ，而不是单独的 U-Boot。 再次将你的定制电路板从 LS1046ARDB 参考电路板移植过来 对于 LS1046 定制板，NXP 指向 LS1046ARDB U-Boot 参考文件： configs/ls1046ardb_tfa_defconfig 、 arch/arm/dts/fsl-ls1046a-rdb.dts 和 board/freescale/ls1046ardb/ 。 对于旧式自定义，还要查看 include/configs/ls1046ardb.h 和板文件夹。 请将您现有的板更改与新的设备模型/Kconfig/DTS 结构进行协调，而不是直接复制旧的 2019.04 代码。 安全启动：重建并重新验证整个链 在 Yocto 中，安全启动映像的构建方式如下： DISTRO_FEATURES ：追加= "安全" 然后运行： bitbake 安全启动- qoriq 在修改生产熔丝设置之前，应该在开发/未熔丝单元上重新验证 CST、SRKH、OTPMK、RCW SB_EN 、ATF 和签名 U-Boot 启动映像处理。 预计 2019 年 4 月起启动流程会有所不同 自 LSDK 18.12 起，NXP 为 Layerscape RDB 引入了 TF-A 启动流程： 与旧的 PPA 式流程相比， Boot ROM → BL2 → BL31 → U-Boot/UEFI → Linux 。 如果您的当前产品仍然沿用旧的 PPA/直接 U-Boot 路径的假设，请仔细检查这些假设。 保持可控的迁移基线 首先，建立一个与您的硬件接近的、未经修改的 NXP 参考配置。 然后分小组应用您的电路板增量：RCW/SerDes、DDR、控制台、启动介质、QSPI/eMMC/SD、以太网/FMan、环境布局、安全启动。 在声明与旧的 2019.04 + fslc 树的一致性之前，请验证非安全启动路径和安全启动路径。 此致

32 位并行接收上升沿引脚 (FRDM-MCXN947) 我目前正在尝试配置一个 32 位并行移位器，以从外部设备接收数据，其中一个引脚（FLEX_D4/DATA_VALID）用作移位数据的信号。 我取得的进展使我能够在 DATA_VALID 触发时读取 32 位数据，并将数据移动到 eDMA Ping-Pong 缓冲区。我目前正在通过 Printf 语句测试将缓冲区数据读取到控制台，如果移位器出现任何错误（通常根据数据手册指示为溢出），它们也会打印到控制台。 我认为我的主要问题出在 TimerConfig 上，因为它在 DATA_VALID 的一个上升沿触发 Shifter 读取过多次，但我还没有找到一种配置，允许我只读取一次，同时实际移动正确的数据。 控制台输出： 读取缓冲区 A：0x3fffefff 换挡器错误代码：0x8 换挡器状态：0x0 SHIFTSDEN：0x8 DMA CSR：0x0 DMA 错误：0x0 TCD BITER：0x2 CSR：0x12 CH_MUX: 0x40 读取缓冲区 B：0x3fffefff 换挡器错误代码：0x8 换挡器状态：0x0 SHIFTSDEN：0x8 DMA CSR：0x0 DMA 错误：0x0 TCD BITER：0x2 CSR：0x12 我的FLEX_IO设置已附上。谢谢。 时钟|计时器 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） 开发板 MCX N Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 更新：我推断出“ kFLEXIO_TimerDisableOnTriggerFallingEdge ”导致我的 CPU 一直处于回调状态。 我想在计时器比较后禁用它，但使用此选项后，SHIFTBUF 只报告值为 0x0，而没有 SHIFTERR 标志。 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 嗨@carlos_o，谢谢你的回复！ 我如愿以偿地在 DATA_VALID 边沿获取了定时器读数，但没有更新线程。我的代码已附上。 我现在面临的问题是如何让 FlexIO 跟上其他设备的运行速度。在我目前的设置中，我基本上是在对 DATA_VALID 进行采样，并且在更高的速度下，Shifter 可能会过载。我的想法是，我的设计需要 MCX 和发送 32 位数据的主机设备之间共享时钟。我可以使用 32 位数据总线中的一个引脚作为该信号，因此我不需要拆分 FlexIO 引脚。欢迎大家就这个想法提出任何意见！ 回答你之前的问题： 1.寄存器正在按预期以较低速度填充数据。在每个 DATA_VALID 下降沿，SHIFTBUF 存储来自 32 个引脚的数据，EDMA 通过 Scatter-Gather 方法传输到我的 Ping-Pong 缓冲区。 2. 我正在通过 Analog Discovery 2 模拟输入，因为它只有 16 个数据引脚，所以我只写入 32 位的上限值，在 DATA_VALID 引脚上模拟时钟，并将未使用的引脚连接起来。低速测试数据匹配正确。 3. 我正在使用 FRDM-MCXN947 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 嗨@Flexin_On_The_IO 感谢您的帖子！ 请问您能否分享一下您在收银机中观察到的当前情况？ 您想接收哪些测试数据？您目前接收到的数据是什么？ 请问您使用的是哪个版本的MCXN？ 这是定制电路板吗？否则，请说明您使用的板型号。

S32k344マルチリンクfxの使い方 私はFRDM-A-S32K344モデルを使っていて、Multilink FXでLEDの点滅機能をダウンロードしようとしていますが、うまくいきません。理由を知りたいです。エラーが頻繁に発生し、Gemini経由で修正しようとしても解決しません。助けてください。 また、Multilink FXモデルのオレンジライト(TGPWR)が点灯していることも確認しました。 GeminiはJP11 OPENSDAの電圧を外すように指示していますが、その方法がわかりません。 Re: how to use S32k344 multilink fx 解決しました。JP11を削除したらうまくいった。

S32DS 3.5 How can I obtain the toolchain classification report for S32DS3.5, including... What about the TI/TD/TCL reports on analysis and use of constraints and known limitations? Re: S32DS 3.5 Hi, lhy These types of documents have security attributes and require an NDA. Please submit a case through the internal support system. https://support.nxp.com BR Joey

MCUXpressoでのMCUをLPC54S018J4MからLPC54S018J2Mに変更する方法 みなさんこんにちは、 私は上記のMCUの評価ボードを使ってMCUXpressoでプロジェクトを開発しました。 評価ボードにはLPC54S018J4Mが搭載されており、私のカスタムボードにはLPC54S018J2Mが搭載されています。フラッシュメモリの容量（2MB/4MB）が異なる点を除けば、基本的に同じものです。 両方のプロセッサのSDKsの起動ファイルを比較しましたが、どちらもまったく同じで、つまり4MBフラッシュ用のSPIディスクリプタが内蔵されています /* SPI ディスクリプタ - Winbond W25Q32JV */ メモリ詳細の最初の行にあるメモリサイズを0x400000から0x200000に変更するだけで安全でしょうか？ よろしくお願いいたします。 ライナー Re: Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso こんにちは、 @hfuhruhurr 投稿ありがとうございます！ 常に推奨されるのは、プロジェクトで使っている特定のデバイスやパッケージを選ぶことです。 新しいプロジェクトを作成し、正しいデバイスパッケージを選択し、既存のソースファイル、プロジェクト設定、設定を新しいプロジェクトにコピーしてください。 これにより、選択したパッケージごとにデバイス固有の設定が正しく生成され、設定に関する問題が解決される可能性があります。 また、選択しているMCUを変更する方法も可能です:MCUXpressoでMCUを変更する方法 この情報がお役に立てば幸いです！

NXPS32k144EVBの問題 こんにちは NXPS32K144EVBボードを使っていますが、S32 Design Studioでコードをフラッシュしようとすると問題が発生し、同じウィンドウを再度押すと、JFLASHに接続するとこのウィンドウが表示されます 接続中... - USB 経由でプローブ/プログラマデバイス 0 に接続中 - プローブ/プログラマファームウェア: J-Link V9 コンパイル日 2021 年 5 月 7 日 16:26:12 - プローブ/プログラマ S/N: 69408845 - デバイス "S32K144" が選択されました。- ターゲットインターフェース速度:4000 kHz(固定) - VTarget = 3.288V - InitTarget() 開始 - SWD 選択。JTAGからSWDへの切り替えシーケンスを実行しています。-アドレス 0x400 - 0x40F のフラッシュメモリ内の保護バイトは、読み出し保護が設定されていることを示します。デバッガーを接続するには、デバイスのセキュリティ設定を解除する必要があります。注意:固定を解除すると内部フラッシュの大量消去が発生します。レジストリに以前保存されたデフォルトの動作を実行します。- デバイスのセキュリティは解除されます。デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は決して止まらない。- InitTarget() 終了 - 2.15 秒かかりました - ID 0x2BA01477 の SW-DP を検出しました - DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - CPUへの接続に失敗しました。リセット状態で接続を実行します。- DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - Coresightセットアップでコアが見つからず - InitTarget() 開始 - SWDを選択しています。JTAGからSWDへの切り替えシーケンスを実行しています。- アドレスのフラッシュメモリ内の保護バイト。0x400～0x40Fは、読み出し保護が設定されていることを示します。デバッガーを接続するには、デバイスのセキュリティ設定を解除する必要があります。注意:固定を解除すると内部フラッシュの大量消去が発生します。レジストリに以前保存されたデフォルトの動作を実行します。- デバイスのセキュリティは解除されます。デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は決して止まらない。- InitTarget() 終了 - 2.15 秒かかりました - ID 0x2BA01477 の SW-DP を検出しました - DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - CPUへの接続に失敗しました。リセット状態で接続を実行します。- DPIDR: 0x2BA01477 - CoreSight SoC-400 以前 - 利用可能なすべての AP を見つけるために AP マップをスキャンしています - AP[2]: AP マップの終わりに達したため、AP スキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - 使用する AHB-AP を見つけるために AP マップを反復処理しています - AP[0]: スキップしました。CPUIDレジスタを読み取れませんでした - AP[1]:スキップ。AHB-APではありません - Coresightの設定でコアが見つからず - エラー:接続に失敗しました。ターゲットとの接続が確立できませんでした。- エラー: 接続に失敗しました Re: NXPS32k144EVB issue ハイ 考えられる原因: フラッシュセキュリティはフラッシュ構成フィールドで設定されます。 S32K144では、セキュリティ状態はフラッシュセキュアレジスタから得られます  FSEC  。これはリセット時にフラッシュ構成フィールドのフラッシュセキュリティバイトから読み込まれます。デバイスは安全である場合  SEC  安全でない  0b10  です。 一括消去が必要ですが、ブロックされています。 S32K144は通常、関連する FSEC ビット によって有効化された Mass Erase または Verify Backdoor Access Key によって安全解除されることがあります。しかし、もし CSEcはパーティショニングによって有効化されました 、 一括消去はブロックされています 一括消去が有効になっている場合でも  MEEN/MEEM  。https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 CSEcが有効になっている場合、復旧にはCSEcデバッグ認証フローが必要です。 文書化された復旧手順は、CSEc パーティションを破壊することです。  CMD_DBG_CHAL  そして  CMD_DBG_AUTH  知識を持って  MASTER_ECU_KEY  その後、一括消去が再び可能になります。 。キーが不明で、デバイスがCSEcによる一括消去ブロックで保護されている場合、そのデバイスを復元する手段はありません。 。https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 私が試してみる手順は以下の通りです（順不同）： このボードで過去にCSEc/セキュアブート/EEPROMパーティショニングのサンプルが実行されたことがある場合： CSEcのパーティショニングが関係している可能性があると想定してください。使用する  MASTER_ECU_KEY  キーを持っている場合は、以下の手順を実行してください。  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → CSEcパーティションを破壊 → 一括消去。 CSEcが意図的に有効化されていなかった場合: もう一度、非常に低いSWD速度で基本的なJ-Link復帰を試し、電源を入れ直し、リセットを正しくアサート/リリースし、  unlock Kinetis  。これはマス消去が実際に許可されている場合にのみ機能します。   unlock Kinetis  マスイレイスを有効にしていれば動作するはずです。https://community.nxp.com/t5/S32K/S32K148-Unsecurity/mp/1182938 もしPEmicroやOpenSDAスタイルのフローで接続する方法があれば NXPは、PEmicroツールは Erase Flash Block で消去し、J-Linkは mass ease を用いて新しいプロジェクトを読み込むと述べているので、試す価値はあるかもしれません。この区別はCSEcが大量消去をブロックする場合に影響します。 リセットボタンが物理的にローレベルに保持されている場合： まずそれを直してください。リセット中にスタックしたターゲットもコアアタッチを妨げることがありますが、ログの繰り返しのセキュリティ/大量消去タイムアウトの方がより強力な手がかりです。 結論としては、これは通常の接続速度の問題ではなく セキュリティ/CSEc/大量消去によるブロック状態 ようです。CSEcが有効で  MASTER_ECU_KEY  がない場合は、実際の解決策は通常MCUを交換することです。 決定的な分岐は、CSEcパーティショニングが有効になっているかどうかです。  MASTER_ECU_KEY  CSEcパーティションを破壊して消去してください。そうしないと、保護されたS32K144は復元できない可能性があります。   よろしくお願いいたします ロビン

DCDxツールが無効になっています DCDの設定が無効になっているようです。それを可能にするために何がCANできるのでしょうか? ツールの互換性に問題があるのでしょうか？ MCUXpresso IDE v25.6.136を使用中です。 SDK_26_03_00_FRDM-MCXA266から抽出したサンプルプロジェクトusb_cdcを開いています Re: DCDx Tool is disabled Hello サンプルに修正を加えているのか、それともSDKsからのインポートによる修正なしのサンプルなのか、確認を手伝ってもらえますか? おそらく、MCXA266が含まれていない古いバージョンのConfig Toolsを使用しているため、アップデートする必要があります。 バージョンを確認しましたが、エラーメッセージは表示されませんでした。バージョンを更新しました。 MCUXpresso IDEでは、設定ツールの更新はデフォルトで無効になっています。MCUXpresso IDEに統合されたConfig Toolsを更新するには、この投稿の指示に従ってConfigツールの更新を有効にしてください。 ウィンドウ>設定>インストール/更新>利用可能なソフトウェアサイト>MCUXpresso設定ツールを有効にする MCUXpresso IDEsの設定ツールを更新すること、 その後、利用可能なアップデートに関するウィンドウがいくつか表示されるので、それらを選択して次へ進み、ライセンス契約の条項に同意してください。 「Accept>Finish>Select All>Trust Selected>Restart MCUXpresso IDEをクリックしてください その後、再度試行してMCUXpressoのIDEs機能ウィンドウを表示し、バージョンを確認してください。 それがうまくいくか教えてください。もしダメなら、最新バージョンのConfig Tools(26.03)を手動でMCUXpresso Config Tools v26をインストールするのを手伝ってもらえますか?03、調査結果を教えてください。 敬具、ルイス Re: DCDx Tool is disabled こんにちは、 あなたは何を達成しようとしているのですか？DCDツール(デバイス構成データの略で、一部のI.MXRT10xxでしか利用できない)と、特定のツールはなく、一部のMCUのペリフェラルツールのサポート以外には特別なツールがないUSB CDCクラスを混同しているようです。 DCDツールはMCXAファミリでサポートされることはありません。私の知る限り、DCDツールに必要な機能を持っていません。 よろしくお願いします。 ペトル・フラドスキー 設定ツールチーム Re: DCDx Tool is disabled 現在、DCDファイルを手動で追加しています。なぜMCXAファミリのツールでサポートしてはいけないのでしょうか? Re: DCDx Tool is disabled 設定ツールを最新バージョンにアップデートしましたが、選択されたプロセッサ(TEE、デバイス設定)ではツールがサポートされていないことが依然として確認されています。バージョン26.03を使用しています。 Re: DCDx Tool is disabled DCDファイルには何が入っていますか？DCDツールは、デバイスの起動時にロードされるバイナリデータを生成します。現在、この機能がブートROMによって提供されるi.MXRT10xx向けに提供されています。

NXPS32k144EVB 问题 你好 我正在使用 NXPS32K144EVB 开发板，当我尝试使用 S32 Design Studio 烧录代码时，出现以下问题。如果我点击重试，同样的窗口会再次出现。我注意到，当我连接 JFlash 时也会出现这个问题。 正在连接... - 通过 USB 连接到探针/编程器设备 0 - 探针/编程器固件：J-Link V9，编译于 2021 年 5 月 7 日 16:26:12 - 探针/编程器序列号：69408845 - 已选择设备“S32K144”。- 目标接口速度：4000 kHz（固定） - VTarget = 3.288V - InitTarget() 开始 - 已选择 SWD。执行 JTAG -> SWD 切换序列。-闪存地址 0x400 - 0x40F 处的保护字节表示已设置读取保护。要连接调试器，设备必须处于非加密状态。注意：解除安全设置将触发对内部闪存的大规模擦除。- 执行之前保存在注册表中的默认行为。- 设备现在将处于不安全状态。- 解除设备安全保护时超时。抹除永无止境。- InitTarget() 结束 - 耗时 2.15 秒 - 找到 ID 为 0x2BA01477 的 SW-DP - DPIDR：0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 映射以查找所有可用的 AP - AP[2]：已到达 AP 映射的末尾，停止 AP 扫描 - AP[0]：AHB-AP（IDR：0x24770011） - AP[1]：JTAG-AP（IDR：0x001C0000） - 正在遍历 AP 映射以查找要使用的 AHB-AP - AP[0]：已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。非AHB-AP - 连接到CPU失败。执行RESET后的连接操作。- DPIDR：0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 地图以查找所有可用的 AP - AP[2]：已到达 AP 地图末尾，已停止 AP 扫描 - AP[0]：AHB-AP（IDR：0x24770011） - AP[1]：JTAG-AP（IDR：0x001C0000） - 正在遍历 AP 地图以查找要使用的 AHB-AP - AP[0]：已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。不是 AHB-AP - 在 Coresight 设置中找不到核心 - InitTarget() 开始 - 已选择 SWD。执行 JTAG -> SWD 切换序列。- 地址处的闪存中的保护字节。0x400 - 0x40F 表示已设置读取保护。要连接调试器，设备必须处于非加密状态。注意：解除安全设置将触发对内部闪存的大规模擦除。- 执行之前保存在注册表中的默认行为。- 设备现在将处于不安全状态。- 解除设备安全保护时超时。抹除永无止境。- InitTarget() 结束 - 耗时 2.15 秒 - 找到 ID 为 0x2BA01477 的 SW-DP - DPIDR：0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 映射以查找所有可用的 AP - AP[2]：已到达 AP 映射的末尾，停止 AP 扫描 - AP[0]：AHB-AP（IDR：0x24770011） - AP[1]：JTAG-AP（IDR：0x001C0000） - 正在遍历 AP 映射以查找要使用的 AHB-AP - AP[0]：已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。非AHB-AP - 连接到CPU失败。执行RESET后的连接操作。- DPIDR：0x2BA01477 - CoreSight SoC-400 或更早版本 - 正在扫描 AP 地图以查找所有可用的 AP - AP[2]：已到达 AP 地图末尾，已停止 AP 扫描 - AP[0]：AHB-AP（IDR：0x24770011） - AP[1]：JTAG-AP（IDR：0x001C0000） - 正在遍历 AP 地图以查找要使用的 AHB-AP - AP[0]：已跳过。无法读取 CPUID 寄存器 - AP[1]: 已跳过。不是 AHB-AP - 在 Coresight 设置中找不到核心 - 错误：连接失败。无法与目标建立连接。- 错误：连接失败 Re: NXPS32k144EVB issue HI 最可能的原因： 闪存网络安全设置在闪存配置字段中。 在 S32K144 上，网络安全状态来自闪存安全寄存器。  FSEC  该值在 RESET 时从闪存配置字段中的闪存安全字节加载；设备在以下情况下处于网络安全状态：  SEC  不是  0b10  。 需要进行批量擦除，但该操作被阻止。 S32K144 通常可以通过以下方式解除安全： 批量擦除 或者 验证后门访问密钥 如果这些路径已由相关系统启用  FSEC  比特 。然而，如果 CSEc是通过分区实现的。 ， 批量擦除功能已被阻止 即使批量擦除功能似乎已启用  MEEN/MEEM  。https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 如果启用了 CSEc，则恢复需要 CSEc 调试认证流程。 已记录的恢复路径是使用以下命令销毁 CSEc 分区  CMD_DBG_CHAL  和  CMD_DBG_AUTH  具备以下方面的知识  MASTER_ECU_KEY  之后，批量擦除功能将再次可用。 。如果密钥未知，且设备启用了 CSEc 安全机制以阻止批量擦除，则该设备无法恢复。 。https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 我会按以下顺序尝试： 如果该板曾经运行过 CSEc / 安全启动 / EEPROM 分区示例： 假设可能涉及 CSEc 分区。使用  MASTER_ECU_KEY  如果你有密钥，流程如下：  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → 销毁 CSEc 分区 → 批量擦除。 如果并非有意启用 CSEc： 再次尝试使用非常低的SWD速度进行基本的J-Link恢复，断电重启，RESET已正确钳位/释放，并且  unlock Kinetis  。只有在允许批量擦除的情况下，这种方法才有效；  unlock Kinetis  如果启用批量擦除功能，应该可以正常工作。https://community.nxp.com/t5/S32K/S32K148-Unsecurity/mp/1182938 如果您仍然能够使用 PEmicro/OpenSDA 风格的流程进行连接： 或许值得一试，因为NXP指出PEmicro工具可以使用擦除功能。 擦除闪存块 而 J-Link 使用 批量擦除 加载新项目时；当 CSEc 阻止批量擦除时，这种区别可能很重要。 如果RESET物理保持低电平： 先解决这个问题。目标卡在RESET状态也可能阻止核心附加，但日志中反复出现的网络安全/批量擦除超时才是更有力的线索。 总之：这看起来像是一个 网络安全/CSEc/批量擦除阻止条件 这不是普通的连接速度问题。如果启用了 CSEc 并且您没有  MASTER_ECU_KEY  通常情况下，实际的解决方法是更换MCU。 决定性的分支在于是否启用了 CSEc 分区：启用后  MASTER_ECU_KEY  销毁 CSEc 分区并擦除；没有它，受保护的 S32K144 可能无法恢复。   此致敬礼， Robin

Backward compatibility TJA1051 Hi, i am using the TJA1050 in our products and replaced it with the TJA1051 because of this line in the datasheet: Today i was working on another project and came across the TJA1051 again and saw this: with Vio = VCC this means that VIH = 0,7*5=3,5V From the datasheet TJA1050: So in other words: TJA1050 and TJA1051 are not compatible on controller side. Somehow i missed that part and now our products are running with the TJA1051 (not the /3 variant) directly connected to a Kinetis MK22, which has 3.3V outputs. And it just works fine. So my question is: am i lucky that it works? Or is this a combination of the five volt tolerant MK22 pins and the internal pull up from the TJA1051 on TXD? I am not sure on which way to go now... Accept the fact that this is working or redesign all of our products? Thanks in advance! Greetings Jörn Re: Backward compatibility TJA1051 1:You can test the TX pin value during TJA1051 work. 2: change it into TJA1051/3,it should be no more risk.

LS1046/26 CPU向けu-bootのZeus 2019.04 +fslcからWrynose 2026.01への移行 こんにちは 私たちは「git://source.codeaurora.org/external/qoriq/」のu-bootコードバージョンを使用しています。当社のLS1046/26 CPU搭載カード向け。このU-Bootのバージョンは2019.04 +fslcです。また、セキュアブートもサポートしています。 現在、U-BootをWrynose 2026.01にアップグレードすることを検討しています。 既存のU-Bootソースコードは、元々は現在非推奨となっているリポジトリから入手したものです。 git://source.codeaurora.org/external/qoriq/. 最新のコードに使うのに適したGitリポジトリについてアドバイスいただけますか? また、アップグレード期間中のスムーズな移行を確実にするための重要なポイントやベストプラクティスを教えていただけると助かります。 Re: u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU こんにちは、 LS1046/LS1026AファミリのLayerscape U-Bootの場合、廃止されたCodeAurora QorIQツリーの代替は以下の通りです: git clone https://github.com/nxp-qoriq/u-boot.git NXPのガイダンスでは、次のような古いURLを置き換えることを推奨しています。 source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git​​​​​​​​​​​ 説明： ギットハブ。 com / nxp - qoriq / u - boot 。 git または、より一般的には、 source.codeaurora.org/external/qoriq/qoriq-components /qoriq/qoriq-components を置き換えます。ビルドスクリプト、マニフェスト、Yoctoレシピに入 github.com/nxp-qoriq 。 WrynoseベースのBSPなら、U-Bootだけをクローンするのではなく、QorIQ Yocto SDKのマニフェストから始めます。 リポジトリ init - u https: / //GitHub. com / nxp-qoriq / yocto-sdk - b wrynose repo sync -- force-sync 公開 nxp-qoriq/yocto-sdk リポジトリにはアクティブな wrynose ブランチが表示されています。同じリポジトリには一般的なリポジトリ-initの流れやYoctoのブランチ/リリースマッピングメカニズムが記載されています。 U-Boot に関しては、公開されている nxp-qoriq/u-boot リポジトリは QorIQ U-Boot ツリーです。取得したリポジトリページに表示されるデフォルトのブランチは lf_v2024.04 で、アクティブなブランチのリストには lf_v2026.04 も表示されます。表示されるタグには、 lf-6.12.49-2.2.0 、 lf-6.18.2-1.0.0 、 lf-6.18.20-2.0.0 などの最近の lf-* リリース タグが含まれます。実用的なルールとしては、 Wrynose Yoctoのマニフェストやレシピで選択したU-Bootのリビジョンを使う べきで、任意の「最新」U-Bootブランチを手動で取得するのではなく、 移行における重要な考慮事項： CodeAuroraへの参照をすべて移行する ビルドツリーで古いURLを検索してください: grep - rn 'source.codeaurora.org/external/qoriq' 。 source.codeaurora.org/external/qoriq/qoriq-components を置き換えてください。マニフェスト、ビルド構成、レシピに github.com/nxp-qoriq を使用します。 リリースマニフェストを信頼できる情報源として使用する BSPのアップグレードを行う際は、U-Boot、ATF、RCW、CST、カーネル、デバイスツリー、およびレシピを同じNXPリリースストリームに合わせておいてください。 NXPの現在のLayerscapeフローでは、一般的にATFとU-Bootを組み合わせて使用しており、スタンドアロンのU-Bootのみを使用しているわけではありません。 LS1046ARDBリファレンスからカスタムボードを再度移植してください。 LS1046カスタムボードの場合、NXPはLS1046ARDB U-Bootのリファレンスファイル( configs/ls1046ardb_tfa_defconfig 、 arch/arm/dts/fsl-ls1046a-rdb.dts 、 board/freescale/ls1046ardb/ )を指しています。 旧式のカスタマイズについては、 include/configs/ls1046ardb.h とボードフォルダも確認してください。 既存の基板変更を、古い2019.04コードを丸ごとコピーするのではなく、新しいデバイスモデル/Kconfig/DTS構造と照合してください。 セキュアブート：フルチェーンを再構築して再検証する Yoctoでは、セキュアブートイメージは以下を追加することで構築されます: DISTRO_FEATURES : append = " secure" そして実行中: bitbake secure - boot - qoriq CST、SRKH、OTPMK、RCW SB_EN 、ATF、および署名付きU-Bootイメージの処理は、製品版のヒューズ設定を変更する前に、開発用/非ヒューズユニットで全て再検証する必要があります。 2019.04以降、ブートフローに違いが生じる可能性があります。 LSDK 18.12以降、NXPはLayerscape RDB用のTF-Aブートフローを導入しました。 Boot ROM → BL2 → BL31 → U-Boot/UEFI → Linux 、従来のPPAスタイルのフローと比較して。 もし現在の製品に古いPPA/直接U-Bootの想定がまだ残っているなら、よく見直してください。 管理された移行ベースラインを維持する まず、変更を加えていないNXPのリファレンス構成を、ご使用のハードウェアの近くで起動してください。 その後、ボードのデルタを小グループに分けて適用します:RCW/SerDes、DDR、コンソール、ブートメディア、QSPI/eMMC/SD、イーサネット/FMan、環境レイアウト、セキュアブート。 古い2019.04 + fslcツリーとの互換性を宣言する前に、非セキュアブートパスとセキュアブートパスの両方を検証してください。 よろしくお願いします。

後方互換性 TJA1051 こんにちは、 私は製品にこのTJA1050を使い、データシートの以下の文言のためにTJA1051に置き換えました。 今日、別のプロジェクトに取り組んでいたところ、再びTJA1051に出くわし、以下の内容を見つけました。 Vio = VCC の場合、VIH = 0.7 * 5 = 3.5V となります。 データシートTJA1050より： つまり、TJA1050とTJA1051はコントローラ側で互換性がないということです。 なぜかその部分を見落としていたのですが、今ではTJA1051(/3バリアントではなく)をKinetis MK22に直接接続し、3.3V出力で製品は動作しています。 そして、それは何の問題もなく機能します。 SO質問ですが、うまくいっているのは幸運でしょうか? それともこれは、5ボルト耐性のMK22ピンと、TXD上のTJA1051による内部プルアップ抵抗の組み合わせによるものなのでしょうか？ 今はどちらの方向へ進むべきか迷っています…。 これがうまくいっていることを受け入れるべきか、それともすべての製品を再設計すべきか? よろしくお願いいたします！ ご挨拶 ヨルン Re: Backward compatibility TJA1051 1:作業中にTXピン値をテストTJA1051。 2：TJA1051/3に変更すれば、リスクはなくなるはずです。

NXPS32k144EVB issue Hello i am using nxps32k144evb board when i try to flash code using s32 design studio following issue occure and if i press retry same window again appear one this i notices when i connect jflash  Connecting ... - Connecting via USB to probe/ programmer device 0 - Probe/ Programmer firmware: J-Link V9 compiled May 7 2021 16:26:12 - Probe/ Programmer S/N: 69408845 - Device "S32K144" selected. - Target interface speed: 4000 kHz (Fixed) - VTarget = 3.288V - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Attach to CPU failed. Executing connect under reset. - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Could not find core in Coresight setup - InitTarget() start - SWD selected. Executing JTAG -> SWD switching sequence. - Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set. For debugger connection the device needs to be unsecured. Note: Unsecuring will trigger a mass erase of the internal flash. - Executing default behavior previously saved in the registry. - Device will be unsecured now. - Timeout while unsecuring device. Erase never stops. - InitTarget() end - Took 2.15s - Found SW-DP with ID 0x2BA01477 - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Attach to CPU failed. Executing connect under reset. - DPIDR: 0x2BA01477 - CoreSight SoC-400 or earlier - Scanning AP map to find all available APs - AP[2]: Stopped AP scan as end of AP map has been reached - AP[0]: AHB-AP (IDR: 0x24770011) - AP[1]: JTAG-AP (IDR: 0x001C0000) - Iterating through AP map to find AHB-AP to use - AP[0]: Skipped. Could not read CPUID register - AP[1]: Skipped. Not an AHB-AP - Could not find core in Coresight setup - ERROR: Failed to connect. Could not establish a connection to target. - ERROR: Connect failed Re: NXPS32k144EVB issue Hi Most likely causes: Flash security is set in the Flash Configuration Field. On S32K144, the security state comes from the Flash Secure Register  FSEC  , which is loaded from the flash security byte in the Flash Configuration Field at reset; the device is secure when  SEC  is not  0b10  . Mass erase is required but is being blocked. S32K144 can normally be unsecured by Mass Erase or Verify Backdoor Access Key , if those paths are enabled by the relevant  FSEC  bits . However, if CSEc was enabled by partitioning ,  mass erase is blocked , even if mass erase appears enabled in  MEEN/MEEM  . https://community.nxp.com/t5/S32K/Device-is-secure/td-p/1744921 If CSEc is enabled, recovery requires the CSEc debug-auth flow. The documented recovery path is to destroy the CSEc partition using  CMD_DBG_CHAL  and  CMD_DBG_AUTH  with knowledge of  MASTER_ECU_KEY  ; after that, mass erase becomes available again . If the key is not known and the device is secured with CSEc blocking mass erase, there is no recovery path for that device . https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/td-p/2036891 What I would try, in order: If this board ever ran CSEc / secure boot / EEPROM-partitioning examples: assume CSEc partitioning may be involved. Use the  MASTER_ECU_KEY  flow if you have the key:  CMD_DBG_CHAL  →  CMD_DBG_AUTH  → destroy CSEc partition → mass erase. If CSEc was not intentionally enabled: try a basic J-Link recovery once more with very low SWD speed, power-cycle, reset asserted/released correctly, and  unlock Kinetis  . This only works when mass erase is actually allowed;   unlock Kinetis  should work if mass erase is enabled. https://community.nxp.com/t5/S32K/S32K148-Unsecurity/m-p/1182938 If you still have any way to connect using a PEmicro/OpenSDA-style flow: it may be worth trying because NXP notes that PEmicro tools erase using Erase Flash Block , while J-Link uses mass erase when loading a new project; that distinction can matter when CSEc blocks mass erase. If reset is physically held low: fix that first. A target stuck in reset can also prevent core attach, but your log’s repeated security/mass-erase timeout is the stronger clue. Bottom line: this looks like a security/CSEc/mass-erase-blocked condition , not a normal connection-speed problem. If CSEc is enabled and you do not have the  MASTER_ECU_KEY  , the practical answer is usually to replace the MCU. The decisive branch is whether CSEc partitioning was enabled: with the  MASTER_ECU_KEY  , destroy the CSEc partition and erase; without it, the secured S32K144 is likely unrecoverable.   Best Regards, Robin

DCDx 工具已禁用 DCD配置似乎已被禁用。如何才能实现这一点？ 是工具兼容性问题吗？ 使用 MCUXpresso IDE v25.6.136。 打开从 SDK_26_03_00_FRDM-MCXA266 中提取的示例项目 usb_cdc Re: DCDx Tool is disabled Hello 能否请您确认一下，您是否对示例进行了修改，还是直接从 SDK 导入的示例未经任何修改？ 可能是您的配置工具版本过旧，其中不包含 MCXA266，您需要更新。 我检查了我的版本，没有出现错误信息。我已经更新了版本。 在 MCUXpresso IDE 中，配置工具更新默认处于禁用状态。要更新 MCUXpresso IDE 中集成的配置工具，请按照本文中的说明启用配置工具更新。 窗口>首选项>安装/更新>可用软件站点>启用MCUXpresso配置工具 更新MCUXpresso IDE中的配置工具 之后可能会出现一些更新提示窗口，选择更新并点击“下一步”，然后接受许可协议条款。 点击“接受”>“完成”>“全选”>“信任所选”>“重启 MCUXpresso IDE”。 然后请重试并再次查看 MCUXpresso IDE 功能窗口以确认版本。 如果这样可以解决问题，请告诉我；如果不行，能否请您手动安装最新版本的 Config Tools (26.03) MCUXpresso Config Tools v26.03，并告知我您的发现。 此致敬礼，路易斯 Re: DCDx Tool is disabled 我已将配置工具更新到最新版本，但仍然看到所选处理器不支持该工具：TEE，设备配置。使用 26.03 版本。 Re: DCDx Tool is disabled 你好， 你想达到什么目的？您似乎将 DCD 工具（代表设备配置数据，仅适用于部分 I.MXRT10xx）与 USB CDC 类混淆了，后者没有任何特殊工具，只是外设工具对某些 MCU 提供支持。 DCD 工具永远不会支持 MCXA 系列，因为据我所知，它不具备 DCD 工具所需的功能。 此致 彼得·赫拉德斯基 配置工具团队 Re: DCDx Tool is disabled 目前我正在手动添加DCD文件。为什么 MCXA 系列工具不支持它？ Re: DCDx Tool is disabled 你的DCD文件里有什么内容？DCD 工具生成在设备启动期间要加载的二进制数据，目前适用于 i.MXRT10xx，该功能由启动 ROM 提供。

后向兼容性 TJA1051 您好， 我的产品中使用的是TJA1050，但由于数据手册中的这一行，我将其替换为TJA1051： 今天我在做另一个项目的时候又遇到了TJA1051，然后看到了这个： 当 Vio = VCC 时，这意味着 VIH = 0.7 * 5 = 3.5V 数据手册 TJA1050 内容如下： 换句话说：TJA1050 和 TJA1051 在控制器方面不兼容。 不知何故我错过了那部分，现在我们的产品使用的是直接连接到 Kinetis MK22 的 TJA1051（不是 /3 版本），而 Kinetis MK22 有 3.3V 输出。 而且它运行良好。 所以我的问题是：我运气好吗？它居然奏效了？ 或者这是由于 MK22 引脚具有 5 伏耐压能力，以及 TXD 上的 TJA1051 内部上拉电阻共同作用的结果？ 我现在不知道该往哪个方向走了…… 接受现状，还是重新设计我们所有的产品？ 提前感谢！ 您好 约恩 Re: Backward compatibility TJA1051 1：您可以在 TJA1051 工作期间测试 TX 引脚值。 2：换成 TJA1051/3，应该就没有风险了。

如何使用 S32k344 多链接效果器 我正在使用 FRDM-A-S32K344 型号，并且我正在尝试通过 Multilink FX 下载 LED 闪烁功能，但它不起作用。我想知道为什么。我一直遇到错误，即使尝试通过 Gemini 修复也无济于事。请帮忙。 我还确认了 Multilink FX 型号的橙色指示灯（TGPWR）亮起。 Gemini 指示移除 JP11 OPENSDA 电压，但我不知道该怎么做。 Re: how to use S32k344 multilink fx 我解决了。移除 JP11 后就生效了。

在 MCUXpresso 中将 MCU 从 LPC54S018J4M 更换为 LPC54S018J2M 大家好， 我使用 MCUXpresso 和上述 MCU 的评估板开发了一个项目。 评估板采用的是 LPC54S018J4M，而我的定制板采用的是 LPC54S018J2M，两者基本相同，只是闪存容量不同（2 / 4 MB）。 我比较了两个处理器的 SDK 中的启动文件，它们完全相同，也就是说，两者都包含指向 4MB 闪存的 SPI 描述符。 /* SPI 描述符 - Winbond W25Q32JV */ 直接将内存详细信息第一行中的内存大小从 0x400000 更改为 0x200000 是否安全？ 顺祝商祺！ 雷纳 Re: Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso 嗨@hfuhruhurr 谢谢你的帖子！ 建议始终选择您在项目中使用的特定设备/软件包。 请创建一个新项目，选择正确的设备包，然后将您现有的源文件、项目设置和配置复制到新项目中。 这将有助于确保为所选套餐正确生成所有设备特定设置，并可能解决任何与配置相关的问题。 此外，您还可以更改所选的MCU：如何使用MCUXpresso更改MCU 希望这些信息对您有所帮助！

u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU Hi  We are using u-boot code version from  "git://source.codeaurora.org/external/qoriq/" for our LS1046/26 Cpu based cards. The version of this u-boot is  2019.04 +fslc. We also supports secure boot. We are now thinking of upgrading our u-boot to Wrynose 2026.01. Our existing U-Boot source code was originally obtained from the now-deprecated repository: git://source.codeaurora.org/external/qoriq/. Could you please advise on the appropriate Git repository to use for the latest code? Additionally, it would be helpful if you could share any key considerations or best practices to ensure a smooth transition during the upgrade. Re: u-boot migration from Zeus 2019.04 +fslc to Wrynose 2026.01 for LS1046/26 CPU Hello, For LS1046/LS1026A-family Layerscape U-Boot, the replacement for the deprecated CodeAurora QorIQ tree is: git clone https://github.com/nxp-qoriq/u-boot.git NXP guidance is to replace old URLs such as: source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git with: github.com/nxp-qoriq/u-boot.git or, more generally, replace source.codeaurora.org/external/qoriq/qoriq-components with github.com/nxp-qoriq in build scripts, manifests, and Yocto recipes . For a Wrynose-based BSP , I would start from the QorIQ Yocto SDK manifest , not by cloning U-Boot alone: repo init -u https://github.com/nxp-qoriq/yocto-sdk -b wrynose repo sync --force-sync The public nxp-qoriq/yocto-sdk repo shows an active wrynose branch . The same repo documents the general repo-init flow and lists the Yocto branch/release mapping mechanism. For U-Boot specifically, the public nxp-qoriq/u-boot repo is the QorIQ U-Boot tree; its default branch shown in the retrieved repo page is lf_v2024.04 , and the active branch list also shows lf_v2026.04 . Tags shown include recent lf-* release tags such as lf-6.12.49-2.2.0 , lf-6.18.2-1.0.0 , and lf-6.18.20-2.0.0 . So the practical rule is: use the U-Boot revision selected by the Wrynose Yocto manifest/recipe , rather than manually taking an arbitrary “latest” U-Boot branch. Key transition considerations: Migrate all CodeAurora references Search your build tree for old URLs: grep -rn 'source.codeaurora.org/external/qoriq' . Replace source.codeaurora.org/external/qoriq/qoriq-components with github.com/nxp-qoriq in manifests, build configs, and recipes. Use the release manifest as the source of truth For a BSP upgrade, keep U-Boot, ATF, RCW, CST, kernel, device trees, and recipes aligned to the same NXP release stream. NXP’s current Layerscape flow commonly uses ATF + U-Boot , not standalone U-Boot only. Port your custom board from the LS1046ARDB reference again For LS1046 custom boards, NXP points to the LS1046ARDB U-Boot reference files: configs/ls1046ardb_tfa_defconfig , arch/arm/dts/fsl-ls1046a-rdb.dts , and board/freescale/ls1046ardb/ . For older-style customizations, also review include/configs/ls1046ardb.h and the board folder. Reconcile your existing board changes against the new device-model/Kconfig/DTS structure rather than copying old 2019.04 code wholesale. Secure boot: rebuild and re-validate the full chain In Yocto, secure boot images are built by adding: DISTRO_FEATURES:append = " secure" then running: bitbake secure-boot-qoriq CST, SRKH, OTPMK, RCW SB_EN , ATF, and signed U-Boot image handling should all be revalidated on a development/non-fused unit before touching production fuse settings. Expect boot-flow differences from 2019.04 Since LSDK 18.12, NXP introduced the TF-A boot flow for Layerscape RDBs: Boot ROM → BL2 → BL31 → U-Boot/UEFI → Linux , compared with the older PPA-style flow. If your current product still carries assumptions from the old PPA/direct U-Boot path, review them carefully. Keep a controlled migration baseline First bring up an unmodified NXP reference configuration close to your hardware. Then apply your board deltas in small groups: RCW/SerDes, DDR, console, boot media, QSPI/eMMC/SD, Ethernet/FMan, environment layout, secure boot. Validate both non-secure and secure boot paths before declaring parity with the old 2019.04 + fslc tree. Regards

32ビット並列受信（立ち上がりエッジピン）（FRDM-MCXN947） 現在、32ビットパラレルシフターを構成して、外部デバイスからデータを受信するようにしようとしています。その際、ピンの1つ（FLEX_D4/DATA_VALID）をデータシフトのための信号として使用します。 これまでの進歩により、DATA_VALIDがトリガーされたときに32ビットデータを読み込み、そのデータをeDMA Ping-Pongバッファに移動させることが可能になりました。現在、Printf文を使用してバッファデータをコンソールに読み出すテストを行っています。Shifterにエラーが発生した場合（データシートによると通常はオーバーランを示す）、それもコンソールに出力されます。 私の主な問題はTimerConfigにあると考えています。DATA_VALIDの立ち上がりエッジでShifterが何度も読み取りをトリガーしてしまうのですが、正しいデータを実際に移動させながら一度だけ読み取りを行うような設定が見つかりません。 コンソール出力: 読み取りバッファA: 0x3fffefff シフトエラーコード: 0x8 シフターの状態: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMAエラー: 0x0 TCD BITER: 0x2 CSR: 0x12 CH_MUX: 0x40 バッファBの読み取り: 0x3ffffefff シフトエラーコード: 0x8 シフターの状態: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMAエラー: 0x0 TCD BITER: 0x2 CSR: 0x12 私のFLEX_IOの設定ファイルを添付します。ありがとう。 クロック|タイマー 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) 開発ボード MCX N Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) 更新: 「 kFLEXIO_TimerDisableOnTriggerFallingEdge 」がCPUをコールバック内に留めていたことが分かりました。 タイマー比較後に無効にしたいのですが、このオプションでは SHIFTBUF は 0x0 の値のみを報告し、SHIFTERR フラグは報告しません。 Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) こんにちは、 @carlos_oさん、返信ありがとうございます！ 思ったようにタイマーをエッジで表示DATA_VALIDきましたが、Threadは更新しませんでした。現在使用しているコードを添付します。 私が現在直面している問題は、FlexIOを他のデバイスと同等の速度で動作させることです。今のセットアップでは基本的にサンプリングDATA_VALIDで、高速になるとシフターがオーバーランになることがあります。私の考えでは、私のデザインにはMCXとホストデバイス間で共有クロックが必要であり、ホストデバイスが32ビットデータを送る予定だと思います。32ビットデータバス内のピンをこの信号に使えるので、FlexIOのピンを分割する必要がありません。このアイデアについて何かご意見があればぜひお聞かせください! 以前のご質問にお答えします。 1.レジスタは、低速でも意図どおりにデータが格納されています。DATA_VALIDの降下エッジごとに、SHIFTBUFは32ピンからデータを保存し、EDMAは散布・採集方法でピンポンバッファに転送します。 2. アナログ Discovery 2で入力をシミュレートしています。アナログ Discovery 2はデータピンが16本しかないため、32ビットの上限値を書き込み、DATA_VALIDピンでクロックをシミュレートし、未使用のピンを固定しています。低速走行時におけるテストデータは正しく一致している。 3. 私はFRDM-MCXN947を使用しています Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) こんにちは、 @Flexin_On_The_IO さん。 投稿ありがとうございます！ あなたのレジスターで現在の行動について教えていただけますか? どのようなテストデータを受信しようとしていますか？また、現在どのようなデータが受信されていますか？ どのMCXNを使っているのか教えていただけますか? これはカスタムボードですか？そうでない場合は、使用しているボードを指定してください。

how to use S32k344 multilink fx I am using the FRDM-A-S32K344 model and I am trying to download the LED blinky feature via Multilink FX, but it isn't working. I would like to know why. I keep getting errors, and even trying to fix it through Gemini doesn't help. Please help. I also confirmed that the orange light (TGPWR) was on for the Multilink FX model. Gemini says to remove the JP11 OPENSDA voltage, but I don't know how to do that. Re: how to use S32k344 multilink fx I solved it. It worked after removing JP11.

DCDx Tool is disabled DCD configuration appeared disabled. What can be done to enable it? Is it problem with compatibility of the tool?  Working with MCUXpresso  IDE v25.6.136. Opening extracted example project usb_cdc from SDK_26_03_00_FRDM-MCXA266 Re: DCDx Tool is disabled Hello Could you help us confirm if you have made modifications on the example or it’s the example without modifications from importing from the SDK? Probably you had an older version of Config tools that do not contain MCXA266 and you need to update. I review my versions and doesn’t appear the error message. I have updated versions. In the MCUXpresso IDE, the config tools updates are disabled by default. To update Config Tools integrated in the MCUXpresso IDE, kindly follow the instructions in this post to enable the Config tools updates. Window>Preferences>Install/Update>Available Software Sites>Enable MCUXpresso Config Tools Updating Config Tools in the MCUXpresso IDE, After this, probably some windows appear for available updates, select them and next, then accept terms of license agreement, Click on Accept>Finish>Select All>Trust Selected>Restart MCUXpresso IDE Then please retry and view for the MCUXpresso IDE Features window again to confirm the versions. Let me know if that work for you, and if not, could you help us install the latest version of Config Tools (26.03) manually MCUXpresso Config Tools v26.03 and let me know your findings. Best Regards, Luis Re: DCDx Tool is disabled I updated Config Tools to the latest version, but still see that Tools are not supported for the selected processor: TEE, Device Configuration. Using 26.03 version. Re: DCDx Tool is disabled Currently I'm adding DCD file manually. Why it shouldn't be supported by the tool for MCXA family? Re: DCDx Tool is disabled Hi,  What are you trying to achieve ? It seems you are confusing DCD tool (which stands for Device Configuration Data and is available only for some of the I.MXRT10xx) and the USB CDC class which does not have any special tool, except the support in the Peripherals tool for some MCUs. The DCD tool will never be supported for MCXA family, as it as far as I know doesn;t have the feature needed for DCD tool.  Regards Petr Hradsky Config Tools Team Re: DCDx Tool is disabled What is inside your DCD file? The DCD tool generates binary data to be loaded during device boot and is currently provided for i.MXRT10xx where this feature is provided by the boot rom.