2400549_ja-JP

はい

S32K344 RTD 3.0.0:空の.slewRateCtrlSelLPSPI4ピン用に生成されました - ビルドが失敗します

こんにちは、

私は、NXP RD33772C14EVMリファレンス・デザインに従ってSPI配線をしたS32K344(172ピンMQFP)カスタムボード上のバッテリー・マネジメントアプリケーションを紹介しています。私はS32 Design Studio 3.5とRTD 3.0.0を使っています(プラットフォーム、ポート、SPIモジュールはすべてSWバージョン3.0.0を報告しています)および FS26 SBC CDD 2.0.0 (Sbc_fs26)。私の出発点は、S32K344 用の Sbc_fs26_example_HLD サンプルです。

私のシステムではLPSPI0はFUTUREの2チャネルデイジーチェーン用に予約されており、他のSPIインスタンスはすでに使用中なので、FS26のSBCはLPSPI4上で動作しなければなりません。RD33772C14EVM回路図に従い、4つのLPSPI4信号をリファレンス・デザインで使われている同じパッドにルーティングしました:lpspi4_pcs0はPTB8、lpspi4_soutはPTB9、lpspi4_sckはPTB10、lpspi4_sinはPTB11に。ペリフェラル側ではSPIの物理ユニットマッピングをLPSPI_4に設定し、SpiHwUnitをCSIB0に残し、MCUコンポーネントのLPSPI_4ペリフェラルクロックゲートを有効にしました。

「Update Code」を実行してビルドすると、生成されたファイルgenerate/src/Siul2_Port_Ip_VS_0_PBcfg.cでエラーが発生してコンパイラが停止します。ジェネレーターは右辺のない代入式を生成しました。

../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: エラー: ',' トークンの前に式が必要です
118 | .slewRateCtrlSel= 、

同じ空の.slewRateCtrlSel= は、158行目、198行目、238行目に現れます。これは、4つのLPSPI4ピンそれぞれに対応しています。手動でその4行にPORT_SLEW_RATE_NOT_AVAILABLEを入力すると、ビルドは少し進みますが、.inputMuxRegで同じように失敗します。= { (空の初期化子、「ISO C では空の初期化子の括弧は禁止されています」)。つまり、これら4つのパッドのピン構成構造は、有効なCではない空のフィールドで生成されます。

PTB8–PTB11のピンツール「ルーティング詳細」を見ると、スリューレートコントロール列(および入力フィルター列)に該当なしが表示され、スリューレートセルを選択するとツールチップが表示されます:「選択したピンはこの機能の設定をサポートしていません。スルーレート制御を選択します。SO、これらのパッドにはスルーレート制御ハードウェアが搭載されていないのです。私の理解では、そのCASEジェネレーターは他のサポートされていないパッド機能に対して*_NOT_AVAILABLE値を使うのと同様に、PORT_SLEW_RATE_NOT_AVAILABLEを放出するはずです(その値はこのデバイスのSiul2_Port_Ip_PortSlewRateControl枚数に存在します)。しかし実際には何も発信せず、ビルドが壊れます。

これがピンの選択の誤りではなくツールやドライバの問題だと確信する理由は、NXP自身のLVBMS_RD_Bring_up_ExampleがFS26 SBC用にまったく同じ4つのLPSPI4パッド(PTB8/PTB9/PTB10/PTB11)を使っていて、きれいに組み立てられることです。その例と私のプロジェクトで唯一の違いはRTDバージョンです。LVBMSの例はRTD 2.0.0(プラットフォーム/Port/Spi SW 2.0.0)に基づいて構築されているのに対し、私のプロジェクトはRTD 3.0.0を使っています。基板のピン配置は同じで、ピンも4本とも同じ、ピンの電気的特性も同一です（方向のみが両者で設定されています）。SO、スルーレート対応しないパッドのSiul2_Port_Ipコード生成がRTD 2.0.0とRTD 3.0.0の間で逆行したように見えます。

私の質問：

これはRTD 3.0.0の既知の問題ですか？修正版／パッチ適用済みのRTDリリースはありますか？
RTD 3.0.0環境下で、PTB8～PTB11（RD33772C14EVMピン配置）においてLPSPI4を正しく、かつサポートされている方法で構成するにはどうすればよいでしょうか？つまり、ピンツールが有効なコードを生成するようにするためです。つまり、slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLEと有効なinputMuxRegを生成し、空欄ではなく?
設定レベルでの修正がない場合、生成された Siul2_Port_Ip_VS_0_PBcfg.c を手動で編集することが唯一の回避策でしょうか (「コードの更新」のたびに上書きされます)、それともプロジェクトを Port/RTD 2.0.0 に移行することが推奨される方法でしょうか？

もし役に立つなら、完全なビルドログ、ピンの「ルーティング詳細」スクリーンショット(ツールチップ付き)、そして2つのプロジェクトのモジュールバージョンを並べて添付CAN。

ありがとう、
ソン・ヒョンシク

Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails

こんにちは、VaneBさん。

どうもありがとうございました。まさにそれが問題だったのです。ピンツールはLPSPI4(PTB8–PTB11)に更新されていましたが、 ポート コンポーネントのポートピンエントリは元のLPSPI0パッドを指していたため、PortPin Pcr(Mscr)の値は古くなっていました。

ポート設定内の4つのPortPin Pcr値を、新しいピン割り当てに合わせて更新しました。

PCS0 → PTB8 (PCR 40)
SOUT → PTB9 (PCR 41)
SCK → PTB10 (PCR 42)
SIN → PTB11 (PCR 43)

Update Codeを実行して再構築した後、空の .slewRateCtrlSel/ .inputMuxRegSiul2_Port_Ip_VS_0_PBcfg.c のエラーは解消され、プロジェクトは正常にビルドされます。

迅速かつ的確なご回答、本当にありがとうございました。おかげで大変時間を節約できました。これを解決策としてマークします。

よろしくお願いします、
ヒョンシク

Re: S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails

こんにちは、 @hyunsiksong

この問題は、RTD自体にも、S32DS構成ツールによって生成されたコードにも関係ありません。むしろ、それは設定に関係している。

ペリフェラルツール内のポートドライバ構成では、PortPin Mscrパラメータに割り当てられた値は元のプロジェクト構成に対応しています。例えば、プロジェクトは以前、PTB1をLPSPI0_PCS0として使用するように構成されており、これはPortPin Mscr = 33に対応します。

ただし、更新された構成ではLPSPI4が使用され、PCS0はピン8に再割り当てされています。したがって、対応するPortPin Mscrの値は33ではなく40になります。

すべてのピンについてPortPin Mscrを確認し、現在のピン割り当てと一致していることを確認してください。これらの値を新しい構成に合わせて更新することで、問題は解決するはずです。

BR、VaneB