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、調査結果を教えてください。 敬具、ルイス

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，并告知我您的发现。 此致敬礼，路易斯

后向兼容性 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 フラグは報告しません。

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

Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso Hi everybody, I developed a project with MCUXpresso using the evaluation board for above mentioned MCUs. The eval board carries a LPC54S018J4M and my custom board carries the LPC54S018J2M which is essentially the same except the different size of the flash memory (2 / 4 MB) I compared the startup files in SDKs for both processors and they're exactly the same, i.e. both have the SPI descriptor for 4MB flash inside /* SPI Descriptor - Winbond W25Q32JV */ Is it safe to just change the memory size in the Memory Details, first line, from 0x400000 to 0x200000? Best regards, Rainer Re: Changing MCU from LPC54S018J4M to LPC54S018J2M in MCUXpresso Hi @hfuhruhurr  Thank you for the post! The recommendation always will be to select the specific device/package you are using in your project.  Please create a new project, select the correct device package, and then copy your existing source files, project settings, and configurations into the new project. This will help ensure that all device-specific settings are generated correctly for the selected package and may resolve any configuration-related issues. Also, you could change the MCU selected: How to Change MCU with MCUXpresso Hope this information helps!

32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) I am currently trying to configure a 32-bit parallel Shifter to receive data from an external device with one of the pins (FLEX_D4/DATA_VALID) being used as a signal to Shift in the data.  The progress I have made has allowed me to read in the 32-bit data when DATA_VALID has triggered and move the data into an eDMA Ping-Pong buffer. I am currently testing through Printf statements of reading the buffer data to a console and if the Shifter has any errors (usually indicating Overrun according to the datasheet) they will print to the console as well.  I believe my main issue is with the TimerConfig as it is triggering the Shifter to read too many times on one rising edge of DATA_VALID but I have not found a configuration that allows me to read only once while actually moving the correct data.  Console Output:  Reading Buffer A: 0x3fffefff Shifter Error Code: 0x8 Shifter Status: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMA Error: 0x0 TCD BITER: 0x2 CSR: 0x12 CH_MUX: 0x40 Reading Buffer B: 0x3fffefff Shifter Error Code: 0x8 Shifter Status: 0x0 SHIFTSDEN: 0x8 DMA CSR: 0x0 DMA Error: 0x0 TCD BITER: 0x2 CSR: 0x12 My FLEX_IO setup is attached. Thank you. Clock|Timers Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Development Board MCXN Re: 32-Bit Parallel Receive on Rising Edge Pin (FRDM-MCXN947) Update: I was able to deduce that "kFLEXIO_TimerDisableOnTriggerFallingEdge" was keeping my CPU in the callback. I believe I want to disable after a Timer Compare but with this option SHIFTBUF only reports a value of 0x0 but with no SHIFTERR flag. 

How to force 32-bit instructions (avoiding 16-bit Thumb) on i.MXRT1170 EVKB using Arm FuSa Compiler Hi Everyone, I am currently working on a Proof of Concept (PoC) project using the NXP MIMXRT1176DVMAA processor on an i.MXRT1170 EVKB board. My development environment consists of MCUXpresso IDE with the safety-certified Arm Compiler for Embedded FuSa.During compilation, I want to avoid the generation of 16-bit instructions and force the toolchain to emit only 32-bit instructions.I understand that the Thumb-2 (T32) instruction set natively mixes 16-bit and 32-bit instructions by default to balance performance and code size. However, for our project requirements, we need every single generated instruction to be exactly 32 bits wide. Could anyone kindly guide me on how to configure the compiler or toolchain options in MCUXpresso IDE to enforce 32-bit wide instruction generation? Thank you, Karthi Re: How to force 32-bit instructions (avoiding 16-bit Thumb) on i.MXRT1170 EVKB using Arm FuSa Compi Hi @KD7 , Thanks for your interest in NXP MIMXRT series! On RT1170 / Cortex-M7, this is not supported as a global compiler setting. The core executes ARMv7-M Thumb/T32 code, and T32 is inherently mixed 16-bit/32-bit. The A32 -marm option would be the fixed 32-bit instruction set option, but it is not valid for M-profile targets. For hand-written assembly only, .W can force selected T32 instructions to 32-bit encodings where valid, but it cannot force all compiler-generated C/C++ instructions to be 32-bit. ARM may provide more information on this topic. Thanks and best regards, Gavin

如何使用 Arm FuSa 编译器在 i.MXRT1170 EVKB 上强制执行 32 位指令（避免使用 16 位 Thumb 指令集） 大家好， 我目前正在使用 NXP MIMXRT1176DVMAA 处理器在 i.MXRT1170 EVKB 板上进行概念验证 (PoC) 项目。 我的开发环境由 MCUXpresso IDE 和经过功能安全认证的 Arm 嵌入式 FuSa 编译器组成。在编译过程中，我希望避免生成 16 位指令，并强制工具链只生成 32 位指令。我知道 Thumb-2 (T32) 指令集默认情况下会混合使用 16 位和 32 位指令，以平衡性能和代码大小。但是，根据我们的项目要求，我们需要生成的每一条指令都正好是 32 位宽。 请问哪位好心人可以指导我如何在 MCUXpresso IDE 中配置编译器或工具链选项，以强制生成 32 位宽的指令？ 谢谢你， 卡尔蒂 Re: How to force 32-bit instructions (avoiding 16-bit Thumb) on i.MXRT1170 EVKB using Arm FuSa Compi 嗨@KD7 ， 感谢您对 NXP MIMXRT 系列产品的关注！ 在 RT1170 / Cortex-M7 上，不支持将此作为全局编译器设置。该内核执行 ARMv7-M Thumb/T32 代码，而 T32 本质上是 16 位/32 位混合的。A32 -marm 选项是固定的 32 位指令集选项，但对 M我的目标无效。 仅对于手写汇编，.W 可以强制选定的 T32 指令在有效的情况下使用 32 位编码，但它不能强制所有编译器生成的 C/C++ 指令都是 32 位的。 ARM可能会提供更多相关信息。 谢谢，并致以最诚挚的问候！ 加文

MCUXpresso Secure Provisioning Tool (SEC) version 26.06 now available What's new in SEC v26.06? Support new processors: - MCX A series extended with MCX A557 variant - MCX N series extended with MCX N246 variant - New MCX NxxxT processors: MCX N246T/N247T/N527T/N536T/N537T/N546T/N547T/N556T/N557T/N946T/N947T - New MCX C processors: MCXC151, MCXC161, MCXC162 - i.MX952 A0 processor with Cortex-M debug support (unsigned only, serial downloader) MCX A28x/45x/5xx: Added FlexSPI NOR support; added signed & encrypted boot support for ECC and PQC ML-DSA MCX E31x: Added key catalog configuration, SMR region configuration and reset core configuration.  Added debug access protection (ADKP) for OEM_PROD and IN_FIELD life cycles MCX L25x: Added Secure Installer support for signed boot and more ! Known issues and limitations Troubleshooting Downloads  To download the installer, please login to our download site via: https://nxp.com/mcuxpresso/secure Useful links: Release Notes: MCUXpresso Secure Provisioning Tool (SEC) release notes Fact Sheet: MCUXpresso Secure Provisioning Tool Fact Sheet announcement

Create Key & Certificate for HTTPS Server using IP on Windows Introduction HTTP is a protocol used to enable communication between web browsers and servers. A secure variation of this protocol is HTTPS, which adds encryption to protect data exchanged between the client and the server. This ensures that even if someone intercepts the communication, they cannot understand the transmitted information. In embedded systems and MCU-based applications, libraries such as mbedTLS are commonly used to implement secure communication. These libraries rely on cryptographic keys and digital certificates. For production environments, certificates are typically signed by a Certificate Authority (CA), which guarantees their authenticity and allows web browsers to trust the connection. However, when a certificate is generated manually (self-signed), web browsers do not inherently trust it. Despite this, self-signed certificates are a practical option for internal or development use cases, since the communication remains encrypted. Additionally, it is possible to configure client devices to trust these certificates when required.   Download OpenSSL First, verify whether OpenSSL is installed on your system. If not, it must be downloaded and installed. To check if OpenSSL is already installed, run next line in command prompt: openssl --version If the command is not recognized, OpenSSL is not installed. If OpenSSL is not already installed on your system, you can easily find installation instructions by searching the web for your specific operating system. There are many reliable step‑by‑step guides available for Windows, Linux, and macOS that explain how to download, install, and verify OpenSSL properly. Following an up‑to‑date guide for your OS will help ensure the installation is completed correctly and securely.   Preparation Select a folder where all keys and certificates will be stored. Open a command prompt in this folder and proceed with the following steps.   Create Keys NOTE: Please replace %%Name%% according to your preference. Create a private key for the Server Certificate openssl genrsa -out %%KeyName%%.key 2048 Create a private key to simulate Certificate Authority (CA) openssl genrsa -out %%CAKeyName%%.key 2048 Create Certificate Authority Generate a self-signed CA certificate: openssl req -x509 -new -nodes -key %%CAKeyName%%.key -sha256 -days 3650 -out %%CAName%%.crt Create Server Certificate Config file to request certificate Create a configuration file named %%ConfigFileName%%.cnf using the following template, this can be created with Notepad. [req] default_bits = 2048 prompt = no distinguished_name = dn req_extensions = v3_req [dn] C=%%Country%% ST=%%State%% L=%%City%% O=%%Owner%% OU=%%Division%% CN=%%CommonName%% [v3_req] subjectAltName = @alt_names [alt_names] IP.1 = %%ServerIP%% Generate Certificate Signing Request (CSR) openssl req -new -key %%KeyName%%.key -out %%CertificateRequestName%%.csr -config %%ConfigFileName%%.cnf Sign Certificate with simulated CA openssl x509 -req -in %%CertificateRequestName%%.csr -CA %%CAName%%.crt -CAkey %%CAKeyName%%.key -CAcreateserial -out %%CertificateName%%.crt -days 365 -extensions v3_req -extfile %%ConfigFileName%%.cnf Prepare to use with mbedTLS Convert private Key to DER (Distinguished Encoding Rules) openssl rsa -in %%KeyName%%.key -outform DER -out %%KeyName%%_key.der Convert Certificate to DER (Distinguished Encoding Rules) openssl x509 -in %%CertificateName%%.crt -outform DER -out %%CertificateName%%.der Convert Key DER to array in a source file xxd -i %%KeyName%%_key.der > %%KeyName%%_key.c Convert Certificate DER to array in a source file xxd -i %%CertificateName%%.der > %%CertificateName%%_cert.c Install CA Certificate (Optional – Avoid Browser Warnings) To prevent browser warnings, install the CA certificate on the client device (PC, phone, etc.). Double-click the CA certificate file (.crt). Click Install Certificate. Select Local Machine. Choose Place all certificates in the following store. Click Browse and select Trusted Root Certification Authorities. Click Next → Finish. After this step, the system will trust certificates signed by this CA.