Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
FRDM-IMX93 — LPSPI3/EXPI (P11) SPIピンは、外部デバイスとの間で有効なSPIトランザクションを生成しません。 件名:FRDM-IMX93 — LPSPI3/EXPI(P11)SPIピンは外部デバイスとの有効なSPIトランザクションを発生させません。オンボードトライラジオモジュール(MAYA-W27x)との競合が疑われています。 こんにちは、NXPチームの皆さん、 外部のSPIデバイス(Waveshare 2-CHのCAN HAT https://www.waveshare.com/wiki/2-CH_CAN_HAT)を起動しようとしています。FRDM-IMX93ボードのEXPI 40ピンヘッダー(P11)にデュアルMCP2515を搭載し、LPSPI3(GPIO_IO08–11、RPi互換ピン位置に一致)を使用しています。HAT自体が完全に機能することを確認しました(標準のdtoverlay=mcp2515構成の純正Raspberry Piでテストし、動作確認済みです)。 理事会 / BSP: FRDM-IMX93、モデルNXP FRDM-IMX93 NXP i.MX リリースディストリビューション 6.18-whinlatter、カーネル 6.18.2-1.0.0-gf49f45233f7b 私が設定した内容(デバイスツリーレベルで全て正しいことを確認済み): オーバーレイは &lpspi3 の下に mcp2515@0/mcp2515@1 を追加します。cs-gpios = <&gpio2 8 1>、<&gpio2 7 1>;(GPIO_IO08/GPIO_IO07)で、これは NXP 自身のアップストリームパッチで見つけた類似の FRDM-IMX93 SPI3 ペリフェラル(pixpaper display overlay)の GPIO ベースの CS パターンに対応しています。 以前は /sys/kernel/debug/pinctrl/ で (MUX UNCLAIMED) であったため、&pinctrl_lpspi3 を拡張して GPIO_IO07 (CS1) を GPIO として mux しました。 CS0と競合していた既存のspidev0ノードを無効化しました。 reg_vexp_3v3/reg_vexp_5v (レギュレータ常時オン) を有効にしました。これらはデフォルトでは無効になっており、これがないと EXPI ヘッダーに電源が供給されませんでした。 /dev/spidev2.0が作成され、pinmuxで4つのSPIピンすべてに正しい機能割り当て(lpspi3grp)が表示されていることを確認しました。 症状: MCP251Xドライバは常に失敗します:spi2.0:MCP2515を初期化できません。配線が間違っている?(err=19) および spi2.1:MCP251x はリセット後に設定モードに入りませんでした (err=110) — 上記のすべてのデバイスツリーのバリエーションでまったく変わりません。 /dev/spidev2.0 上で spidev_test (互換性のある lwn、bk4) を使用して SPI レベルの生テストを実行します。RXバッファは、MOSI/MISOが物理的に短絡(ループバック)、開放状態、またはシャントでブリッジされているかどうかに関わらず、バイト単位で同一のデータを返します。これは、P11ヘッダーピン19/21/23/24にあるSPI3信号がコントローラの実際のバス活動に反映されていないことを示唆しています。つまり、信号がヘッダーに届いていないか、他の何かが干渉している可能性があります。 疑われる根本原因: UM12181(FRDM-IMX93ボードユーザーマニュアル、セクション2.11「トライラジオモジュールインターフェース」)によると、SPI3信号(CLK、MOSI、MISO、CS0 — GPIO_IO08-11で多重化)は、オンボードのMAYA-W27xトライラジオモジュールとM.2コネクタ間で、双方向の1.8Vレベルトランスレーター(U729、抵抗選択)を介して共有されます。この文書では、SPI3代替機能がSoC側から駆動される場合に、EXPIヘッダー(P11)がこの共有パスから電気的に絶縁されるかどうか、またどのように絶縁されるかについては明確にされていません。 質問: P11のGPIO_IO08-11の露出はU729トランスレーター/トライラジオパスから電気的に独立しているのでしょうか?それともP11でSPI3を使う場合、信号を正しくヘッダーにルーティング・隔離するために、トライラジオモジュールの無効化、GPIOエキスパンダービットの無効化、抵抗の再作業などの追加設定が必要でしょうか? FRDM-IMX93ボード上でLPSPI3を外部で使用するための、検証済みのリファレンスデバイスツリー(EVK用のimx93-11x11-evk-lpspi.dtsのようなもの)はありますか? P11接続トポロジーを確認するために、SPI3/U729信号経路の回路図抜粋を共有できますか? ご協力に感謝いたします。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi はい、p11ヘッダーには3.3Vと5Vがあります。 なぜエラーが発生するのでしょうか? imx93-11x11-lpddr4x-frdm ログイン:ルート root@imx93-11x11-lpddr4x-frdm:~# dmesg |grep -iE 'mcp251|lpspi3' [ 8.989639] MCP251X:module_layoutのシンボルなしバージョン [ 10.032864 mcp251x spi2.1: リセット後、MCP251xがコンフットモードに入らなかった [ 10.033021] mcp251x spi2.1: プローブ失敗、err=110 [ 10.033034] MCP251x SPI2.1: ドライバー付きプローブ MCP251x エラー -110 で失敗 [ 10.074097] MCP251x spi2.0: 初期化できませんMCP2515。配線が間違っているのですか? [ 10.074256] mcp251x spi2.0: プローブ失敗、err=19 root@imx93-11x11-LPDDR4x-frdm:~# IP リンク 表示 1: lo: MTU 65536 qdisc noqueue state 不明モード デフォルトグループ default qlen 1000 リンク/ループバック 00:00:00:00:00:00 BRD 00:00:00:00:00:00:00 2: eth0: MTU 1500 QDISC MQ 状態 ダウンモード デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 90:A9:f7:80:42:26 BRD FF:FF:FF:FF:FF:FF 3: eth1: MTU 1500 QDISC MQ STATE DOWN MODE デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 90:A9:f7:80:42:27 BRD FF:FF:FF:FF:FF:FF 4: mlan0: MTU 1500 QDISC MQ STATE UP モード 休眠グループ デフォルト QLEN 1000 リンク/エーテル 80:A1:97:50:4E:0d BRD FF:FF:FF:FF:FF:FF 5: uap0: MTU 1500 qdisc noop state DOWN mode デフォルトグループ デフォルト qlen 1000 リンク/エーテル 82:A1:97:50:4f:0d brd ff:ff:ff:ff:ff 6: wfd0: MTU 1500 QDISC NOOP 状態 ダウンモード デフォルトグループ デフォルト QLEN 1000 リンク/エーテル 82:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff:ff 7: can0: MTU 16 QDISC NOOP 状態 ダウンモード デフォルトグループ デフォルト qlen 10 リンク/CAN Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi FRDM-IMX93: LPSPI3 (P11 EXPIヘッダー) のSCKピンに信号が出力されません 問題 私はP11 EXPIヘッダー上のLPSPI3(GPIO_IO08-11、spi@42550000)を使って外部SPIデバイス(2× MCP2515 CAN)を操作しようとしています。ドライバーはアクティブで、ペリフェラルは「内部」で動作しているように見えますが、物理的なSCKピン(GPIO_IO11)には信号が出力されていません。 証拠 オーバーレイはエラーなく適用され、SPIコアにspi2.0/spi2.1が登録されました。 電源、pinctrl、pinctrl-assert-gpios、cs-gpios、およびクロックソースはすべて正しく、検証済みです。 CS0(同一バンク、GPIO代替機能、モード=0)は完璧に動作し、マルチメーターとロジックアナライザーの両方でパルスが確認できます。 SCK(モード=1、ネイティブLPSPI3_SCK)はロジックアナライナ上で完全にフラット/0Vで、HATが接続されているかどうかにかかわらず、連続トリガーループには影響しません。 それにもかかわらず、LPSPI3のIRQ(GIC 97)は実際には/proc/interrupts(220回の割り込みで生成される単一の転送試み)でトリガーされており、ペリフェラルの内部ロジック(ステータス/IERレジスタ)がアクティブです。 /dev/memでLPSPI3のベースアドレス(0x42550000)を読み取ると「バスエラー」が返されますが、同じバス上で動作しているflexcan2(0x425b0000)も同じエラーを返します。つまり、これはLPSPI3特有のものではなく、一般的な/dev/memの制限であり(コントロールグループで除外されています)。 DMA理論は検証され、無効とされました。無効なphandleでDMASを上書きすると、ドライバーは「dma setup error -19, use pio」というメッセージとともにPIOにフォールバックしましたが、SCK信号は依然として表示されませんでした。 `clk_ignore_unused` ブート引数も効果はありませんでした。 まとめ LPSPI3ペリフェラルの内部ロジックは動作しており(割り込みを発生)、SCK信号は外部ピン(GPIO_IO11)に到達しません。同じpinctrlグループのCS0(GPIOモード)は正しく出力しますが、SCK(LPSPI3のネイティブ代替機能)はそうではありません。これは、パッドドライバーやシリコンに関連する設定の詳細、あるいはNXPが認識すべき設定の詳細を示しているように見えますが、これはデバイスツリーやソフトウェアでは説明できません。 質問 FRDM-IMX93において、P11を介したLPSPI3_SCK(GPIO_IO11、ネイティブ代替機能)のために、デバイスツリーとは別にハードウェア/ファームウェアの有効化手順は追加されていますか? LPSPI3がi.MX93 EVK(community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ)と同じピンで動作する例があります—可能かもしれませんFRDM特有の違いはあるのでしょうか? Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi こんにちは、 @irfanktm お元気でお過ごしのことと思います。 実際には、i.MX93 FRDM PADとP11 GPIO_IO08-IO11ピンの間には直接的な接続があります。 Manuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.png 私のそばで再現するための手順を教えていただけますか? よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi ログを見る限り、あなたはspidev_test上でSPIデバイスにアクセスしようとしているようですが、デバイスはMCPドライバーによって処理されています。 私が知りたいのは、使用しているデバイスツリー(.dts)全体です。例えば、以下のようなものです。 imx93-11x11-frdm.dts また、もし変更を加えた場合は、変更内容をお知らせください。 また、MCP2515のCANモジュールを手に入れて統合を試してみようと思います。 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi お使いのデバイスツリー全体を共有していただけますでしょうか。 あるいは、lpspi3ノードとピンマルチプレクサに関連するものだけかもしれません。 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi こんにちは、 @irfanktm 私は自分の側でいくつかテストを行いました。 Manuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.png 私のi.MX93 FRDMではSPIは正常に動作しています。 Manuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.png 私もあなたと同じ環境にいます。 もう一つ質問があります。 i.MX93 FRDMボードの3V3ピンと5Vピンに電圧はかかっていますか? そうでない場合は、以下のリンクを参照して、委員会の規制当局に通知してください。 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Enable-3-3-V-and-5-V-Regulators-for-Expansion-Header-on-i-MX9/ta-p/2299415 よろしくお願いいたします。 サラス。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi いいえ、imx93-11x11-frdm.dtsファイルがオリジナルです。私はmcp2515-can-hat.dtboのオーバーレイファイルを編集しました、https://www.waveshare.com/wiki/2-CH_CAN_HATINT_1をデフォルトのGPIO_25からGPIO_24(物理ピン18)に変更しただけです。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi もし何か足りなければ、私が追加できます。 root@imx93-11x11-lpddr4x-frdm:/sys/firmware/devicetree/base# ls '#address-cells' クロック-OSC-24Mファームウェア mcp2515_clock PMU レギュレーター-HMISC-VDDIOレギュレーター-vEXC-3v3 soc@0 USBphynoP2 「#size-Cells」クロック-OSC-32K IMX93-LPM メモリ PSCI レギュレーター-USDHC2 レギュレーター-VEXP-5V サウンド-MQS usdhc3_pwrseq __symbols__ 互換割り込みcontroller@48000000モデル レギュレーター-ADC-VREF レギュレーター-usDHC3 リモートプロック-CM33 SW-キー 別名 CPUS 割り込み親 MQS1 レギュレーター-AVDD レギュレーター-VDD-12V リザーブドメモリ熱ゾーン 選択したディスプレイサブシステム LDB-ディスプレイ-コントローラ MQS2 レギュレーター-CAN2-STBYレギュレータ-VDD-5P0V セキュア・エンクレーブ タイマー クロック-ext1 エトス LDB-PHY名 レギュレーター-DVDD レギュレーター-VDDOシリアルナンバーUSBYyNOP1 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi MCP2515 / i.MX93 LPSPI3 — 根本原因の更新 前回の報告の続報です。新たな隔離テストでは、MCP2515モジュールから離れ、i.MX93 LPSPI3 SPIコントローラ/ドライバに向けられています。 実施されたテスト: ユーザー空間のspidevツールを使用して、MISOラインの物理状態のみを変化させながら、LPSPI3(500kHz、モード0)に対してRESET + CANSTAT読み取りサイクルを繰り返し発行します。 MISOを実際のMCP2515チップに接続した場合:不安定で、期待される0x80に到達することはまれです。 MISOが物理的に切断された状態(フローティング状態、チップが接続されていない状態):それでも、約10~11ミリ秒の周期で、構造化された繰り返しバイトパターン(0x00 / 0xFF / 0xFB)が表示されます。 MISOを10kΩの抵抗器を介してGNDに接続した場合、同じ繰り返しパターンが依然として現れ、本質的に変化はありません。 MISOをGND(約0Ω)に直接短絡すると、パターンは完全に消え、読み取り値は平坦で一定の0x00になります。 主な調査結果: まったく同じバイトシーケンスが、ミリ秒ごとに同じタイミングで、独立した実行(異なるプロセスID、異なる時間)や異なる物理的なMISO条件(切断、10kΩプルダウン、または実際のチップに接続した場合)でも再表示されます。SPI ioctl() 呼び出し自体は毎回成功(エラーなし)を返します。これは転送の失敗が隠蔽されているわけではなく、実際のデータが呼び出しごとにクロックインされています。 解釈: 真にフローティング状態または抵抗負荷状態の入力ピンは、異なるプロセス呼び出し間で、ミリ秒単位まで同一のホスト非依存のビットパターンを再現してはならない。この決定性のレベルから、読み戻されるバイト値は実際のMCP2515 SO/MISOラインを代表するものではなく、LPSPI3周辺機器やそのLinuxドライバの固定的で再現可能な内部状態(例:古いRXのFIFOコンテンツや、入力ピンの実際の論理レベルに関係なく固定パターンの読み取り)から来ていることを示唆しています。これを上書きするのはGNDへのハードショートだけです。 NXPへの質問です:LPSPI3(またはそのLinuxドライバーであるspi-fsl-lpspi)は、ピンの実際のサンプリング値の代わりに固定または古びたRX FIFOコンテンツを返すことはあり得ますか?このようなデターミニスティックで配線に依存しないリードバックパターンを説明する既知のエラタムやドライバの挙動はありますか? Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技術サポートの要請 MCP2515 (Microchip) と i.MX93 (NXP) の SPI2/LPSPI3 との SPI 通信障害 1. 要約 2つのMCP2515 CANコントローラ(Waveshare 2-CHAN HAN、MCP2515-I/SO、16 MHzクリスタル)は、LPSPI3を介してi.MX93-11X11-LPDDR4X-FRDMボードにコネクテッドされています(SPI2、CS0/CS1)は、電源アップやSPIやハードウェアリセット後に構成モードに入ることはありません。すべてのレジスタ読み取りで、期待されるCANSTAT = 0x80ではなく、固定された不変の値が返されます。カーネルmcp251xドライバは常にプローブの失敗を報告します(err=-110「リセット後にconfモードに入らなかった」またはerr=-19「配線が間違っている?」)。 2. 環境 SoM/ボード: i.MX93-11X11-LPDDR4X-FRDM カーネル: 6.18.2-1.0.0-gf49f45233f7b (NXP ダウンストリーム)、CONFIG_SPI_FSL_LPSPI=y (組み込み)、ERR051608 プリスケール修正が既に適用済み SPIバス:LPSPI3(spi@42550000)、チップセレクト2系統、カスタムデバイスツリーオーバーレイ(16MHz固定クロック、IRQ GPIO3-23 / GPIO3-24) CANモジュール:Waveshare 2CHキャンハット、MCP2515-I/SO、「E3 2335BK5」(正規のマイクロチップマーキングフォーマット) ドライバ:mcp251x(メインライン)、カーネルドライバーおよびカスタムspidevベースのテストユーティリティでテスト済み 3. トラブルシューティングを実施 デバイスツリーのオーバーレイターゲット(&spi1/&lpspi3 対 誤り & spi2 ラベル)を修正しました — オーバーレイが正しく適用され、MCP2515の子ノードがライブDTに存在します LPSPI3のpinctrl、cs-gpios、割り込み親/GPIOマッピングを、実行中のデバイスツリーに対して検証しました。すべて正しいです。 ロジックアナライザを使用してマスター側のSPI信号の完全性を検証しました。複数のキャプチャにおいて、i.MX93によってMOSI、SCK、およびCSが正しく一貫して生成されていることが確認されました。 両CANモジュールでVDD = 3.3V、アイドルMISO = 3.3Vが確認(GNDへのショートなし) 両方のモジュールで、リセットピン(SOIC-18の17番ピン)が3.3V(非アクティブ)であることを確認しました。 SPIモード0,0とモード1,1(CPOL/CPHA)、100kHz~8MHzクロックでテストしましたが、動作に変化はありませんでした。 2つの並列MCP2515デバイス間のMISOバス競合を解消するため、CS0/CS1に10kΩのプルアップ抵抗を追加しました。これにより、読み出しデータは安定しましたが、修正はされませんでした。 カスタムspidevテストツール:リセット命令+リセット後の即時/連続CANSTATポーリング(1ms間隔、300msウィンドウ)—CANSTATは瞬時に固定値に落ち着き、0x80に達することはありません。 WRITEをCANCTRL(0x80)に強制し、その後READに続けます — 読み戻しは書き込みの影響を受けず、SPIトランザクションがCANコントローラロジックで処理されていないことを示します 4. 重要な観察事項 CS0 デバイス: CANSTAT/CANCTRL/すべてのレジスタは一貫して 0x00 を読み出します (数十回のリセット + 読み取りサイクルにわたって 100% 再現可能、レジスタ アドレス、SPI モード、または書き込み値に関係なく)。 CS1デバイス:CANSTAT/CANCTRL/すべてのレジスタは常に0xFFを読み出す(100%再現可能、トランザクション中にMISOが切り替わることはない)。 両デバイスともマスターからはクリーンで正しくタイミングされたMOSI/SCK/CSを表示しますが、命令、アドレス、CSプルの設定に関係なく固定値を返します。このパターンはホスト側のSPIモード/タイミング/配線では説明できず、MCP2515 CANコアがリセット後/発振器不安定な状態から決して離れないことと一致しています。 5. リクエスト ホスト側のSPIシグナリングがロジックアナライザーで正確であることが確認され、デバイスツリーやカーネルドライバの設定も正しいことが確認されたため、以下の点についてのガイダンスを望みます。 この障害シグネチャ(レジスタの読み取りが固定され、CANSTATが0x80にならない)が、既知のMCP2515水晶発振器の起動問題と一致するかどうか、およびOSC1/OSC2に対する推奨オシロスコープ/検証手順 MCP2515とi.MX93 LPSPIの間には、既知の互換性の問題が存在するか(既に解決済みのERR051608以外)? MCP2515モジュールにハードウェアの欠陥が疑われる場合の推奨される次の診断手順またはRMAプロセス 追加のロジックアナライザキャプチャ、デバイスツリーファイル、またはカーネルログが必要な場合はお知らせください。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技術サポートリクエスト — i.MX93 LPSPI3 MCP2515 複数のMCP2515 CANコントローラ(テスト済み3台、2つの異なるメーカー/ボード、8/16 MHzのクリスタル)がLPSPI3(SPI2)経由でi.MX93-11X11-LPDDR4X-FRDMボードに接続されていると、リセット後に断続的に構成モードに到達できません(CANSTATは0x80を認識すべきです)。 環境: カーネル 6.18.2 (NXP ダウンストリーム)、CONFIG_SPI_FSL_LPSPI 組み込み、ERR051608 プリスケール修正あり。デバイスツリー/pinctrlが正しいことを確認しました(LPSPI3のSIN/SOUT/SCKは適切に多重化され、CSはcs-gpios経由)。ロジックアナライザによるキャプチャ結果から、MOSI/SCK/CSがホストによって正しく一貫して生成されていることが確認されました。 重要な観察事項: 新しく開いたspidevハンドルでは、最初のRESET + CANSTAT読み取りが約50~60%の確率で成功し(~0x80)、タイミングは常に約2~6msです。 同じ、まだ開いているSPIファイルディスクリプタに対して追加のRESET+読み取りサイクルを発行すると、その後は一貫して失敗し、0x80に再び到達することのない、約10~11ミリ秒周期の固定値(0x00 / 0xFF / 0xFB)の繰り返しパターンに落ち着きます。 この同じ故障シグネチャは3つの物理MCP2515ユニットと2つの異なる基板デザインすべてで再現されており、単一の欠陥チップやモジュールを除外しています。 転送間隔遅延(delay_usecs)の追加、ダミーの「フラッシュ」SPI転送、およびサイクル間のギャップを100msに増やしても、結果は変わりませんでした(パターンが開始されると、10回中0回成功)。 VDD、GND、RESETピン、およびアイドル時のMISOレベルはすべて正常(3.3V)であることが確認されています。 メインラインのmcp251xカーネルドライバーのプローブ()も同じ不安定さを示しています。5回連続のバインド試行(アンバインド/クリアdriver_override/バインド)すべて失敗し、err=-19(「配線が間違っている??」)とerr=-110(リセット後にコンフィングモードに入らなかった)を交互に繰り返すパターンです。 このパターン(開いた後の最初の転送で良好、その後同じセッション内のその後の転送で固定された再現可能な失敗署名が現れる)は、MCP2515ユニット自体の欠陥というよりも、連続するLPSPI3転送やCSサイクル間で完全にクリアされていない状態を示唆しています。 NXP への質問: これは、既知の LPSPI3 (i.MX93) の動作と一致していますか?同じSPIファイルディスクリプタ上で連続転送間でFIFO/CSの状態がきれいにリセットされないことについて — そして推奨されるドライバーレベルの回避策はありますか(例:ERR051608を超える遅延、FIFOフラッシュ、またはCS処理が必要ですか?
View full article
FRDM-IMX93 — LPSPI3/EXPI (P11) SPI 引脚无法与任何外部设备产生有效的 SPI 通信; 主题:FRDM-IMX93 — LPSPI3/EXPI (P11) SPI 引脚无法与任何外部设备产生有效的 SPI 通信;怀疑与板载三频模块 (MAYA-W27x) 冲突 NXP团队您好, 我正在尝试启动一个外部SPI设备(Waveshare 2通道CAN HAT( https://www.waveshare.com/wiki/2-CH_CAN_HAT )),在 FRDM-IMX93 板的 EXPI 40 针接头 (P11) 上使用 LPSPI3 (GPIO_IO08–11,与 RPi 兼容的引脚位置匹配) 连接双 MCP2515)。我已经确认 HAT 本身功能齐全(在具有标准 dtoverlay=mcp2515 配置的真正 Raspberry Pi 上进行了测试并运行正常)。 板/电路板支持包。 FRDM-IMX93,型号 NXP FRDM-IMX93 NXP i.MX 发布发行版 6.18-whinlatter,内核版本 6.18.2-1.0.0-gf49f45233f7b 我已配置好(所有配置均已在设备树级别验证正确): Overlay 在 &lpspi3 下添加了 mcp2515@0/mcp2515@1,其中 cs-gpios = <&gpio2 8 1>, <&gpio2 7 1>; (GPIO_IO08/GPIO_IO07),与我在 NXP 自己的上游补丁中找到的基于 GPIO 的 CS 模式相匹配,该补丁用于类似的 FRDM-IMX93 SPI3 外设(pixpaper 显示覆盖层)。 将 &pinctrl_lpspi3 扩展为将 GPIO_IO07 (CS1) 复用为 GPIO,因为它之前在 /sys/kernel/debug/pinctrl/ 中是 (MUX UNCLAIMED)。 禁用了与 CS0 冲突的已存在的 spidev0 节点。 启用 reg_vexp_3v3/reg_vexp_5v(稳压器始终开启)——这些默认是禁用的,如果没有这些,EXPI 标头将无法供电。 已确认 /dev/spidev2.0 已创建,引脚复用显示所有 4 个 SPI 引脚上的功能分配 (lpspi3grp) 正确。 症状: mcp251x 驱动程序始终失败:spi2.0:无法初始化MCP2515。接线错误?(错误代码=19)和 spi2.1:RESET后 MCP251x 未进入配置模式(错误代码=110)——以上所有设备树变体均完全不变。 使用 spidev_test(兼容 lwn、bk4)对 /dev/spidev2.0 进行原始 SPI 级测试:无论 MOSI/MISO 是物理短路(环回)、开路还是用分流器桥接,RX 缓冲区都会返回逐字节相同的数据。这表明 P11 接头引脚 19/21/23/24 处的 SPI3 信号没有反映在控制器的实际总线活动中——也就是说,这些信号可能根本没有到达接头,或者有其他东西在干扰。 疑似根本原因: 根据 UM12181(FRDM-IMX93 板用户手册,第 2.11 节“三射频模块接口”),SPI3 信号(CLK、MOSI、MISO、CS0 — 在 GPIO_IO08-11 上复用)通过双向 1.8V 电平转换器 (U729)(电阻选择)在板载 MAYA-W27x 三射频模块和 M.2 连接器之间共享。该文档没有说明当 SPI3 备用功能由 SoC 端驱动时,EXPI 接头 (P11) 是否/如何与此共享路径电气隔离。 问题: P11 的 GPIO_IO08-11 引脚在电气上是否独立于 U729 转换器/三路无线电路径?或者,在 P11 上使用 SPI3 是否需要任何额外的配置(例如,禁用三路无线电模块、GPIO 扩展位或电阻器改造)才能正确地将信号路由/隔离到接头? 是否有经过验证的参考设备树(类似于 EVK 的 imx93-11x11-evk-lpspi.dts),专门用于在 FRDM-IMX93 板上外部使用 LPSPI3? 能否提供 SPI3/U729 信号路径的原理图片段,以确认 P11 连接拓扑结构? 提前感谢您的帮助。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 如果有什么遗漏,我可以补充。 root@imx93-11x11-lpddr4x-frdm:/sys/firmware/devicetree/base# ls '#address-cells' clock-osc-24m 固件 mcp2515_clock pmu regulator-hmisc-vddio regulator-vexp-3v3 soc@0 usbphynop2 '#size-cells' clock-osc-32k imx93-lpm memory psci regulator-usdhc2 regulator-vexp-5v sound-mqs usdhc3_pwrseq __symbols__兼容中断控制器@48000000 型号 regulator-adc-vref regulator-usdhc3 remoteproc-cm33 sw-keys 别名 cpus 中断父级 mqs1 稳压器-avdd 稳压器-vdd-12v 保留内存 热区 选定的显示子系统 ldb-display-controller mqs2 regulator-can2-stby regulator-vdd-5p0v secure-enclave timer clock-ext1 ethosu ldb-phy 名称 regulator-dvdd regulator-vddo 序列号 usbphynop1 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 是的,我在p11接头上测得3.3V和5V电压。 为什么我的电脑会出现错误? imx93-11x11-lpddr4x-frdm 登录:root root@imx93-11x11-lpddr4x-frdm:~# dmesg | grep -iE 'mcp251|lpspi3' [ 8.989639] mcp251x:模块布局没有符号版本 [ 10.032864] mcp251x spi2.1:MCP251x RESET 后未进入配置模式 [ 10.033021] mcp251x spi2.1:探测失败,错误代码=110 [ 10.033034] mcp251x spi2.1:使用驱动程序 mcp251x 进行探测失败,错误代码为 -110 [ 10.074097] mcp251x spi2.0:无法初始化 MCP2515。接线错误? [ 10.074256] mcp251x spi2.0:探测失败,错误代码=19 root@imx93-11x11-lpddr4x-frdm:~# ip link show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 链接/回环 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc mq 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 90:a9:f7:80:42:26 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 90:a9:f7:80:42:27 brd ff:ff:ff:ff:ff:ff 4: mlan0: mtu 1500 qdisc mq 状态 UP 模式 DORMANT 组 default qlen 1000 链接/以太 80:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff 5: uap0: <广播,组播> mtu 1500 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链路/以太网 82:a1:97:50:4f:0d brd ff:ff:ff:ff:ff:ff 6: wfd0: <广播,组播> mtu 1500 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 1000 链接/以太 82:a1:97:50:4e:0d brd ff:ff:ff:ff:ff:ff 7: can0: mtu 16 qdisc noop 状态 DOWN 模式 DEFAULT 组 default qlen 10 链接/罐 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi FRDM-IMX93:LPSPI3(P11 EXPI 接头)SCK 引脚无信号输出 问题 我正在尝试使用 P11 EXPI 接头上的 LPSPI3 (GPIO_IO08-11, spi@42550000) 操作外部 SPI 设备 (2× MCP2515 CAN)。驱动程序处于活动状态,外设似乎正在“内部”运行,但没有信号输出到物理 SCK 引脚 (GPIO_IO11)。 证据 覆盖层应用无误;spi2.0/spi2.1 已在 SPI 内核中注册。 电源、引脚控制、引脚控制断言-GPIOS、CS-GPIOS 和时钟源——全部正确,并且已经过验证。 CS0(同一组,GPIO 交替功能,模式=0)工作完美——用万用表和逻辑分析仪都能看到脉冲。 在逻辑分析仪上,SCK(模式=1,原生 LPSPI3_SCK)完全平坦/0V——无论 HAT 是否连接,对连续触发回路都没有影响。 然而,LPSPI3 的 IRQ(GIC 97)实际上是在 /proc/interrupts 中触发的(一次传输尝试产生了 220 次中断)——外设的内部逻辑(状态/IER 寄存器)处于活动状态。 使用 /dev/mem 读取 LPSPI3 基地址 (0x42550000) 时返回“总线错误”——但是运行在同一总线上的 flexcan2 (0x425b0000) 也返回相同的错误,这意味着这是 /dev/mem 的一般限制,而不是 LPSPI3 特有的限制(已通过控制组排除)。 DMA 理论经过测试并被排除:当使用无效句柄覆盖 dmas 时,驱动程序回退到 PIO 并显示消息“dma 设置错误 -19,请使用 pio”,但 SCK 信号仍然没有出现。 `clk_ignore_unused` 启动参数也没有任何作用。 结束语 LPSPI3 外设的内部逻辑正在工作(产生中断),但 SCK 信号始终无法到达外部引脚 (GPIO_IO11)——尽管同一引脚控制组中的 CS0(GPIO 模式)输出正确,但 SCK(LPSPI3 原生替代功能)却无法输出。这似乎指向与焊盘驱动器/硅相关的配置细节,或者指向 NXP 应该了解的配置细节,而这些细节无法通过设备树或软件来解释。 问题 在 FRDM-IMX93 上,是否需要在设备树之外通过 P11 为 LPSPI3_SCK(GPIO_IO11,本机替代功能)添加额外的硬件/固件使能步骤? 已知有一个例子表明,LPSPI3 可以使用 i.MX93 EVK 上的相同引脚(community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ)——可能FRDM是否存在特殊差异? Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 根据日志,我怀疑您尝试通过 spidev_test 访问 SPI 设备,但该设备由 MCP 驱动程序处理。 我需要知道的是您使用的完整设备树(.dts)文件,例如: imx93-11x11-frdm.dts 另外,如果您对它进行了修改,请告诉我您的修改之处。 另外,我也会尝试弄一个 mcp2515 CAN 模块,以便我这边进行集成测试。 顺祝商祺! 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 你好@irfanktm 希望你一切都好。 实际上,i.MX93 FRDM PAD 与 P11 GPIO_IO08-IO11 引脚之间存在直接连接: Manuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.pngManuel_Salas_0-1789421014211.png曼努埃尔_萨拉斯_0-1789421014211.png 能否请您提供一下重现问题的步骤? 顺祝商祺! 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 你好@irfanktm 我刚才做了一些测试: Manuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.pngManuel_Salas_0-1789495251012.png曼努埃尔_萨拉斯_0-1789495251012.png 我的 i.MX93 FRDM 上的 SPI 工作正常。 Manuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.pngManuel_Salas_1-1789495295645.png曼努埃尔_萨拉斯_1-1789495295645.png 我的环境和你一样。 最后一个问题。 你的i.MX93 FRDM板的3V3和5V引脚有电压吗? 如果不行,请点击以下链接启用董事会监管功能: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Enable-3-3-V-and-5-V-Regulators-for-Expansion-Header-on-i-MX9/ta-p/2299415 顺祝商祺! 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 请您提供完整的设备树。 或者只是与 lpspi3 节点和引脚复用相关的。 顺祝商祺! 萨拉斯。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 不,imx93-11x11-frdm.dts 文件是原始文件;我编辑了 mcp2515-can-hat.dtbo 覆盖文件, https://www.waveshare.com/wiki/2-CH_CAN_HAT我只将 INT_1 从默认的 GPIO_25 改为 GPIO_24(物理引脚 18)。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技术支持请求 MCP2515(Microchip)SPI 通信故障,i.MX93(NXP)SPI2/LPSPI3 1. 总结 两个 MCP2515 CAN 控制器(Waveshare 2-CH CAN HAT、MCP2515-I/SO、16 MHz 晶振)通过 LPSPI3(SPI2、CS0/CS1)连接到 i.MX93-11X11-LPDDR4X-FRDM 板,上电或 SPI/硬件 RESET 后始终无法进入配置模式。所有寄存器读取都返回固定不变的值,而不是预期的 CANSTAT = 0x80。内核 mcp251x 驱动程序持续报告探测失败(err=-110“RESET 后未进入配置模式”,或 err=-19“接线错误?”)。 2. 环境 SoM/板:i.MX93-11X11-LPDDR4X-FRDM 内核:6.18.2-1.0.0-gf49f45233f7b(NXP 下游),CONFIG_SPI_FSL_LPSPI=y(内置),ERR051608 预分频修复程序已存在 SPI 总线:LPSPI3 (spi@42550000),2 个片选信号,自定义设备树覆盖(16 MHz 固定时钟,IRQ GPIO3-23 / GPIO3-24) CAN 模块:Waveshare 2 通道 CAN HAT,MCP2515-I/SO,标记“E3 2335BK5”(Microchip 原装标记格式) 驱动程序:mcp251x(主线),已使用内核驱动程序和基于 spidev 的自定义测试工具进行测试。 3. 已执行的故障排除 已更正设备树覆盖目标(&spi1/&lpspi3 与错误的 &spi2 标签相比)——覆盖现在已正确应用,mcp2515 子节点已存在于实时设备树中 已根据运行中的设备树验证 LPSPI3 pinctrl、cs-gpios 和 interrupt-parent/GPIO 映射——全部正确 使用逻辑分析仪验证了主端SPI信号的完整性:在多次捕获中,i.MX93均能正确且一致地生成MOSI、SCK和CS信号。 已确认两个 CAN 模块的 VDD = 3.3V 和空闲 MISO = 3.3V(无对地短路) 已确认两个模块的 RESET 引脚(引脚 17,SOIC-18)均为 3.3V(未激活) 测试了 SPI 模式 0,0 和模式 1,1 (CPOL/CPHA),时钟频率为 100 kHz 至 8 MHz — 行为未发生变化 在 CS0/CS1 上添加了 10k 上拉电阻,以解决两个并联 MCP2515 器件之间的 MISO 总线争用问题——这稳定了(但并未纠正)回读数据。 自定义 spidev 测试工具:RESET 指令 + 复位后立即/连续轮询 CANSTAT(1 毫秒间隔,300 毫秒窗口)— CANSTAT 立即稳定到一个固定值,且永远不会达到 0x80。 强制写入 CANCTRL (0x80) 后执行读取操作——读取操作不受写入操作的影响,表明 SPI 事务未被 CAN 控制器逻辑处理。 4. 关键观察 CS0 设备:CANSTAT/CANCTRL/所有寄存器始终读取回 0x00(在数十次复位+读取周期中 100% 可重复,与寄存器地址、SPI 模式或写入值无关)。 CS1 设备:CANSTAT/CANCTRL/所有寄存器始终读取回 0xFF(100% 可重复,MISO 在事务处理期间从不翻转)。 两个设备均显示来自主控端的干净、时序正确的 MOSI/SCK/CS,但无论指令、地址或 CS 拉取配置如何,都返回一个固定值——这种模式无法用主机端的 SPI 模式/时序/接线来解释,并且与 MCP2515 CAN 内核永远不会离开其复位后/振荡器不稳定状态一致。 5. 请求 鉴于逻辑分析仪已验证主机端 SPI 信号传输正确,且设备树/内核驱动程序配置也已确认正确,我们希望获得以下方面的指导: 此故障特征(固定寄存器回读,CANSTAT 始终不等于 0x80)是否与已知的 MCP2515 晶振(晶体振荡器)启动问题一致,以及 OSC1/OSC2 的推荐示波器/验证程序。 MCP2515 和 i.MX93 LPSPI 之间是否存在已知的兼容性问题(除已解决的 ERR051608 之外) 如果怀疑MCP2515模块存在硬件缺陷,建议采取以下后续诊断步骤或RMA流程。 如果您需要提供额外的逻辑分析仪捕获文件、设备树文件或内核日志,请告知我们。 Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi MCP2515 / i.MX93 LPSPI3 — 根本原因更新 这是我们之前报告的后续报道。一项新的隔离测试现在完全指向了 i.MX93 LPSPI3 SPI 控制器/驱动程序,而不是 MCP2515 模块。 已执行测试: 使用用户空间 spidev 工具,我们反复对 LPSPI3(500 kHz,模式 0)发出 RESET + CANSTAT 读取周期,同时仅改变 MISO 线的物理状态: MISO 连接到真正的 MCP2515 芯片:不稳定,很少达到预期的 0x80。 MISO 物理断开(浮空,未连接芯片):仍会出现结构化的重复字节模式(0x00 / 0xFF / 0xFB),周期约为 10-11 毫秒。 MISO 通过 10kΩ 电阻连接到 GND:仍然出现相同的重复模式,基本没有改变。 MISO 直接短接到 GND (~0Ω):图案完全消失——读取结果变为平坦的恒定值 0x00。 主要发现: 完全相同的字节序列,毫秒级的时序完全相同,在不同的运行(不同的进程 ID、不同的时间)和不同的物理 MISO 条件(断开连接、10kΩ 下拉电阻、连接到真实芯片)中反复出现。SPI ioctl() 调用本身每次都会返回成功(无错误)——这不是被掩盖的传输失败;每次调用都会将真实数据记录到时钟中。 解释: 真正浮空或电阻负载的输入引脚不应该在不同的进程调用中精确到毫秒地重现与主机无关的相同位模式。这种确定性表明,读取回来的字节值并不代表实际的 MCP2515 SO/MISO 线,而是来自 LPSPI3 外设或其 Linux 驱动程序的固定、可重复的内部状态(例如,过时的 RX FIFO 内容,或者无论输入引脚的实际逻辑电平如何,读取的固定模式)——只有硬短路到 GND 才能覆盖它。 向 NXP 提出问题:在某些情况下,LPSPI3(或其 Linux 驱动程序 spi-fsl-lpspi)是否会返回固定/过时的 RX FIFO 内容,而不是引脚的实际采样值?是否存在已知的错误或驱动程序行为可以解释这种确定性的、与线路无关的读取模式? Re: FRDM-IMX93 — LPSPI3/EXPI (P11) SPI pins produce no valid SPI transactions with any external devi 技术支持请求 — i.MX93 LPSPI3 上的 MCP2515 多个 MCP2515 CAN 控制器(测试了 3 个单元,2 个不同的制造商/板,8/16 MHz 晶振)通过 LPSPI3 (SPI2) 连接到 i.MX93-11X11-LPDDR4X-FRDM 板,RESET后间歇性地无法进入配置模式(CANSTAT 应读取 0x80)。 环境:内核 6.18.2(NXP 下游),CONFIG_SPI_FSL_LPSPI 内置,ERR051608 预分频修复已存在。设备树/引脚控制已验证正确(LPSPI3 SIN/SOUT/SCK 已正确复用,CS 通过 cs-gpios)。逻辑分析仪捕获结果证实主机能够正确且一致地生成 MOSI/SCK/CS。 关键观察结果: 对于新打开的 spidev 句柄,第一次 RESET + CANSTAT 读取操作大约有 50-60% 的概率成功(~0x80),且计时稳定在 2-6 毫秒左右。 如果对同一个仍然打开的 SPI 文件描述符发出额外的 RESET+读取周期,则之后会持续失败,并稳定为可重复的 ~10-11 毫秒周期性固定值 (0x00 / 0xFF / 0xFB) 模式,永远不会再次达到 0x80。 所有 3 个物理 MCP2515 单元和 2 种不同的电路板设计都出现了相同的故障特征,排除了单个芯片/模块存在缺陷的可能性。 添加传输间延迟(delay_usecs)、虚拟“刷新”SPI 传输,并将周期之间的间隔增加到 100 毫秒,结果都没有改变(一旦模式开始,成功率就为 0/10)。 VDD、GND、RESET 引脚和空闲 MISO 电平均已确认正常(3.3 V)。 主线 mcp251x 内核驱动程序自身的 probe() 也显示出同样的不稳定性:连续 5 次绑定尝试(取消绑定/清除 driver_override/绑定)全部失败,错误信息在 err=-19(“接线错误?”)和 err=-110(“重置后未进入配置模式”)之间交替出现,且模式具有规律性,并非随机性。 这种模式(打开后第一次传输正常,然后在同一会话中的后续传输中出现固定的可重复故障特征——内核驱动程序自己的探测也重现了该故障)表明,连续的 LPSPI3 传输/CS 周期之间没有完全清除状态,而不是 MCP2515 单元本身存在缺陷。 向 NXP 提出的问题:这是否与已知的 LPSPI3 (i.MX93) 行为一致——例如:在同一 SPI 文件描述符上连续进行数据传输时,FIFO/CS 状态无法干净地重置——是否有推荐的驱动程序级解决方法(例如,使用 FIFO/CS 进行数据交换)?除了 ERR051608 之外,还需要延迟、FIFO 刷新或 CS 处理吗?
View full article
MCU P89C52X2BNフラッシュするにはどうすればいいですか? こんにちは、皆さん。 P89C52X2BNとP89C52RD2という2つの古いMCUをプログラムする必要があります。 P89C52RD2については、シリアル経由でISPをサポートしていると理解しています。しかし、ISP/IAPプロトコルをアクティブ化する方法はまだわかっていません。 P89C52X2BNの場合、どのようにファームウェアを書き換えればよいですか?並列プログラマが必要ですか?必要であれば、どのようなプロトコルを使用し、フラッシュモードをアクティブ化すればよいでしょうか? 主にこれら2つのチップ(特にX2BN)の公式プログラミングドキュメントを探しています。正しいフラッシュプログラミングインターフェースとタイミングを参照できるようにするためです。データシートのプログラミングに関するセクション、またはリンクをお持ちでしたら、ぜひ共有してください。 ありがとう! Re: How to Flash P89C52X2BN MCU? Hello ご不便をおかけし申し訳ありません。P89C52ファミリーは現在製造中止で、そのためサポートも終了しており、このファミリーに関する情報はもはや利用できません。 もしあなたに合うなら、89C51の情報があります;重要:この情報がいつ有効か確認・テストすることはできませんし、89C52の申請もできません。 89C51Rx+/Rx2/66xマイクロコントローラの回路内およびアプリケーション内プログラミング よろしくお願いいたします。 Re: How to Flash P89C52X2BN MCU? 申し訳ありませんが、XSP6100Nは非常に高価で、平均的な人の6~12か月分の給料に相当します。だから、ドキュメントを読んで、自分でフラッシュしてみようと思います。XSP6100Nできますが、払えません、ありがとう。 Re: How to Flash P89C52X2BN MCU? このANNはP89C5xRx2に使えますが、P89C5xX2が欠けています。このANは正しいタイプのドキュメントですが、P89C5xX2が欠けているだけです。ありがとう!
View full article
I'm not sure what this position specifically means. 屏幕截图_14-9-2026_20244_.jpegScreenshot_14-9-2026_20244_.jpeg I'm very confused about what bit 0 of the Authentication Status (AUTHSTTS) register means: has it entered challenge mode, or does it mean the challenge value is ready? Could someone please help me understand this? Thank you so much! 屏幕截图_14-9-2026_202943_.jpegScreenshot_14-9-2026_202943_.jpeg Re: 我不确定这个位的具体含义 Hi,Vane If the chip has not enabled challenge mode, will bit 0 of AUTHSTTS still be set to 1? Re: 我不确定这个位的具体含义 Hi @TakanashiLika  AUTHSTTS[CHALRDY] is a read-only status bit that indicates when the challenge is ready. The debugger should wait for CHALRDY to be asserted before reading the challenge in the KEYCHALn registers. BR, VaneB 回复: 我不确定这个位的具体含义 The chip is S32K314
View full article
使用 EB Tresos 生成的 RTD 驱动程序,并结合 FreeRTOS + MPU 你好, 我们使用 RTD 6.0.0 和 电池管理系统 0.9.1。使用 EB Tresos 中的 SDK 生成我们的驱动程序代码。它在不使用 MPU 的 FreeRTOS Cortex M7 移植版下运行良好。 现在,我们想切换到使用 MPU 的 FreeRTOS 移植版。我想分两步完成这件事: 1)将所有任务设为特权任务,但使用MPU,即每次上下文切换时都对MPU进行重新编程。 2)将所有任务设为非特权任务。这意味着我必须在非特权任务使用的驱动程序中启用“启用用户模式支持”。 目前,我在1点上遇到了困难。驱动程序功能不稳定。例如,SPI 只能间歇性地工作。MPU区域似乎无法正常工作。即使这个问题得到解决,第 2) 点又该如何实现呢?监控调用处理程序由 FreeRTOS 和 RTD 提供。我应该把它们合并吗? Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@Julián_AragónM , 我从他们的网站下载了 FreeRTOS,并使用了一个同时支持 Cortex M7 和 MPU 的移植版本。如果我理解正确的话,我需要使用 NXP 提供的 FreeRTOS。我只找到了 NXP 的 FreeRTOS 可以在 S32DS 中配置,而没有找到 EB Tresos 的 FreeRTOS。我的问题如下: 我可以使用提供正确 M7+MPU 端口的通用 FreeRTOS 吗? 如果没有,NXP 是否提供了可在 EB Tresos 中配置的 FreeRTOS? 我们迟早需要使用通过 ASIL-D 认证的操作系统。如果 NXP 提供的 FreeRTOS 没有获得 ASIL-D 认证,我们需要切换到其他方案。 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@PhilippH , 首先,FreeRTOS 7.0.0 中添加了对 MPU 的初始支持。CD1,请确认这是你正在使用的软件包吗?(或最新版本 0.8.0 CD1)。 1)能否告知哪些MPU区域无法正常工作?如果可以,请分享配置信息和运行流程。 此外,请遵循 S32K3 FreeRTOS 用户手册中的建议: 启用“使用 MPU”和“使用 MPU 包装器 v1”选项。 将第一个可配置区域设置为 9 而不是 0,以避免与 RTD 中的 MPU 区域发生冲突。 注意:将 FreeRTOS 与 MPU 支持集成需要修改 RTD 链接器文件,以定义 FreeRTOS 使用的所需内存段。在对应用程序进行更改时,请参考示例文件。 2) 我认为不需要合并,因为 FreeRTOSConfig.h声明以下宏: /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler 这会将 FreeRTOS 的 SVC 调用重定向到 exceptions.c 中 RTD 提供的 SVC_Handler。 此致, 朱利安 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 你好@PhilippH , 我可以使用提供正确 M7+MPU 端口的通用 FreeRTOS 吗? 您可以使用通用的 FreeRTOS 移植版;但是,您需要为 S32K3 的特定配置实现自己的解决方案,而 NXP FreeRTOS 软件包中已经提供了大部分解决方案。请尝试使用此端口启动,看看是否能解决问题。 如果没有,NXP 是否提供了可在 EB Tresos 中配置的 FreeRTOS? 不,目前提供的 NXP 软件包仅兼容 S32DS。能否请您解释一下为什么您需要在 EB Tresos 中使用 FreeRTOS? 通常情况下,EB Tresos 用于符合 AUTOSAR 标准的应用,但是,我们提供的 FreeRTOS 软件包仅供客户评估,不建议在生产中使用,因为它不符合汽车认证 (ISO26262)。您可以看到它以代码发布(CD)质量发布,这是因为 FreeRTOS 是一个开源软件,NXP 将其作为参考软件提供,而没有任何功能安全认证。 如果您的应用需要经过功能安全认证的操作系统,您可以考虑其他选择,甚至可以考虑我们合作伙伴提供的操作系统: SafeRTOS(基于 FreeRTOS 功能模型,易于迁移): https://www.highintegritysystems.com/safertos/ AUTOSAR操作系统 µ速度 embOS-Safe NXP RTOS 客户可以自行选择适合其项目的第三方实时操作系统、协议栈、集成开发环境、编译器等。 此致, 朱利安 Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU 非常感谢您的解答。 我使用 NXP 提供的 SafeRTOS 和端口成功运行了它,因为 NXP 提供的端口已经解决了我在使用 SafeRTOS 提供的通用 Cortex M7 + MPU 端口时遇到的问题。 关于我们对 EB Tresos 的需求:我们最初使用的是 S32DS,但由于我们使用的 IC,我们需要最新版本的电池管理系统 SDK,而 S32DS 中没有提供该 SDK(至少当时没有)。我们希望尽可能少地使用 Autosar。目前可行的办法是生成驱动程序函数,然后从 FreeRTOS 调用它们。我们目前未使用,也不打算使用 Autosar RTE。 关于第三方操作系统:“易于迁移”是否意味着 SafeRTOS 也存在同样用户友好的移植版本?我们之前使用过 SafeRTOS,但不是使用 Autosar 驱动程序,而是完全手写的驱动程序。
View full article
LX2160A - SerDesレーン番号付け こんにちは、 LX2160Aの**リファレンス・マニュアル**でSerDes 1レーンの番号付けに矛盾があることに気づきました。 セクション26.1.4(SerDes オプション)、文字を使用する場合、SerDes 1 レーンの番号付けが逆になります: レーン H = 0 -> レーン A = 7。 fdekeers_0-1789391391196.pngfdekeers_0-1789391391196.png セクション26.4.1.19(SerDes Lane m RX 一般制御レジスタ 1 (LNARGCR1 - LNHRGCR1)) のテキストには、文字番号が増加すると記載されています: Lane A = 0 -> Lane H = 7。 fdekeers_1-1789391514092.pngfdekeers_1-1789391514092.png 汎用制御レジスタ1のレジスタEXT_REC_CLK_SELを設定したいのですが、正しいレーンのアドレスオフセットはこの番号付けに依存します。どちらが正しいか確認してもらえますか? よろしくお願いいたします。 Re: LX2160A - SerDes lanes numbering こんにちは、 どちらのセクションも正しい。それぞれ異なる(しかし一貫性のある)索引付け規則を使用している。 この一見矛盾する点は、2つのセクションが異なる「変数」を使用していることを理解することで解消される。 第26.1.4項— プロトコルテーブルにおけるレーン番号(H=0 … A=7) SerDes 1の場合、RM は物理層の観点からレーン番号を割り当てます。 手紙 レーン番号(プロトコル表) H 0 G 1 F 2 E 3 D 4 C 5 B 6 A 7     これは意図的なものであり、文書に記載されているとおり正しいものです。NXP TSは以前のCASEでこれを明確に確認しています:「SerDes1はレーンの順序が逆です。」LS1046Aに関して同様の疑問が提起された際、LX2160Aにも同じ方式が適用されることが確認された。AN13022 アプリケーションノートも同じH/0 ...A/7列ヘッダーを使用しています。 セクション 26.4.1.19—接尾辞文字をアドレスインデックスとして登録します(A=0 … H=7) オフセット式 848h + (a × 100h) では、 レジスタ名の文字インデックス として a 使用します。ここで、A=0、B=1、…、H=7 です。 Register name a (文字索引) オフセット LN A RGCR1 0 0x848 LN B RGCR1 1 0x948 LN E RGCR1 4 0xC48 LN F RGCR1 5 0xD48 LN H RGCR1 7 0xF48       これはAN13022によって相互に確認されており、そこには正確に「LNmRGCR1(レーンAの場合はオフセット0x0848、レーンBの場合は0x0948、レーンEの場合は0x0C48、レーンFの場合は0x0D48)」と記載されています。 ―すべてA=0…H=7の文字インデックス式と一致している。 正しいレーンに合わせてEXT_REC_CLK_SELを設定する方法 SerDes 1プロトコルテーブル(セクション26.1.4)からレーン文字を特定します。ここで最初の物理レーンは H (レーン0)とラベル付けされています。 その文字にちなんで名付けられたレジスターを使用してください。たとえば、レーンHの場合は LNHRGCR1 、レーンAの場合は LNARGCR1 を使用します。 アドレスオフセットは、 848h + (letter_index × 100h) を使用して計算します。ここで、A=0、B=1、…、H=7 です。 例えば、レーンH(SerDes 1の最初のレーン、プロトコルテーブルのレーン番号0)で EXT_REC_CLK_SEL 設定するには、次のようにします。 登録番号: LNHRGCR1 オフセット: 848h + 7 × 100h = 0xF48 よろしくお願いします。
View full article
Request for TED-Kit 2 (OM6716) GUI Software Download Instructions Dear NXP Support Team, i am jwHyun, Could you please provide instructions on how to download the GUI software package, so that we can pass this along to our customer? We would appreciate your guidance on the registration/download process at your earliest convenience. Thank you in advance for your support.
View full article
フィットデータ こんにちは、 NX5P3090はどこで入手できますか? FITデータを送っていただけますか?ありがとうございます。
View full article
安全なログインを作成する 母のためにウェブサイトを作成していて、今はユーザーの登録用のログイン部分を作成しようとしているのですが、パスワードの入力とデータベースに送るデータを保護しなければならないときに問題が起きています。何か助けてください。
View full article
Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello, we use the RTD 6.0.0 and BMS 0.9.1. SDK in EB Tresos to generate our driver code. It runs fine under FreeRTOS with Cortex M7 port that does not use the MPU. Now, we want to switch to a FreeRTOS port that does use the MPU. I want to do this in two steps: 1) Making all tasks privileged but using the MPU, i.e. the MPU is reprogrammed in each context switch 2) Making all tasks unprivileged. That means I have to enable "Enable user mode support" in the drivers that are used by unprivileged tasks Right now, I struggle at 1). Driver functions do not work reliably. For example, SPI only works intermittently. It seems as MPU regions are not working correctly. Even if this is resolved, how could 2) be implemented? The supervisor call handler is given by FreeRTOS and the RTD. Am I supposed to merge them? Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @Julián_AragónM, I downloaded FreeRTOS from their website and used a port that supports both Cortex M7 and the MPU. If I understand you correctly, I need to use the NXP-provided FreeRTOS. I only found FreeRTOS by NXP that can be configured in S32DS, not EB Tresos. My questions are as follows: - Can I use the generic FreeRTOS, provided with correct M7+MPU Port? - If not, is there an NXP-provided FreeRTOS that can be configured in EB Tresos? We need to use an ASIL-D certified OS at some point. If the NXP-provided FreeRTOS is not ASIL-D certified, we need to switch to something else. Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @PhilippH, Firstly, MPU initial support was added in FreeRTOS 7.0.0 CD1, can you confirm this is the package you are using? (or 0.8.0 CD1, which is the latest release).  1) Can you share which MPU regions are not working correctly? If possible, please share configuration and routine.  Also, please follow the recommendations included inside the S32K3 FreeRTOS User Manual: Enable Use mpu and Use mpu wrappers v1 options. Set first configurable region to 9 instead of 0 to avoid conflict with MPU region from RTD. Note: Integrating FreeRTOS with MPU support requires modifications in the RTD linker file to define the required memory sections used by FreeRTOS. Use the example files as reference when applying changes to your application. 2) I believe merging is not required, as FreeRTOSConfig.h declares the following macros: /* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS standard names. */ #define vPortSVCHandler SVC_Handler #define xPortPendSVHandler PendSV_Handler #define xPortSysTickHandler SysTick_Handler This redirects FreeRTOS's SVC calls to the RTD-provided SVC_Handler in exceptions.c. Best regards, Julián Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Hello @PhilippH, - Can I use the generic FreeRTOS, provided with correct M7+MPU Port? You can use the generic FreeRTOS port; however, you will need to implement your own solution for S32K3-specific configuration, which is mostly provided in the NXP FreeRTOS package already. Please try to start with this port to see if it solves the problem. - If not, is there an NXP-provided FreeRTOS that can be configured in EB Tresos? No, the provided NXP package is compatible only with S32DS for now. Could you share why do you need FreeRTOS with EB Tresos? Usually, EB Tresos is used for AUTOSAR compliant applications, however, the FreeRTOS package we provided is just for customer evaluation, not recommended to be used in production since it does not meet automotive certifications (ISO26262). You can see it is released as Code Drop (CD) Quality, this is because FreeRTOS is an open-source software and NXP provides it as a reference software without any safety certification. If your application requires a safety-certified OS, you can explore other options, even from our partners: SafeRTOS (Based on the FreeRTOS functional model, with simple migration): https://www.highintegritysystems.com/safertos/ AUTOSAR OS µ-velOSity embOS-Safe NXP RTOS It is up to the customer to select the appropriate third-party RTOS, stacks, IDEs, compilers, etc. for their project. Best regards, Julián Re: Using EB Tresos-generated RTD drivers with FreeRTOS + MPU Thanks a lot for the answer. I got it working with the NXP-provided SafeRTOS and Port as the NXP-provided port already solved the problems I had with the generic Cortex M7 + MPU port provided by SafeRTOS. Regarding our need for EB Tresos: We started with S32DS, but due to the ICs we use, we needed a recent version of the BMS SDK, which was not available in S32DS (at least at the time). We want to do Autosar as little as possible. What worked for now was to generate the driver functions and calling them from FreeRTOS. We do not use and do not plan to use the Autosar RTE. Regarding the 3rd party OS's: Does "With simple migration" mean that an equally user-friendly port exist for SafeRTOS? We used SafeRTOS before, but not with Autosar drivers, but purely handwritten drivers.
View full article
i.MX8 PCIe RC PERSTの外部プルダウン設計に関する技術的問い合わせ 背景: 現在、PERST#はi.MX8の通常のGPIOによって制御されており、外部プルアップ抵抗やプルダウン抵抗は追加されていません。電源投入時のブートROM/SPLステージでは、GPIO PADは初期化されず、高インピーダンスのフローティング状態のままです。ノイズの多い環境では、ピンレベルがトグルし、PCIeエンドポイントデバイスの異常リセットが発生してリンクが確立されません。フローティングノイズを除去するために外部抵抗を追加することを計画しており、2つの案を作成しました。NXPの公式見解を伺いたいと考えています。 スキーム1:プルアップ抵抗を3.3Vに接続する ブートローダーがGPIOを設定する前は、PADは高インピーダンス状態にあります。PERST#は連続的にハイに引き出され、リセットは早期に解除されるため、PCIe CEM仕様のTPV_PERSTのタイミング要件を満たせません(PERST#は電源が安定した後、少なくとも100msはアサート状態を保たなければなりません)。これにより電源オンの信頼性が低下しますか?NXPはこの方式を承認していますか? スキーム2:プルダウン抵抗をGNDに接続する ブート段階ではPERST#は低く保たれ、電源オン時のリセットタイミング要件を満たすことができます。しかし、通常システム動作中にプルダウン抵抗と外部ノイズの組み合わせでPERST#が予期せず低く引き込まれ、予期せぬデバイスリセットを引き起こす懸念があります。このリスクは現実的なのでしょうか?NXPはどのくらいの抵抗値を推奨していますか? 重要な質問: 公式に推奨されているシナリオ、つまりi.MX8 GPIOがPERST#を制御する場合、NXPは外部プルダウン抵抗の追加を許可していますか、それとも外部プルアップ/プルダウン抵抗を明示的に禁止していますか?PERST#を生成するためにPORハードウェア遅延回路を使用することは推奨されますか? ご返信をお待ちしております。ありがとう!      
View full article
如何刷写 P89C52X2BN MCU? 大家好, 我需要对两个旧的MCU进行编程:P89C52X2BN和P89C52RD2。 据我了解,P89C52RD2 支持通过串口进行 ISP 通信。但是不知道如何激活 ISP/IAP 协议? P89C52X2BN芯片该如何刷机?它需要并行程序员吗?如果需要,请说明协议以及如何激活闪光灯模式? 我主要想找到这两款芯片(特别是 X2BN)的官方编程文档,以便参考正确的闪存编程接口和时序。如果您有数据手册中的编程部分或相关链接,请分享。 谢谢! Re: How to Flash P89C52X2BN MCU? Hello 由此给您带来的不便,我深表歉意。P89C52 系列产品已停产,因此不再提供支持,有关该系列产品的信息也已不再提供。 如果这对您有用,以下是 89C51 的相关信息;重要提示:我无法确认或测试这些信息是否适用于 89C52。 89C51Rx+/Rx2/66x 微控制器的在线编程和应用内编程 顺祝商祺! Re: How to Flash P89C52X2BN MCU? 抱歉,XSP6100N 价格太贵了,相当于普通人 6-12 个月的工资。因此,我会阅读文档并尝试自己刷写固件。XSP6100N可以做到,但我买不起,谢谢。 Re: How to Flash P89C52X2BN MCU? 此 AN 可用于 P89C5xRx2,但缺少 P89C5xX2;此 AN 是正确的文档类型,但缺少 P89C5xX2。谢谢!
View full article
Fit Data Hello, where can I find the NX5P3090? Could you please send me the FIT data? Thank you.
View full article
TED-Kit 2(OM6716)GUIソフトウェアダウンロード手順の要請 親愛なるNXPサポートチームへ、 私はjwヒョンです。 お客様にお渡しできるように、GUIソフトウェアパッケージのダウンロード方法について教えていただけますか? お手数ですが、登録/ダウンロードの手順について、できるだけ早くご教示いただければ幸いです。 サポートにあらかじめ感謝いたします。
View full article
Technical Inquiry External Pull--down Design for i.MX8 PCIe RC PERST Background: Currently, PERST# is controlled by a normal GPIO of the i.MX8, and no external pull-up or pull-down resistor has been added. During power-on startup, in the Boot ROM/SPL stage, the GPIO PAD is uninitialized and remains in a high-impedance floating state. In a noisy environment, the pin level toggles, causing abnormal reset of the PCIe endpoint device and preventing the link from being established. We now plan to add external resistors to eliminate floating noise, and have drafted two schemes; we would like to obtain NXP's official opinion. Scheme 1: Connect a pull-up resistor to 3.3V Before the bootloader configures the GPIO, the PAD is in a high-impedance state; PERST# is pulled high continuously, and the reset is released early, so it cannot meet the timing requirement of TPV_PERST in the PCIe CEM specification (PERST# must remain asserted for at least 100 ms after power is stable). Will this cause unreliable power-on? Does NXP approve this scheme? Scheme 2: Connect a pull-down resistor to GND During the boot stage, PERST# remains low, which can meet the power-on reset timing requirement. However, the concern is that during normal system operation, the pull-down resistor in combination with external noise may unexpectedly pull PERST# low, triggering an unexpected device reset. Is this risk real? What resistor value does NXP recommend? Key Questions: In the officially recommended scenario where an i.MX8 GPIO controls PERST#, does NXP allow adding an external pull-down resistor, or does it explicitly prohibit external pull-up/pull-down resistors? Is it recommended to use a POR hardware delay circuit to generate PERST#? We look forward to your reply. Thank you!      
View full article
我不确定这个位的具体含义 屏幕截图_14-9-2026_20244_.jpeg屏幕截图_14-9-2026_20244_.jpeg 对于Authentication Status(AUTHSTTS)寄存器,bit0位置一的含义是已经进入挑战模式了吗,还是说明挑战值准备完成,我对这点非常困惑,有谁能帮我解答一下吗,非常感谢! 屏幕截图_14-9-2026_202943_.jpeg屏幕截图_14-9-2026_202943_.jpeg Re: 我不确定这个位的具体含义 嗨,Vane 如果芯片未启用挑战模式,AUTHSTTS 的第 0 位是否仍设置为 1? Re: 我不确定这个位的具体含义 你好@TakanashiLika AUTHSTTS[CHALRDY] 是一个只读状态位,指示挑战何时准备就绪。调试器应等待 CHALRDY 被置位后再读取 KEYCHALn 寄存器中的挑战信息。 BR,VaneB 回复: 我不确定这个位的具体含义 芯片是S32K314
View full article
创建安全登录 我正在为我妈妈创建一个网站,现在我正在尝试创建用户注册的登录部分,但在确保密码输入和要发送到数据库的数据受到保护方面遇到了一些问题,请问有什么办法吗?
View full article
Create a secure login I'm creating a website for my mom, and now I'm trying to create the login part for the user's registration, but I have some problems when I have to make sure that the input of the password and the data to be sent to the database should be protected, some help?
View full article
この役職が具体的に何を意味するのか、よく分かりません。 屏幕截图_14-9-2026_20244_.jpegScreenshot_14-9-2026_20244_.jpeg 認証ステータス(AUTHSTTS)レジスタのビット0が何を意味するのか、とても混乱しています。チャレンジモードに入ったということでしょうか、それともチャレンジ値が準備できたということでしょうか?どなたかご説明いただけないでしょうか?よろしくお願いいたします! 屏幕截图_14-9-2026_202943_.jpegScreenshot_14-9-2026_202943_.jpeg Re: 我不确定这个位的具体含义 こんにちは、ベイン チップがチャレンジモードを有効にしていない場合でも、AUTHSTTSのビット0は1に設定されますか? Re: 我不确定这个位的具体含义 こんにちは、 @TakanashiLika さん AUTHSTTS[CHALRDY]は、チャレンジの準備が完了したことを示す読み取り専用のステータスビットです。デバッガは、KEYCHALnレジスタ内のチャレンジを読み取る前に、CHALRDYがアサートされるまで待機する必要があります。 BR、VaneB 回复: 我不确定这个位的具体含义 チップはS32K314です。
View full article
TED-Kit 2 (OM6716) GUI 软件下载说明申请 尊敬的恩智浦技术支持团队: 我是jwHyun, 请问能否提供下载图形用户界面软件包的说明,以便我们将其提供给我们的客户? 请您在方便的时候尽快指导我们完成注册/下载流程。 感谢您提前给予的支持。
View full article