USB DFUを動かす - 下調べ

Quad SPIフラッシュの動作が確認できたので、次にUSB経由で書き込む手段を用意します。その手段とは、USBのDFUインターフェースを組み込みことです。STM32L452では元々のブートローダでUSB DFUがサポートされていますので、まずはその見え方を確認してみましょう。



拡張コネクタのBOOT0ピンの上がVDDになっているので、この２つの端子をジャンパした状態で追加実装したUSBコネクタからE5V端子に５Vを供給してやれば、USB DFUで ブートローダが動きます。dfu-utilで確認してみると...




フラッシュのプログラム領域だけでなく、オプションバイト等もDFUで統一的にアクセス可能になっており、Alternate Interfaceを切り替えることで、どの領域にアクセスするかを決められるようになっているのですね。Serial番号はUniq Device IDレジスタを読みだして使っているのだろうと思い、該当領域(0x1FFF7590からの3ワード)を確認してみると...



うーん、なんか違うようです。ちょっと気になったので、STM32のフォーラムで検索してみたら、答えが見つかりました。

0x00230017+0x20323634 --> 0x2055364B
0x5736500F --> 0x5736

と、合成しているそうです。

STM32風のDFUの流儀がわかったので、次に実際にSPI FlashにアクセスできるDFUを組み立て始めましょう。幸いなことに CubeMXを使うことで簡単にDFUクラスのインタフェースの枠組みを生成することができますので、まずはCubeMXでの設定から作業を開始します。



QSPIのメモリ空間は0x90000000からのアドレスにマップされますので、それに応じてUSB_DFU_MEDIA Interaceを設定します。ここではMX25R6435Fを64Kのブロックが128ある構成であることも示しています。USB_DFU_XFER_SIZEは少し大きめの4KBに設定してみました。



Device Descriptorの内容はCubeMXのディフォルトのままとしました。この設定だとシリアルは固定になってしまうので、後ほどUniq Device IDから導出することを考えてみたいと思います。

上記のように設定しただけでコード生成を行なって、ビルドしてみると、とりあえずEnumeratitonまでは動作するようになりました。



まだDFUクラスのインタフェース部分のコードは何も書いていないので、実際にSPI Flashにアクセスすることはできません。この部分を追加で作ってやれば、実際にフラッシュへの書き込みができるようになるはずです。

QSPI Flashの動作確認

Nucleo-L452につなげたQSPI Flash (MX25R6435F)の動作確認をしました。

QSPI Flashの操作のためのコードは、CubeL4に含まれているSTM32L496G-Discovery用のBSPのコード(stm32l496g_discovery_qspi.c)を流用しました。PIN割り当てを変更すればいいだけのようなものです。BSPのAPIには初期化、Read, Write, Eraseといった基本操作が用意されているので、それらをシェルから使えるようにして、動作確認です。


先頭の256バイトの部分しか試していませんが、消去、書き込み、読み出しができることを確認。BSPのコードは割り込みを使っておらず、書き込み終了もポーリングで検出しているのですが、今回の用途にはこれでも十分に用が足りるので、このまま使うつもりです。

一旦、データの書き込みができれば、QSPIの動作モードをMemory mappedに変更してやると、0x90000000以降のメモリ空間で内容が読み出せるようになります。以下、Map前メモリダンプ、Map操作、そしてMap後のメモリダンプです。





イメージとしては理解してましたが、実際に動かしてみるととっても簡単に使えて便利そう。

LCD表示の事前準備

BM20で再生中の曲名の取得ができるところまで作業を進めたところで、しばらく停滞していました。次の段階として、曲名をLCDに表示しようと考えていたのですが、今までも何度か同じようなことはやっているので、今回は何か新しい要素を入れたいところです。どうしたもんかと考えているうちに時間ばかりが経ってしまいました。おおよその方向性は決めたので、作業を再開することにします。LCD本体はまだ注文を入れたばかりで到着まで少し時間がかかりそうなので、まずは事前準備から進めることにします。

再生中の曲名は、当然ながら日本語での表示を可能とします。フォントデータを用意するとともに、その格納方法を準備する必要があります。これまではSDカードやNANDフラッシュを使ったりしてきましたが、近頃はNOR SPI Flash が安くなってきていますので、今回はSPIフラッシュにフォントデータを格納することにしました。STM32L452にはQuaD SPIインターフェースが備わっていますので、Quad SPI Flashを使うことにします。一旦、フォントデータを書き込んでしまえば、Flashメモリの内容をメモリ空間にマッピングすることができますので、簡単にフォントデータにアクセスすることが可能になるのも利点です。



使うことにしたのでは容量64MbのMX25R6435Fです。Quad SPI 使うの初めてなんで、評価ボードでも使われているMX25R6435を実装して、コードはそのままパクろうという魂胆です。

ついでにUSBのコネクタも接続。SPIフラッシュにフォントデータを格納するためには、まずSPIへフォントデータの書き込みを行わねばなりません。Discoveryボードではデモのプログラムで使用するデータをSPIフラッシュへ書き込む際にはST-Link Utilityと外部のローダを使っているようですが、わたしはDiscoveryボードを使っているわけでもないし、ST-Link Utilityも使ってないので、この方法は使えません。そこで、書き込みはUSB経由で行うことにします。具体的にはUSBのDFUクラスのドライバを組み込んで、SPIフラッシュへの書き込みを行うことにします。

STM32L4R9I

STM32CubeMXの新バージョンが出たので、更新。CubeL4も新バージョンが出たのでダウンロード。今度のバージョンは前回のバージョンよりも1GBもデカくなって1.8GBもあります。内容を確認してみると未発表のL4+シリーズの評価ボードであるSTM32L4R9I-DiscoveryとSTM32L4R9I_EVAL向けのコードとイメージがその大半を占めているようです。どうやらデモ用のバイナリや、デモで使用する音楽再生用のWAVファイルなどの容量が大きいようです。

STM32L4R9はフラッシュ2MBで、SRAMも640KBという大容量になるようですが、どうやらDiscoveryには円形のLCDが搭載されているようです。STM32L4+ではGFXMMUという機能が搭載されていますが、CubeMXの設定パラメータをみると、どうやら各ラスター行毎にフレームバッファーの開始アドレスを指定できる機能のようです。この機能を使うことで、四角形でないディスプレイ形状でもフレームバッファのメモリを無駄なく有効に使えるというアイデアのようです。
Wearable機器向けに特徴を出してアピールする面白い機能ですね。正式発表が楽しみです。

FRDM-K28

NXPからFRDM-K28 が出ていることを今頃になって知りました。内蔵RAMが1MBもあってUSB High speed PHYも付いているようです。STM32F4を使ってのUSB High speedの実験が今ひとつ満足できなかったので、こちらを使って挑戦してみるのもいいかもしれないのですが...

自分としての問題は開発環境です。結構気に入って使っていたKDE が　NXPになってからLPCXpressoと統合されてMCUXpressoになってからというものの、使っていません。KDEではRTOSとしてMQX Lite が使えたのも個人的にはポイントが高かったのですが、それも無くなってしまったために新しいIDEとSDKに手をつける気になれません。