はじめに
GR-KAEDEが秋月電子で在庫処分特価で売っていたので、買ってみました。GR-KAEDEは、RX64Mを搭載した評価ボードで、イーサネットやUSBの他に256MビットのSDRAMが実装されています。本記事は、GR-KAEDEにUSB MSCのファンクション機能をゼロから実装したときの覚書です。e2studioを使う場合、FITが便利ですが、それでは勉強にはならないので、レジスターレベルでゼロから実装することにしました。
仕様
| 項目 | 仕様 | 備考 |
|---|---|---|
| ターゲットボード | GR-KAEDE | |
| MCU | R5F564MLCDFB | 144ピン、RAM:512K/ROM:4M |
| 開発環境 | e2studio v2022.01 | |
| RTOS | 使用しない | |
| ツールチェイン | GCC for Renesa RX 8.3.0.29.201904 | バージョンに注意※1 |
| エミュレータ | E1エミュレータ | |
| その他のツール | usbmon、wireshark、他 |
※1,8.3.0.29.201904以降のバージョンでは、optlibが使えなくなりました。替わりのnewlibはoptlibに比べると数値計算が圧倒的に遅い。
テストプロジェクト
WindowsまたはLinux上でGR-KAEDEがUSBメモリーとして見えます。ただし、マスストレージはSDRAMなので電源を落とすと、当然ながら中身は消えます。ソースコード１式は、VLXのダウンロードサイトにあります。どなたでも無料でダウンロードできます。また、RX62N用のプロジェクトも一緒に置いてあります。
文献
[1]RX64Mグループユーザーズマニュアル ハードウェア編ルネサス32ビットマイクロコンピュータRXファミリ／RX600シリーズ
[2]Universal Serial Bus Specification Revision 2.0, April 27, 2000
[3]Universal Serial Bus Mass Storage Class Specification Overview, Rev 1.4, February 19, 2010
[4]Universal Serial Bus Mass Storage Bulk-Only Transport, Revision 1.0, September 31,1999
[5]Universal Serial Bus Mass Storage Specification For Bootability, Revision 1.0, October 25,2004
[6]SFF-8070i Specification for ARAPI Removal Rewritable Media Devices, Rev 1.2, Nov.4, 1998
[7]SCSI Commands Reference Manual, Rev.L, November 2020, Seagate
[8]Microsoft FAT Specification, August 30, 2005
プログラムの構成
概要
USB MSC(Mass Storage Class)の基本的な考え方は、SCSIやATAPIなどのストレージデバイスを模擬することです。模擬対象となるストレージデバイス用コマンドにUSB固有の項目を付加した拡大コマンドパケット（ラッパーと言う）をホスト・デバイス間で送受信します。模擬対象としてSCSIコマンドを採用するケースが多いようですが、SCSIはコマンド数が多いうえ、やや複雑です。一方、ATAPI用のSFF-8070i規格のコマンド数は１７個と少なく、プロトコルも簡単です。（文献3）では、SFF-8070iの採用は勧めていないようですが、本書では、SFF-8070iを採用することにします。また、通信プロトコルは、Bulk-InとBulk-Outの２つのエンドポイントのみを使用するBulk Only Transfer（BOT）を使用します。Windowsの汎用USB MSCデバイスドライバーであるusbstor.sysがSFF-8070iとBOTに対応しているので、そのまま使用できます。
割り込み駆動
本プロジェクトでは、RTOSを使用していないので、すべての処理の起点は割り込みです。USBとしての基本機能は、デフォールトパイプの割り込み処理ルーチンが扱います。MSC固有の処理は、Bulk InとBulk Outの2つのエンドポイントが担当します。両者ともに割り込み要因はBRADYです。各エンドポイントごとのBRADY割り込みルーチンが処理します。
ファイルシステム
Linuxではddコマンドが使えるので、ファイルシステムが無くてもなんとかなりますが、Windowsの場合は、ファイルシステムに対応していないと、ドライブ文字が割り当てられません。USB MSCデバイス自体が見えないので、お手上げ状態になります。前述したように、マスストレージはSDRAM上にあるので、このデバイスを起動したときに、毎回マイコン側でFAT16でフォーマットするようにしました。
FAT領域サイズの計算
FAT領域のサイズの計算は（文献8）にも書いてありますが、少し補足します。下記は、Master Boot Recordを持ち、予備を含めてFAT領域を2つ作成した場合のFAT16ファイルシステムのレイアウトです。サイズの単位は、セクション数です。セクターは512バイト、クラスターサイズは8セクターと仮定しています。
| 領域 | サイズ | 説明 |
|---|---|---|
| MBR | 1 | Master Boot Record |
| BPB | 1 | Bios Parameter Block |
| 空き | 6 | クラスターサイズで整列する |
| FAT1 | 16 | 第1FAT領域 |
| FAT2 | 16 | 予備FAT領域 |
| RDE | 2 | Root Directory Entry |
| Data | データ本体 |
FAT領域のセクション数をxとすると、
(512/2)*SecPerClus*x = DskSize-(RsvSecCnt+RootDirSectors+NumFATs*x)
xについてこれを解くと、
x=\frac{DskSize-(RsvSecCnt+RootDirSectots)}{256*SecPerClus+NumFATs}
ここで、SecPerClusはクラスターのセクター数=8、DskSizeはデバイスの全セクター数=32678、RsvSecCntはFAT以前のセクター数=8、RootDirSectorsはRDE領域のセクター数で、最大ファイル数を32と仮定すると、32*32/512=2となります。NumFATsはFAT領域の個数=2です。これらを代入するとx=15.98になります、切り上げてx=16です。
SFF-8070i規格
SFF-8070i（文献6）は、ATAPIインターフェースに対応したリム―バブルディスク用の通信規格です。17個のコマンドのうちすべてを実装する必要はないようです。本記事では、実装したのは、下記の7個だけです。それ以外は、STALLを返しています。
| コマンド名 | コード | 説明 |
|---|---|---|
| TEST_UNIT_READY | 00h | デバイスの生存確認 |
| INQUIRY | 12h | デバイスのタイプなどの問い合わせ |
| MODE_SENSE10 | 5Ah | 特に何もしない |
| READ10 | 28h | データの読み取り |
| READ_CAPACITY | 25h | 最大セクター数とセクターのバイト長 |
| REQUEST_SENSE | 03h | エラーコードを返す |
| WRITE10 | 2Ah | データの書き込み |
デバッグ
開発の初期段階では、いつもの通り、全く動きません。プロトコルアナライザ―があれば、うれしいのですが、結構高いです。趣味の範囲を超えています。ソフトウエアで通信パケットが見られるツールを探したところ、usbmonとwiresharkが見つかりました。usbmonはLinux専用です。Windows用のusbpcapもありましたが、usbmonの方が使い勝手が良さそうです。このため、開発の初期段階ではLinuxでデバッグをします。ある程度動くようになったら、Windows上でWiresharkを使ってデバッグします。
苦労したところ
下記コードの断片は、ホストから送られてくるマスストレージデータを受信するルーチンです。すべてのデータを受信し終えたところで、ACLRMビットでPIPE1（Bulk In用）をクリアーします。これをしないと、次に送信するステータスのdCSWTagが前のままになり、通信不良が発生して、デバイスがリセットされてしまうと言う症状がありました。この症状は、usbmonでプロトコルを解析して見つけました。対処療法としては、ACLRMによる全クリアーで症状は出なくなりますが、何故これで解決するのか十分に理解できていません。
//マスストレージデータを受信
int recv_ms_data()
{
int dtln;
debug(DEBUG_LEVEL3,"recv_ms_data: rx_remaining=%d, wrp=%d\n",rx_remaining,wrp);
//read D1FIFO
dtln = USB0.D1FIFOCTR.WORD & DTLN;
for (int i=0; i<dtln; i++) {
if (wrp>=mass_storage_length) {
debug(DEBUG_ERROR,"recv_ms_data: invalid wrp=%d\n",wrp);
return -1;
}
uint8_t c = USB0.D1FIFO.BYTE.L;
mass_storage[wrp] = c;
wrp++;
}
rx_remaining -= dtln;
if (rx_remaining<0) {
debug(DEBUG_ERROR,"recv_ms_data: invalid rx_remaining\n");
rx_remaining = 0;
}
if (rx_remaining>0) {
//マスデータ受信を継続
bulkout_state = RECV_MS_STATE;
} else {
//*** 受信完了 ***
/**
* [重要]
* PIPE1(BulkIN)のダブルバッファをクリアーする。PIPE2(BulkOut)ではないことに注意。
* これをしないと、WRITEコマンドの次に受信するコマンド（TEST_UNIT_READYなど）に対するdCSWTagが、
* WRITEコマンド時のdCSWTagのままになっている。
* dCBWTagとdCSWTagの不一致が生じ、ホストはデバイスをリセットしてしまう。
* 理由は良く理解していない。
*/
USB0.PIPE1CTR.WORD |= ACLRM;
sleep_in_msec(0.1f);
USB0.PIPE1CTR.WORD &= ~ACLRM;
//BulkInの次のフェーズはCSWステータスを返す
bulkin_state = STATUS_STATE;
//応答を返すためBulkIn割り込みを許可
USB0.BRDYENB.WORD |= PIPE1_BITPOS;
//BulkOutの次のフェーズはCBWコマンド受信
bulkout_state = COMMAND_STATE;
}
return rx_remaining;
}
おわりに
最後まで読んでいただいてありがとうございます。ご感想等などがあれば、どんなことでも結構です、Mailを下さい。