RL78/G16のCOM Portデバッグについて

お世話になります。Sei_Kagaと申します。

現在、RL78/G16でUSBシリアル変換ICを使ったCOM Portデバッグを試みております。(IDEはCS+ for CC V8.11.00  [30 Nov 2023])

USBシリアル変換ICとして、WCH社の「CH340N」を使用しているのですが、マイコンからの応答が返ってこず、接続が確立できない状態です。(リセット制御はRTSに変更済、ボーレート設定は全パターン試行)

回路は、AN「R20AN0632JJ0211」(Rev.2.11)に準拠した回路になっております。(3state-bufferはなし)

オシロスコープで波形を確認したところ、CH340NからRESET信号の制御、変換ICのTXDからTOOLRXDの経路でシリアルの信号がでていることも確認できましたが、TOOLTXDから何も信号を出していない状態です。(ただ、それらの信号がタイミング的に正しいかまでは判断できておりません。)

そこで、USB変換ICをFTDI社の「FT232H」に変えて実行したところ、問題なくCS+上でCOM Portデバッグができました。

AN「R20AN0632JJ0211」には、"FTDI社製"と"FTDI社製以外"でボーレートが変わる旨記載されておりましたので、FTDI社製以外のUSBシリアル変換ICでも動作するものと理解していたのですが、現状FTDI社製でしかCOM Portデバッグはできないのでしょうか?

なお、RFPによる書き込みも、上記と同じ結果になり、FT232Hならば問題なく書き込みが可能でした。

お手数をおかけし大変恐縮ではございますが、本件情報をいただけますと幸いです。

Parents
  • CH340EでRL78/G16のCOMポートデバッグを試してみましたが、問題無く接続可能でした。

    (使用したドライバソフトは、WCH社のWebから最新版?を適用しました。ダウンロードページにVersion3.8, 2023-03-16と記載のあるドライバ)

  • tf 様

    ご返信くださりありがとうございます。

    CH340Eで問題なく接続可能との情報、誠にありがとうございます。非常にありがたく存じます。

    また、ドライバの情報も添付いただきありがとうございます。(弊方の環境を確認したところ、ご教示いただいたVerと同一でございました。)

    実際に試していただき、かつ情報ご提供いただきましたこと、重ねて感謝申し上げます。

  • 弊方で確認した内容をアップさせていただきます。

    モードエントリに失敗しているのではないかと考え、RFPによる書き込みを以下のパターンで実施し、そのときの各端子(TOOLTXD, TOOLRXD, RESET, TOOL0)をロジックアナライザ(全チャネル100Msps)で計測しました。

    1. FT231XとRL78/G16(RFP:〇 , COMポートデバッグ:〇)

    FT231X_RL78G16_RFP

    2. CH340NとRL78/G16(RFP:× , COMポートデバッグ:×)

    CH340N_RL78G16_RFP

    3. CH340NとRL78/F13(RFP:〇 , COMポートデバッグ:非対応)

    CH340N_RL78_RFP

    今回問題となった「2. CH340NとRL78/G16」の場合ですと、リセット解除前後で本来TOOL0をLowレベルにしておく必要があるはずですが、Highのままになっておりました。そのせいで、リセット解除後に0x00のモード設定1バイトデータを送ってもMCU側は反応していないのかなと考えています。

    ちなみに、「3. CH340NとRL78/F13」の場合は、問題なくリセット解除前後は期待した動きをしており、問題なく書き込みができています。

    このRESET解除前後のTOOL0の波形は、ボーレートを遅くした状態で0x00を送って波形を作っているのかなと考えたのですが、そうなると1のときと3のときでそこまで差がない。(Lowレベルの期間がスタートビット+データ8=9bitと仮定した場合、それぞれ1373bpsと1313bpsになる。)

    正直何が原因かパッとしないですが、tf様よりCH340EでCOMポートデバッグができるとの情報から、もしかしたらチップによるものかなと思いつつ。(ネットの情報によるとCH340NはCH340Eより古いらしいので。とはいえそれがどう影響してこうなるかはわかりませんが。)

    ちなみに、ボーレート実測値は以下です。

     ・RL78/G16実測:115,740bps

     ・FT231X実測:115,473bps

     ・CH340N実測:115,875bps

    tf様の情報より、CH340Eでできるということですので、下名の目的は達せられそうですので、本件はこれで一旦クローズとさせていただきます。
    (関係者の方でなにかしら上記に関する情報をお持ちでございましたら、書き込みいただけますと幸いです。)

Reply
  • 弊方で確認した内容をアップさせていただきます。

    モードエントリに失敗しているのではないかと考え、RFPによる書き込みを以下のパターンで実施し、そのときの各端子(TOOLTXD, TOOLRXD, RESET, TOOL0)をロジックアナライザ(全チャネル100Msps)で計測しました。

    1. FT231XとRL78/G16(RFP:〇 , COMポートデバッグ:〇)

    FT231X_RL78G16_RFP

    2. CH340NとRL78/G16(RFP:× , COMポートデバッグ:×)

    CH340N_RL78G16_RFP

    3. CH340NとRL78/F13(RFP:〇 , COMポートデバッグ:非対応)

    CH340N_RL78_RFP

    今回問題となった「2. CH340NとRL78/G16」の場合ですと、リセット解除前後で本来TOOL0をLowレベルにしておく必要があるはずですが、Highのままになっておりました。そのせいで、リセット解除後に0x00のモード設定1バイトデータを送ってもMCU側は反応していないのかなと考えています。

    ちなみに、「3. CH340NとRL78/F13」の場合は、問題なくリセット解除前後は期待した動きをしており、問題なく書き込みができています。

    このRESET解除前後のTOOL0の波形は、ボーレートを遅くした状態で0x00を送って波形を作っているのかなと考えたのですが、そうなると1のときと3のときでそこまで差がない。(Lowレベルの期間がスタートビット+データ8=9bitと仮定した場合、それぞれ1373bpsと1313bpsになる。)

    正直何が原因かパッとしないですが、tf様よりCH340EでCOMポートデバッグができるとの情報から、もしかしたらチップによるものかなと思いつつ。(ネットの情報によるとCH340NはCH340Eより古いらしいので。とはいえそれがどう影響してこうなるかはわかりませんが。)

    ちなみに、ボーレート実測値は以下です。

     ・RL78/G16実測:115,740bps

     ・FT231X実測:115,473bps

     ・CH340N実測:115,875bps

    tf様の情報より、CH340Eでできるということですので、下名の目的は達せられそうですので、本件はこれで一旦クローズとさせていただきます。
    (関係者の方でなにかしら上記に関する情報をお持ちでございましたら、書き込みいただけますと幸いです。)

Children
No Data