サマリ
想定読者:USBの設定に興味がある方 / 想定時間:25分~30分程度
第24回目のテーマは、USBのレジスタ設定について取り上げます。

#1 レジスターマップをつぶさに確認
これまでの記事で回路設計やパターン設計を取り上げてきました。この後は、基板が製造され、簡易チェックが無事完了したあと、チップ自体の設定に移ります。今回はその設定について取り上げたいと思います。
レジスタ設定はかなりの分量があります。ですので、まず初めに、頭の中で枠を作ってから臨んだ方が迷わなくなりますので紹介です。以下の図を見てください。基本的にはどのデバイスであっても、大きく捉えて、チップ自体の制御、周辺デバイスとの連携の制御、(ここではUSBの)識別/通信仕様の制御の3つで構成されます。
チップ自体の制御とは、そもそもどのポートを利用するのか、(今回取り上げているUSBチップだとありませんが)クロックの設定をどうするかなど、基本的な動作の設定を意味しています。
周辺デバイスとの連携は、I2Cや(今回取り上げているUSBチップだとありませんが)DDRなど、必ず周辺デバイスとの連携には通信規格が用いられます。その際には通信速度やマスタ/スレーブの設定など、規格に沿った通信制御の設定を意味しています。
識別/通信仕様の制御は、今回だとわかりやすくUSB自体の通信など、外部との通信制御を意味します。例えば、許容できる速度や電力、エラー時の処理などです。

それでは、今回対象とするUSBチップ(TUSB8044A)のレジスタマップを見てみましょう。SoCなどよりは比較的少ない分量ですが、これだけの設定を一からする必要があります。まずは、どのレジスタがどの役割を担っているかをざっくり掴むことが、混乱しないためのおすすめになります。

#2 本体やUSBの通信を制御するレジスタ設定
それでは早速中身を見ていきましょう。ID系などは後述するとして、根幹となるチップ自体の利用を制御するコンフィギュレーションレジスタやUSB通信の仕様を制御するレジスタを見ていきましょう。
まず初めにチップ自体を制御するレジスタですが、例えば5h: Device Configuratinや8h: Port Used Configurationがあります。(基本的には何かしらのConfigurationと命名されています)
Device Configuratinは、複数のアドレスに分かれており、それぞれこのチップ自体の動作を制御するためのレジスタになります。例えばこの中身を見ると、1bit目は”u1u2TimerOvr”と記載され、Host側に立った際のDevice側からの応答の待機可能時間を設定します。2bit目には”ullPwrMgmtz”と記載され、このデバイスがフルパワー(電力供給)が可能かを設定します。3bit目には”ganged”と記載され、上記の設定でONの場合に、それぞれのポートでON/OFFの設定ができます。なお、この設定はチップ自体のピンと連動されているため、”BATEN1″ピンのプルアップ/プルダウンでも選択できます。(逆に言えば設定が合うように回路も調整しなければなりません)。これらのように一つ一つのレジスタにはそれぞれ特有の意味が付与されているため、自身の設計にあった内容に設定する必要があります。


Port Used Configurationは、ポート自体の利用可否を選択できます。例えば、本チップは4つのポートがある中で、もし用途が限定されており2つしか使わないなどあれば2つ閉じることが出来ます。不具合防止や消費電力の削減、製品戦略※として活用されます。(※市場にはよく、上位機種ほど高性能などグレード設定があると思います。一方、製造面では共通品を大量に製造したほうがコストが下がるため、あえて高性能なチップで安価版も設計し、レジスタ設定で切り替えることでチップや回路自体の共通化による製造コスト削減といった戦略を取ることがあります)


次にUSB通信を制御するレジスタについて、一部上記でも設定済みの内容もありますが、他には6h: Battery Charging SupportやBh: USB2.0 Port Polarity Contorol、2Bh: Billboard Configurationなどがあります。
Battery Charging Supportは、Device側のポートに向けて本チップ(Host側)がバッテリーチャージできる能力を有しているかの設定になります。この設定をONにしていると大電流を流すことが出来るサインをDevice側に通達します。

USB2.0 Port Polarity Contorolは、USB2.0は1本の制御線にTX/RXの双方向の通信が用いられるため、その時点でどちら側の通信を実施しているかを制御するレジスタになっています。とはいえ、ほとんどの場合チップ自体がハンドシェイクを実施するため、どちらかというとデバッグのための読み込み用レジスタの位置づけにいます。


Billboard Configurationは、USBの通信がエラーした際にどのような情報を連携するかを制御します。例えば、そもそもこの機能のON/OFFを制御するレジスタや、Host側に本基板の仕様情報を伝達する際の設定などが細かくできます。イメージとしては、接続がうまくできない際に、windowsのデバイス画面でデバイス(USBチップ)の情報をHost側(windows)が読み込み、ユーザーに対してどのようなデバイスを接続しているかを伝達する機能になります。当然、ハードウェアの問題ではない不具合のケースに限定されます。(物理的に断線していたら通信すらできませんので)

#3 その他、識別番号などの設定
それ以外のレジスタも見ていきましょう。
まず0番地から見ていくと、チップ自体を識別するID系などが記載されていることが多いです。0h: ROM Signature/ 1h: Vendor ID/ 3h-4h: Product IDがそれぞれ記載されています。
ROM SignatureはI2Cを用いる際に、(I2Cは複数のチップ間で接続されるケースが多いため、)そもそもこのチップは何かを示す際のIDを登録するための番地になります。
Vendor IDは言わずもがなベンダー(製作会社)のIDを示します。デフォルトでTIのベンダIDが付与されている状態ですが、上書きして登録することが出来ます。このベンダーIDはUSBのフォーラムで登録すると番号が付与されるため、それをここに書き込みます。

Product IDは言わずもがな製品のIDを示します。ここに書き込んでおくことで、何か不具合が出た際にどの製品かを認識するためなどに使われます。後述するシリアルナンバーや製造ナンバーと組み合わせることで、ロット管理が可能になります。
このように、レジスタの最初の方にはID系を記載する箇所が用意されていることが多いです。

次にコンフィグ系(前章)が記載されているのでスキップし、その次に出てくるのUUIDの設定/言語IDの設定あたりになります。
UUIDとは、特にLinuxなどで用いられる識別IDになります。USBを差し込んだ際、2つのUSBがあった際にIDが被ると識別できなくなりますので、疑似乱数を用いて個々に番号が付与されます。ホスト側はそれを用いて、個々にデバイスを認識しています。このような仕組みですので、Typeの欄がROのみになっています(こちらが何か書き込むレジスタではない)。
言語IDとは、読んで字の如く、どの言語が設定されているかを示すIDになります。Microsoftの解説HP(URL:https://learn.microsoft.com/ja-jp/office/2016/language/language-identifiers-optionstate-id-values)にそれぞれの国のIDが記載されています。英語は”1033″のため、16進数表示で0409hとなり、こちらが初期設定されていることが記載されています。なお、日本語は”1041″により、16進数表示で0411hを設定すればOKです。

その後、またコンフィグ設定やビルボードの設定が続き、その次には製造番号の設定が出てきます。IDの部分で記載したように、製造時にこのレジスタに任意の番号を書き込むことで、ロット管理が可能になります。よくメーカがリコールの際に”2010年にご購入した機種”など特定していると思いますが、その際にはロット番号をみて、共通する時期に不具合品が集中していた場合になります。(逆に一貫性が無くバラバラのロット番号品に不具合が生じていると、そもそも設計に不具合があったと判断できますね。その際には製品全てを回収する必要があると判断します)

こちらで全体を一通り見てきました。実際には、I2Cの通信を用いて、RWできるレジスタに書き込みます。電源起動時に毎回書くことは非効率ですので、EEPROM上にあらかじめ設定を保存しておくことで、次回起動時からは本チップがEEPROM上の設定を読み込み、自動でスタートアップしてくれるようになります。
念のため、ここまでは、あくまで本チップの場合におけるレジスタ設定になります。例えばSoC/ASIC/FPGAなど制御機構が複雑であればあるほど、様々な種類の設定がありますので、これが膨大になります(データシートにあるレジスタ設定の部分だけで300ページとかも普通です)。ただし、やることは同じで、上記のような感じで一つ一つ読み込み、設定していきます。
ここまで全て設定した後に、ようやくテストと認証が待ち受けています。次回はこちらを取り上げることで、USBの開発プロセスがいったん終了することになります。