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

KW43 Knowledge Hub The KW43 product family is a low-power, secure, single-chip wireless MCU that integrates a high performance, Bluetooth Low Energy, Bluetooth Channel Sounding, EdgeLock Secure Accelerators, and various MCU peripherals targeted for Automotive applications. The KW43 family utilizes an Arm® Cortex®-M33 core (Armv8-M architecture) running up to 96 MHz for customer applications. The family includes memory configurations of up to 1.5MB flash and 256 KB SRAM across all listed part numbers. All devices in the family integrate a state-of-the-art, scalable security architecture including Arm’s TrustZone®-M, a resource domain controller and an isolated EdgeLock Secure Accelerators supporting hardware cryptographic accelerators, random number generators and key generation, storage, and management along with secure debug. All members of the KW43 family are designed to be compliant to a SESIP Level 3 certification following the Arm PSA Level 3 profile. KW43 uses dual Arm Core Cortex-M33 (‘CM33’) and supports multiple interfaces and security features. One is for application and system use and other is for radio link layer and both cores share a common flash of 1.5 MB. The devices include a full certified Bluetooth LE 6.x controller stack with support for up to 10 simultaneous connections in any controller/peripheral combination. The multiprotocol radio subsystem integrated in the KW43 Family is energy efficient and is designed for Wi-Fi coexistence. The radio is supported with tested software stacks for Bluetooth Low Energy for standalone and hosted applications to enable a range of Automotive, IoT and industrial applications. There is also software and hardware support for 2.4 GHz proprietary protocols. To address ranging requirements, the Localization Engine (LCE) is integrated into the system for enhanced localization performance. The KW43 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. Early access program The KW43 is in pre-production, developers can get started today with the KW45/KW47, which is pin and software compatible.   you can request access contacting NXP sales team - Pascal Bernard ([email protected]) Join KW47 early access program here: KW43 Early Access Training Bluetooth Low energy 6.0 NXP Introduction Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology.  2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Useful Links How to import and run demo examples with MCUXpresso for Visual Studio Code: This article gives information on how to import and run demo examples from the new SDK with ARM GCC toolchain, in MCUXpresso for Visual Studio Code. [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide: This article describes a simple process for enabling the user controls the radio through serial commands.

KW43 知识中心 KW43 产品系列是一款低功耗、安全的单芯片无线 MCU，集成了高性能、低功耗蓝牙、蓝牙信道探测、EdgeLock 安全加速器以及各种针对汽车应用的 MCU 外围设备。 KW43 系列采用运行频率高达 96 MHz 的 Arm® Cortex®-M33 内核（Armv8-M 架构），用于客户应用程序。该系列包括所有列出的部件号中高达 1.5MB 闪存和 256 KB SRAM 的内存配置。该系列中的所有设备都集成了最先进的可扩展安全架构，包括 Arm 的 TrustZone®-M、资源域控制器和隔离式 EdgeLock 安全加速器，支持硬件加密加速器、随机数生成器、密钥生成、存储和管理以及安全调试。KW43系列的所有成员均按照Arm PSA 3级配置文件设计符合SESIP 3级认证。 KW43 使用双核 Arm Core Cortex-M33（'CM33'），支持多种接口和安全功能。一个用于应用程序和系统，另一个用于无线链路层，两个内核共享一个 1.5 MB 的公共闪存。 这些设备包括经过全面认证的蓝牙 LE 6.x 控制器堆栈，在任何控制器/外设组合中支持多达 10 个同时连接。KW43 系列中集成的多协议无线电子系统节能，专为 Wi-Fi 共存而设计。该无线电由经过测试的低功耗蓝牙软件堆栈支持，适用于独立和托管应用程序，以支持一系列汽车、物联网和工业应用。软件和硬件还支持 2.4 GHz 专有协议。为满足测距要求，系统中集成了本地化引擎 (LCE)，以提高本地化性能。 KW43 系列受 MCUXpresso开发人员体验支持，可优化、简化并帮助加速嵌入式系统的开发。 早期使用计划 KW43 处于试生产阶段，开发人员现在就可以开始使用引脚和软件兼容的 KW45/KW47。 您可以联系恩智浦销售团队申请访问权限 - Pascal Bernard ([email protected]) 点击此处加入 KW47 早期访问计划： KW43 提前访问 培训 低功耗蓝牙 6.0 恩智浦简介 对蓝牙技术感兴趣？ 低功耗蓝牙 Primer – 理解 BLE 基础知识的必备读物。 蓝牙® 规格 - 标准、协议和技术文件的完整列表。 奖项与表彰- 每年，蓝牙特殊兴趣小组（SIG）都会表彰在推动蓝牙技术发展方面做出突出贡献的工作组、委员会成员和贡献者。 2024:通道探测 2025 年：基于信道探测振幅的攻击弹性、LE 测试模式增强以及测距配置文件和服务。 蓝牙功能概述 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙_5.2_特性_概述 蓝牙_5.3_特性_概述 蓝牙_5.4_特性_概述 蓝牙_6_特性_概述 蓝牙_6.1_特性_概述 蓝牙_6.2_特性_概述 蓝牙_6.3_特性_概述 射频开关比较 吸收式/反射式 标准比较 ETSI / FCC / ARIB 要求 BLE 信道探测 - 概述 BLE 信道探测 - 射频硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备：本文提供了有助于项目开发的设备链接 实用链接 如何使用适用于 Visual Studio Code 的 MCUXpresso 导入和运行演示示例：本文介绍了如何在适用于 Visual Studio Code 的 MCUXpresso 中使用 ARM GCC 工具链从新 SDK 导入和运行演示示例。 [MCUXSDK]如何为 KW4x、MCXW7x、MCXW2x 使用 GitHub SDK - NXP Community 本社区帖子将逐步介绍如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区 该社区帖子提供了 BLE 平台的文档。 如何在 Kinetis 系列产品上使用 HCi_BB 并获得 DTM 模式的访问权限：本文分为两部分： 如何将 HCi_BB 二进制文件闪存到 Kinetis 产品中。 使用 R&S CMW270 执行射频测量 用于@@ 设置发射器/接收器测试命令的 BLE HCI 应用程序：本文提供了演示用户如何向设备发送串行命令的步骤。 蓝牙 LE HCI 黑盒快速入门指南： 本文介绍了用户通过串行命令控制无线电的简单过程。

KW43 ナレッジハブ KW43製品ファミリーは、低消費電力でセキュアなシングルチップ無線MCUであり、高性能なBluetooth Low Energy、Bluetoothチャネルサウンディング、 EdgeLockセキュアアクセラレータ、および各種MCU周辺機器を統合し、車載アプリケーション向けに設計されています。 KW43ファミリーは、お客様アプリケーション向けに最大96MHzで動作するArm ® Cortex ® M33コア（Armv8-Mアーキテクチャ）を採用しています。このファミリには、記載されているすべての型番において、最大1.5MBのフラッシュメモリと256KBのSRAMを搭載したメモリ構成が含まれています。このファミリのすべてのデバイスは、ArmのTrustZone ® -M、リソースドメインコントローラ、ハードウェア暗号アクセラレータ、乱数発生器、鍵の生成、保存、管理、およびセキュアデバッグをサポートする独立したEdgeLockセキュアアクセラレータを含む、最先端のスケーラブルなセキュリティアーキテクチャを統合しています。KW43ファミリーの全製品は、Arm PSAレベル3プロファイルに準拠したSESIPレベル3認証を取得するように設計されています。 KW43はデュアルArmコアCortex-M33（「CM33」）を搭載し、複数のインターフェースとセキュリティ機能をサポートしています。一つはアプリケーションとシステム用、もう一つは無線リンク層用で、両方のコアは1.5MBの共通フラッシュメモリを共有している。 これらのデバイスには、認証済みのBluetooth LE 6.xコントローラースタックが搭載されており、コントローラーと**ペリフェラル**の組み合わせに関わらず、最大10台の同時接続をサポートします。KW43ファミリに統合されたマルチプロトコル無線サブシステムは、エネルギー効率が高く、Wi-Fiとの共存を前提に設計されています。この無線機は、スタンドアロンおよびホスト型アプリケーション向けに、Bluetooth Low Energy用のテスト済みソフトウェアスタックをサポートしており、自動車、IoT、産業用アプリケーションなど、幅広い用途に対応できます。2.4GHz帯の独自プロトコルに対するソフトウェアおよびハードウェアのサポートも提供されています。測距要件に対応するため、測位性能を向上させるために、測位エンジン（LCE）がシステムに統合されています。 KW43シリーズは、 MCUXpresso開発者エクスペリエンス 組み込みシステム開発を最適化、簡素化、加速化する。 早期アクセスプログラム KW43は現在試作段階ですが、開発者はピンとソフトウェアの互換性があるKW45/KW47を使用して本日より開発を開始できます。  アクセスをご希望の場合は、NXPの営業チーム（担当：パスカル・ベルナール、メールアドレス：[email protected]）までご連絡ください。 KW47早期アクセスプログラムへの参加はこちら： KW43早期アクセス トレーニング Bluetooth Low Energy 6.0 NXP 導入 Bluetooth技術にご興味がありますか？ Bluetooth Low Energy Primer – BLEの基礎を理解するために必読の書。 Bluetooth ®仕様 －規格、プロトコル、技術文書の完全なリスト。 表彰と評価- Bluetooth Special Interest Group (SIG) は毎年、Bluetooth 技術の発展に貢献したとして同業者から認められたワーキンググループ、委員会メンバー、貢献者の努力と献身を称えています。 2024: チャネル Sounding 2025年：チャネルサウンディング振幅ベースの攻撃耐性、LEテストモードの機能強化、および測距プロファイルとサービス。 Bluetooth機能の概要 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能概要 Bluetooth_5.3_機能概要 Bluetooth_5.4_機能概要 Bluetooth 6の機能概要 Bluetooth 6.1の機能概要 Bluetooth 6.2 機能概要 Bluetooth 6.3 機能概要 RFスイッチ比較：吸収型／反射型 規格比較：ETSI / FCC / ARIBの要件 BLEチャネルサウンディング - 概要 BLEチャネルサウンディング - RFハードウェア BLEチャネルサウンディング - ANSYSモデリングツール BLEチャネルサウンディング - アンテナプロトタイプの検証測定 装置 無線機器：この記事では、プロジェクト開発に役立つ機器へのリンクを提供します。 役立つリンク集 Visual Studio Code 用 MCUXpresso を使用してデモ例をインポートして実行する方法: この記事では、Visual Studio Code 用の MCUXpresso で、ARM GCC ツールチェーンを使用した新しい SDK からデモ例をインポートして実行する方法について説明します。 [MCUXSDK] KW4x、MCXW7x、MCXW2x 用 GitHub SDK の使い方 - NXP コミュニティこのコミュニティ投稿では、GitHub SDK の使い方をステップバイステップで解説します。 [MCUXSDK] GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティこのコミュニティ投稿では、BLEプラットフォームのドキュメントを提供します。 Kinetisファミリー製品でHCI_bbを使用し、DTMモードにアクセスする方法：この記事は2つのパートで構成されています。 HCI_bbバイナリをKinetis製品に書き込む方法。 R&S CMW270を使用してRF測定を実施する BLE HCIアプリケーションでトランスミッタ/レシーバのテストコマンドを設定する：この記事では、ユーザーがデバイスにシリアルコマンドを送信する方法を示す手順を説明します。 Bluetooth LE HCI ブラックボックス クイックスタートガイド：この記事では、シリアルコマンドを使用してユーザーが無線を制御できるようにする簡単な手順について説明します。