Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
FS6500 IO2_3/FCCU障害におけるデバッグモードと通常モード間の動作の不一致 こんにちは!   FS6500のIO2_3ピンはMCU FCCUに接続されています。   デバッグモードでは、FCCUの障害が1回発生すると、即座にリセットされます。   通常動作モードでは、FCCUの障害が1回発生すると、SBCはディープフェイルセーフ(DFS)モードに移行します。 この行動が予想されるものかどうか確認してもらえますか? 私の理解では、IO2_3の障害が発生すると、障害エラーカウンタが増加します。セーフティ応答(RSTBパルス、FS0Bアサーション、またはDFS遷移)は、フォールトエラーカウンターが設定済み閾値(3または6)を超えた場合にのみ行われます。 FS6500開発キット-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、ピーターさん。 ご説明いただき、ありがとうございました。   もう一つ質問があります。   FS6500のデータシートとRMを徹底的に検索しましたが、FCCUフォルトによって引き起こされるセーフティメカニズム戦略や対応するIMPACTレジスタ構成についてのドキュメントIO2_3ほとんど見当たりません。 以前は、故障IO2_3 Fault Error Counterが増加し、カウンターが閾値に達した後にセーフティ対策が適用されると思っていました。あなたの返信によると、IO2/IO3の故障がセーフティレスポンスを直接トリガーします。   マニュアルのどの章でIO2/IO3の直接セーフティ反作用の設定が説明されているか教えていただけますか? よろしくお願いいたします。 Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 この挙動は、SBCが両方のテストで同じ動作状態でない場合に予想されます。 以下の点を区別してください。 MCUのデバッグモード、例えばMPCデバイスに接続されたデバッガー、 FS6500のデバッグモードは、FS6500のDEBUGピンを介して起動します。 FS6500がデバッグモードの場合、ウォッチドッグは内部的に動作しますが、リセットピンやフェイルセーフピンをアサートすることによってデバイスの動作に影響を与えることはありません。したがって、デバッグ中に観察される挙動は、単独または通常の動作とは異なる場合があります。このモードは、SBCがシステムを継続的にリセットすることなくソフトウェアデバッグを可能にすることを目的としています。 通常動作時、FS6500フェイルセーフ状態機械は設定されたセーフティ入力や反応を監視します。IO_2/IO_3がMCU FCCUエラー出力監視に使用される場合、SBCはFCCUフォルトを検出し、設定されたリアクションを実行することができます。例えば、構成に応じてFS0B/RSTBのアサーションなどです。 したがって、デバッグモードとスタンドアロンモードの違いは必ずしもMCUのFCCUの問題ではありません。これはおそらくFS6500がデバッグモードに入っているか、両CASE間のSBC初期化・構成の違いが原因です。 障害エラーカウンタは、通常、ウォッチドッグ監視やフェイルセーフ状態機械処理などのメカニズムに関連付けられています。FCCUが報告したセーフティクリティカルな故障は、カウンタが閾値に達するまで蓄積されるのではなく、直接設定された反応をトリガーすべきです。 したがって、即時のセーフティ応答の観察された挙動は意図されたセーフティ概念と整合しています。 よろしくお願いいたします。 ピーター Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode こんにちは、 重要な点は、FS6500はIO2/IO3 FCCUの監視を、他のほとんどの故障源とは異なる方法で処理するという点です。 この説明はFCCUの故障反応(IMPACT)表には記載されておらず、代わりにFS6500のフェイルセーフ故障マネジメントドキュメントに記載されています。 [[ ## completed ##]] FS6500のドキュメントによると、IO_23エラー検出(FCCU)は、常にフォールトエラーカウンターを増加させ、設定できないフォールトソースの一つとしてリストされています。ドキュメントでは、設定可能な故障源とは明確に区別されています。 したがって、IO2/IO3障害時に観測される動作は、設定可能なフェイルセーフ反応に使用されるIMPACTレジスタの設定のみによって制御されるわけではありません。IO2/IO3 FCCUモニターは、SBCの専用FCCU監視パスの一部であり、フェイルセーフ状態マシンによって処理されます。 確認すべき関連セクションはFS6500のドキュメント章 "故障エラーカウンター" で、以下のように記載されています。 [[ ## completed ##]] IO_23エラー検出(FCCU)は、障害エラーカウンタをインクリメントします。 この動作は設定変更できません。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html よろしくお願いいたします。 ピーター
記事全体を表示
UM11490とBluetooth Classic NXPサポートの皆様、 お客様の一人がUM11490の149ページから以下のコマンドを実行していますが、波形が見えません。 追加のコマンドや条件が不足していないか、ご確認ください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 ------------------------------------ # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 39 00 00 00 --------------------、TXトランスミッションの前にBLEとCLASSICのスキャンを止めること---------------- # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # BLEスキャンを無効に root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 00 > HCIイベント:0x0eプレン4 01 1A 0C 00 # クラシックスキャンを無効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCIコマンド:ogf 0x08、ocf 0x000c、プレン2 00 00 > HCIイベント:0x0eプレン4 01 0C 20 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 63 07 00 00 **テストモードに入る前にスキャンを無効にすると、TX送信の停止により次のようになります。 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント:0xffプレン6 19 01 ED 04 00 00 Wi-Fi 5GHz用 -------------------------------------------------------------------------------- パラメータ: 連続送信、帯域幅 = 40 MHz、802.11ac、DFSなし、CH = 40、MCS0 (13.5)、電力 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 SDCMD52RW=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 バンド=1 BW=1 チャネル=44 radio_mode[0]=3 radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 0 4294967295 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic こんにちは、 @Christine_Li さん。 文脈が抜けていて申し訳ありません。 カーネルバージョン:lf-6.6.52-2.2.2(6.6.yとマージ済み)コミュニティカーネル FWバージョン:IW612-18.99.3.p25.7、BT/WiFiファームウェアは別々、コンボは不可 製品:IW612 UM11490 バージョン: Rev.1.8 — 2025年6月2日 以下の詳細は近日中に公開されます ファームウェアをロードしたときのdmesgログまたはコンソールログ スペクトラムアナライザの設定画面のスクリーンショット その間、他に何か必要なことがございましたら、お知らせください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 Re: UM11490 and Bluetooth Classic こんにちは、 @pierluigi_p どのWi-Fi/Bluetooth製品を使っていますか? Linuxカーネルのバージョンは何ですか?WiFi/BluetoothドライバとFWバージョンは? コマンドログからは、すべてのHCIコマンドが正常に完了し、TXスタートコマンドがコントローラに受け入れられます。さらに、TX停止コマンドで返されるベンダー固有のイベント情報にはゼロでないパケットカウンタが含まれており、これはコントローラがテスト期間中にパケットが送信されたと判断していることを示します。 したがって、この問題はテストシーケンスにおけるHCIコマンドの欠落が原因ではないと考えられる。 確認することをお勧めします: スペクトラムアナライザの中心周波数とスパンの設定。 TXテストコマンドで設定したBluetoothチャネル。 基板上のRFアンテナ構成。 Bluetoothファームウェアが正しくロードされているかどうか。 また、以下のことも教えていただけますか: 使用されているチップはどれですか(IW416/IW612など)? 正確なUM11490のバージョンは? ファームウェアをロードしたときのdmesgログまたはコンソールログは? コンボファームウェアをインストールしていますか、それともBluetooth専用ファームウェアをインストールしていますか? スペクトラムアナライザの設定画面のスクリーンショットはありますか? よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、ピアとクリスティーン 私はHelbert、Verisciteフォーラムでスレッドを始めた開発者です。 テストに関する添付ファイルは以下のとおりです。 dmesgログ(電源設定なし): dmesgログ(電源設定を含む): スペクトラムアナライザと5GHz帯の設定ファイル(自社実装およびNXP実装)のスクリーンショット 5GHz-running-test.png 実行後 5GHz-after-test.png 注:電力に-1を使用するとデフォルト値が使用されることがわかりましたが、異なる値も実験しました。 NXPスクリプト: NXP-5GHz-running-test.png 定番のBluetoothテストのスクリーンショット: Bluetooth-2.4-Classic-RUNNING.png ご覧の通り、波形は生成されません BLEテスト実行時のスクリーンショット: BLE-RUNNING-2.4-CH2.png BLEテスト後のスクリーンショット(波形が途切れています): BLE-FINISHED.png 下の図で、テスト終了時に波形が中断されたことがわかります Modinfoのログ: テストされたHCI CMD: Re: UM11490 and Bluetooth Classic 補足ですが、HackRFの異なる設定(ゲインやグラフィック調整)で試したところ、2.4GHz(Wi-Fi)波形が見えます。さらに、imx-firmwareリポジトリ内の異なるバージョンの異なるファームウェアをテストし、RF-test用のファームウェアも含まれています(sduart_nw61x_rftm_v1.bin.se)は https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se)で成功しませんでした。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細を教えていただきありがとうございます。 あなたの情報とスクリーンショットを確認してから、返信します。 少々お時間をください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 詳細情報をご提供いただきありがとうございます。 あなたのスクリーンショットには背景ノイズが少ししか映っておらず、有用なRF波形情報はありません。 お尋ねしてもよろしいでしょうか? 1.弊社のIW612-EVKをご利用ですか?または、どのモジュールでも構いませんか?モジュールに関するものであれば、モジュールの部品番号を教えていただけますか? 2. ハードウェアと試験装置との接続状況はどうですか? 3.ご質問はBluetoothに関するものですか、それともWi-Fiに関するものですか? BTの場合、RFテストガイドでテストコマンドが見られますが、停止コマンドは以下の通りです: hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF しかし、あなたは以下を送信しています: root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 実行する際は、ガイドに記載されているコマンドに正確に従ってください。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。確認していただきありがとうございます。 1.弊社のIW612-EVKをご使用ですか?それとも他のモジュールをご使用ですか?モジュールをご使用の場合は、モジュールの部品番号をお知らせいただけますでしょうか? 当社では、このモジュールをSoM Variscite DART-IMX8Mに統合しています。https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-plus/dart-mx8m-plus/ 部品番号はLBES5PL2EL.4です。 2. テスト機器とのハードウェア接続はどうですか? HackRF One機器を通じて無線で機器の無線にアクセスでき、アンテナで信号をキャプチャできます(他の信号も受信できます。これがノイズが見られる理由です) 3 - 質問はBTですか、それともWi-Fiですか? どちらの場合にも当てはまります。クラシックなBluetoothでは生成された波形が見えず(Bluetooth Low Energyのみ)、Wi-Fiでは5GHz帯の信号をキャプチャできませんでした HCIコマンドについては両方見ましたし、NXP/Murataの文書でも推奨されています AN14114では、47ページに短いコマンドがあります UM11490では150ページに長いコマンドがあります クラシックなBluetoothについては、解決策を見つけたと思います。UM11490を確認すると、コマンドの説明は次のようになります。 hcitool -i hci0 cmd ドキュメントの例では、tx_test_intervalを0x0Dに設定していますが、このシナリオでは間隔が少し長くなるため、生成された波形が見づらくなります。それはノイズのように見える。このパラメータを0x01に設定すると、波形が一貫しているのが見えました。さらに、低帯域幅の波形であるため、周波数範囲を狭めました。これでBluetoothの問題は解決したと思います。 しかし、5GHzの波形はまだ確認できません。何かコツはありますか? ご協力ありがとうございました。 Re: UM11490 and Bluetooth Classic クリスティーンさん、私の使用済みSoMに別の村田モジュールが搭載されている可能性が指摘されました。地雷を分解してみると、部品番号が「LBEE5PL2DL」であることが分かりました。 したがって、2ELのコマンドがこのモデルにも適用されるかどうかを確認しなければなりません Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 初期キャプチャの帯域幅を40MHzから20MHzに変更してみていただけますか? echo "tx_frame=0" >> /proc/mwlan/adapter0/config echo "bw=0" >> /proc/mwlan/adapter0/config 読み上げ結果によると  bw=1  AN14114では次のように定義されています。 40MHz ;  bw=0  は 20MHz 。 HackRFによる観測においては、20MHzの方が最初のテストとして適しています。なぜなら、40MHzのWi-Fiは、狭帯域または限界に近いSDR設定では、きれいに捕捉/認識するのが難しいためです。 20MHz帯で正常に動作するかどうか教えてください。次に、段階的に40MHzへと移行します。   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 情報ありがとうございます。Bluetoothが正常に動作するようになったとのこと、良かったです。 では、Wi-Fi 5GのRFテストモードの問題に焦点を当てましょう。 LBEE5PL2DLモジュールのチップセットは、NXP製のWiFi/BluetoothチップセットであるIW611です。 IW611とIW612の違いは以下の通りです:IW612は802.15.4をサポートしています。しかしIW611はサポートしていません。 しかし、Wi-FiとBluetoothに関しては、IW611とIW612は同じです。 つまり、 2ELのコマンドはこのモデル(LBEE5PL2DL)にも適用できるということです。 では、AN14114のセクション「2 Wi-Fi RFテストモード」に従ってボードを設定し、WiFi 5G RFテストを開始するのを手伝ってください。 現在、あなたが共有してくれた cat /proc/mwlan/adapter0/config の結果からは、疑わしい点は見つかりません。唯一の注意点は、テスト機器の接続とハードウェアの接続を確認することです。 同時に、これら2つのモジュールでRFテストがサポートされているかどうか内部で確認させてください。確認したのは、IW611またはIW612のEVKボードでテストは可能ですが、これら2つのモジュールについては、RF性能をテストするためにハードウェアの再作業が必要かどうかを確認する必要があるということです。 何か進展があればお知らせします。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティーンさん。 サポートありがとうございます。 もう少しデバッグしてみたところ、潜在的な問題点が見つかりました。ここで提供されているファイルを使用してリージョンを変更する場合: https://github.com/murata-wireless/nxp-linux-calibration/tree/imx-6-6-23/murata/files/2DL、IWのレギュレーションセットに問題があることに気づきました 基本的には、ここに投稿されているアイデアに従ってください:https://murata.my.site.com/muratacommunity/s/question/0D5RC00001HGuiQ0AT/rf-test-mode-firmware-and-tools-for-murata-type-2dl-module-not-working  2EL(および2DL、同じです)用のファイルを使いましたが、リージョンを切り替えた際にiwレジスターの位置が変わっていないことが確認でき、以下のメッセージが表示されました: HelbertPaulino_0-1784905230306.png したがって、ファイル *txpower*.bin でドライバーが使用する領域を変更する際、システムリージョンを変更していたわけではありません。選択した地域や無線機に適用した設定によっては、波形の発生を阻止できる可能性があることが分かりました。 regulatory.db* を削除しました村田製作所から提供されたファイルを使用し、オリジナル版を使用しましたが、動作が改善されたようです。5GHzの波形をいくつか検出できた一方で、ノイズで隠れていると思うものもあります iw reg set/reg と使用されたレギュレーションファイルが波形生成に影響を与えるか確認してもらえますか? もしそうなら、問題の根本原因を見つけたと言えるでしょう。ファームウェアやスクリプト、キャリブレーションファイルの問題ではなく、地域制限の問題です。これは理にかなっていると思いますか?それとも他に容疑者をご存知ですか? 改めてありがとうございました。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。このメッセージに気づかず、別のメッセージに返信してしまいました。 はい、色々なBW設定を試しましたが、問題はリージョンの制限や一部のリージョンでのノイズに起因するのではないかと考えています。 Re: UM11490 and Bluetooth Classic やあ、クリスティーン コマンドを確認していたのですが、あなたの言う通りですが、なぜそのパラメータ(SHORT_PREAMBLEとADVANCED_CODING)が-1(次のように表される)として表示されているのか分かりません4294967295) おそらく最初の実装で誤って-1に設定されていたのかもしれません。しかし、ご要望に返答すると、5GHz(tx_frame)の波形を生成できるようになりました。tx_continuousでは波形は見えましたが、振幅が小さい(ほとんど見えないほどです) 下の写真でフレーム生成の様子を見ることができます: 5GHz-CH100-BW40-FRAME-0x1100-14.png 連続音をトリガーしようとしたとき、波形は見えましたが、とても滑らかでした 5GHz-CH100-BW40-CONTINUOUS-0x1100-14.png 上記の設定を使用しました。 チャネルの波形が見えない問題は、機器内のノイズが波形自体よりも大きいからだと思います。私はハードウェアチームに、より高性能なスペクトラムアナライザを使用して検証するよう依頼しました。生成されていない波形に関する質問を閉じるために、その回答を待っています。 では、領域についてですが、なぜ一部の波形が生成されないのか説明できると思いますか?   Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino 以下のコマンドで試してみてください。 echo "tx_continuous=1 0 0xAAA 0 3 0x1100" >> /proc/mwlan/adapter0/config tx_frameコマンドの代わりに? 以前の「cat /proc/mwlan/adapter0/config」の出力で、 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff 正しく認識されないのではないかと心配です。 よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino はい、誤ったリージョン/レギュレーションドメインの設定も、一部の5 GHz Wi-Fi波形が生成されない理由や、特定のチャネルで全く送信できない理由を説明できます。   貴社のハードウェアチームは、より高性能なスペクトラムアナライザを使用して検証を行う予定ですか? このCASEで他に何かCANことはありますか?   よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、クリスティンさん。 今回の確認と、彼らが別の無音環境で行ったテストの結果から、すべてが正常に機能していることが確認されたと思います。 サポートありがとうございます。 はじめまして Re: UM11490 and Bluetooth Classic こんにちは、 @HelbertPaulino ご返信ありがとうございます。すべてが正常に動作するようになったとのこと、安心しました。 では、このThreadの解決策として私の回答をマークしてくれませんか?SOすればこのCASEを終結CANできます。 また、FUTUREも他のトピックに関する質問があれば、どうぞ新しいCASEを作成してください。 いつでもあなたをサポートできることを嬉しく思います! よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic クリスティン、改めて本当にありがとう。 そうします 🙂
記事全体を表示
LS1046A DDR4 32GB DDR4 容量支持 你好, 我想知道LS1046A是否支持32GB DDR4内存。它是否兼容DDR3L? Re: LS1046A DDR4 32GB DDR4 Size Support 感谢yipingwang的及时回复,请问LS1034A支持的最大DDR内存容量是多少? Re: LS1046A DDR4 32GB DDR4 Size Support 1. LS1046A 是否支持 32 GB DDR4? 是的。 2. LS1046A 可以与 DDR3L 兼容吗? 不。 LS1043A 支持 32 位 DDR3L/DDR4 控制器,而 LS1046A/LS1088A 支持 64 位 DDR4 控制器。 Re: LS1046A DDR4 32GB DDR4 Size Support 根据 LS1043A 参考手册/产品简介,LS1043A 支持高达 32 GB 的 DDR/主内存。
記事全体を表示
PMIC Safety Configuration by MCU Hello NXP, From the FS26 Safety Manual, we understand that the fault reactions for the output regulators can be configured by the MCU during initialization. Could you please clarify whether this configuration requirement applies only to the output regulator fault reactions, (RSTB , FS0B & 01) of  PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 or whether the fault reactions for the internal voltage monitoring functions (e.g., VANA, VDIG, and other internally monitored supply rails) also need to be configured by the MCU during initialization? If the internal voltage monitoring fault reactions are not configurable by the MCU, can we assume that these reactions are fully managed internally by the FS26 PMIC? can you list which fault reaction does not required to be configured by the MCU and which requires  FSBC+PMIC Functional Safety Re: PMIC Safety Configuration by MCU You can refer to below picture showed: guoweisun_0-1785720521280.png ABIST can check VANA VDIG automatically not need configure. guoweisun_1-1785720570149.png
記事全体を表示
imx93 AHAB SGK サポート セキュア ブート署名用の SGK は imx93 でサポートされるようになりましたか、それとも SRK のみですか? アプリケーションノート12312「AHAB対応デバイスでのセキュアブート」の第3章には次のように書かれています。 注意: i.MX8ULP および i.MX93 の場合、現在リリースされているファームウェアでは SRK のみがサポートされています。 これはまだ当てはまりますか、それとも SGK は現在サポートされていますか?もしSOなら、どのファームウェアリリースからですか? Re: imx93 AHAB SGK support これは今でも真実です。SGK は i.MX93 ではサポートされていません。 よろしくお願いします。 Harvey Re: imx93 AHAB SGK support こんにちは、IMX91はどうですか?SGKをサポートしていますか?(リファレンス・マニュアルはそう示唆しています) [[ ## completed ##]]
記事全体を表示
通过MCU进行PMIC功能安全配置 您好,NXP, 根据 FS26 功能安全手册,我们了解到,输出调节器的故障反应可以在初始化期间由 MCU 配置。 请问此配置要求是否仅适用于输出调节器故障响应(RSTB、FS0B 和 01)? PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 或者, MCU在初始化期间是否也需要配置内部电压监测功能(例如VANA、VDIG和其他内部监控的电源轨)的故障响应? 如果 MCU 无法配置内部电压监控故障反应,我们是否可以假设这些反应完全由 FS26 PMIC 在内部管理? 能否列出哪些故障响应不需要由MCU配置,哪些需要配置? FSBC+PMIC 功能安全 Re: PMIC Safety Configuration by MCU 您可以参考下图: guoweisun_0-1785720521280.png ABIST 可以自动检查 VANA VDIG,无需配置。 guoweisun_1-1785720570149.png
記事全体を表示
SGTL5000XNLA3/R2 部分处于激活状态 大家好, SGTL5000XNLA3/R2 这个部件是否处于激活状态?我们可以把它用于新设计吗? 数据手册中提及的EOL Re: SGTL5000XNLA3/R2 is part is active 好的,谢谢你的回复。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 产品信息 | 恩智浦半导体 guoweisun_0-1785821314080.png 数据表显示: guoweisun_1-1785824177846.png
記事全体を表示
SGTL5000XNLA3/R2 is part is active Hi Team, is this part is active SGTL5000XNLA3/R2? Can we use it for new design Datasheet mentioned asEOL Re: SGTL5000XNLA3/R2 is part is active Ok. Thanks for the response Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 Product Information | NXP Semiconductors guoweisun_0-1785821314080.png datasheet shows : guoweisun_1-1785824177846.png
記事全体を表示
FS6500 IO2_3/FCCU故障在调试模式和正常模式下的行为差异 你好!   FS6500 的 IO2_3 引脚连接到 MCU FCCU。   在调试模式下,单个 FCCU 故障触发会导致立即复位。   在正常运行模式下,单个 FCCU 故障触发信号会导致 SBC 进入深度故障保护 (DFS) 模式。 请问这种现象是否属于预期行为? 我的理解是:IO2_3故障将增加故障错误计数器。只有当故障错误计数器超过配置的阈值(3 或 6)时,才应执行功能安全响应(RSTB 脉冲、FS0B 断言或 DFS 转换)。 FS6500 DEVKIT-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 嗨,彼得, 非常感谢您的解释。   我还有一个问题。   我仔细查阅了 FS6500 数据手册和 RM,但几乎没有文档介绍由 IO2_3 FCCU 故障触发信号所触发的功能安全机制策略以及相应的 IMPACT 寄存器配置。 之前我以为 IO2_3 故障会使故障错误计数器递增,功能安全措施会在计数器达到阈值后生效。根据您的回复,IO2/IO3故障会直接触发信号安全响应。   请问手册的哪一章介绍了IO2/IO3直接功能安全反应的配置? 顺祝商祺! Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好, 如果两次测试中 SBC 的运行条件不同,则可能会出现这种现象。 请区分以下各项: 例如,MCU调试模式,即调试器连接到MPC设备,以及 FS6500 调试模式,通过 FS6500 DEBUG 引脚进入。 当 FS6500 处于调试模式时,看门狗仍在内部运行,但它不会通过置位 RESET 或故障保护引脚来影响设备操作。因此,调试期间观察到的行为可能与独立组网 \(SA\)/正常运行时的行为有所不同。此模式旨在允许进行软件调试,而无需 SBC 不断重置系统。 在正常运行中,FS6500 故障保护状态机监测已配置的功能安全输入/反应。如果 IO_2/IO_3 用于 MCU FCCU 错误输出监控,则 SBC 可以检测到 FCCU 故障,并执行配置的反应,例如根据配置断言 FS0B/RSTB。 因此,调试模式和独立组网 \(SA\)模式之间的不同行为不一定是MCU FCCU的问题。这很可能是由于 FS6500 处于调试模式,或者两种情况下 SBC 初始化/配置存在差异造成的。 故障错误计数器通常与看门狗监控和故障保护状态机处理等机制相关联。FCCU 报告的功能安全关键故障应直接发出触发信号,以触发其配置的反应,而不是累积到计数器达到阈值。 因此,观察到的即时功能安全响应行为与预期的功能安全理念是一致的。 顺祝商祺! Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好, 关键在于,FS6500 对 IO2/IO3 FCCU 监控的处理方式与其他大多数故障源不同。 该描述不在 FCCU 故障反应 (IMPACT) 表中,而是在 FS6500 故障保护故障管理文档中。 根据 FS6500 文档,IO_23 错误检测 (FCCU) 被列为始终递增故障错误计数器的故障源之一,并且无法配置为关闭。文档明确将其与可配置故障源区分开来。 因此,观察到的 IO2/IO3 故障行为并非完全由用于可配置故障保护反应的 IMPACT 寄存器设置所控制。IO2/IO3 FCCU 监测器是 SBC 专用的 FCCU 监视路径的一部分,由故障保护状态机处理。 需要查阅的相关章节是 FS6500 文档中的“故障计数器”章节,其中指出: IO_23 错误检测 (FCCU) 会增加故障错误计数器。 此行为不可配置。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html 顺祝商祺! Peter
記事全体を表示
MCUによるPMICセーフティ構成 こんにちは、NXPさん。 FS26セーフティマニュアルから、出力レギュレータの故障反応は初期化時にMCUによって設定できることが理解されています。 この構成要件が出力レギュレーターの故障反応にのみ適用されるのか、明確にしていただけますか(RSTB, FS0B & 01) PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 また、 内部電圧監視機能 (例: VANA、VDIG、その他の内部監視供給レール)の故障反応も初期化時にMCUによって設定される必要があるのか? 内部電圧監視の故障反応がMCUで設定できない場合、これらの反応はFS26 PMICが内部で完全に管理していると考えてよいでしょうか? どの故障反応がMCUで設定不要で、どの回路が設定が必要かをリストアップできますか? FSBC+PMIC 機能安全 Re: PMIC Safety Configuration by MCU 以下の写真を参照してください: guoweisun_0-1785720521280.png ABISTはVANAのVDIGを自動的にCANチェックできます。設定は不要です。 guoweisun_1-1785720570149.png
記事全体を表示
RTC Power Calculation Hello NXP, We are calculating battery life for RTC for which active & sleep current are required for SNVS power domain in RT1176. However refer to datsheet IMXRT1170BIEC - Table13, page 35, only sleep current is given. Please let us know the factors affecting the active current and various calculations related to active current for the SNVS power domain. Re: RTC Power Calculation Hi @specneeraj , Thanks for your interest in NXP MIMXRT series! VDD_SNVS_IN supplies power to the SNVS/RTC domain. This domain is an always-on, low-power domain that primarily maintains the 32 kHz RTC, SNVS logic, and related wake-up and safety functions. Its current consumption is only weakly correlated with the active/sleep states of CM7/CM4; therefore, the VDD_SNVS_IN values for the SNVS mode listed in Table 13 are not omitted “sleep-only” data, but rather baseline values that can be used in RTC backup scenarios. If the coin cell only provides power when the main power source fails → Use the SNVS mode current estimate directly; If the coin cell also supplies power to VDD_SNVS_IN while the system is active, calculate the average current based on the active/SNVS duty cycle. The main factors affecting the SNVS current include temperature,  VDD_SNVS_IN  voltage, process variations, leakage from the 32 kHz RTC crystal/board, external leakage from SNVS-related pins, and whether the device has actually entered SNVS mode. Please refer to AN13104 for more details. Best regards, Gavin
記事全体を表示
Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi!   The IO2_3 pin of FS6500 is connected to the MCU FCCU.   In DEBUG mode, one single FCCU fault trigger leads to an immediate reset.   In Normal operating mode, one single FCCU fault trigger causes the SBC to enter Deep Fail-Safe (DFS) mode. Could you help confirm whether this behavior is expected? My understanding: The IO2_3 fault will increment the Fault Error Counter. The safety responses (RSTB pulse, FS0B assertion or DFS transition) should only take place once the Fault Error Counter exceeds the configured threshold (3 or 6). FS6500 DEVKIT-MPC5744P  Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi Peter, Thanks a lot for your clarification.   I have a further question.   I searched the FS6500 datasheet and RM thoroughly, yet there is little documentation introducing the safety mechanism strategy triggered by IO2_3 FCCU fault, as well as the corresponding IMPACT register configuration. Previously I thought IO2_3 fault will increment the Fault Error Counter, and safety actions take effect after the counter hits the threshold. According to your reply, IO2/IO3 fault triggers safety response directly.   Could you tell me which chapter of the manual covers the configuration of direct safety reaction for IO2/IO3? Best regards Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, This behavior can be expected if the SBC is not in the same operating condition in both tests. Please distinguish between: MCU debug mode, for example debugger attached to the MPC device, and FS6500 debug mode, which is entered through the FS6500 DEBUG pin. When the FS6500 is in debug mode, the watchdog still runs internally, but it does not affect device operation by asserting reset or fail-safe pins. Therefore, the behavior observed during debug can differ from standalone/normal operation. This mode is intended to allow software debugging without the SBC continuously resetting the system. In normal operation, the FS6500 fail-safe state machine monitors the configured safety inputs/reactions. If IO_2/IO_3 are used for the MCU FCCU error output monitoring, then an FCCU fault can be detected by the SBC and the configured reaction can be executed, for example assertion of FS0B/RSTB depending on the configuration. So the different behavior between debug and standalone mode is not necessarily an MCU FCCU issue. It is most likely caused by the FS6500 being in debug mode, or by a difference in the SBC initialization/configuration between the two cases. The Fault Error Counter is typically associated with mechanisms such as watchdog supervision and fail-safe state machine handling. A safety-critical fault reported by the FCCU should trigger its configured reaction directly rather than being accumulated until the counter reaches its threshold. Therefore, the observed behavior of an immediate safety response is consistent with the intended safety concept. Best regards, Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, The key point is that the FS6500 treats IO2/IO3 FCCU monitoring differently from most other fault sources. The description is not located in the FCCU fault-reaction (IMPACT) tables, but rather in the FS6500 fail-safe fault management documentation. According to the FS6500 documentation, IO_23 error detection (FCCU) is listed among the fault sources that always increment the Fault Error Counter and cannot be configured out. The documentation explicitly separates it from the configurable fault sources. Therefore, the behavior observed with an IO2/IO3 fault is not governed solely by the IMPACT register settings that are used for configurable fail-safe reactions. The IO2/IO3 FCCU monitor is part of the dedicated FCCU supervision path of the SBC and is handled by the fail-safe state machine. The relevant section to review is the FS6500 documentation chapter "Fault error counter", which states: IO_23 error detection (FCCU) increments the Fault Error Counter. This behavior is not configurable. https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html Best regards, Peter
記事全体を表示
Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a steering control system using Pulse Width Modulation (PWM) on NXP S32K3 microcontrollers. The application reads an analog input from a potentiometer (simulating a steering wheel) and converts it into a servo motor position. As the input changes, the servo motor reacts in real time, mimicking how steering systems work in modern vehicles. This example is based on Application Code Hub demonstrations for: PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 In this workshop, a POT Click simulates the steering wheel position. When the student rotates it, an analog voltage proportional to the angle is read by the MCU through the ADC, scaled in software, and converted into a PWM duty cycle. The PWM is generated by the Servo Click (configured by the MCU over I²C) and drives a Micro Servo motor SG 180°, whose angle tracks the potentiometer in real time. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic steering control system and the ideas behind EPS and steer-by-wire. Use the POT Click as a simulated steering-wheel input. Acquire analog values (0–3.3 V) using the ADC and understand analog-to-digital conversion. Perform signal scaling from the ADC range to a servo angle / PWM duty cycle. Generate PWM signals to drive a servo motor. Configure the Servo Click over I²C using the OE (Output Enable) pin. Recognize the actuation data flow: sensor input → MCU processing → PWM actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why steering functions are relevant for functional safety. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Potentiometer (POT Click simulates the steering-wheel position) Processing: S32K3 MCU (reads the ADC, scales the value, commands the actuator) Output: Servo motor controlled via PWM (Micro Servo SG 180°) This matches the classic flow of an embedded actuation system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The potentiometer generates an analog voltage based on its position The ADC converts this voltage into a digital value The application scales this value into a steering angle The system generates a PWM signal based on the angle The servo motor moves accordingly This loop runs continuously to ensure real-time control. Designer.png Steering Monitoring Application Architecture 4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The POT Click outputs 0–3.3 V depending on the wiper position. The ADC samples this voltage at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). The further the potentiometer is turned, the higher (or lower) the digital sample. ADC acquisition is the foundation of automotive sensing — used for torque, throttle, battery voltage, and many others. 4.2 Signal Scaling — From ADC to Servo Angle The ADC range (for example 0–4095) and the servo range (0°–180°, expressed as a PWM duty cycle) are different. The application performs a linear mapping so that one end of the potentiometer corresponds to one steering extreme and the other end to the opposite. This is the same scaling used in real EPS systems, where a hardware reading is converted into a normalized control command. 4.3 PWM — Pulse-Width Modulation and Servo Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A hobby servo such as the SG 180° interprets this duty cycle as a position command. In this demo, the PWM is not generated by the MCU itself but by the Servo Click's dedicated PWM controller, which the MCU configures over I²C — a typical embedded pattern that offloads time-critical signal generation and keeps the CPU free for application logic. 4.4 I²C — Configuring the Servo Click I²C — Inter-Integrated Circuit is a two-wire serial bus made of SDA (data) and SCL (clock). The S32K3 uses LPI2C1 on PTC6 (SDA) and PTC7 (SCL) to configure the Servo Click — PWM frequency, channel, and duty cycle. The OE — Output Enable pin on PTB17 is an additional control line that enables or disables the PWM outputs without reconfiguring the chip, which is also useful for a quick "safe stop" behavior. 4.5 POT Click as Steering Wheel The POT Click is a simplified, safe stand-in for a real steering sensor. The student rotates it by hand, the voltage changes, the MCU reads it through the ADC, scales it, and the servo reacts. 4.6 Data Flow at a Glance Physical rotation → analog voltage → ADC sample → scaled command (angle / duty cycle) → I²C configuration of the Servo Click → PWM signal → servo angle. This direct chain from the student's hand to the servo shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the steering application and process steering inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the steering application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Servo Click servo-click.jpg PWM driver board used to control the servo motor position. POT Click pot-click.jpg  Potentiometer module used to simulate steering wheel input. Micro Servo SG 180°                     micro-servo-motor-sg-180-degree.jpg Actuator used to convert control signals into steering movement. USB-C / 12 V supply — Provides power and enables programming and debugging of the system. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate steering wheel input and actuator control. Steering Control Monitoring on FRDM-A-S32K312 Steering Control Monitoring on FRDM-A-S32K344 S32K312_Steering.png  S32K344_Steering.png     Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the steering demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable (and 12V supply for S32K312) Attach click boards Verify wiring Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Rotate the potentiometer Observe servo movement Servo follows potentiometer position in real time 7. Signal Behavior and Control Logic Steering_Control_Signal.png Figure: Steering control signal mapping. The 12-bit ADC value (0–4095) is linearly mapped to a servo angle (0°–180°) and a matching PWM duty cycle (1.0–2.0 ms), with reference points at Left, Center and Right. At startup the servo moves to the neutral position; during operation, any input change produces an immediate, proportional reaction — implementing a basic steer-by-wire behavior. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE No Servo Movement Verify PWM configuration Check servo wiring Ensure correct power supply Incorrect Behavior Check ADC configuration Validate scaling function Ensure PWM duty cycle mapping is correct Unstable Movement Add signal filtering Check power stability 9. Extending the Application The basic implementation can be extended in several ways: Steering Range Control Restrict or extend the actuator's range of motion Define software-based limits to protect the mechanics Input Direction Inversion Reverse how the actuator responds to the input Useful for left-hand vs. right-hand drive calibration Noise Filtering Apply software filtering to stabilize readings Avoid jitter near the center position Scaling Logic Exploration Identify and analyze how the input is mapped to the output Connect software math with hardware behavior Fault-Handling Behavior Add a mechanism that reacts to a detected fault Transition the system into a safer state State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator control In real systems: Redundancy is required Fault detection mechanisms are implemented Systems must comply with ISO 26262 (functional safety standard) Steer-by-wire systems require high reliability since there is no direct mechanical link. 11. Conclusion This module demonstrates how a simple embedded system can implement steering control using ADC input and PWM output. It shows how: Analog input is acquired Data is processed in real time Actuators are controlled using PWM Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 S32K312_Steering_Demo.gif S32K344_Steering_Demo.gif The course provides a strong foundation for more advanced systems, including filtering, state machines, and safety-oriented designs.
記事全体を表示
Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers 1. Overview The application demonstrates actuator control concepts commonly encountered in automotive transmission systems using the FRDM-A-S32K344 development platform. The application showcases how analog input acquisition, signal processing, and actuator control can be combined to emulate the behavior of an automotive transmission control module. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Transmission Control Module On FRDM-A-S32K344  The demonstration uses a potentiometer as the primary input device, representing the driver's throttle command. The analog signal is sampled using the ADC peripheral and fed into a transmission model that simulates vehicle speed, automatically selects one of six forward gears or neutral, and estimates engine RPM. The current gear is physically indicated by a servo motor, while a DC motor reflects the throttle input through a variable PWM duty cycle, emulating the drivetrain response of a real vehicle.   The example highlights the interaction between analog sensing, ADC conversion, transmission control algorithms, I²C communication, PWM generation, and actuator control commonly found in automotive embedded systems.   More than a technical course, this program embodies the Eat-Sleep-Code-Repeat approach to learning, where students learn by doing. By repeatedly designing, coding, testing, and refining automotive embedded applications on real hardware platforms, participants build both practical skills and the confidence needed to tackle real-world engineering challenges. 2. Learning Scope This article focuses on both practical implementation and core embedded system concepts: Analog signal acquisition using ADC Potentiometer-based continuous control inputs PWM generation using the eMIOS peripheral I²C communication with an external PWM controller Servo motor position control through an external PWM driver DC motor speed control with a dead-band region Automatic gear selection with shift hysteresis Engine RPM estimation and smoothing Real-time embedded control loops running at a fixed update rate Signal mapping and actuator response The example provides a practical introduction to automotive control systems where continuous sensor values drive actuator behavior through a simulated transmission model. 3. System Architecture The system follows a typical embedded control structure organised around a periodic control loop: Input: Analog throttle signal from the potentiometer Processing: S32K3 microcontroller running the transmission model (vehicle speed, gear selection, RPM) Output: Servo motor position (via I²C to an external PWM controller) and DC motor speed (via eMIOS PWM) Functional Flow The potentiometer voltage is sampled by the ADC and converted into a throttle command The MCU updates the transmission model, computing the simulated vehicle speed and selecting the appropriate gear The current gear is sent to the external PWM controller through I²C, which positions the servo motor accordingly The DC motor speed is updated through an eMIOS PWM channel proportional to the throttle command The entire cycle repeats at a fixed update rate to keep the actuators synchronised Transmission_Control_Architecture.png Transmission Control Application Architecture 4. Key Concepts 4.1 Control Principle Unlike systems based on push buttons or digital switches, this implementation uses a continuous analog input signal. The potentiometer provides a variable voltage level that represents the driver's throttle command. This value is continuously monitored and converted into a digital representation using the ADC peripheral. The processed value feeds a transmission model that simulates vehicle speed, selects a gear, and estimates engine RPM, which are then translated into commands for the servo (gear display) and the DC motor (speed). This approach allows smooth transitions instead of abrupt state changes and better reflects real-world automotive control systems. 4.2 Analog Input Acquisition The potentiometer acts as a variable voltage divider. As the potentiometer position changes, the output voltage changes continuously, the ADC acquires the voltage, and the MCU converts it into a throttle percentage. This value becomes the primary input variable for the transmission model. This process mirrors how many automotive sensors operate, where physical movement or operating conditions are converted into an analog voltage signal that must be processed by the control unit. 4.3 Servo Motor Control via I²C and External PWM Controller Unlike the DC motor, the servo motor is not driven directly by an MCU PWM channel. Instead, the MCU sends I²C commands to an external PWM controller located on the Servo Click board, which in turn generates the PWM pulses required to position the servo shaft. The transmission model computes the current gear and provides it as an input; the MCU translates the gear number into a pulse-width value and sends it to the external controller. Each discrete gear position corresponds to a specific servo angle, so the servo acts as a physical gear indicator on a graduated scale. 4.4 PWM-Based DC Motor Control The DC motor is driven directly by the MCU through the eMIOS peripheral, which generates the PWM signal required by the DC Motor 2 Click H-bridge driver. As the potentiometer value increases, the PWM duty cycle also increases, resulting in higher motor speed. When the throttle is at zero, the motor is stopped; above zero, the duty cycle is clamped to a minimum dead-band value (approximately 20 % of the full range) to guarantee reliable motor start-up, and then scales linearly up to full speed. This mirrors the response of a real drivetrain to a throttle input. 4.5 Automatic Gear Selection with Hysteresis The transmission model implements six forward gears plus neutral. Rather than mapping the throttle directly to a gear, the model maintains an internal simulated vehicle speed, which increases when the throttle is applied and decreases when it is released. Gear selection is performed by comparing the vehicle speed against a set of predefined thresholds: An upshift occurs when the simulated speed rises above the upper threshold of the current gear. A downshift occurs when the speed drops below the lower threshold of the current gear. The distance between the up and down thresholds forms a hysteresis band, preventing rapid oscillation between two gears when the speed hovers near a shift point. When the throttle is held at zero for a sustained period, the model detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 4.6 Engine RPM Estimation In parallel with gear selection, the model estimates an engine RPM value based on the throttle input and the currently engaged gear. On each gear change, the RPM is smoothly adjusted — decreasing on upshifts and increasing on downshifts — to reproduce the characteristic behaviour of an automatic transmission. This smoothing avoids abrupt jumps and gives a more realistic feel to the simulation. 4.7 Signal Mapping The application transforms the continuous throttle input into two coordinated actuator commands: a discrete gear position displayed by the servo, and a continuous PWM level applied to the DC motor. The conceptual mapping is shown below. Throttle Input Transmission State Servo Position (Gear Indicator) DC Motor Speed 0 % (idle) Neutral Rest position Stopped Low 1st – 2nd gear Low-gear positions Dead-band minimum → low speed Medium 3rd – 4th gear Mid-range positions Medium speed High 5th – 6th gear High-gear positions Maximum speed This mapping demonstrates how a continuous sensor input can be transformed into both a discrete state (gear) and a continuous actuator command (motor speed). 4.8 Data Flow at a Glance Physical rotation of the potentiometer → analog voltage → ADC sample → throttle percentage → transmission model (vehicle speed, gear, RPM) → I²C command to the external PWM controller (servo position) and eMIOS PWM signal (DC motor speed). All stages are re-evaluated at a fixed update rate to keep the actuators synchronised. This direct chain from the student's hand to the actuators is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the transmission control application, execute the transmission model, and drive the connected peripherals through ADC, eMIOS PWM, and I²C. FRDM K64 click shield                  frdm-k64-click mikroBUS expansion adapter that connects Click modules to the FRDM board. Servo Click                          servo-click Expansion board carrying an external PWM controller. It receives I²C commands from the MCU and generates the PWM pulses that drive the servo motor. Micro Servo Motor SG 180°                         micro-servo-motor-sg-180-degree Actuator used to physically indicate the currently selected gear on a graduated scale. DC Motor 2 Click   dc-motor2-click Compact add-on board with a PWM-controlled, full-bridge brushed DC motor driver. It receives the eMIOS PWM signal directly from the MCU. DC Motor                       DC MotorDC Motor Simulates the vehicle drivetrain speed, reflecting the throttle input applied by the user. USB-C cable — Provides power and enables programming and debugging. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate a complete transmission control chain, from throttle input to gear indication and drivetrain speed. Transmission Control Full Setup on FRDM-A-S32K344 Transmission Full SetupTransmission Full Setup The hardware configuration allows simultaneous control of a position actuator (servo motor driven through I²C) and a speed-controlled actuator (DC motor driven through eMIOS PWM). Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) Application Code Hub project import Transmission Control Module On FRDM-A-S32K344  6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for transmission control example Use the GitHub link for automatic configuration Select main branch Import project Project appears in workspace 2 Build the Application Compile the project Check for errors Confirm SDK component management Successful build with no errors 3 Connect Hardware Connect the board via USB-C Attach FRDM K64 Click Shield, Servo Click and DC Motor 2 Click Wire the servo motor, DC motor and potentiometer Verify wiring before powering the system Board powers up and is detected by IDE 4 Flash and Run Program the MCU Start execution Application runs continuously 5 Functional Validation Rotate the potentiometer Observe the servo pointer moving between the gear positions Observe the DC motor speed changing proportionally to the throttle Release the potentiometer and observe the transmission gradually downshifting back to neutral Gear indicator and motor speed respond consistently to throttle changes 7. Signal Behavior and Control Logic The following diagram illustrates how the transmission model selects the current gear based on the simulated vehicle speed, applying a hysteresis band to prevent frequent shifting around each threshold.   Transmission_Gear_Selection.png The transmission continuously compares the simulated vehicle speed against a set of predefined speed thresholds, one per gear. An upshift occurs when the vehicle speed rises above the upper threshold of the current gear (blue lines), while a downshift occurs only when the speed drops below the lower threshold of that gear (red dashed lines). The distance between the two thresholds forms a hysteresis band that prevents rapid oscillation between adjacent gears when the vehicle speed hovers near a shift point. When the throttle is held at zero for a sustained period, the transmission detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 8. Troubleshooting Issue Possible Actions Board Not Detected Verify USB connection Check drivers Restart IDE DC Motor Not Responding Check eMIOS PWM configuration Verify motor driver wiring and external power supply Confirm code execution Servo Not Moving Check I²C wiring (SDA / SCL) and pull-up resistors Verify that the external PWM controller is powered Confirm the servo is connected to the correct channel and powered by 5 V Incorrect Behavior Validate the ADC input range Inspect GPIO configuration for motor direction pins Verify transmission control logic implementation Unstable / Jittery Output Add software filtering on ADC readings Check power supply stability Verify grounding between motor drivers and MCU 9. Extending the Application The application can be enhanced by adding: Closed-Loop Control Integrate feedback sensors to dynamically adjust actuator outputs Compare commanded vs. actual position/speed for corrective action Additional Transmission Modes Extend the current six-gear + neutral model with Park and Reverse modes for a full PRND emulation Map potentiometer regions or dedicated inputs to specific transmission states Safety Functions Implement input plausibility checks on the throttle signal Add fault monitoring and safe-state transitions in case of sensor or actuator failure CAN Communication Transmit gear, RPM, and speed information over CAN or CAN FD networks Integrate with larger automotive powertrain systems Continuous Versus Discrete Control Compare button-based (discrete) and potentiometer-based (continuous) input styles Emulate electronic throttle control, position sensing, or actuator positioning applications 10. Safety Context Transmission control is part of vehicle motion systems, requiring: Reliable signal processing Deterministic control behavior Safety-aware design In production systems: Redundant checks are implemented Fault detection is mandatory Standards such as ISO 26262 apply Automotive transmission control units also implement input plausibility checks and safe-state fallback strategies to prevent unintended gear engagement or actuator runaway. 11. Conclusion This transmission control demonstration illustrates how the S32K344 platform can combine analog sensing, ADC conversion, I²C communication, PWM generation, and actuator control to implement a complete embedded control application. Using a potentiometer as a continuous input source, the system processes the throttle signal through a transmission model with six forward gears plus neutral, hysteresis-based gear selection, and RPM estimation, and translates the result into real-time commands for both a servo motor (gear indicator) and a DC motor (drivetrain speed). The project provides practical insight into the operation of automotive control systems and serves as a foundation for more advanced transmission, actuator, and motion-control applications. Result on FRDM-A-S32K344 Transmission resultTransmission result The course provides a strong foundation for more advanced systems, including closed-loop feedback control, additional transmission modes, CAN communication, and safety-oriented designs typical of automotive transmission control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.
記事全体を表示
LPC55S69 SPI - DMA - リンク転送またはピンポン転送でうまくいかない もう長すぎるよ…。 単一のSPI/DMA転送の例を試してみましたが、これらは正常に動作します。 DMA/リンクメモリ転送のサンプルコードを確認しましたが、これらは正常に動作します。 しかし、どれも私の要件を満たしておらず、試してみても合うものが見つかりません。 最初は、リンク構成または単なるピンポン方式で、DMAを使用したフリーランニングSPI TX/RXが必要です。 きっとここには既にこれを実現した人がいて、その知識を共有してくれる人がいるはずですよね? これまでのところ、私ができた最良の方法は、SPI_DMA用のリンクされた設定のセットを作成することです。これは(最後の設定が最初の設定にリンクしているにもかかわらず)一度だけ実行され、その後停止します。 最悪のケースは、連結された16ビット転送に対して、単一の8ビット転送しか行わない場合だ。 アイデアが尽きてきて、おそらく既に失敗したことを試しているだけだと思う。 誰かいますか…? 全般 LPC55xx ペリフェラル Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers これは古い投稿だと分かっていますが、とにかく...問題は、送信転送の幅に関係しています。FIFOを設定するには、32ビット(16ビットのデータ + 16ビットの設定)である必要があります。そうでない場合、SPIのすべての設定ビットがゼロになり、発生している問題が発生します。 --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers こんにちは、 @IanMcCarthy さん。 遅れてしまい申し訳ありません。最近、異常なほど多くの質問を受けています。辛抱強く待ってくださり、本当にありがとうございます。 ご質問に関してですが、一度手動で起動(デバッグセッションで実行)すると、すべてのコードが無限に実行され、SPIからのSCK信号は2パルス以上(停止ボタンを押すまで連続して)生成されなければなりません。LPC55S69で使用しているSDKのサンプルコードはどれでしょうか?コードにどのような変更を加えましたか?そうすることで、あなたのコードを私のボード上で再現し、何が起こっているのかを確認できます。 ご協力いただき、本当にありがとうございました。他に質問があれば、遠慮なくお尋ねください。 よろしくお願いします。 パブロ・アバロス。 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 更新情報の投稿、3回目の試みです… スレーブSPIデバイスから一定のレートで継続的にデータを受信する必要があります(手動でトリガーする方法では要件を満たせません)。 以下のコードは現在の私の状態を示していますが、これはSPIクロックのプラス信号を2つ生成するだけで、それ以上何も起こりません。 SPIの設定が完了すれば、リンクされたDMA記述子のセットを設定でき、一度手動で起動すれば、その後は無期限に動作する、という理解で合っていますか?それとも間違っているでしょうか? どなたかお手伝いいただける方がいらっしゃいましたら、大変ありがたいです。 srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers あなたの答えを完全には理解できていませんが、もう少し詳しく説明してもらえますか?転送時のuint8_t型の幅を維持しないのはなぜですか? また、関数 DMA_SetupDescriptor() の 3 番目と 4 番目の入力パラメータの位置が間違っていることにも気づきました。 さらに、各ディスクリプタ宛先アドレスはデータを別のメモリ位置にリダイレクトすべきではないでしょうか?すべてが &masterTxData を指すのではなく。
記事全体を表示
有使用MCUXpresso经验的人请问,PRINTF宏的输出会输出到哪里? 我正在尝试调试 FRDM-KL25Z 上的一些代码,但我无法确定使用此宏时会将输出打印到哪个控制台。我不得不使用串口连接进行调试。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? 你好@kyoto5 感谢你的帖子。 MCUXpresso SDK 中的 PRINTF 不是标准的 C printf() 函数。这是一个 SDK 调试控制台宏,通常映射到 DbgConsole_Printf,其输出目标取决于项目的 SDK 调试控制台配置。 在 MCUXpresso IDE 中,SDK 项目可以配置为以下两种模式之一: - 半托管控制台 输出通过调试器连接发送到 IDE 半主机/控制台窗口,而不是通过 UART。 - UART 控制台 输出通过板载UART发送。在 FRDM-KL25Z 上,这通常作为 OpenSDA 虚拟 COM 端口暴露给主机 PC,因此您需要 Tera Term 或 PuTTY 等终端程序来查看它。 要在 MCUXpresso IDE 中将 UART 输出切换到 PRINTF,请参阅NXP 社区的“MCUXpresso 通常不会在‘hello world’示例中将 PRINTF 输出到控制台”一文。 希望对您有所帮助。 BR 塞莱斯特
記事全体を表示
sCheck 集成功能安全文档 设备:NXP S32K388 微控制器 元器件:SAF 软件包 - SW32K3_SAF_1.0.6_HF01_D2603,sCheck 插件(SRAM ECC 测试) 可用资料: S32K3xx 参考手册(S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf,sCheck UserManual、sCheck SRAM ECC 测试源代码。 差距:缺乏端到端的技术规范、设备寄存器映射、依赖关系交互和预期结果。 版本说明:明确指出以下版本存在一些限制 所需信息: 假定明确的功能安全目标和ECC方案 S32K388 中哪些 SRAM 实例/存储体/分区在范围内,哪些不在范围内 逐步流程包括初始化、故障注入方法、验证和恢复。 所需运行条件(时钟、MPU/XRDC 设置、缓存/TCM 状态、从 RAM/Flash 运行) 跨插件的前置条件/后置条件;元器件间初始化序列示例 SAF/sCheck/eMcem/SafetyBase 基于 S32K388 的版本兼容性矩阵 及格/不及格标准、结果代码及其解读方法 使用的中断、NMI 或错误报告路径;用于应用程序级处理的钩子/回调 Re: Safety documentation for sCheck integration 你好, 对于 sCheck 集成,请主要参考 sCheck 用户手册,特别是“软件集成”章节。本章包含集成要求、假设、内存段定义、链接器文件更新、MPU 配置要求以及任何特定于测试的先决条件。 除了 sCheck 用户手册外,请查阅相应的 S32K3 功能安全手册,其中列出了 sCheck (SM2.*.SCHECK) 涵盖的功能安全机制,并解释了它们在整体功能安全概念中的作用。 SAF 文档代码包,软件包还包含针对其他 SAF 元器件(sBoot、mSel、eMCEM、BIST 等)的模块特定集成指南。因此,集成要求分散在 SAF 模块用户手册中,而不是集中在一个独立组网 \(SA\) 功能安全集成文档中。 我们至少建议您查看以下内容: sCheck 用户手册 → 软件集成 查看用户手册 → 条件、限制和副作用 S32K3 功能安全手册 → SAF/sCheck 涵盖的功能安全机制 SAF 集成文档,涵盖链接器、MPU、启动和 API 集成要求 [[ ## completed ##]] 这些文档提供了将 sCheck 集成到功能安全应用程序所需的信息。 顺祝商祺! Peter
記事全体を表示
Imx6ull KSZ8041NLイーサネットの問題 こんにちは 、 私たちの潜在的なプロジェクトの一つにデュアルイーサネットを利用するために、Imx6ullプロセッサを搭載した2つのイーサネット物理線を接続しました。 一方のPHYはKSZ8081、もう一方のPHYはKSZ8041です。以下は当社のDTS構成です。 &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: イーサネット-phy@1 { reg = <1>; micrel、LEDモード = <1>; クロック = <&CLKS IMX6UL_CLK_ENET_REF>; クロックネーム = 「rmii-ref」; }; ETHphy1: イーサネットphy@3 { reg = <3>; micrel、LEDモード = <1>; クロック = <&clks IMX6UL_CLK_ENET2_REF>; クロックネーム = 「rmii-ref」; }; }; }; pinctrl_enet1: enet1grp { fsl、pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl、pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; イーサネットの物理はカーネルログで検出され、イーサネットケーブルを接続するとリンクも検出されています。 しかしIPはKSZ8081物理に接続されているイーサネットに届き、IPはKSZ8084NLに接続されているイーサネットに割り当てられていません。 そして、イーサネットKSZ8041NL eth0でrxエラーが観察されます。以下のログは以下の通りです: root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr BA:9C:69:1F:76:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:1065 ドロップ:0 オーバーラン:0 フレーム:1065 送信パケット数:65 エラー数:0 ドロップ:0 オーバーラン数:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:12024(11.7 KiB) eth1 リンク encap:イーサネット HWaddr 42:19:11:7F:5E:89 inet addr:10.20.0.184放送日時: 10.20.1.255マスク:255.255.254.0 inet6 アドレス: fe80::8248:9837:9647:2a00/64 スコープ:リンク UP ブロードキャスト実行中 マルチキャスト MTU:1500 メトリック:1 受信パケット数:18 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:23 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2494 (2.4 KiB) TX バイト:3162 (3.0 KiB) lo Link encap:ローカルループバック インターネットアドレス: 127.0.0.1マスク:255.0.0.0 inet6 アドレス: ::1/128 スコープ:ホスト UPループバック実行中 MTU:65536 メトリック:1 受信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2011 (1.9 KiB) TX バイト:2011 (1.9 KiB)   root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 自動交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された自動交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが自動交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 自動交渉:オン 移植版:ツイステッドペア ファイアド:3 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい   また、50MHzのクロックも確認しましたが、これは適切に生成され、PHY KSZ8041NLにも入力されています。 要するに、1本のイーサネットは正常に動作していますが、2本目のイーサネットは正常に動作KSZ8081 KSZ8041NL。 解決策をご提案ください。参考までに、両方のイーサネット物理ハードウェアのスクリーンショットも添付しています。 image (1).png image (2).jpg i.MX6 全て i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue NXPチームの皆様、こんにちは。 問い合わせ内容について、何か最新情報があれば教えていただけますか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、NXPサポートチームの皆さん、 私たちはすでに、私たちが直面しているイーサネットの問題について詳細を共有しています。 ですので、あなたの側で確認して、何か解決があれば教えていただけますか? 必要であれば、お電話にて貴社チームと問題について話し合うことも可能です。 貴社チームからの良いフィードバックをお待ちしております。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@HarshilSoni434 @ritesh_prajapat お元気でお過ごしのことと思います。 KSZ8041の回路図のストラップオプションを見てみましょう。 Manuel_Salas_0-1785172670273.png 分離モード:プルアップ(デフォルト)=有効 プルダウン= 無効にする PHYは、RMIIデータピン(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)をMACから切り離します。 MDIO/MDCは完全に機能しており、PHYも検出され、リンクパルスも生成されています。おそらくこれが、PHYが検出され、リンクがアップ状態に見える理由でしょう。 ISOLATEピンのR37をプルアップ抵抗 (~4.7kΩからGND)に変更してみてもらえますか? 次に確認すべき点はリセットピンです。リセットが正しくアサルされているか確認していただけますか? そして、reset_n信号が以下の接続点に合っているかを確認してください: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 次に、CONFIG[2:0] RMII のストラップが物理的に正しく接続されていることを確認してください。 また、KSZ8041の回路図の信号マッピング表には、次の情報が記載されています。 Manuel_Salas_1-1785173206995.png ネット名が入れ替わっているように見えます(MDCはenet_mdioとラベル付けされ、その逆も同様です)。 よろしくお願いいたします。 サラス。 Re: Imx6ull KSZ8041NL ethernet issue @Manuel_Salasさん、ご提案いただきありがとうございます。 お客様からいただいたご提案事項はすべて確認し、結果は大体本日中にご報告いたします。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@Manuel_Salas ご返信ありがとうございます。 ご提案通り、プルダウン抵抗の変更を行い、イーサネットの通信も確認しましたが、残念ながら挙動は同じです。 IPネゴシエーション中にRXエラーが発生しています。 また、以下の点についても確認いたしました。 - リセットピンは、imx6ullのピン接続に基づいて適切です。リセットラインに手動でパルスを印加したところ、PHY(KSZ8041NL)はリセットされましたが、動作は同じでした。 - MDIOとMDCのピンの入れ替わりは回路図上の問題であり、実際のハードウェアでは接続は正しく行われています。 つまり、変更後も動作は同じで、両方のPhyは検出されますが、IPはKSZ8081と共に出ていて、KSZ8041NLでは検出されません。以下は更新されたログです: root@sls-IMX6ull14x14evk:~# DMESG |グレップFEC [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 2.207221 FEC 2188000.イーサネット eth1: 登録済みPHCデバイス1 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14x14evk:~# DMESG |グレップ eth0 [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr 26:F5:A6:8C:73:42 inet6 addr: FE80::F2af:2D7A:228C:2038/64 Scope:Link UP放送 マルチキャスト実行 MTU:1500 メトリック:1 RXパケット:0 エラー:63 ドロップ:0 オーバーラン:0 フレーム:63 送信パケット:12 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:2093(2.0 KiB) eth1 リンク encap:イーサネット HWaddr 22:81:A6:66:8C:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 TXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:0(0.0 B) lo Link encap:ローカルループバック inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host ループバックを走らせる MTU:65536 メトリクス:1 RXパケット:91 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 送信パケット数:91 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 collisions:0 txqueuelen:1000 RXバイト:7797(7.6 KiB) TX バイト:7797(7.6 KiB) root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 車載交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された車載交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが車載交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 車載交渉:オン 移植版:ツイステッドペア ファイアド:0 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい ぜひご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん さらにイーサネットFECドライバ fec_main.Cへのデバッグも行いましたRXエラーの根CASEを特定するために。 その結果、ドライバがCRCの不一致エラー BD_ENET_RX_CRのためにすべてのrxパケットを無視していることがわかりました。 SO これを踏まえて、問題解決のためのご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 前回の観察結果に基づくと、何か最新情報はありますか? CRCエラーのため、すべての受信パケットが無視されることを改めてお知らせします。SO、何がその原因になり得るCANでしょうか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 おはよう、 すでに共有された問題に関する直近のアップデート@HarshilSoni434確認する機会はありましたか?CRCミスマッチの受信パケットの正確な問題を絞り込むために、何か手がかりや追加の発見があれば教えていただけませんか? 弊社側で何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 リテシュ・プラジャパティ
記事全体を表示
LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers This has dragged on for far too long now... I've been through the examples for single SPI/DMA transfers and these work. I've been through the examples for DMA/Linked memory transfers and these work. But none cover my requirement and try s I might I can't get one to fit. I need a free running SPI TX/RX using DMA with either linked configurations or just ping-pong to start. Surely there must be someone on here that's achieved this already, who'd be willing to share some knowledge? The best I've managed so far is a set of linked configurations for SPI_DMA, which execute just once (despite the last linking back to the first) and then stop. The worse is a single 8-bit transfer for linked 16-bit transfers. I'm running out of ideas and pretty sure I'm now trying things that have already failed. Anybody..? General LPC55xx Peripherals Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I know this is an old post, but anyway... the problem is related with the width of your tx transfer. To configure the fifo must be 32 bits (16 data + 16 cfg) or you have all the configuration bit in the spi that are zeroes, with the problems you are experiencing. --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Hi @IanMcCarthy  I would like to apologize for the delay. We are experimenting an anormal volume of questions these days. I really thank you for your patience. Regarding your question, once you do a single manual start (run on debug session), all the code has to run indefinitely, and SCK from SPI has to generate more than 2 pulses (continuosly until you press stop). I would like to ask for you which example from our SDK you are using for LPC55S69? What changes did you make to the code? So I can reproduce your code on my board and see what is going on. Thank you so much for your help. Please let me know if you have more questions. Best Regards. Pablo Avalos. Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Third attempt to post an update... I need to continuously receive data from a slave SPI device at a fixed rate (manually triggering won't meet the requirements). The code below shows where I'm currently at, but this just generates 2 SPI clock pluses and that's it. I'm assuming once SPI is configured I can configure a linked set of DMA descriptors and after a single manual start, this will run indefinately, or am I mistaken? If someone would be willing to help out, it'd be much appreciated. srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I haven't totally understood your answer, could you please further explain? Why not keeping the uint8_t width of the transfer? I have also noticed that the 3rd and 4th input parameters of the function DMA_SetupDescriptor() are in the incorrect place. Additionally, shouldn't each descriptor destination address re-direct the data to another memory position, instead of all of them pointing to &masterTxData ?
記事全体を表示
MCUXpressoの使用経験のある方、PRINTFマクロはどこに出力されますか? FRDM-KL25Zのコードをデバッグしようとしているのですが、このマクロを使うときにどのコンソールに印刷されているのか分かりません。デバッグのためにシリアル接続を使わざるを得ませんでした。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? こんにちは@kyoto5 投稿ありがとうございます。 MCUXpresso SDKのPRINTFは標準のCのprintf()ではありません。これはSDKデバッグコンソールのマクロで、通常DbgConsole_Printfにマッピングされ、その出力先はプロジェクトのSDKデバッグコンソールの設定に依存します。 MCUXpresso IDEでは、SDKプロジェクトは以下のいずれかに設定できます: - セミホスティングコンソール 出力はUART経由ではなく、デバッガ接続を通じてIDEのセミホスティング/コンソールウィンドウに送信されます。 - UARTコンソール 出力は基板上のUARTを介して送信されます。FRDM-KL25Zでは、これは通常OpenSDAバーチャルCOMポートとしてホストPCに公開されるため、Tera TermやPuTTYなどのターミナルプログラムで表示する必要があります。 MCUXpresso IDEでUARTをPRINTF出力に切り替えるには、「MCUXpressoはしばしばPRINTFをコンソールに変換しない」例を「hello world」で参照してください - NXPコミュニティ お役に立てば幸いです。 BR セレステ
記事全体を表示