なんとかなるさね

マイコンをネタにブログを始めてみました


RXマイコン基板(RX62N) | USBマルチファンクションファームウェア + RXマイコン用GDBSTUB 

2つ前1つ前のエントリを読み返していて、またちょっと好奇心から、マニアックなことを考え始めました。

(1) USBマルチファンクションファームウェアの仮想COMポートとHIDとマスストレージを自由に使えるように
  したままでUSB接続GDBSTUBを作ることは出来ないか?

(2) 内蔵フラッシュメモリ上のプログラムをデバッグ出来るGDBSTUBをRXマイコンの公開されている仕様から
  作ることは出来ないか?

今のところ、漠然とですが、以下のような思い付きがあります。

(1-1) USBの残っているエンドポイントでカスタムデバイスクラスを作り、それをリード/ライトしてTCP/IP
   通信へリダイレクトするWindowsアプリケーションを作成し、GDBへTCP/IP通信で接続する。(もし
   GDBがWindowsのパイプを扱えるなら、TCP/IP通信ではなくパイプを使うことがあるかもしれない。)

(1-2) あるいは、HIDに同時に複数の機能を持たせ(可能かどうか不明)、そのうちの1つをGDBSTUBとの通信に
   使用する。上と同様なWindowsアプリケーションを作成して、GDBと接続する。(いずれ、HIDの実最大
   通信速度を測定してみる。)

(2-1) ソフトウェアブレークは、内蔵フラッシュメモリ上のプログラムの命令コードをBRK命令に書き換える
   ことで実現する。1ブロック全体の書き換えが必要になるので、(1-1)のWindowsアプリケーション上に、
   内蔵フラッシュメモリのデータのコピーを持たせ、GDBSTUBとの通信量を減らすようにする。(いずれ、
   USBマルチファンクションファームウェアでUSB通信して内蔵フラッシュメモリを書き換える場合の実
   書き換え速度を測定してみる。今現在、そういう機能さえありませんが。)

(2-2) シングルステップ実行は、大半の命令は何番地のアドレスで実行されようとも、命令実行結果に違いが
   ないことを利用して、内蔵RAMへ命令をコピーして、内蔵RAM上でシングルステップ実行する。相対
   分岐命令などは、実際に実行することを諦め、GDBSTUBまたは(1-1)のWindowsアプリケーションで
   命令を解析して、直接プログラムカウンタの値を変更するようにする。(全命令なんとかなるか不明。)

(2-3) RAM上でのシングルステップ実行は、RXマイコン用GDBSTUBを作られた人がGitHubで公開している
   方法で行う。(2-2)で相対分岐命令などは特別扱いすることにしたので、基本的に、実行対象の命令の
   次のアドレスにBRK命令を配置した状態(つまり、その命令を実行するとソフトウェアブレークが発生
   ようにした状態)で、実行対象の命令のアドレスからコンティニュー実行させることで実現する。

(2-4) 内蔵フラッシュメモリの書き換え前後で、USBマルチファンクションファームウェアのアドレスが移動
   してしまわないように、USBマルチファンクションファームウェアは、内蔵フラッシュメモリの最後尾
   辺りにアドレスを固定するようにセクション配置を行う。

追記 : メモ

HID機能を自由にしたいのは、HID経由でRXマイコンのデジタル入出力やアナログ入出力、シリアルインター
フェイス送受信を制御するプログラムを仕込む余地があると、ちょっと面白そうだと思っているからです。
また、プログラムに以下のような仕込みをしておいて、実際の入力データや受信データの代わりに、HID経由
でPCからセットした変数の値を参照するようにしたら、最終的にはRXマイコンに繋がる筈のターゲットがない
時でも、HID経由で擬似的な入力を与えることが出来て、簡単な動作確認ぐらい出来るようになるかもしれず、
ちょっと面白そうだと思っているからです。

    if( IsFunctionTestMode == 0x55AA55AA )
    {
        ReadData = HID経由でPCからセットした変数の値;
    }
    else
    {
        ReadData = 実際にポートから読み込んだ値;
    }
    return ReadData;

追記 : メモ

e2studioに同梱されているrx_converter.exeというプログラムを使用すると、ルネサス純正Cコンパイラで
ビルドしたプログラムをGDBでデバッグ出来るようになります。

追記 : メモ

GDBとGDBSTUBの間の通信に使われるGDB Remote Serial Protocolには、マイコン側のプログラムからの
デバッグメッセージを、GDBやGDBのフロントエンドになっているe2studioの画面に出力するプロトコルも
定義されています。(その他にも、まだ詳細を理解出来ていませんが、マイコン側のプログラムから標準入力、
標準出力、標準エラー出力を含むファイル全般を操作するリモートファイルI/Oプロトコルも定義されている
ようです。) ですので、デバッグメッセージの出力用に仮想COMポートを取られてしまうこともないです。

追記 : メモ

さらに、GDB Remote Serial Protocolには、GDB側から任意のメッセージ(モニタコマンド)をGDBSTUBに
送り、GDBSTUB側からGDBへのリプライを受け取ることが出来るプロトコルも定義されているので、HID
機能を使わずに(本来の用途に使ったまま)、RXマイコンのデジタル入出力やアナログ入出力、シリアルイン
ターフェイス送受信を制御するプログラムを仕込むことも可能です。(追記 : 書いた後で、マイコン側のプロ
グラム実行中でもGDB側からGDBSTUBへメッセージを送ることが出来たかどうか気になって来ましたので、
いずれ、確認しようと思います。また、以前、EclipseのGDBフロントエンドプラグインの1つのZylin CDT
ではモニタからのリプライが表示されていたのに、Eclipseの標準のGDBフロントエンドプラグインでは表示
されないという違いに気付いたことがあるのですが、今でもそうなのか、いずれ、確認しようと思います。)

追記 : メモ

RX62Nのユーザーズマニュアルを読んでいて気付いたのですが、マイコン内部の殆どのモジュールの電源が
OFFになるディープソフトウェアスタンバイモードから復帰した時、電源がOFFになっていたモジュールは
リセット状態に戻りますが、RX62NのUSBモジュールには、USBケーブル接続端子の出力状態を、ディープ
ソフトウェアスタンバイモード中も、復帰した時にUSBモジュール(とRX62Nの殆どのモジュール)がリセット
状態に戻った時も、ディープソフトウェアスタンバイモード前の状態で保持し続ける機能があります。多分、
この状態の時は、パソコン側から見ればUSB接続が保持され続けているように見えるのだと思います。この
機能を利用すると、パソコン側のGDBとマイコン側のGDBSTUBの間のUSB接続を切断してしまうことなく、
マイコン内部の殆どのモジュールをリセット状態に戻すことが出来るかも知れません。

追記 : 雑感

V850E2/ML4のマルチファンクションUSBのアプリケーションノートによると、V850E2/ML4の内蔵USB周辺
回路には、USBのエンドポイント0の特定のコントロール転送パケットに自動応答する機能があるようです。
それを読んで思ったのですが、特定のコントロール転送パケットを受信した時にBRK命令実行と同等な動作を
する最強無条件割り込みを自動発生させるようなことが、もし出来るようになれば、割り込み不許可状態で
デッドロックしてしまったようなプログラムでも、GDBから実行を強制停止させることが出来るようになって、
ちょっと面白くなるかもしれない気がしました。(もっとも、そんな機能は、まず入らないでしょうが。)

関連記事

2013/08/04   blog-entry-320   category: RX /* 32bit CISC */

go page top