Segmentation fault when using ReadPipeUIntArray via Python Hi, I am running into issues currently where I want to use a pipe to stream data packets (header+payload) from target to host. When using ReadPipeUIntArray to read the binary data I am running into fmlite crashes frequently. I attached a python example and fmlite output as reference. Thanks in advance Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, We are looking into this issue and will get back to you once we have an update. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @tschue-nxt, Could you check the attached fmlite binary and let us know if it works in your case. Re: Segmentation fault when using ReadPipeUIntArray via Python Hi @iulian_stan, looks good, working smoothly for quite some minutes now. Thanks for the fast fix!

Wi-FiチップセットMCU制御 こんにちは、みんな、 AP+STA機能を備えたWi-Fiモジュールを探していました。例えば、NXP、Microchip、Infineonなどのモジュールを見つけました。しかし、ほとんどのモジュールはPCIe経由でWiFiインターフェースを使えず、高度なOSでしか対応していません。 しかし、InfineonのAIROC CYW55X(シリーズ)というMCU+WiFiモジュールのセットを見つけました。 こういったタイプのモジュールの統合や制御に関する経験はありますか？もしそうなら、これまでに使っていて外部MCUとうまく統合できた他のモジュールを教えてもらえますか?私の意図は、データをマイクロコントローラにオフロードするのではなく、例えばメッシュやAPの機能を制御することです。 Wi-Fiモジュールを制御しながら基本的なAIモデルに対して推論を行うために、MCU(例えばSTM)を使っています。 ありがとう、みんな Re: Wi-Fi Chipset MCU Control @ajihu様、 あなたの説明からすると、特に基本的なAIモデルを動かすなら、RW61X(RW610/RW611/RW612)で十分かもしれません。 RW61Xは以下の積分を行います: - MCU - Wi-Fi - Bluetooth LE - (RW612は802.15.4 / Threadもサポート) 基本的なAI推論ワークロードにおいては、RW61Xはアプリケーションとワイヤレス・コネクティビティ・スタックの両方を1台のデバイス上で実行できるため、追加のMCUを不要にする可能性もあります。 しかし、「メッシュ」という言葉が何を意味するのかを明確にすることが重要です。 RW61Xは以下をサポートしていません: - IEEE 802.11s メッシュ - イージーメッシュ RW61Xは以下をサポートしています: - マター - Thread - ZigBee(802.15.4エコシステム経由) - STA + uAP 同時接続モード [注] 追加のAIプロセッシング性能が必要な場合は、以下のことを検討できます: - i.MX RT700 + IW61X - i.MX RT1170 + IW61X - i.MX RT1180 + IW61X これらのソリューションは以下もサポートしていませんのでご注意ください: - IEEE 802.11s メッシュ - イージーメッシュ 彼らは以下のサポート: - マター - Thread - ZigBee - STA + uAP 同時接続モード よろしくお願いします！ よろしくお願いいたします。 維東

HMAC検証ジョブのリクエスト時にHSEが「HSE_SRV_RSP_INVALID_PARAM」を返す NXPチームの皆様、こんにちは。 HMACのVerifyジョブを使うユースケースがあります。ジョブ暗号ドライバーをトリガーした後、DETを投げると、HSEからの返答は「HSE_SRV_RSP_INVALID_PARAM」でした。 現在の設定のどこが間違っているのか理解できません。添付されたconfig zipファイルを確認していただけますか? 問題解決のためのサポートが必要です。 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @lukaszadrapa さん。 詳細： デバイス: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 どのデバイス、どのRTD、どのHSEファームウェアバージョンを使っているか確認していただけますか? よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 設定に問題はありません。 私の環境では問題なく動作しています。しかし、タグの長さ(secondaryInputLength)が一つの問題かもしれません。 これは関数Crypto_Ipw_HmacVerifyで確認できます: lukaszadrapa_0-1784036699903.png リダイレクトが無効になっている場合は、タグの長さをバイト単位ではなくビット単位で指定する必要があります。これこそが問題なのではないですか？ よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、ルーカスさん。 返信が遅くなり申し訳ありません。 はい、タグの長さはビット単位で指定します。私の環境でも問題なく動作します。 ありがとう！ よろしくお願いします、 アディティヤ

S32K358マルチコアデータ共有 こんにちは 、 私はs32k358マルチコアで共有メモリを使用しようとしています。 私はユーザー定義の例に従っています。 buzzer_state_shared_data_U32で値を割り当てようとすると(現在はコア0のみがこのメモリにアクセスしています)、コア0がハングし、SWTがコントローラーをリセットします。 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 フラッシュ中は正常に動作するのに、電源のオンオフでは動作しないのはなぜですか？ nirmal_masilamani_0-1783316750067.png Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 迅速なご対応ありがとうございます。 起動ファイルを確認したところ、SRAMの初期化が実行されている。 起動ファイルとリンカーファイルを添付しました。この問題を解決するために、ぜひ私をサポートしてください Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 これはおそらくECC RAMのエラーが原因です。通常、デバッガは揮発性メモリ上でECCを初期化しますが、電源オン・オフ時にRAMを初期化せず、メモリへのアクセス時にハードフォールトが発生します。 これは通常、メイン関数の前に実行される起動コード内で行われます。 このセクションはキャッシュ不可に設定する必要があります。 2つ目の問題についてですが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 ハードフォルトを遡って追跡してみることもできます。HardFault_Handler()でコアを停止し、コアレジスタでSP値を見つけます:How To Debug A Fault Exception On ARM Cortex-M(V7M) MCU(S32K3XX)。 よろしくお願いします、 ジュリアン Re: S32K358 multi core data sharing こんにちは、 main()で共有メモリにアクセスすると、電源オフ・オンでも問題なく動作しますが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 どうか私をサポートしてください。 Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 この質問についてサポートしてください。私が何か見落としているのでしょうか？ Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 PORリセット後にデバッガなしでmain()の共有メモリにアクセスできますか?問題はRAMの初期化だったのでしょうか？ しかし、タイマー、ISR、OSタスクからアクセスしようとすると、コア0がハードフォールトに切り替わります。 前回の返信でお伝えしたように、故障の種類を特定できましたか？ 変数がキャッシュされない領域に配置されているか、またはキャッシュが無効になっていることを確認しましたか？ 提案として： core1Status を揮発性のままにしておき、読み取り側 (Core0) と書き込み側 (Core1) の両方で__DMB()/__ DSB() バリアを使用します。 問題がMPU設定が原因かもしれません。もし定義MPU_ENABLEなら、ISRやOSタスクが実行される前にMPU設定を呼び出してください。 以下のリンクを参照してください:Arm Cortex-M7 デバイス汎用ユーザーガイド r1p2 & AN14715: S32K3XX ハードウェアリソースのアイソレータと保護。 よろしくお願いします、 ジュリアン Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 ご回答ありがとうございます。 残念ながら、これ以上続けることができませんでした。いただいたご指摘を確認させていただきます。

当请求 HMAC 验证作业时，HSE 返回“HSE_SRV_RSP_INVALID_PARAM” 您好，NXP团队， 我有一个使用 HMAC 验证作业的用例。触发作业加密驱动程序后抛出 DET，HSE 的响应为“HSE_SRV_RSP_INVALID_PARAM”。 我无法理解我当前的配置出了什么问题。请查收附件中的配置文件压缩包。 需要技术支持来解决问题。 谢谢！ 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@lukaszadrapa ， 细节： 设备：S32K311 HSE固件：HSE_FW_S32K311_0_2_55_0 RTD：SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 谢谢！ 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@WagdeoA 请问您能否确认一下您使用的是哪款设备、哪款RTD以及哪款HSE固件版本？ 此致， Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@WagdeoA 您的配置没有问题。 在我这边运行正常。但一个可能的问题可能是标签的长度（secondaryInputLength）。 这可以在函数 Crypto_Ipw_HmacVerify 中找到： lukaszadrapa_0-1784036699903.png 如果重定向被禁用，则必须以比特为单位提供标签长度，而不是以字节为单位。难道这不是问题所在吗？ 此致， Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨，卢卡斯， 抱歉回复晚了。 是的，标签长度以比特为单位。我这边也运行正常。 谢谢你！ 此致， 阿迪亚

FS26 Reset issue Hi Team, We are facing a reset issue in the SBC section. During initial testing, I assembled only the NXP Semiconductors MFS2633HMDB2AD SBC section and checked the reset output. The reset line was HIGH, and the IC was working properly. After assembling the MCU and other related components, the PMIC reset line is always LOW, and all associated reset signals are being pulled LOW. When I connect the JTAG debugger, the reset line becomes HIGH and the system enters debug mode successfully. Additional observations: Removed  MCU reset line using a 0Ω resistor. MCU reset line is HIGH. PMIC reset line remains LOW. FS26 is working correctly in debug mode. Without JTAG connection, the PMIC reset output remains LOW. It appears that the issue occurs only after MCU integration. The SBC section works correctly when tested independently, but after MCU connection, the PMIC reset sequence is not releasing. Thanks. Re: FS26 Reset issue Hi Guoweisun, The FS26 is operating in Debug mode, and all the power outputs (LDOs and VCORE) are present and within the expected range. However, the RESET line is still not going HIGH. Our application includes an external watchdog, so we removed it from the circuit and tested again. Even after removing the external watchdog, the RESET line remains LOW. Could you please let us know what other conditions could prevent the RESET line from being released or what additional checks we should perform? Thank you. Re: FS26 Reset issue The FCCU1 and FCCU2 pins are connected with the recommended pull-up and pull-down resistors. Should we leave these connections as they are, or do you recommend isolating the FCCU pins from the MCU as well for debugging? Re: FS26 Reset issue guoweisun_0-1784527719465.png In the INIT phase setting as above circled. Re: FS26 Reset issue We ḥave checked the pins FCC 1 & 2 pin  are low still the reset line is not released high Re: FS26 Reset issue Since in debug mode still RSTB pull low which is not related with WD. Please try to disable FCCU function in INIT phase to test it again. Re: FS26 Reset issue Hi Please Confirm whether there is some error for WD refresh and the power rails UV/OV. Re: FS26 Reset issue According my last reply to disable this FCCU function in the INIT phase of SBC to test again.

MCXN547:SWD DP IDは読み取れるが、AP0/AP2アクセスはWIRE ACKフォルトを返す こんにちは、NXPサポートの皆さん、 カスタムボード上のMCXN547VKLTと外部のMCU-Linkプローブを使用しています。 デバッグセッションを開始する際にSWD接続が失敗する： Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. SWD-DPは正しく検出できます: DPID = 0x6BA02477 しかし、CPU0 AHB-AP(AP0)へのアクセスは以下の場合に失敗します: WIRE ACK FAULT デバッグ用メールボックスのリクエストも失敗します。LinkServer のレポート: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 確認した内容： SWD周波数は1MHzから10kHzまでテスト済み。 SWDIOとSWCLKの波形はオシロスコープ上で良好に見える。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDCおよびI/O電源 = 3.3V RESET_Bは正しく動作します MCU-Linkファームウェア:CMSIS-DAP V3.172 LinkServer バージョン: 26.5.59 同じMCU-LinkはMCXN947開発ボードで動作します MCXN547は新しいチップに交換されたが、問題は解決していない。 USB ISPはVID/PID 1FC9:014Fで正しく動作します。blhostを使えば、以下ができます: 内部フラッシュを消す 内部フラッシュのプログラムと読み取り アプリケーションを正常に実行してください アプリケーションのUSBコンポジットデバイスを列挙します ROMの報告によると、 Security State = UNSECURE USB ISP経由でPFRも読み取りました。 CMPAは完全に消去されました（0xFF） CFPAはROMで生成されたCMACを除いて消去されます。 お客様向けのSOCUやデバッグ認証の設定は存在しません 何かアドバイスをいただけますか: AP0とAP2が利用可能になるには、どのような条件が必要ですか？ DM-APステータス0x60F93638は、既知の電源、リセット、またはハードウェア構成の問題に関連していますか？ SWDやDebug Mailboxへのアクセスに関する既知のMCXN547エラタはありますか? この症状を確認するには、どの電源信号とリセット信号をチェックすればよいでしょうか？ MCX N Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT こんにちは、ルイスさん。 SPSDKデバッグメールボックスツールを使用して、SWDデバッグ接続を確立することができました。 私たちが用いた手順は以下のとおりです。 1. デバッグメールボックスを通じてMCUをリセットする: NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ ツールリセット -f mcxn547 2. デバッグメールボックスからデバッグセッションを開始します。 NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ cmd -f mcxn547 start-debug-session 3. デバッグセッションが開かれた後、SWD経由でLinkServerを使ってCortex-M33コアに接続します。 認証キー、パスワード、デバッグ認証情報、一括消去コマンドは一切使用しませんでした。「start-debug-session」コマンドは、常時アクセス可能なAP2デバッグメールボックスを介して、一時的にAP0を有効にするようです。 デバッグセッションを開いた後、NXP LS_preconnect_MCXN5XX.scpスクリプトからGDETレジスタシーケンスも使用しました。このシーケンスは、デバッグ中にaGDETおよびdGDETのリセットルーティングを無効にし、SPCグリッチ検出を無効にします。 電源装置に関して： - VDD_VBATはVDDに直接接続されており、どちらも3.3Vです。 - VDD_P4はVDDに直接接続されており、どちらも3.3Vです。 - VDD_ANAはフェライトビーズを介してVDDに接続されています。 - VDDは3.3Vです。 しかし、今度は別のデバッグ問題が発生しました。 SWDデバッグリセットを行わずにボードを通常通り電源投入した場合、ファームウェアは正しく動作します。しかし、上記のデバッグメールボックスリセット手順を使用してデバッグセッションに入ると、ファームウェアが正しく起動しません。 以下のSDK関数をシングルステップで実行するとデバッグ接続が失われます。 static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_タイプ *ベース、 spc_dcdc_voltage_level_t voltageLevel) ヤージュ base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } より具体的に言うと、アクティブモードのDCDC電圧レベルを変更するためにACTIVE_CFGが書き込まれると、接続が失われます。 したがって、以下の2つの場合で挙動が異なります。 1. 電源投入時の冷間状態： ファームウェアは正常に起動し、正常に動作します。 2. デバッグ:メールボックスリセット、続いて開始・デバッグセッションおよびSWD接続: ファームウェアはSPC DCDC構成に到達しますが、ACTIVE_CFGが書き込まれるとデバッガはターゲットを失い、アプリケーションは通常起動できません。 デバッグメールボックスのリセットが、完全な電源オンリセットと異なる状態にしてしまいますか? デバッグメールボックスのデバッグセッションを開始した後、SPC ACTIVE_CFGを変更する前に、必要な手順はありますか？例えば： - SPC_SC[BUSY]がクリアされるのを待っています。 - SPCまたはGDETステータスフラグをクリアする。 - グリッチ検出のロック解除または無効化。 - 特定のリセットタイプを使用する。 - デバッグセッション開始後のソフトリセットを回避する。 または、LS_preconnect_MCXN5XX.scp シーケンス全体を適用する？ デバッグ中にDCDC電圧レベルを書き込むと、GDETイベント、DCDC保護イベント、ブラウンアウトリセット、または別のシステムリセットがトリガーされる可能性はありますか? ACTIVE_CFG書き込みの直前に取得すべきレジスタについてもご教示ください。SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS、そしてデバッグメールボックスCSWなどのレジスタの値を提供できます。 よろしくお願いいたします。 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT これは難しい問題だ！接続問題のデバッグは特にカスタムボードの場合非常にフラストレーションが溜まります。その「WIRE ACK FAULT」は、間違いなく通信障害を示しています。異なるSWDクロック速度を試したり、デバッグセッション中にMCUの電源を確認したりしてみましたか?時には限界的な電力供給がこのような断続的な故障を引き起こすことがあります。これは Snow Rider 3D で完璧なランを狙うような感覚を少し思い出させます。ほんの小さなミスで全てが狂ってしまうこともあります!早く真相が解明されることを願っています！

FS26 RESET 问题 大家好， 我们在SBC部分遇到了RESET问题。 在初步测试期间，我只组装了 NXP Semiconductors MFS2633HMDB2AD SBC 部分，并检查了 RESET 输出。RESET 线为高电平，集成电路工作正常。 组装好 MCU 和其他相关组件后，PMIC RESET 线始终为低电平，所有相关的 RESET 信号都被拉低。 连接 JTAG 调试器后，复位线变为高电平，系统成功进入调试模式。 补充说明： 使用 0Ω 电阻移除 MCU RESET 线。 MCU RESET line is HIGH. PMIC RESET 线保持低电平。 FS26 在调试模式下运行正常。 如果没有 JTAG 连接，PMIC RESET 输出将保持低电平。 这个问题似乎只在MCU集成后才会出现。单独测试时，SBC 部分工作正常，但连接 MCU 后，PMIC RESET 序列无法释放。 谢谢。 Re: FS26 Reset issue 郭伟孙您好， FS26 处于调试模式，所有电源输出（LDO 和 VCORE）均存在且在预期范围内。然而，RESET 线仍然没有变为高电平。 我们的应用程序包含一个外部看门狗，所以我们将其从电路中移除并再次进行了测试。即使移除外部看门狗，RESET 线仍然保持低电平。 请问还有哪些情况可能导致 RESET 线无法释放？或者我们应该进行哪些额外的检查？ 谢谢！ Re: FS26 Reset issue guoweisun_0-1784527719465.png 在 INIT 阶段设置如上圈出的部分。 Re: FS26 Reset issue FCCU1 和 FCCU2 引脚分别连接推荐的上拉电阻和下拉电阻。我们应该保持这些连接不变，还是建议为了调试也把 FCCU 引脚与 MCU 隔离？ Re: FS26 Reset issue 因为在调试模式下 RSTB 仍然拉低，这与 WD 无关。 请尝试在初始化阶段禁用 FCCU 功能，然后再进行测试。 Re: FS26 Reset issue HI 请确认 WD 刷新和电源轨 UV/OV 是否存在错误。 Re: FS26 Reset issue 我们已检查过 FCC 1 和 2 引脚，它们均为低电平，但 RESET 线仍未释放。 Re: FS26 Reset issue 根据我上次的回复，需要在 SBC 的 INIT 阶段禁用此 FCCU 功能以再次进行测试。

MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello NXP Support, We are using an MCXN547VKLT on a custom board with an external MCU-Link probe. The SWD connection fails when starting a debug session: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. The SWD-DP can be detected correctly: DPID = 0x6BA02477 However, access to CPU0 AHB-AP (AP0) fails with: WIRE ACK FAULT The Debug Mailbox request also fails. LinkServer reports: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR What we have checked: SWD frequency tested from 1 MHz down to 10 kHz SWDIO and SWCLK waveforms look good on an oscilloscope VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC and I/O supplies = 3.3 V RESET_B works correctly MCU-Link firmware: CMSIS-DAP V3.172 LinkServer version: 26.5.59 The same MCU-Link works with an MCXN947 development board The MCXN547 was replaced with a new chip, but the problem remains USB ISP works correctly with VID/PID 1FC9:014F. Using blhost, we can: Erase internal Flash Program and read internal Flash Run the application successfully Enumerate the application USB composite device The ROM reports: Security State = UNSECURE We also read the PFR through USB ISP: CMPA is completely erased (0xFF) CFPA is erased except for the ROM-generated CMAC No customer SOCU or Debug Authentication configuration is present Could you please advise: What conditions are required before AP0 and AP2 become accessible? Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue? Are there any known MCXN547 errata related to SWD or Debug Mailbox access? Which power and reset signals should we check for this symptom? MCXN Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello Luis, We have now been able to establish an SWD debug connection by using the SPSDK Debug Mailbox tool. The procedure we used is as follows: 1. Reset the MCU through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ tool reset -f mcxn547 2. Start a debug session through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. After the debug session has been opened, we connect to the Cortex-M33 core with LinkServer over SWD. We did not use any authentication keys, passwords, debug credentials, or mass erase commands. It appears that the "start-debug-session" command temporarily enables AP0 through the always-accessible AP2 Debug Mailbox. We also used the GDET register sequence from the NXP LS_preconnect_MCXN5XX.scp script after opening the debug session. The sequence disables the aGDET and dGDET reset routing and disables SPC glitch detection during debugging. Regarding the power supplies: - VDD_VBAT is directly connected to VDD, and both are 3.3 V. - VDD_P4 is directly connected to VDD, and both are 3.3 V. - VDD_ANA is connected to VDD through a ferrite bead. - VDD is 3.3 V. However, we now have another debugging problem. When the board is powered on normally without an SWD debug reset, the firmware runs correctly. However, when we enter the debug session using the Debug Mailbox reset procedure described above, the firmware does not start correctly. The debug connection is lost when single-stepping through the following SDK function: static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base, spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } More specifically, the connection is lost when ACTIVE_CFG is written to change the active-mode DCDC voltage level. The behavior is therefore different between the following two cases: 1. Cold power-on: The firmware starts and runs normally. 2. Debug Mailbox reset followed by start-debug-session and SWD connection: The firmware reaches the SPC DCDC configuration, but the debugger loses the target when ACTIVE_CFG is written, and the application cannot start normally. Could the Debug Mailbox reset leave the SPC, DCDC, GDET, or reset status in a different state compared with a full power-on reset? Is there a required sequence before modifying SPC ACTIVE_CFG after starting a Debug Mailbox debug session? For example: - waiting for SPC_SC[BUSY] to clear; - clearing an SPC or GDET status flag; - unlocking or disabling glitch detection; - using a specific reset type; - avoiding a soft reset after start-debug-session; - or applying the complete LS_preconnect_MCXN5XX.scp sequence? Could writing the DCDC voltage level while debugging trigger a GDET event, DCDC protection event, brownout reset, or another system reset? Please also advise which registers we should capture immediately before the ACTIVE_CFG write. We can provide values for registers such as SPC_SC, SPC_CNTRL, SPC_ACTIVE_CFG, SPC_GLITCH_DETECT_SC, CMC_SRS, CMC_SSRS, and the Debug Mailbox CSW. Best Regards, Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT This is a tough one! Debugging connection issues can be really frustrating, especially with custom boards. That "WIRE ACK FAULT" definitely points to a communication breakdown. Have you had any luck trying different SWD clock speeds, or perhaps checking the power supply to the MCU during the debug session? Sometimes a marginal power delivery can cause these kinds of intermittent failures. It reminds me a bit of trying to get a perfect run in Snow Rider 3D – one small misstep can throw everything off! I hope you get to the bottom of it soon!

SW32K14-MCAL421-RTMC-1.0.1 ダウンロードへのアクセスを有効にするリクエスト こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1のダウンロード アクセスをリクエストします。 現在、NXP ソフトウェア ライセンス ページの [前へ] タブがグレー表示されており、このバージョンにアクセスできません。 私のアカウントのユーザー名はChefanqfです。 このバージョンは、 S32K14x MCAL 4.2に基づく既存のプロジェクトとの互換性を保つために必要です。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは@Chefanqf 、 NXP.com (検索 | NXP Semiconductors) で「S32K1 MCAL」を検索し、次のように flexera と入力してみてはいかがでしょうか。 Snag_1f0587dc.png この後、「オートモーティブ SW - AUTOSAR MCAL / QM」を選択すると、以前のソフトウェアが利用できるようになります。 「前へ」タブがまだグレー表示されている場合、直接リンク： SW32K14-MCAL421-RTMC-1.0.1 から入力してみてください。直接リンクを使用する場合は、nxp.com にログインしていることを確認してください。 よろしくお願いします、 ジュリアン Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1 のダウンロードアクセスをお願いしたいです。 現在、NXPソフトウェアライセンスページの「前回」タブが グレーアウト 表示され このバージョンにアクセスできません。 私のアカウントのユーザー名はmianlongxuです。 このバージョンは、既存のプロジェクトとの互換性のために必要です。 S32K14x MCAL 4.2 。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、 @mianlongxu さん。 サポートチケットを入力してください:NXPサポート。 よろしくお願いします、 ジュリアン

[S32K3] [RTD 7.0.1] Three Issues in the BCTU Module I have found three problems with the BCTU module in the RTD code version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. The detailed issues are listed below:   Issue 1: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1558, the current code uses bitwise OR assignment: BctuBasePtr->FIFOERR |= FifoWatermarkMask; It should be modified to direct assignment: BctuBasePtr->FIFOERR = FifoWatermarkMask;   Issue 2: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, lines 567 and 568, the existing code contains incorrect bit shift operations. The original code is shown below: ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << Index) : 0U; These two lines should be revised to the correct shift logic as follows: ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (Index * 2u)) : 0U;   Issue 3: There is a type inconsistency alignment issue between the MCAL/SDK code generation tools and the static source code of the BCTU module. In the MCAL generated code (Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m, line 2397), the arrays defined in both header and C files uniformly adopt the uint32 type. In the SDK generated code, the type definition is inconsistent between header and C files: the array type in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h (line 249) switches between uint16 and uint32 depending on whether the BctuFifoDmaRawData option is enabled, while the corresponding array in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c (line 317) is fixed as uint32 type. In the static code (Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1629), the transmission length (2-byte or 4-byte) is determined dynamically based on the BctuFifoDmaRawData configuration. All the following abnormal problems occur when theBctuFifoDmaRawData option is unchecked: 1. For SDK projects: The mismatched array types between header and C files cause direct compilation failures. 2. For MCAL projects: Although compilation can succeed, the fixed uint32 array definition leads to half of the memory space being wasted. Besides, each uint32 data unit contains two ADC results, requiring manual splitting of high and low uint16 values during data parsing. The above three bugs exist in the official version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. We hope NXP software engineers can fix these BCTU module defects in the next RTD release. Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module Hi@chenwilsoft Your question has been escalated to the internal forum and is awaiting confirmation from the design team. Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module Hi@chenwilsoft Thank you for your feedback. The software team and I have confirmed these issues, they are indeed bugs. We have escalated these issues internally and will fix them in a future update.

在 FRDM-K64F 上使用 MCUxpresso 25.6 时出现未定义的 SD 卡符号 我想在我的项目中使用 SD 卡来加载双向无线电系统的个人个性化数据。我收到 #include "tx_api.h"并且 #include "tx_event_flags.h" 未定义。 这是因为我没有在 SDK 中包含 Azure RTOS。 我尝试使用“管理 SDK 组件”将 Azure 安装到 SDK 中来解决这个问题，但显然 Azure RTOS 支持在 2.11 版本中被取消了，而我在发现这个问题之前已经为项目加载了该版本。 所以我在线创建了一个新的 SDK，但为了获得 Azure 支持，它又降级到了 2.10 版本。但是，当我尝试更改项目的 SDK 时，它不允许我删除我已有的 SDK，当我尝试添加另一个 SDK 时，它告诉我 SDK 2.x_FRDM-K64F 已经存在。 我如何获得 Azure 支持？我只需要它来访问SD卡！ Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 你好@ve3id ， 感谢你的帖子。 提醒一下，在 FRDM-K64F 上，SDK 已经提供了基于 SDHC + FatFs 的 SD 卡文件系统示例，而 FatFs 可以在裸机模式下运行，无需 RTOS。FRDM-K64F SDK 示例包括 frdmk64f_driver_examples_sdcard_fatfs / fatfs_sdcard 风格的项目，用于挂载 SD 卡并执行目录/文件读写操作。 如果您仍然想要 Azure RTOS，对于“SDK 2.x_FRDM-K64F 已存在”的问题，这意味着 IDE 中已经安装了具有该身份的 SDK。MCUXpresso IDE 支持从该视图中删除已安装的 SDK 包。请参考下图进行卸载。 Celeste_Liu_0-1784529590904.png 之后，您可以再次尝试安装 SDK v2.10。 希望对您有所帮助。如果您还有其他问题，请告诉我。 BR 塞莱斯特 Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 谢谢你，塞莱斯特。从文献中并没有明确看出情况确实如此。不过，我已经通过将我的代码复制粘贴到示例中解决了这个问题，现在正在处理下一个问题，即挂载后尝试读取目录时返回零！ 干杯 奈杰尔 Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 你好@ve3id ， 不客气，很高兴能帮到您！ 如有任何新问题，请随时发帖提问。 BR 塞莱斯特

Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F I want to use an SD card in my project to load individual personalisation data fpor a two-way radio system.   I am getting #include "tx_api.h" and #include "tx_event_flags.h" as not defined. This is due to the fact that I did not include azure rtos in the SDK. I try to overcome this by installing azure into the SDK using 'manage sdk components', but I apparently azure rtos support was dropped in 2.11, which I loaded for the project before I saw this problem. So I created a new SDK online, but it drops back to 2.10 to get azure support.  However when I try to change the SDK for my project, it will not let me remove the SDK I have, and when I try to add another one it tells me that SDK 2.x_FRDM-K64F already exists. How can I get azure support.  I only need it for SD card access! Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Thank you Celeste.  It was not clear from the literature that such was the case.  However I have solved the problem by cutting and pasting my code into the example and have moved on, working on the next problem now which is the fact that it returns zero when trying to read the directory after mounting! Cheers Nigel Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hello @ve3id , Thanks for your post. Just a reminder, on FRDM-K64F, the SDK already provides SD card file-system examples based on SDHC + FatFs , and FatFs can run in bare-metal mode without an RTOS, the FRDM-K64F SDK examples include frdmk64f_driver_examples_sdcard_fatfs / fatfs_sdcard style projects for mounting an SD card and doing directory/file read-write operations. If you still want Azure RTOS, for the “SDK 2.x_FRDM-K64F already exists” issue, this means the IDE already has an SDK with that identity installed. MCUXpresso IDE supports deleting installed SDK packages from that view. Please refer to below picture to uninstall. Celeste_Liu_0-1784529590904.png After that, you can try to install SDK v2.10 again. Hope it helps. Please let me know if you have any other questions. BR Celeste Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hello @ve3id , You are welcome, glad to help! Any new questions, please feel free to create a new post. BR Celeste

Wi-Fi芯片组MCU控制 大家好， 我正在寻找一些具有 AP+STA 功能的 Wi-Fi 模块。例如，我找到了一些来自恩智浦半导体（NXP）、微芯科技（Microchip）和英飞凌科技（Infineon）的模块。然而，大多数模块仅通过 PCIe 和高级操作系统启用 wifi 接口。 不过，我找到了一套来自英飞凌的名为 AIROC CYW55X（系列）的 MCU+Wifi 模块。 您在集成和控制这类模块方面有经验吗？如果可以的话，您能否分享一下您之前使用过并成功与外部MCU集成的不同模块？我的目的不是将数据卸载到微控制器，而只是为了控制例如网状网络和接入点功能。 我想使用 MCU（例如 STM）对一些基本的 AI 模型进行一些推理，同时控制 wifi 模块。 谢谢大家 Re: Wi-Fi Chipset MCU Control 亲爱的@ajihu ， 根据您的描述，特别是对于运行基本 AI 模型而言，RW61X（RW610/RW611/RW612）可能已经足以满足您的应用需求。 RW61X 集成了： - MCU - 无线上网 - 低功耗蓝牙 - （RW612 也支持 802.15.4 / Thread） 对于基本的 AI 推理工作负载，RW61X 可以在单个设备上运行应用程序和无线连接协议栈，从而可能无需额外的 MCU。 但是，有必要澄清一下您所说的“网状物”是什么意思。 RW61X 不支持： - IEEE 802.11s 网状网络 - EasyMesh RW61X 支持： - 事情 - 线 - Zigbee（通过 802.15.4 生态系统） - STA + uAP 并发模式 [注意] 如果需要额外的AI处理性能，您可以考虑： - i.MX RT700 + IW61X - i.MX RT1170 + IW61X - i.MX RT1180 + IW61X 请注意，这些解决方案也不支持： - IEEE 802.11s 网状网络 - EasyMesh 他们支持： - 事情 - 线 Zigbee - STA + uAP 并发模式 谢谢您！ 顺祝商祺！ 卫东

S32K358 multi core data sharing Hello , I am trying to use shared memory in s32k358 multi core. I am following user define example,  When i try to assign some value in buzzer_state_shared_data_U32 ( currently only core 0 is accessing this memory), core 0 is hanging and swt resetting the controller. But when i flash the code in debug flash, its running properly. With power on reset, core 0 is hanging.  Why its running properly in when flashing and not running in power off and on. nirmal_masilamani_0-1783316750067.png Re: S32K358 multi core data sharing Hello @Julián_AragónM , Thank you for your quick response, I check the startup files, SRAM Init is happening. I have attached my startup files and linker files. Please support me to resolve this issue Re: S32K358 multi core data sharing Hello @nirmal_masilamani, But when i flash the code in debug flash, its running properly. With power on reset, core 0 is hanging.  This is most likely caused by ECC RAM error. Usually, debuggers initialize the ECC on volatile memories, however, when powering on and off, debugger does not initialize RAM, and hardfault occurs when trying to access memory. This is usually done in the startup code, before main. The section should be also configured as non-cacheable. Regarding your second issue: but when i try to access it from timer ISR or OS task, core 0 going to hardfault. You can try to trace back your hardfault. Halt the core in the HardFault_Handler(), and find the SP value in the core registers: How To Debug A Fault Exception On ARM Cortex-M(V7M) MCU(S32K3XX). Best regards, Julián Re: S32K358 multi core data sharing Hello, When i access shared memory in main(), its working fine even in power off and on, but when i try to access it from timer ISR or OS task, core 0 going to hardfault. Please support me in this. Re: S32K358 multi core data sharing Hello @Julián_AragónM , Please support on this query. What i am missing here? Re: S32K358 multi core data sharing Hello @nirmal_masilamani, Are you able to access shared memory in main() after POR reset without debugger? Was the issue RAM initialization? but when i try to access it from timer ISR or OS task, core 0 going to hardfault. Were you able to identify the fault type as I mentioned in my previous reply? Have you also made sure the variable is placed in a non-cacheable area, or the cache is disabled? As suggestions: Keep volatile on core1Status and use __DMB()/__DSB() barriers on both the read (Core0) and write (Core1) sides. Your issue could also be caused by MPU configuration, if MPU_ENABLE is defined, please call the MPU config before any ISR or OS task starts executing. You can refer to the following links: Arm Cortex-M7 Devices Generic User Guide r1p2 & AN14715: S32K3XX Hardware Resource Isolation and Protection. Best regards, Julián Re: S32K358 multi core data sharing Hello @Julián_AragónM , Thank you for your response, Unfortunately, i was unable to continue on this, I will check your points.

HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hello Nxp team, I have use case to use HMAC verify job. After triggering the job crypto driver throw DET and the response from HSE is "HSE_SRV_RSP_INVALID_PARAM". I am not able to understand what wrong with my current configuration. could you please check attached config zip file?  Need support to resolve issue. Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @lukaszadrapa , Details: Device: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  Could you confirm which device, which RTD and which HSE firmware version you have? Regards, Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  There’s no problem in your configuration. It works on my side. But one possible issue could be the length of tag (secondaryInputLength). This can be found in function Crypto_Ipw_HmacVerify: lukaszadrapa_0-1784036699903.png If redirection is disabled, it’s necessary to provide the length of tag in bits, not in bytes. Isn’t this the problem? Regards, Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi Lukas, Sorry for late reply. Yes, with length of tag in bits. It works at myside as well. Thank you! Best Regards, Aditya

Zone Node Software & Hardware Environment 1 Table of Contents • Introduction • Required Software • Required Hardware • References • Conclusion 2 Introduction This article is part of the Zone Node series and describes the software and hardware environment used throughout the project. The purpose of this article is to describe the software and hardware setup required to follow the series and reproduce the results. Before examining communication routing, control logic, or integration challenges, it is important to understand the tools and platforms that support the development and execution of the zonal node application. This article introduces the software components used to develop, configure, and deploy the application, as well as the hardware platforms used to demonstrate the zonal controller functionality. This information provides the foundation required for the remaining articles in the series. Overview of the development flow The zonal node application presented in this series is developed using a combination of Model-Based Design tools, NXP software components, and automotive-grade hardware platforms. At a high level: Application modeling starts in MATLAB® and Simulink®, where communication routing and control logic are implemented graphically. Code generation converts the model into production-ready embedded software using the code-generation tools provided by MathWorks and NXP. Deployment compiles the generated software and loads it onto the target hardware, where it is used to demonstrate communication between multiple vehicle networks. This environment was selected to support rapid development, easier validation, and improved traceability between model design and generated software. By using a Model-Based Design approach, algorithm development, communication integration, and application verification can be performed within a common framework. The software and hardware presented here are used consistently throughout the series and will be referenced when discussing communication routing, system behavior, and integration scenarios. dragostoma_0-1784698703294.png Figure 1. Development flow diagram The workflow begins with application development in Simulink. Communication routing logic, control functions, and software configuration are implemented within the model. The NXP Model-Based Design Toolbox (MBDT) provides hardware-specific blocks that enable integration with S32K3 peripherals and communication interfaces. Following code generation, the application is compiled and deployed to the target hardware, where communication routing functionality can be validated. This article is intended for: Engineers interested in reproducing the zonal node demonstration Simulink users developing automotive communication applications Developers evaluating Model-Based Design workflows Engineers working with NXP automotive microcontrollers and evaluation boards By understanding the software and hardware environment early in the series, readers will be better prepared to follow the implementation details presented in subsequent articles. 3 Required Software The following software components are used throughout the project: MATLAB® and Simulink® – model development and simulation Embedded Coder® (required MATLAB toolbox) – automatic code generation from the model Simulink models – the zonal node routing application model referenced throughout the series NXP Model-Based Design Toolbox (MBDT) – S32K3 support and peripheral configuration NXP additional tools – FreeMASTER and S32 Design Studio for build, deployment, and debugging CAN analysis software – monitoring and validating CAN communication LIN analysis software – monitoring and validating LIN communication 3.1 MATLAB® and Simulink® MATLAB® and Simulink® form the foundation of the development environment. They are used to create the zonal node application, implement communication routing logic, configure software behavior, and perform model-based verification activities. The application described throughout this series is developed as a Simulink model and later translated into embedded software using automatic code-generation tools (Embedded Coder®). 3.2 NXP Model-Based Design Toolbox (MBDT) The NXP Model-Based Design Toolbox (MBDT) extends Simulink with hardware-specific support for NXP automotive microcontrollers. For this project, MBDT for S32K3 version 1.8.0 is used. The toolbox provides blocks and configuration interfaces for communication peripherals, timers, digital I/O resources, and other hardware modules available on the target device. It also integrates with the code-generation workflow, allowing Simulink models to be converted into software that can run directly on the S32K3 microcontroller. Note: Installation and configuration instructions are provided in the dedicated article series (How to install .MLTBX). Readers who have not yet installed the toolbox should complete that step before continuing with this series. 3.3 CAN Analysis Software CAN analysis tools are used during development and validation to observe CAN and CAN FD traffic exchanged between the zonal node and other network participants. Typical use cases include: Monitoring transmitted and received CAN frames Verifying CAN-to-CAN routing behavior Measuring message timing and bus utilization Troubleshooting communication issues Examples of commonly used software include PCAN-View, CANalyzer, and CANoe. 3.4 LIN Analysis Software LIN analysis tools are used to monitor communication between the zonal node and LIN-connected edge devices. Typical use cases include: Verifying LIN schedule execution Monitoring frame transmission and reception Validating signal timing and integrity Testing LIN-to-CAN routing scenarios Examples of commonly used software include PLIN-View and LINalyzer. 4 Required Hardware The following hardware components are used throughout the project: S32K344 automotive microcontroller – used to execute the zonal node application S32K344-WB Evaluation Board – used as the development and validation platform CAN analysis hardware – used to monitor and verify CAN/CAN FD communication LIN analysis hardware – used to monitor and verify LIN communication 4.1 S32K3 Microcontroller The S32K3 family provides: Arm® Cortex®-M7 processing cores CAN FD communication interfaces LIN communication support Safety-oriented automotive features Low-power operating modes Rich peripheral connectivity These capabilities make the device suitable for implementing communication aggregation and routing functions within the scope of this project. 4.2 Evaluation Hardware The zonal node application runs on the S32K344-WB Evaluation Board, a development platform based on the NXP S32K344 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities. Within the scope of this project, the board is used to execute the routing application and exchange messages with nodes connected through CAN and LIN networks. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating zonal communication architectures and routing scenarios. dragostoma_0-1784547235185.png Figure 2. S32K344-WB evaluation board 4.3 Communication Networks The examples presented throughout this series use CAN and LIN networks to demonstrate message forwarding, routing, and protocol translation scenarios. These networks provide the communication backbone between the zonal node, central controller, and edge nodes, and are referenced throughout the upcoming routing and integration articles. 4.4 Network Analysis Hardware Additional hardware tools are used during development and validation to observe network traffic and verify communication behavior. CAN analysis interfaces can be connected to the network to monitor transmitted and received CAN/CAN FD frames, validate routing functionality, and troubleshoot communication issues. LIN analysis interfaces can be used to monitor LIN schedules, frame exchanges, and LIN-to-CAN routing scenarios. These tools provide visibility into network activity and support verification of the communication flows presented in later articles of this series. 5 References Model-Based Design Toolbox (MBDT) Embedded Coder® Documentation MATLAB® and Simulink® Documentation S32K3 Microcontrollers S32K344-WB Evaluation Board 6 Conclusion This article introduced the software and hardware environment used throughout the zonal node project. It presented the development tools, code-generation workflow, and target hardware that support the implementation of the communication routing application. The next article will build on this foundation by examining the internal logic control mechanisms used within the zonal node and how they contribute to communication handling across multiple networks.

How to generate a Standalone IAR toolchain project from MCUXSDK application example - KWX/MCWX To generate a hello world (suppose) example for KW47-EVK for IAR toolchain. We asume that IAR toolchain is already installed. Set IAR_DIR environment variable. In Windows, this can be done via Edit environment variables system option. Example: IAR_DIR=C:\iar\ewarm-9.60.1.    Note: IAR toolchain version may change. Type the following commands on your MCUXSDK workspace: cd mcuxsdk west build -b kw47evk ./examples/demos_apps/hello_world --toolchain=iar -t standalone_project -Dcore_id=cm33_core0 --pristine -d ./build/kw47evk/kw47evk_standalone_hello_world_iar​ IAR project should have been generated on  MCUXSDK_WS/mcuxsdk/build/kw47evk/kw47evk_standalone_hello_world_iar/iar directory. IAR project has .eww file extension.  neidys_vargas_0-1784665664365.png  Relevant links IDE Project Generation: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/develop/build_system/IDE_Project.html# Note: Ruby is required for this feature. Typically, this tool is installed via MCUXpresso Installer. However, if having issues with this tool refer to the next link: Ruby Environment Setup: https://mcuxpresso.nxp.com/mcuxsdk/latest/html/develop/build_system/IDE_Project.html#ruby-environment-setup Suppose you want to generate a hello world example for KW47-EVK for IAR toolchain as the previous example, but this time LPTMR driver is required for low-power timer operating purposes. We asume that IAR toolchain is already installed and IAR_DIR variable is already set. The easiest way to accomplish this is to add the lptmr Kconfig symbols with ‘yes’ value at Board-Application level (Refer to Kconfig User Guide). In this case, the target prj.conf file is located on  MCUXSDK_WS/mcuxsdk/examples/_boards/kw47evk/demo_apps/hello_world.​ Edit this file and add the LPTMR required symbols:  CONFIG_MCUX_COMPONENT_driver.lptmr=y CONFIG_MCUX_COMPONENT_component.lptmr_adapter=y​ neidys_vargas_4-1784665984531.png neidys_vargas_1-1784665840673.png Type the following command on your MCUXSDK workspace:  west build -b kw47evk ./examples/demo_apps/hello_world --toolchain=iar -t standalone_project -Dcore_id=cm33_core0 --pristine -d ./build/kw47evk/kw47evk_standalone_hello_world_iar IAR project should have been generated on MCUXSDK_WS/mcuxsdk/build/kw47evk/kw47evk_standalone_hello_world_iar/iar directory. IAR project has .eww file extension. This time LPTMR drivers should be included in iar/drivers/lptmr   neidys_vargas_2-1784665938476.png  neidys_vargas_3-1784665959007.png neidys_vargas_5-1784666017506.png

KW47ナレッジハブ KW47 ファミリでは、96 MHz Arm® Cortex®-M33コアをBluetooth LEサブシステムとカップリングしています。この無線サブシステムは独立しており、コアやメモリも専用で、メインCPUの負荷を軽減するので、プライマリ・アプリケーションの分が保持され。また、ファームウェア・アップデートによる将来のワイヤレス標準のサポートも可能です。EdgeLock® Secure Enclave Core Profileを統合した高度なセキュリティのKW47は、NXPのEdgeLock 2GOクラウド・サービスによるサポートで認証情報の共有にも対応します。 KW47ファミリにはBluetoothのチャネル・サウンディング機能が搭載されており、オンチップの専用Localization Compute Engineで測距遅延を短縮します。アプリケーション固有のコード、コネクティビティ・スタック、OTA（Over-The-Air）ファームウェア・アップデートをサポートするための追加メモリも搭載されています。これにより、無線のリアルタイム動作がアプリケーションとは別のコアで実行されるため、信頼性の高いワイヤレス性能が得られます。 オートモーティブ・ソリューションを提供してきたNXPの豊富な経験に基づくKW47ファミリは、-40°C～125°Cの幅広い動作温度範囲と、車載アプリケーション向けペリフェラルを備えるほか、KW47は、長期使用をサポートするNXPの15年間の長期製品供給プログラムの対象ともなっています。 KW47シリーズは、MCUXpresso開発者エクスペリエンスによってサポートされ、組込みシステム開発の最適化、簡素化、迅速化に役立ちます。 KW47は製造開始前ですが、開発者はピンやソフトウェアの互換性があるKW45なら今すぐ使用を開始できます。   joseAntonio_ruiz_0-1739544574098.png   joseAntonio_ruiz_1-1739544610236.png   早期アクセスプログラム KW47早期アクセスプログラムはこちらKW47 Early Accessから参加できます。 アクセスのリクエストはNXPセールスチームまでご連絡ください。   チャネル・サウンディング チャネル・サウンディングご紹介プレゼンテーション CCC CS消費電力計算ツールあり（Excelファイル添付）   Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   トレーニング Bluetooth Low Energy 6.0 NXPご紹介 RFスイッチの比較 吸収型と反射型 規格の比較 ETSI/FCC/ARIB要件 BLEチャネルサウンディング - 概要 BLEチャネル・サウンディング - RFハードウェア BLEチャネル・サウンディング - ANSYSモデリング・ツール BLEチャネル・サウンディング - アンテナのプロトタイプの検証測定 機器 ワイヤレス機器：この記事には、プロジェクト策定に役立つ機器へのリンクが掲載されています。 便利なリンク リファレンスデザイン - NXP Community KW45/KW47/MCXW71/MCXW72でのSignal Frequency Analyzer（SFA）モジュールを使用したクロック測定 - NXPコミュニティ：このコミュニティでは、Signal Frequency Analyzerの使用方法に関する手順を提示しています。 ［MCUXSDK］KW4x、MCXW7x、MCXW2xにGitHub SDKを使用する方法 - NXPコミュニティ GitHub SDKの使用方法をステップ別に紹介しています。 ［MCUXSDK］GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティ BLEプラットフォーム用ドキュメントを提供しています。  KW47（オートモーティブ）またはMCXW712（IIoT）を使用してPCBを初めて正しく構築するための最適な方法 - コミュニティ：このコミュニティには、KW45またはK32W148/MCXW71を使用してPCBを構築するための重要なリンクと、無線性能、低電力、無線認証（CE/FCC/ICC）に関するあらゆる情報があります。 HCI_bbをKinetisファミリ製品で使用してDTMモードにアクセスする方法：この記事は次の2つの部分に分かれています。 HCI_bbバイナリを Kinetis製品へフラッシュする方法。 R&S CMW270を使用してRF測定を行う BLE HCIアプリケーションによるトランスミッタ/レシーバテストコマンドの設定：この記事では、ユーザーはどのようにすればシリアルコマンドをデバイスに送信できるかを示す手順を説明します。 Bluetooth LE HCI Black Boxクイックスタートガイド：この記事では、ユーザーが無線をシリアルコマンドで制御できるようにするためのシンプルなプロセスを説明します。 Kinetis（K32/38/KW45およびK32W1/MCXW71）パワー・プロファイル・ツール：Kinetis（KW35/KW38/KW45）およびMCX W7x（MCX W71）パワー・プロファイル・ツールに的を絞ったページです。お使いのアプリケーション（自動車またはIoT）での電力消費量を試算したり、ソリューションのバッテリ寿命を評価したりするのに役立ちます。  

KW47 知识中心 KW47 系列具备 96 MHz Arm® Cortex®-M33 内核，并搭载蓝牙低功耗（LE）子系统。独立的无线子系统具有专用核心和存储器，可减轻主CPU的负载，将其留给主要应用，并允许固件更新以支持未来的无线标准。KW47 还通过集成的 EdgeLock® 安全飞地核心配置文件提供高级安全性，并将由 NXP 的 EdgeLock 2GO 云服务支持凭证共享。 KW47 系列具备蓝牙信道探测功能，以及专用的片上定位计算引擎，可降低测距延迟。它集成了额外的内存，可支持特定应用代码、连接协议栈和无线固件更新。这意味着无线电子系统的实时活动在能够与应用程序不同的核心上运行，实现可靠的无线性能。 基于 NXP 在汽车解决方案领域的深厚历史，KW47 系列提供从 -40 °C 到 125 °C 的宽操作温度范围以及用于汽车应用的外围设备。KW47 将成为 NXP 15 年产品寿命计划的一部分，以支持长期使用。 KW47 系列配备 MCUXpresso Developer Experience 支持，可优化、简化和加速嵌入式系统的开发工作。 KW47 处于试生产阶段，开发人员可以立即开始使用与其引脚和软件兼容的 KW45。   joseAntonio_ruiz_0-1739544574098.png   joseAntonio_ruiz_1-1739544610236.png   早期访问计划 立即加入KW47早期访问计划：KW47 Early Access 您可以通过联系 NXP 销售团队来申请访问权限。   信道探测 信道探测简介 演示文稿 CCC CS 功率估算工具可用（附有 Excel 文件）   蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   培训 蓝牙低能耗 6.0 NXP 简介 射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备： 本文提供了有助于项目开发的设备链接  有用链接 参考设计 - NXP 社区 使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区：该社区提供了如何使用信号频率分析仪的步骤 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  首次正确构建 PCB 的最佳方法，使用 KW47（汽车）或 MCXW712（IIoT）…… 社区：在此社区中，提供了使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接，以及所有关于无线性能、低功耗和无线认证（CE/FCC/ICC）的内容。 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式：本文分为两部分： 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序用于设置发射机/接收机测试命令：本文提供了步骤，展示用户如何向设备发送串行命令 。Bluetooth LE HCI Black Box Quick Start Guide：本文介绍了一个简单的过程，用户可以通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具： 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序（汽车或物联网）的功耗，并评估您解决方案的电池寿命。