RX231 でのコード生成を利用した、RSPIモジュールの利用方法について(データのアクセス単位で混乱しています)

解決しました。ありがとうございます。

最後のページにまとめの記載と資料を添付してあります。

【このスレッドでの問題解決点】

RXマイコンでCS+を用いたコード生成機能を利用したRSPIモジュールでの通信

RXはシングルマスタ

/*************************************************/

 

 

お世話になります。

先の質問でのSPIモジュールの動作については解決したのですが

データのアクセス単位で混乱しており、相談できる相手が近くにいませんので

再度質問の投稿をした次第です。

 

【詳細】

① 繋いでいる温度センサが動かないので、ロジックアナライザにて確認を行った。

② 温度センサは初めに、コマンドバイト0x54を送り初期化を行い、次にダミーデータ2バイトを送信すると、温度データを13bitで返す

③ ダミー送信は1[s]毎に行うので、その時に温度情報を受信する

 

【問題点】

初期化コマンドを送信しないと、センサは0x00、0x00の温度データを返すのだが、この状態である。

そして以下を調べた。

① 初期化バイトの送信が送信できない( 0x00)の送信となる

② ダミーコマンドは、状態把握ため以下を試したところ

     SPIsend_cmd[0]=0x86;

     SPIsend_cmd[1]=0x53;

 ロジアナ上では

 0x86 , 0x00

 と表示されたので、何かアクセス単位のズレが生じている可能性を考えた。

 

③ 1バイト送信を行う時(センサ初期化コマンド送信)に、SPI送信関数の引数に2バイト以上を指定

  してもエラーが発生しないことからも、アクセス単位を疑っている。

  コマンド定義の型を変更したり様々な条件で試した。

 

/*** 以下コード抜粋

【RSPI初期化関数】

・フレーム数:1

・シーケンス長:1

・バッファアクセス単位:ワード単位

・転送方向:MSBファースト

 ・データ長:8ビット

【送受信関数】

・定義

MD_STATUS R_Config_RSPI0_Send_Receive(uint32_t * const tx_buf, uint16_t tx_num, uint32_t * const rx_buf){

     MD_STATUS status = MD_OK;     

     if (tx_num < 1U)

     {
          status = MD_ARGERROR;
     }

     // 引数以上のバイト数を指定するとエラーが返るはずがエラーにならない

     else
     {
          /* Initialize the global counters */
          gp_rspi0_tx_address = tx_buf;
          g_rspi0_tx_count = tx_num;
          gp_rspi0_rx_address = rx_buf;
          g_rspi0_rx_length = tx_num;
          g_rspi0_rx_count = 0U;

     /* Enable transmit interrupt */
     RSPI0.SPCR.BIT.SPTIE = 1U;

     /* Enable receive interrupt */
     RSPI0.SPCR.BIT.SPRIE = 1U;

     /* Enable error interrupt */
     RSPI0.SPCR.BIT.SPEIE = 1U;

     /* Enable RSPI function */
     RSPI0.SPCR.BIT.SPE = 1U;
     }

     return (status);

}

 

・使用時

// 初期化コマンド送信なので一度のみ

uint8_t ondo_cmd[1]

ondo_cmd[0]=0x54;

err = R_Config_RSPI0_Send_Receive(ondo_cmd,1,ondo_cmd_rcv);

 

//温度データ取得なので1[s]に1回

uint8_t SPIsend_cmd[2];

SPIsend_cmd[0]=0x86;
SPIsend_cmd[1]=0x53;

err = R_Config_RSPI0_Send_Receive(SPIsend_cmd,2,SPIrcv_cmd);

 

【まとめ】

SPIモジュールは動いています。したがって上述の通り、データの渡し方が何か勘違いを

していると思うのですが、私の頭がヒートアップし過ぎて堂々巡りです。

何かアドバイスを頂けると幸いです。

Parents
  • しんちょろすさん、こんにちは。NoMaYです。

    >8ビットの通信の度にSSがネゲートされるのは
    >RXのデータ単位が16bit or 32bit なのを8bit単位にしてるからなのでしょうか。

    >そのことからも、8bit単位で送受信するときのみ
    >SPCMD0.SSLKPを[1] : 転送終了後から次アクセス開始までSSL信号レベルを保持
    >が関係しているようです。
    >(16bit単位での通信時はSSLKPが[0]でもSSはアサートされたままでした)

    たぶん、8ビットか、16ビットか、32ビットか、或いは半端なビット数か、ということは関係ないと思います。RSPIというものは、以下の画面コピーのタイミングでCS制御やウェイト挿入が必要な用途向けに設計されたもの、なのだろうと思います。上の引用のように、8ビット単位と16ビット単位で動作が異なるように見えるのは、スマートコンフィグレータが生成したコードが送信終了時に送信許可ビットを落としているから、なのではないかと思われます。

    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r01uh0496jj0120-rx231.pdf

Reply
  • しんちょろすさん、こんにちは。NoMaYです。

    >8ビットの通信の度にSSがネゲートされるのは
    >RXのデータ単位が16bit or 32bit なのを8bit単位にしてるからなのでしょうか。

    >そのことからも、8bit単位で送受信するときのみ
    >SPCMD0.SSLKPを[1] : 転送終了後から次アクセス開始までSSL信号レベルを保持
    >が関係しているようです。
    >(16bit単位での通信時はSSLKPが[0]でもSSはアサートされたままでした)

    たぶん、8ビットか、16ビットか、32ビットか、或いは半端なビット数か、ということは関係ないと思います。RSPIというものは、以下の画面コピーのタイミングでCS制御やウェイト挿入が必要な用途向けに設計されたもの、なのだろうと思います。上の引用のように、8ビット単位と16ビット単位で動作が異なるように見えるのは、スマートコンフィグレータが生成したコードが送信終了時に送信許可ビットを落としているから、なのではないかと思われます。

    www.renesas.com/jp/ja/doc/products/mpumcu/doc/rx_family/r01uh0496jj0120-rx231.pdf

Children
  • NoMaYさん

    ありがとうございます。
    資料まで示して頂きありがとうございます。

    >マートコンフィグレータが生成したコードが送信終了時に送信許可ビットを落としているから、なのではないかと思われます。

    理解できました。(100%とは言い難いですが)
    私の現在の設定は8bit送受信なので、いったんここで割込み関数で「送信完了」となり
    CSをどうするかの選択ができるタイミングなのですね。
    そして今回は上述の通り8bit単位の通信で、2回連続で通信したいのにもかからわず
    SSがネゲートしていたので、通信が終了したとセンサが判断し、望む返信がこなかった
    という訳ですね。

    これをたった一枚のデータ(アナライザーCSが一瞬ネゲートしている写真)で
    一発でご指摘くだいましたNoMaYさんの知識と経験にただただ驚き・尊敬する
    ばかりです。

    本当にありがとうございます。