お世話になります。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ならば問題なく書き込みが可能でした。
お手数をおかけし大変恐縮ではございますが、本件情報をいただけますと幸いです。
私、3DプリンターのコントローラボードでCH340（末尾は色々）が載ったボードを使ったことがあります。Klipperといファームウェアに切り替えるとより演算性能が高いPC上で幾何学演算を行って、コントローラボードは単純なドライブ機能のみにすることができて、印刷品質の向上と印刷時間の短縮が可能になります。まず、CH340系でいえるのことがFTDI社のものより選択できるボードレートがない。正確にいうと設定して使うとズレた周波数だということです。本件もTOOLRXDは波形が出ているということはCH340は初期化ができているのだと思います。そして、波形も出力している。ただ、そのボーレートがズレていたりすれば相手はメッセージを正しく受信できません。それが起これば応答メッセージとしてのTOOLTXDは何も出力しないと思います。試しに、CH340NとFT232Hをクロス接続してターミナルソフトでお互いのメッセージが正しく受け取りできているか確認するのもいいかもしれません。あと、CH340NじゃなくてCH340G/CH340T/CH340Rのどれかなら動くかもしれませんよ。ここまで書いてなんですが、実績のあるチップを使うのが開発環境構築の王道なんですけどね。
Sei_Kagaさん、こんにちは。Sugachanceです。
以前社内の人間が、(型番は違いますが)WCH社のICではパリティがおかしくなる現象が見られたというようなことを言っていました。WCH社の仕様が今回要求される仕様と異なっている可能性があるのではないでしょうか？(このケースでは"FTDI社製"と"FTDI社製以外"ではなく、"WCH社製"と"WCH社製以外")
Shoji Yamamoto 様
早速のご返信ありがとうございます。
仰る通り、実ボーレートの違いによる影響はありそうかなと思いました。対向であるRL78も内蔵発振でボーレートつくりますし、誤差が大きい可能性が確かにあるかなと。
いずれにしろ、動作OKな環境と動作NGな環境両方あるので、波形を見比べてみようと思います。
改めまして、ご返信ありがとうございました。
Sugachance 様
ご返信くださりありがとうございます。
モノによってはパリティがおかしくなる場合があるということですね。
ツール側のプロトコル（UART仕様）とWCHの仕様を可能な範囲で見ていこうと思います。
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ポートデバッグ：〇）
2. CH340NとRL78/G16（RFP：× , COMポートデバッグ：×）
3. CH340NとRL78/F13（RFP：〇 , COMポートデバッグ：非対応）
今回問題となった「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でできるということですので、下名の目的は達せられそうですので、本件はこれで一旦クローズとさせていただきます。（関係者の方でなにかしら上記に関する情報をお持ちでございましたら、書き込みいただけますと幸いです。）
ＵＳＢーＲＳ２３２Ｃ変換ケーブルで、ボーレイトが速いとき、連続した長いデータで不具合が起きました。ケーブルメーカを変えたら、問題無かった。