SC18IM704 does not work Hi everyone! I used STM32F407 for UART communication with SC18IM704 chip. The UART peripheral of STM32 successfully sent data to tx, but there was no feedback from SC18IM704 on rx.when board is power on.UART baud rate is 9600 bit/s. The schematic diagram of the board is shown in the figure. 3046B74B-E9DE-4e11-8E23-9134E0817F20.png3046B74B-E9DE-4e11-8E23-9134E0817F20.png I use the Read version function ID command of SC18IM704 .shown in the figure SDS1204X_HD_JPG_1.jpgSDS1204X_HD_JPG_1.jpg No data feedback provided of SC18IM704 I2C uart Re: SC18IM704 does not work Hi,  according to the SC18IM704 datasheet, after power up the SC18IM704 send two bytes to the host. Do you receive these two bytes after power up?  JozefKozon_0-1779954086888.pngJozefKozon_0-1779954086888.png If you are not receiving these two bytes, please check if the RESET pin is high. Please remove the 10k pull-up resistors on the TX and RX lines. Only the RX pin requires pull-up resistor and only if you want to keep the SC18IM704 in Deep Power-down mode. Otherwise no pull-up resistors should be on the TX and RX lines. With Best Regards, Jozef Re: SC18IM704 does not work Hello,  thank you for confirmation. Please remove the R106 resistor, to disconnect the TX pin from your MCU. To make sure, that the TX pin is floating (not held high by your MCU). Then power up the SC18IM704 and measure the TX pin on the SC18IM704 with an oscilloscope to look for the "OK", the two bytes 0x4F and 0x4B.  If you still don't see the "OK" please conduct the reset with the RESET pin.  1. Watch TX with oscilloscope 2. Hold RESET LOW (GND) for ~10 ms 3. Release to HIGH 4. See if the "OK" appears   With Best Regards, Jozef Re: SC18IM704 does not work hello Jozef: I check the RESET pin of SC18IM704 is high(3.3V) by oscilloscope.after power up the SC18IM704. I not find the two bytes('OK') by oscilloscope. I removed the 10k pull-up resistors on the TX and RX lines. I use four SC18IM704 chips ,and the situation is the same. I don't know how to solve this problem，please help me. Re: SC18IM704 does not work Hi, I am running into similar issue, did remove the Rx and Tx resistors, but still now showing ok. What are some common next step to trouble shoot, or if there is a recommended design that I can look into. Re: SC18IM704 does not work I am facing the same issue. I built a board using SC18IM704 a few years ago, and it worked correctly. However, when I recently built the same board again, I encountered a problem where it does not work at all. Specifically, sending a reset signal to the reset pin yields no acknowledgment(OK). Furthermore, sending commands to the RX pin results in no response—neither the version information nor I2C commands work.  Since I had an older lots on hand, I tried swapping it in, and it operated normally. It appears there is a major issue with the IC itself in specific lots. Please share the problematic lots in this thread. -Work 18IM704 355.101 ZXD23 13 18IM704 355.101 ZXD23 25 18IM704 355.103 ZXD22 32 -Not Work 18IM704 265.102 ZXD21 35

S32K31XEVB-Q100FlexCAN0 — ループバックは正常に動作しますが、外部CANoeツールでは受信できません。 ボード: S32K311-EVB モジュール: FlexCAN0 ツール: J8コネクタで接続されたベクターCANoe デバッグプローブ: Jリンク 私はFlexCAN0を使ってS32K311-EVBでCANプロトコルを実装しています。 ループバックモードテスト（動作確認済み）： 私はまず、FlexCAN0を内部ループバックモードで実装し、テストしました。これはうまくいきました。送信されたメッセージは、私の「void CanIf_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr )」を通じて正しく受信されました。 処理機能により、FlexCAN0の基本設定（クロック設定、ビットタイミング、メッセージバッファ初期化）が正しく機能していることを確認します。 外部コミュニケーションテスト(効果なし): 次に外部CAN通信のテストに移りました: ピン構成でPTA6とPTA7のピンを設定してください。 J8コネクターでVector CANoeをボードに接続しました。 CANoe構成では、私は チェックされていない「CAN Loopback Mode」 12Vアダプターを取り付ける CANoeの送信を開始しました — CANoeはCANフレームを送信していることを示しています。 しかし、S32K311側では何も受信されず、 CanIf_RxIndication （ループバックモードでは正しく動作していた同じ関数）は呼び出されたりトリガーされたりしません。 デバッグには、JTAG を使用した Segger RTT Viewer を使用しています。 設定 Sami2098_0-1789478804307.pngSami2098_0-1789478804307.pngSami2098_0-1789478804307.png Sami2098_1-1789478831337.pngSami2098_1-1789478831337.pngSami2098_1-1789478831337.png Sami2098_2-1789478911944.pngSami2098_2-1789478911944.pngSami2098_2-1789478911944.png Sami2098_3-1789478932611.pngSami2098_3-1789478932611.pngSami2098_3-1789478932611.png よろしくお願いします。   Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool こんにちは、 @Sami2098 さん。 現在使っているRTDバージョンを教えてもらえますか? 私たちのコミュニティには参考にできるいくつかの例があります: Re: S32K311のCAN例 - NXPコミュニティ ポーリングモードDS3.5 RTD300を使用したS32K312 CAN送受信の例 [RTD600 MCAL & IP] S32K3X4EVB-T172 FlexCAN 割り込みのサンプル / ポーリング FlexCANの設定は全体的に問題なさそうです。PTA6/7がそれぞれ入力と出力として設定されていること、そして実際にSiul2_Port_Ip_Init()APIを呼び出してポートの初期化をしているのか確認できますか? Julin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.pngJulin_AragnM_2-1789514266922.png S32K1XEVBを使っている場合、使用されているトランシーバはFS23で、FS23がデバッグモードの場合、CANトランシーバはデフォルトでアクティブモードに設定されているため、CAN_MODE = 0b1xを設定する必要はありません。 S32K311<->CANoeの間で設定されているビットレートとサンプリングポイントが同じであることを確認することもお勧めします。 最後に、もしロジックアナライザーやオシロスコープをお持ちなら、CANTXD、CANRXD、CANH、CANLの信号を共有してもらえますか? よろしくお願いします、 ジュリアン Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool こんにちは、 Julián_AragónMさん。 調べていただきありがとうございます。原因は、実は CANoeのチャネルバス設定の問題 で、S32K311 CANドライバの設定の問題ではありませんでした。CANoe Vectorの設定を修正したところ、受信は正常に動作するようになりました。 追加の質問： 現在は 500 kbpsで動作しており、異なるボーレート(例: 125 kbps)に切り替えると、正しいビットタイミングとCAN周辺クロックに対するサンプルポイントを維持するために、プリスケーラ、伝播セグメント、位相セグメント1、フェーズセグメント2、リシンクジャンプ幅など、いくつかの依存パラメータを再計算する必要があると理解しています。 誰か、 以下の説明書や参考資料 を教えてもらえますか? これらのビットタイミングパラメータ（プリスケーラ、プロップセグメント、PS1、PS2、SJW）が、異なる目標ボーレートとどのように関連し、どのように導出されるか。 オートモーティブ・インダストリアルの文脈で異なるボーレートに対する推奨サンプルポイント範囲。 ビットタイミング計算用の S32K3xx FlexCAN MCAL(AUTOSAR) 構成ツールに関する公式のNXPアプリケーションノートや参考文献など、いかなるものもご存知。 私は MCALレイヤーをAUTOSARモード (S32 Configuration Tool for Canドライバー設定)で使っているので、この設定フローに合わせたガイド(レジスタレベルのFlexCANプログラミングだけでなく)が特に助かります。 ご指導ありがとうございます。 Re: S32K31XEVB-Q100FlexCAN0 — Loopback works fine, but no reception with external CANoe Tool こんにちは、 @Sami2098 さん。 1.リファレンスマニュアルRev. 12の73.3.10.8章(プロトコルタイミング)S32K3XXビットタイミングの設定とその各種パラメータが説明されています。 2. これはアプリケーションや構成によります。ただし、標準ビットレートには125 kbps、250 kbps、500 kbpsがあります。 3. FlexCANビットタイミング計算シートを参照してください。また、RTDトレーニングのシルデスと連携したS32K3XX FlexCANも参照できます。 よろしくお願いします、 ジュリアン

NXP S32k118 I2Cエミュレーション こんにちは、 私は、I2Cマルチプレクサを使用せずに、S32K118（Q48）マスターから10個の同一アドレスのI2Cスレーブを同時に駆動する方法を評価しています。 私の計画は、ハードウェアタイマーでクロックを生成し、DMA転送を組み合わせて同じポート上の10本のGPIOピンを同時に更新することで、10本の並列I2Cバスをエミュレートすることです。 S32K118のDMAやタイマー**ペリフェラル**が、このような方法でポート全体のGPIO更新をトリガーできるかどうか、確認を手伝ってもらえますか?このアーキテクチャに関して注意すべきハードウェアの制限やエッジケースはありますか? よろしくお願いいたします。 Re: NXP S32k118 I2C emulation こんにちは、 @Luke_John さん。 はい、このアーキテクチャは基本的にサポートしています。 S32K1xxシリーズリファレンスマニュアル、Rev. 14を参照: 第13.3.1項 GPIOレジスタの説明 ご覧の通り、すべてのGPIOポートは32ビットレジスタからアクセス可能です。 セクション 17 4.1「GPIOポートを使用して波形を駆動またはサンプリングする」DMAを構成してデータを1つ以上のGPIOポートに転送することにより、オンチップメモリに格納された表形式データを使用して複雑な波形を作成することが可能です。逆に、DMAを使用して1つまたは複数のGPIOポートからデータを定期的に転送することで、複雑な波形をサンプリングし、その結果を表形式でオンチップメモリに保存することが可能です。 DMAトランスファーはDMAMUXやTRGMUXのタイマーでトリガーできます。 シームレスなDMA転送を実現するには、クロスバーをラウンドロビンアービトレーション（MCM_CPCR[CBRR]を「1」に設定）にプログラムする必要があります。 よろしくお願いいたします。 ダニエル

参照構成パス Simulinkでハードウェアを構成する際に、参照構成のディレクトリを相対パスに変更しようとしています。 Simulink -> HW-Settings -> Hardware Implementation -> Target hardware resources -> Referenced Configuration 参照構成パス = '.\generated\referenced_config' 残念ながら、ここでは相対パスを入力することはできません。 また、MATLABスクリプトで進路を設定することもまだできません。 スクリプトはCoderTargetDataにパスを設定しているように見えますが、実際には適用されていません。 古いパスが引き続き有効になるか、空のパスが適用されます。 参照設定に対して相対パスを設定する方法はありますか？ Re: refence configuration path こんにちは、 @AlexG124 さん、 詳細を教えていただきありがとうございます。ご使用中のMBDTツールボックスバージョンとMATLABバージョンについて教えていただけませんか? もしS32K3ツールボックスを使っているなら、model_ref/s32k3xx_refconfig_s32ctフォルダの下に参照された設定ワークフローを示すモデル例があります。ここにはs32k3xx_refconfig_update_paths_callback.mというMATLABスクリプトがあり、あなたの目標達成に役立つかもしれません。 また、ご参照の構成方法、使用方法、アプリケーションの流れについても詳しく教えていただけると助かります。 よろしくお願いいたします。 ドラゴス

s32k144 MBDツールボックスを使用したI2Cの読み書き こんにちは、 私はs32k144を使用して、外部EEPROMからのデータ読み書きを行っています。モデルを下に添付します。データの書き込みはできますが、読み込み時に255+NACKが出力されます。何か見落としているのでしょうか？ Sriram_0-1737789999186.png Sriram_1-1737790013461.png I2CmasterブロックでEEPROMのレジスタアドレスを指定する方法はありますか？ Sriram_2-1737790096449.png この問題について皆さん助けてもらえますか? ありがとう Re: I2C read and write using s32k144 MBD toolbox こんにちは、 私も、マスターとしてS32K144 、スレーブとしてST M24C04 EEPROMを使用したI2C通信で同じ問題に直面しています。 同じマイクロコントローラとEEPROMを使っているので、解決策が見つかっているか確認したいです。もしこの問題が解決したなら、その解決策を教えていただけるか、どう解決したのか教えていただけませんか? ご協力ありがとうございます。 Re: I2C read and write using s32k144 MBD toolbox 私はM24C02-DRE EEPROMを使用しています

MCXN947 HPDACバックポート Zephyrのnxp_hpdacドライバをMCXN947ベースのボード用にZephyr 4.3にバックポートしています。 アップストリームドライバーはデバイスinitコールバックを使用しません。しかし、Zephyr 4.3では、ペリフェラルを使う前にDAC2クロック、SPCアナログモジュールを明示的に初期化し、リセットしないとHPDACが正しく動作しません。 以下の手順を実行するnxp_hpdac_init()関数を追加しました。 CLOCK_SetClkDiv(kCLOCK_DivDac2Clk, 1U) CLOCK_AttachClk(kFRO_HF_to_DAC2) CLOCK_EnableClock(kCLOCK_Dac2) SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac2) SPC_EnableLowPowerModeAnalogModules(SPC0, kSPC_controlDac2) RESET_PeripheralReset(kDAC2_RST_SHIFT_RSTn) DAC14_DoSoftwareReset() DAC14_DoFIFOReset() SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlVref) これらの初期化手順は、MCXN947リファレンスマニュアルに基づいており、対応するMCUX SDK APIを使用して実装されました。 初期化関数は、DEVICE_DT_INST_DEFINE() を介してデバイス初期化コールバックとして登録されます。これらの変更により、HPDACは正常に動作するようになりました。 また、Zephyr MCUXのSYSCONクロックコントロールドライバーとmcux_lpc_syscon_clock.hも確認しましたバインディングは使っていますが、このペリフェラルのHPDAC/DAC2クロック識別子やクロック制御実装が見つからなかったため、現在はMCUX SDKのクロック、SPC、リセットAPIを直接使っています。 私の質問は以下のとおりです。 1. MCXN947 HPDACドライバーをバックポートする際、この方法は正しいのでしょうか? 2. 新しいZephyrバージョンでは、これらのリソースは別の場所で初期化されているのか、それとも上流nxp_hpdacドライバーはすでに設定済みだと想定しているのか? 3. HPDACデバイスのinitコールバックがこのMCXN947固有の初期化の正しい場所でしょうか?それともこれらのステップはZephyrの他の部分で処理すべきでしょうか? 参考までに完全なバックポートドライバを添付しました。 アナログ(ADC|CMP|DAC|オペアンプ) クロック|タイマー MCX N 回复： MCXN947 HPDAC backport こんにちは、 @wesOS 1. MCXN947 HPDACドライバーをバックポートする際、この方法は正しいのでしょうか? はい、これはバックポートを行う上で合理的かつ現実的なアプローチです。必要なDAC2クロック、SPCアナログモジュール、VREF、リセットリソースがZephyr 4.3環境の他の場所で初期化されていない場合、正しいHPDAC動作を確保するためにドライバーでの初期化が必要です。 2. 新しいZephyrバージョンでは、これらのリソースは別の場所で初期化されているのか、それとも上流nxp_hpdacドライバーはすでに設定済みだと想定しているのか? HPDAC サポートはすでに上流に追加されています: https://github.com/zephyrproject-rtos/zephyr/pull/104642 しかし、現在のアップストリーム実装を使用して簡単な検証を行ったところ、DAC2クロックが設定されていないことが確認されました。例えば、CLOCK_GetDacClkFreq(2)は私のテスト環境で0Hzを報告していますが、同等のMCUX SDK例ではDACクロック設定後は48MHzと報告されています。 この観察から、現在のドライバは特定のデバイスリソースがすでに設定されていると仮定しているようです。あなたの側の時計設定経路ももう一度確認してもらえますか? また、クロック初期化のバグが確認された場合は、Zephyrチームにも報告し、さらなる調査を依頼します。 3. HPDACデバイスのinitコールバックがこのMCXN947固有の初期化の正しい場所でしょうか?それともこれらのステップはZephyrの他の部分で処理すべきでしょうか? バックポートの場合、このロジックをHPDACデバイスの初期化コールバックに配置することは、実用的かつ許容できる解決策です。 とはいえ、MCXN947固有のDAC2クロック、SPC、VREF、およびリセットの設定は、汎用的なHPDACの動作として組み込まれるのではなく、SoC固有の機能として明確に分離されるべきである。長期的には、これらのリソースはクロック、リセット、パワーマネージメントフレームワークなど、Zephyrのインフラストラクチャを通じて管理されることが望ましいです。 BR ハリー 回复： MCXN947 HPDAC backport ありがとうございます。MCXN947の設定でDAC2のクロックパスを再確認しました。 HPDACドライバーがクロックを設定する前に: dac_nxp_hpdac: DAC2 クロックの設定前: 0 Hz 後： CLOCK_SetClkDiv(kCLOCK_DivDac2Clk, 1U); CLOCK_AttachClk(kFRO_HF_to_DAC2); CLOCK_EnableClock(kCLOCK_Dac2); 次のようなメッセージが表示されました： dac_nxp_hpdac: 設定後のDAC2クロック：48000000 Hz 私も同じ挙動を目にしています:HPDACドライバーの初期化前にDAC2クロックが設定されていません。 MCXN947固有のリソース処理を分離しておくというあなたの説明も理にかなっています。 私が今主に理解しようとしているのは、最終的な上流ソリューションにおいて、その初期化処理がどのように分割されることを期待しているのかということです。 例えば、DAC2のクロック構成、SPC/VREFの設定、リセット処理がそれぞれ対応するZephyr/SoCインフラストラクチャに移行し、「dac_nxp_hpdac.c」と設定される予定ですか?汎用的なHPDAC初期化のみを保持するのですか？ 主に各初期化ステップの意図された所有権を理解し、バックポートをその方向に合理的に整合させたいためです。 ありがとう。 BR ウアシム 回复： MCXN947 HPDAC backport こんにちは、 @wesOS 結果の確認ありがとうございます。設定前にDAC2のクロックが0 Hz、48000000 Hzが設定後に起きているという事実は、HPDACドライバーが動作する前にDAC2クロックが初期化されていないことを強く示唆しています。 すでに内部のZephyrチームにバグ修正を報告しました。 FRDM-MCXN947実装をさらに調べたところ、既存のDACクロック初期化は現在、DACドライバ自体ではなく基板レベルで処理されていることがわかりました。 zephyr/boards/nxp/frdm_mcxn947/board.c 機能: void board_early_init_hook(void) DAC0とDAC1の両方について、クロックとSPCの初期化を実行します。 #if DT_NODE_HAS_STATUS_OKAY(DT_NODELABEL(dac0)) SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac0); CLOCK_SetClkDiv(kCLOCK_DivDac0Clk, 1u); CLOCK_AttachClk(kFRO_HF_to_DAC0); CLOCK_EnableClock(kCLOCK_Dac0); #endif #if DT_NODE_HAS_STATUS_OKAY(DT_NODELABEL(dac1)) SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac1); CLOCK_SetClkDiv(kCLOCK_DivDac1Clk, 1u); CLOCK_AttachClk(kFRO_HF_to_DAC1); CLOCK_EnableClock(kCLOCK_Dac1); #endif 現在の実装から考えると、既存の基板設計と一貫性を保つことが期待されています。言い換えれば、DAC2のクロック初期化は既存のDAC0/DAC1初期化に加えてboard_early_init_hook()に追加でき、基板固有のクロックセットアップを汎用HPDACドライバに配置するのではなく、 BR ハリー

参考配置路径 在 Simulink 中配置硬件时，我尝试将参考配置的目录更改为相对路径。 Simulink -> 硬件设置 -> 硬件实现 -> 目标硬件资源 -> 参考配置 参考配置路径 = '.\generated\referenced_config' 很遗憾，这里无法输入相对路径。 到目前为止，我还没能通过 MATLAB 脚本设置路径。 虽然脚本似乎在 CoderTargetData 中设置了路径，但实际上并没有应用。 要么保持旧路径有效，要么应用一个空路径。 是否可以为参考配置设置相对路径？ Re: refence configuration path 你好， @AlexG124 ， 谢谢你提供的详细信息。请问您能否告知我们您目前使用的 MBDT 工具箱版本以及 MATLAB 版本？ 如果您正在使用S32K3工具箱，则在model_ref/s32k3xx_refconfig_s32ct文件夹下有一个模型示例，展示了所引用的配置工作流程。这里有一个名为s32k3xx_refconfig_update_paths_callback.m的 MATLAB 脚本，它可以帮助您实现目标。 如果您能与我们联系并提供更多关于您所参考的配置的工作方式、使用方法和应用程序流程的详细信息，将对我们很有帮助。 顺祝商祺！ 德拉戈斯

MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver Hello Dear, I would like to clarify whether the MPC5744P EVM supports operation of two CAN channels using external CAN transceivers. I have successfully tested CAN0 on the EVM using the onboard/inbuilt CAN transceiver, and the CAN0 communication is working as expected. Now, I have configured CAN1 and CAN2 with the appropriate pin mapping to interface with external CAN transceivers. Could you please confirm whether CAN1 and CAN2 can be configured and operated successfully with external CAN transceivers on the MPC5744P EVM? If yes, could you please provide any recommended configuration, hardware connections, or specific settings that need to be considered for CAN1/CAN2 operation? Your guidance and support would be greatly appreciated. Thanks in advance for your help. Re: MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver Hi, Yes, CAN1 and CAN2 can be used with external CAN transceivers on MPC5744P-based evaluation boards. The MPC5744P device provides three independent FlexCAN modules (CAN0, CAN1, and CAN2), and CAN1/CAN2 can be routed to external transceivers through their corresponding MCU TX/RX pins, if no onboard transceiver is available and connected. The device supports operation of all FlexCAN instances independently.  For CAN1/CAN2, please ensure: The selected FlexCAN instance is configured correctly in software. The corresponding TX and RX pins are configured for the FlexCAN alternative function. The external CAN transceiver is powered and connected correctly. Proper CAN bus termination is present. Board-specific jumper settings or routing options may depend on the exact EVM revision. If you can provide the EVM part number or revision, we can check whether any additional hardware configuration is required. BR, Petr

24V電源を備えたS32K3に適したシングルボードコンピュータ 24V環境でS32k3に電源を供給するのに最も適したSBCはどれですか? FS264xファミリについて調べていましたが、FS26は24 V以上の電圧に長時間曝露すべきではないと書かれている情報源を見つけました。代わりにFS8500を使ったシステムの設計がより適切でしょうか? FS85&FS84 Re: Suitable SBC for S32K3 with 24V supply こんにちは、DavidSilvaさん 良い一日！ おっしゃる通り、FS26は統合されているすべての機能から最高の選択肢の一つですが、長期間使う予定ならFS85やFS86の方が24Vを問題なく扱えるのでより良い選択肢です。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。

适用于 24V 电源的 S32K3 的单板计算机 在 24V 环境下，哪款 SBC 最适合为 S32k3 供电？ 我一直在研究 FS264x 系列，但我发现一些资料表明 FS26 不应长时间暴露在 24 V 以上的电压下。使用 FS8500 来设计该系统是否更合适？ FS85&FS84 Re: Suitable SBC for S32K3 with 24V supply 你好，DavidSilva 再会！ 你说得对，FS26 是目前最好的选择之一，因为它集成了所有功能，但如果你打算长时间使用，FS85 和 FS86 是更好的选择，因为它们可以毫无问题地处理 24V 电压。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。

Suitable SBC for S32K3 with 24V supply Which SBC is the most suitable for supplying an S32k3 in a 24 V environment? I have been researching the FS264x family, but I found some sources stating that the FS26 should not be exposed to voltages above 24 V for extended periods. Would it be more appropriate to design the system using the FS8500 instead? FS85&FS84 Re: Suitable SBC for S32K3 with 24V supply Hello DavidSilva Good day! You're right, the FS26 is one of the best options available due to everything it has integrated, but if you plan to use it for extended periods, the FS85 and FS86 are better choices, as they can handle 24V without any issues. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

MPC5744P EVM – 外部CANトランシーバーによるCAN1/CAN2サポート こんにちは、あなた、 MPC5744P EVMが外部CANトランシーバを使って2つのCANチャネルの動作をサポートしているかどうかを明確にしたいと思います。 内蔵のCANトランシーバを使ってEVM上でCAN0をテストすることに成功し、CAN0通信は期待通りに動作しています。 現在、CAN1とCAN2を適切なピンマッピングで設定し、外部CANトランシーバとインターフェースできるようにしました。CAN1とCAN2がMPC5744P EVMの外部CANトランシーバーで正常に設定・運用可能かどうか確認していただけますか? もしそうなら、CAN1/CAN2の動作で推奨される設定、ハードウェア接続、または考慮すべき特定の設定を教えていただけますか? 皆さんのご助言とサポートを大変ありがたいです。 ご協力に感謝いたします。 Re: MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver こんにちは、 はい、CAN1およびCAN2はMPC5744Pベースの評価ボード上の外部CANトランシーバと組み合わせて使用できます。MPC5744Pデバイスは3つの独立したFlexCANモジュール(CAN0、CAN1、CAN2)を提供し、オンボードトランシーバーが利用可能かつ接続されていない場合、CAN1/CAN2は対応するMCU TX/RXピンを介して外部トランシーバーにルーティング可能です。このデバイスはすべてのFlexCANインスタンスの独立動作をサポートしています。  CAN1/CAN2については、以下をご確認ください。 選択したFlexCANインスタンスはソフトウェア上で正しく設定されています。 対応するTXピンとRXピンは、FlexCAN代替機能用に構成されています。 外部CANトランシーバは正しく電源が供給され、接続も正常です。 適切なCANバス終端が存在します。 基板固有のジャンパー設定や配線オプションは、EVMの正確なリビジョンによって異なる場合があります。EVMの部品番号やリビジョンをご提供いただければ、追加のハードウェア構成が必要かどうか確認いたします。 BR、ペトル

MPC5744P EVM – 支持 CAN1/CAN2 和外部 CAN 收发器 你好呀， 我想确认一下 MPC5744P EVM 是否支持使用外部 CAN 收发器操作两个 CAN 通道。 我已经使用板载/内置 CAN 收发器在 EVM 上成功测试了 CAN0，CAN0 通信工作正常。 现在，我已经配置了 CAN1 和 CAN2，并设置了适当的引脚映射，以便与外部 CAN 收发器连接。请问MPC5744P EVM上的CAN1和CAN2是否可以配置并成功使用外部CAN收发器？ 如果可以，能否请您提供 CAN1/CAN2 操作需要考虑的任何推荐配置、硬件连接或具体设置？ 您的指导和支持将不胜感激。 提前感谢您的帮助。 Re: MPC5744P EVM – CAN1/CAN2 Support with External CAN Transceiver 您好， 是的，基于 MPC5744P 的评估板上可以与外部 CAN 收发器一起使用 CAN1 和 CAN2。MPC5744P 设备提供三个独立的 FlexCAN 模块（CAN0、CAN1 和 CAN2），如果没有板载收发器可用且已连接，则 CAN1/CAN2 可以通过其对应的 MCU TX/RX 引脚连接到外部收发器。该设备支持所有 FlexCAN 实例独立运行。  对于 CAN1/CAN2，请确保： 所选的 FlexCAN 实例已在软件中正确配置。 相应的 TX 和 RX 引脚配置为 FlexCAN 替代功能。 外部 CAN 收发器已正确通电并连接。 CAN总线终端连接正常。 特定电路板的跳线设置或布线选项可能取决于具体的 EVM 版本。如果您能提供 EVM 的部件号或版本号，我们可以检查是否需要任何额外的硬件配置。 BR，彼得

i.MX 93 Memory Compatibility Guide The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 4 Gb/ (512 MB) ISSI LPDDR4: IS43LQ16256B-062BLI 4, 8 2 Gb / (256 MB) ISSI LPDDR4: IS43LQ16128A-062BSLI 4, 6, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2 Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8 Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 16 Gb / (2 GB) IM (Intelligent Memory) LPDDR4/4x: IMAG16L4KBBG 4, 8 4 Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 4 Gb / (512 MB) ISSI LPDDR4/4X: IS43LQ16256B-053BLI 4, 8 8 Gb / (1 GB) ISSI LPDDR4/4X: IS46LQ16512B-046BLA2 4, 8 32Gb / (4GB) 16 Gb / (2Gb) usable by i.MX 93 ISSI LPDDR4/4X: IS46LQ32K01B-046BLI 4, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Q3 2026 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.

i.MX 93 内存兼容性指南 本文档旨在为 i.MX 93 系列处理器所支持的 LPDDR4/4X 内存器件的选型提供扩展指导。在任何情况下，强烈建议遵循特定 SoC 的 NXP 硬件开发者指南中概述的 DRAM 布局准则。 i.MX 93 系列处理器支持不同的封装，每种封装都有其支持的最高 LPDDR4/4X 数据速率。请参考相应的数据手册。 注意：部分 LPDDR4/4X 器件可能不支持低速运行，此外，DQ ODT 可能无法激活，这会影响这些速度下的信号完整性。如果用例中计划采用低速运行，请咨询内存供应商有关内存器件的配置方面及可能的定制，以确保功能正常。 LPDDR4/4X - 最大支持的密度 SoC 最大数据总线宽度 最大密度 假设的内存组织 说明 i.MX 93 (i.MX 93xx) 16 位 16 Gb / (2 GB) 具有 17 行地址 (R0 - R16) 的单排、单通道设备 1, 2, 3   LPDDR4/4X - 已验证的内存列表 验证过程是一个持续的工作——预计该表格会定期更新。 SoC 密度 内存供应商 已验证的内存型号 说明 i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/（512 MB） Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U 7, 9 8 Gb/ (1 GB) ISSI LPDDR4: IS43LQ16512A-053BLI 4, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/（512 MB） JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 4Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8 Gb / (1 GB) AM（Alliance Memory） LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 2Gb / (256 MB) ISSI LPDDR4: IS46LQ16128A-062BSLI 4, 6, 8   注 1： 这些数值纯粹基于 DDR 控制器和 DDR PHY 的 IP 文档、为其集成到 SoC 中所选的实现参数设置、SoC 参考手册以及 JEDEC 标准 JESD209-4B/JESD209-4-1 (LPDDR4/4X)。因此，除非另有说明，否则它们没有经过验证支持，也不能保证内存供应商会提供具有特定密度和 / 或所需内部组织的 SoC。如果客户选择使用最大密度并在预期用例中采用，需自行承担风险。 注 2： 不支持任何密度的字节模式 LPDDR4/4X 器件（内部在两个芯片之间拆分的 x16 通道，每个 x8），因此，这些数值仅适用于具有 x16 内部组织的器件（在 JEDEC 规范中称为 “标准” 器件）。 注 3： 该 SoC 还支持双秩单通道器件，因此，16Gb/2GB 密度也可通过使用具有 16 行地址 (R0 - R15) 的双秩单通道器件来实现。 注 4： 该内存型号未经过完整的 JEDEC 验证，但通过了所有功能测试项目 注意事项 5： 这是一款双通道 x32 器件。由于 i.MX93 仅支持 16 位 LPDDR4/X 数据总线，因此它只能与其中一个通道接口，从而仅能利用该器件一半的密度。如表格中所示 —— 该器件具有 32Gb/4GB 密度，但只能使用 16Gb/2GB。使用双通道器件的其中一个通道没有功能问题，因为在 LPDDR4/4X 中通道是独立的。  注6： 这是一款新的 JEDEC 100 球封装，尺寸为标准 200 球封装的一半。这种 100 球封装具有与 200 球封装相同的性能和功能，并且具有比标准封装更小、更便宜的额外优势。 注释7： 该器件已被制造商停产，并已更新为新的内存型号。  注释8： 该型号处于活跃状态。于 2025 年 6 月审核。 注释 9： 该型号已过时。 注10： 该器件将在 24 年第二季度被制造商停产，且不会更新为新的内存型号。 注释 11： 在 TSA 分析期间发现了 DQ 眼图裕量问题。vTSA 和稳定性测试未发现任何问题。

i.MX 93メモリ互換性ガイド このドキュメントの目的は、i.MX 93シリーズのプロセッサでサポートされている、互換性のあるLPDDR4/4Xメモリ・デバイスを選択するために幅広い指針を提供することにあります。いずれの場合も、特定のSoCの「NXPハードウェア開発者ガイド」に記載されているDRAMレイアウト・ガイドラインに可能な限り従うことをお勧めします。 i.MX 93シリーズのプロセッサはさまざまなパッケージをサポートしており、サポートされる最大LPDDR4/4xデータ・レートはそれぞれ異なります。詳細は、各データシートを参照してください。 注：一部のLPDDR4/4Xデバイスは低速での動作をサポートしていない場合があります。また、DQ ODTがアクティブでない場合、低速時における信号の整合性に影響する可能性があります。低速動作での使用を計画している場合は、メモリ・デバイスの構成やカスタマイズの可否についてメモリのベンダーに確認し、正常な機能を確保してください。 LPDDR4/4X - 最大サポート密度 SoC データの最大バス幅 最大密度 想定メモリ構成 備考 i.MX 93 (i.MX 93xx) 16ビット 16Gb/（2GB） 17行アドレス（R0 - R16）を持つシングル・ランク、シングル・チャネル・デバイス 1, 2, 3   LPDDR4/4X - 検証済みメモリ一覧 検証プロセスは継続的な取り組みであり、テーブルは定期的に更新される予定です。 SoC 密度 メモリベンダー 検証済みメモリ部品番号 備考 i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7 4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/（512 MB） Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U 7, 9 8 Gb/ (1 GB) ISSI LPDDR4: IS43LQ16512A-053BLI 4, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/（512 MB） JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb/（256MB） Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb/（1GB） IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 4Gb/（512MB） Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8Gb/（1GB） AM（Alliance Memory） LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 2Gb/（256MB） ISSI LPDDR4: IS46LQ16128A-062BSLI 4, 6, 8   注1： 値は、IDDRコントローラとDDR PHYのIPドキュメント、SoCへの統合のために選択された実装パラメータの設定、SoCリファレンス・マニュアル、およびJEDEC規格JESD209-4B/JESD209-4-1（LPDDR4/4X）に基づいています。したがって、これらの値は、特に明記されていない限り、検証による裏付けがありません。また、特定の密度および/または希望する内部構成のSoCがメモリ・ベンダーから提供される保証はありません。ユーザーが最大密度の使用を選択し、目的とするユース・ケースでその旨を想定する場合は、自己責任の下でそうするものとします。 メモ 2: バイト・モードのLPDDR4/4Xデバイス（x16チャネルが内部で各x8の2つのダイに分割される）は、どの密度でもサポートされません。したがって、数値はx16の内部構成（JEDEC仕様では「標準」構成）を持つデバイスにのみ適用されます。 注3： SoCはデュアル・ランクのシングル・チャネル・デバイスもサポートするため、16行アドレス（R0 - R15）のデュアル・ランクのシングル・チャネル・デバイスを使用しても5密度16Gb/2GBを達成できます。 メモ 4： メモリ部品番号は完全な JEDEC 検証を受けていませんが、すべての機能テスト項目に合格しました。 メモ 5: デュアル・チャネルのx32デバイスです。i.MX93は16ビットのLPDDR4/Xデータ・バスのみをサポートするため、接続できるのは1つのチャネルのみであり、利用できるのはデバイス密度の半分にとどまります。表に記載されるとおり、デバイスの密度は32Gb/4GBですが、使用できるのは16Gb/2GBに限定されます。デュアル・チャネル・デバイスで1つのチャネルのみ使用しても、LPDDR4/4Xでは各チャネルが独立しているため、機能上問題はありません。  注6： 新しいJEDEC 100ボール・パッケージで、標準の200ボール・パッケージの半分のサイズです。200ボール・パッケージと同じ性能と機能を備えており、標準パッケージよりも小型で安価であるという利点もあります。 注７： メーカーによって生産終了となっており、新しいメモリ部品番号に更新されています。 注8： 部品はアクティブであり、2025年6月にレビュー済みです。 注9： 旧型の部品です。 注10： メーカーによって2024年第2四半期に生産終了となっています。新しいメモリ部品番号には更新されません。 注 11： TSA分析中にDQ目視で軽微な問題が発見されました。vTSAと安定性テストでは問題は見つかりませんでした。

MCX C15/C16 Product Training: Essential MCUs built for cost effective, low-end applications Picture1.png Welcome to MCX C15 and MCX C16 Product Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the MCX C15 and MCX C16 MCU family. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning.  Instructions  To get started with the MCX C15/C16 training, you will need to have your FRDM-MCXC162 in hand and perform the set-up operations according to the FRDM-MCXC162 Getting Started Page which is a pre-requisite.   Step 1. Mandatory pre-work before starting with the labs:  Getting Started with FRDM-MCXC162 Step 2. After completing the pre-work, download the lab guides. Each lab has its own guide document and a video guide you can use as support material in case you have any question at any step:  Lab0: Introduction to MCX C15/C16 and FRDM-MCXC162 Lab1: Low Power is a Superpower Objectives Download and run your first project from VS Code on the FRDM-MCXC16 Explore the basics of low-power modes Description Load the SDK low-power example, walk through the code flow, and review the available wake-up options. You'll also learn how to connect a current meter to the FRDM board to measure power consumption. Lab2: Low-Power Sensing Demo Objectives Download and run your first ACH example from VS Code on the FRDM-MCXC16 Explore a low-power sensing application Description Access and download examples directly from ACH in VS Code, then run a real-world low-power sensor use case. Lab3: PWM Lighting Demo Objectives Learn how to load firmware using LinkServer/LinkFlash and simple production-style scripts Explore the timer and PWM capabilities of the MCXC family Description Use a provided binary and step-by-step instructions to program the board. The demo controls the onboard RGB LED using PWM. Source code will also be available in ACH. Lab4: Connecting Expansion Boards to FRDM-MCXC162 Objectives Download an ACH example from VS Code Connect and use expansion boards with the FRDM-MCXC16 Description Connect an expansion board, download the example from ACH, and try a low-power sensing application using an external sensor. Additional requirements as below:  MikroE OLED B/W Click display in I2C mode SparkFun Qwiic dToF Imager (TMF8820) Qwiic board cable Step 3. Review the support material and useful links to get you up to speed with some product information, FRDM board information and Getting started. Below also includes additional reading material.   MCX C15/C16 Product Page  FRDM-MCXC162 Tool Summary Page  FRDM-MCXC162 Getting Started Page  MCX C1 Family Factsheet  MCX C15/C16 Datasheet   MCX C15/C16 Reference Manual  Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC

MCX C Knowledge Hub The MCX C series MCUs, powered by Arm® Cortex®-M23 up to 72 MHz or Arm® Cortex®-M0+ up to 48 MHz, are designed for cost effectiveness and efficiency, making them ideal for low-end Industrial and IoT applications. Featuring precision analog peripherals as well as USB and segment LCD options, these MCUs cater to diverse needs. The MCX C Series extends the classical IPs within NXP MCUs, providing flexible and scalable memory and packages. MCX C MCUs offer features like USB and segment LCD support, making them ideal for a wide range of general-purpose applications. With a focus on versatility, these MCUs provide the performance and scalability needed for today’s evolving technology demands. Documents: MCX C Series  MCX C Fact Sheet MCX C Series Products MCX C04x:  The MCX C04x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer 32 KB Flash, 2 KB SRAM, and 8 KB boot ROM. Designed as entry-level MCUs, they prioritize simplicity and ease of use for a variety of applications. Key peripherals include a 12-bit ADC, comparator and multiple-channel timer/PWM modules. The enhanced low-power architecture ensures efficiency, with static power consumption as low as 2.2 μA and a 7.5 μs wake-up time for full retention. In deep sleep, static mode power consumption drops to just 77 nA. This series supports scalable memory options and flexible packaging, accommodating diverse application needs. Documents: MCX C041 Sub-Family Reference Manual Data Sheet - MCX C04X Errata: MCXC041 Mask Set MCX C14x/C24x/C44x: The MCX C14x/24x/44x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer a range of memory configurations, from 32KB to 256KB Flash and up to 32KB SRAM, with 16KB Boot ROM. These entry-level MCUs are optimized for cost-sensitive and battery-powered applications requiring low-power USB connectivity and segment LCD support. The FlexIO technology enables customization for various serial peripheral emulation needs. They feature optimized low-power modes, achieving efficiency down to 54uA/MHz in very low-power run mode and 1.96 uA in deep sleep mode with retained RAM and RTC. Documents: Data Sheet - MCX C24x/C14x Data Sheet - MCX C44x Errata:  MCXC - x41 x42  Errata: MCXC - x43 x44 MCX C44x Sub-Family Reference Manual MCX C24x Sub-Family Reference Manual MCX C15/C16: The MCX C15 and MCX C16 microcontrollers (MCUs) are low‑cost, entry‑level devices featuring an Arm® Cortex®‑M23 core running at up to 72 MHz, with memory configurations offering up to 64 KB of flash memory and 16 KB of static random‑access memory (SRAM). These devices bring precision analog and control peripherals into the low‑cost, entry‑level MCU class, making advanced features—such as a 16‑bit analog‑to‑digital converter (ADC), comparator with digital‑to‑analog converter (DAC) and flexible pulse‑width modulation (FlexPWM) for motor control—accessible to cost‑sensitive IoT applications. Designed as an upgrade path from legacy 8‑bit and 16‑bit MCUs, as well as devices based on Arm Cortex‑M0+ cores, this entry‑level 32‑bit MCU series delivers higher performance and greater scalability without increasing costs. Documents: Data Sheet -MCX C151/C161/C162  Fact Sheet - MCX C1 Family Reference Manual - MCX C15/C16  Boards: FRDM MCX C444: FRDM-MCXC444 is a compact and scalable development board for rapid prototyping of MCX C444 MCU. It offers industry-standard headers for easy access to the MCU's I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger.  FRDM-MCXC444 QSG Getting Started with FRDM-MCXC444 FRDM-MCXC444 Board User Manual FRDM MCX C242: FRDM-MCXC242 is a compact and scalable development board for rapid prototyping of MCX C242 MCU. It offers industry standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and on-board MCU-Link debugger. FRDM-MCXC242 QSG Getting Started with MCXC242  FRDM-MCXC242 Board User Manual  FRDM-MCX C041:  is a compact and scalable development board for rapid prototyping of MCX C041 MCU. It offers industry-standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger. FRDM-MCXC041 QSG Getting Started with FRDM-MCXC041 FRDM-MCXC041 Board User Manual MCX C to FRDM Board Mapping Supported MCU(s) Recommended Board Best fit for  Key Differentiators MCXC041 (16QFN, 24QFN) FRDM-MCXC041 Ultra-Low-cost entry-level designs  32KB flash - 2KB SRAM- 48MHz Cortex M0+ - LPUART - SPI - I2C - ADC MCX C141/ C142/ C241/ C242 /C441 /C442 / C444 FRDM-MCXC444 General-purpose USB and Segment LCD application Industrial / Consumer Up to 256KB Flash - 32KB SRAM - 48MHz Cortex-M0+ - USB FS 2.0 - SLCD - FlexIO - DMA 0 CAN-FD - Multiple UART/SPI/I2C MCX C151/ C152/ C161/ C162 FRDM-MCXC162 Motor Control Precision analog Power tools    medical devices Up to 64KB flash - 16KB SRAM - 72MHz Cortex-M23 - 16-bit ADC 2.4MSPS - FlexPWM - 4xUART - 45 GPIO   Application Notes: Software, Hardware and Peripherals: AN14321 Using Segment Liquid Crystal Displays (SLCD) Controller on MCX C444 MCU: This document describes the usage of the on-chip SLCD controller by enabling an SLCD device called S401M16KR. The S401M16KR is a four-digit 0.17-inch seven-segment LCD panel. AN14590 Running RT-Thread on MCUXpresso IDE: This document is intended for the users who are familiar with RT-Thread and want to port it to MCUXpressoIDE. It provides steps to streamline the porting process. The porting steps are applicable to other NXP chips also. This document uses FRDM-MCXC444 as an example. AN14319 FlexIO Emulating UART with IRDA: This application note introduces how to use the universal peripheral module FlexIO for emulating the UART bus with IRDA. The FlexIO peripheral, initially introduced on the MCXC242 and MCXC444 family, is a highly configurable module capable of emulating a wide range of different communication protocols. These communication protocols include UART, I2C, SPI, I2S, and so on. AN14322 USB to multi VCOM on MCX C444 Series MCU: This document describes how to implement a USB to functions of multiple VCOMs on MCX C444 series FRDM boards. AN14349 Emulating I2C Bus Controller by using FlexIO on MCX C: This application note lists the steps to use the FlexIO module for emulating the I2C bus controller Power Management:  AN14811 Estimated Power-on Hours for the MCX C04x, MCX C14x, MCX C24x and MCX C44x: This document describes the estimated product power-on hours (PoH) for the MCX C04x, MCX C14x, MCX C24x, and MCX C44x industrial MCUs. It uses the criteria from the qualification process. AN14332 MCX C444 Power Mode Switch Application: This application note focuses on the power management controller (PMC), system mode controller (SMC), Multipurpose Clock Generator Lite (MCG-Lite), and Low-Leakage Wakeup Unit (LLWU). Training: Design without Bounds FRDM Training and Resources FRDM Training Hub MCX C15/C16 Product Training Useful Links: FRDM Boards Enclosures (3D Print) MCX C:  How to Enter the ROM Bootloader to Update the firmware MCUXPresso for Visual Studio Code - MCX MCUXpresso Config Tool for MCUXpresso IDE MCUXpresso Config Tool for 3rd party IDE Download Firmware to MCX microcontrollers over USB, I2Cm UART, SPI, CAN Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here    MCXC

i.MXRT1176 上的 WiFi (SDIO) 断开连接与 Qt/QML UI 的复杂性相关 大家好， 我们目前正在研发一款具有屏幕镜像功能的仪表盘。在我们的架构中，配套的移动应用程序通过 Wi-Fi 将帧流传输到我们的主机 MCU。数据通过 SDIO 连接的 Wi-Fi 模块接收，使用 FFmpeg 解码，并在显示屏上呈现。我们的网络协议栈采用 lwIP，集群 HMI 的 MCU 采用 Qt。 系统规格： 主机MCU： NXP i.MX RT1176 Wi-Fi 模块： u-blox MAYA-W161（SDIO 接口） 显示屏： LCDIFV2（并行RGB接口） 操作系统： FreeRTOS 问题：我们遇到了间歇性的 Wi-Fi 断开连接问题，这似乎与图形负载直接相关。只有当显示器运行资源密集型 GUI（包含大量元素和动画）时，才会出现 Wi-Fi 掉线的情况。切换到轻量级用户界面后，Wi-Fi 连接依然非常稳定。 请指导我们如何解决这个问题。 此致， 维格内什 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 你好@Vignesh_VInayak ，希望你一切都好。 由于图像处理需要较高的 CPU 使用率和较大的内存占用，因此对于 GUI 相关应用程序，两个核心中的一个将是专用的，用于管理界面。请问您的实现方案是否使用了两个核心？每个线程是否有专用的堆栈空间？ 此外，能否请您提供已启用调试日志记录的 Wi-Fi 协议栈日志，以便我们进一步分析 Wi-Fi 线程的状态？要启用调试日志，请在wifi_config.h 文件中启用“CONFIG_WLCMGR_DEBUG”和“CONFIG_WIFI_SDIO_DEBUG”宏。头文件？ Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 嗨@RomanVR ， 感谢您如此迅速地回复我。 请查看下方所需详细信息和日志： 目前，我们的项目只使用 Cortex-M7 内核；没有使用 M4 内核。 是的，所有线程都已分配了足够的堆栈空间。我们还使用 FreeRTOS 堆栈溢出钩子函数验证了这一点，没有发生溢出。 我已附上启用建议宏后的日志文件。在日志中，最后一个 wlcm 日志之后的所有内容都是我们的应用程序日志，每当收到 Wi-Fi 数据包时，这些日志都会打印一些随机帧大小。如您所见，日志在某个点停止了——这就是 Wi-Fi 断开连接发生的地方。断开连接的那一刻，我们没有看到来自 wlcm 或 SDIO 的任何日志。 此致， 维格内什。 Re: WiFi (SDIO) disconnects on i.MXRT1176 correlated with Qt/QML UI complexity 你好@Vignesh_VInayak ， 请问断开连接后，应用程序的其他部分（包括显示）是否还能正常运行？如果情况属实，能否请您分享一下您的线程优先级配置？ 关于前面的问题，能否请您分享一下正在运行的线程的 FreeRTOS 运行时统计信息？ 为此，您需要在FreeRTOSConfig.h中启用“configGENERATE_RUN_TIME_STATS”。文件并定义一个任务，定期调用 FreeRTOS API“vTaskGetRunTimeStats”，并将结果打印到终端。这将提供有关每个线程 CPU 使用率的有用信息，并缩小 Wi-Fi 断开连接的根本原因范围。与此相关的是，由于显示应用程序会导致较高的 CPU 负载，因此强烈建议采用双核架构，以确保高负载应用程序的正确执行。

Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G274A hello expert We are investigating an unexpected dependency between QuadSPI and the PFE HIF data path on an S32G274A running QNX 7.1. If QuadSPI is not initialized, PFE0 and PFE2 complete PHY, EMAC, firmware, and HIF initialization successfully. The EMAC can receive valid frames, but the HIF DMA does not consume TX or RX descriptors, so packets are not transferred between PFE and DDR, and ARP/ping fails. After reducing the QuadSPI initialization sequence step by step, we found that a single write is sufficient to restore PFE communication: writing 0x020F000C to the QuadSPI Module Configuration Register, QuadSPI_MCR at offset 0x0000 from QuadSPI base address 0x40134000—that is, physical address 0x40134000. If this write is removed, PFE communication consistently fails. Flash identification, JEDEC transactions, the QNX F3S framework, /dev/fs0, and startup delay have all been excluded as necessary conditions. Our current interpretation is that the relevant effect may be clearing QuadSPI_MCR[MDIS] to 0, which enables the QuadSPI clocks. Could you please confirm whether clearing QuadSPI_MCR[MDIS] can activate any clock request, bridge, or interconnect state shared with the PFE HIF DMA-to-DDR/XBAR/NoC path on S32G274A? Is there any undocumented or indirect dependency between PFE HIF DDR access and the QuadSPI clock or interconnect state, or could this indicate a missing shared-clock/NoC initialization step during platform startup? Which MC_CGM, RDC, MC_ME, NoC, or PFE platform register should be configured to establish the required state independently, instead of having the PFE driver access the QuadSPI MCR? We are currently performing complementary tests to confirm whether clearing MDIS alone is both necessary and sufficient; at this stage, the confirmed trigger is the complete MCR write value 0x020F000C. Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Thank you for contacting us. 1. Are you using a customer board? 2.What is your PFE version? BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, Yes, we are using a custom board based on the S32G274A. PFE0 and PFE2 are connected through RGMII to KSZ9031 PHYs. The operating system is QNX 7.1. The PFE software versions are as follows: - NXP PFE QNX driver version: PFE-DRV_S32G_QNX_1.9.0 - PFE firmware version: PFE-FW_S32G_1.12.0 - PFE hardware version reported by the driver: 0x00050300 Please let me know if you need the complete startup log, clock configuration, schematic section, or register dump for comparison. Best regards, Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi, Thank you for your reply. 1.What is your method of S32G booting? Was there no initialization of QSPI in the early stage? 2.Try operating only the MDIS bit to see if it affects the results. BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, 1. We load the QNX IFS and DTB via TFTP in U-Boot and start QNX with bootm. QNX is not loaded from QSPI Flash. Before starting the PFE driver, QNX does not start devf-qspi-s32g or explicitly initialize the QuadSPI controller. 2. We tested the MDIS bit using read-modify-write operations on the QuadSPI Module Configuration Register (QuadSPI_MCR, base address 0x40134000, offset 0x0000). Test A — No QuadSPI MCR operation The QSPI driver was not started and QuadSPI_MCR was not written. PFE communication failed. Test B — Set only MDIS MCR before = 0x030F00CC MCR write = 0x030F40CC MCR after = 0x030F40CC MDIS = 1 PFE Communication successful Only MDIS, bit 14, was changed from 0 to 1. The QSPI Flash filesystem was not started, /dev/fs0 was not created, and no JEDEC access was performed. The test program exited normally after the register operation. Test C — Clear only MDIS The initial MDIS value was already 0, so the unchanged MCR value 0x030F00CC was written back. PFE communication failed. We also previously tested writing the complete value 0x020F000C to QuadSPI_MCR. PFE communication succeeded in that case. Could you please advise why setting only the QuadSPI MCR MDIS bit from 0 to 1 affects PFE0/PFE2 communication on S32G274A? Is there any required initialization sequence, known erratum, or documented dependency between QuadSPI MCR operations and the PFE HIF/DMA-to-DDR path? BR, Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Thank you for your reply. I am currently conducting an internal investigation into this matter for you. I will get back to you with the progress! BR Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang Sorry for the late reply. Based on internal information and discussions with experts, there is no special dependency  between QSPI and PFE. It is recommended to check the issue through the following methods.  1. At the ATF/uboot initial stage and the QNX stage, disable QSPI. 2. Test the functionality of PFE during the U-boot stage. 3. If you need further assistance, if you could share some of your resources. For instance, you could provide an Image that can reproduce your problem. Please use the following link for posting you resource:https://support.nxp.com BR Joey