Quad SPIフラッシュの動作が確認できたので、次にUSB経由で書き込む手段を用意します。その手段とは、USBのDFUインターフェースを組み込みことです。STM32L452では元々のブートローダでUSB DFUがサポートされていますので、まずはその見え方を確認してみましょう。
![](https://blogimg.goo.ne.jp/user_image/32/86/5668fa74f7b39ef79dcb34731e1a828d.jpg)
拡張コネクタのBOOT0ピンの上がVDDになっているので、この2つの端子をジャンパした状態で追加実装したUSBコネクタからE5V端子に5Vを供給してやれば、USB DFUで ブートローダが動きます。dfu-utilで確認してみると...
![](https://blogimg.goo.ne.jp/user_image/71/88/e168d1cc43f8815e102689e371898193.png)
フラッシュのプログラム領域だけでなく、オプションバイト等もDFUで統一的にアクセス可能になっており、Alternate Interfaceを切り替えることで、どの領域にアクセスするかを決められるようになっているのですね。Serial番号はUniq Device IDレジスタを読みだして使っているのだろうと思い、該当領域(0x1FFF7590からの3ワード)を確認してみると...
![](https://blogimg.goo.ne.jp/user_image/68/c9/76bff70f599110aafcbec124f84a29f3.png)
うーん、なんか違うようです。ちょっと気になったので、STM32のフォーラムで検索してみたら、答えが見つかりました。
と、合成しているそうです。
STM32風のDFUの流儀がわかったので、次に実際にSPI FlashにアクセスできるDFUを組み立て始めましょう。幸いなことに CubeMXを使うことで簡単にDFUクラスのインタフェースの枠組みを生成することができますので、まずはCubeMXでの設定から作業を開始します。
![](https://blogimg.goo.ne.jp/user_image/16/1f/060dfd7206e5f7f3d10269fe27d01652.png)
QSPIのメモリ空間は0x90000000からのアドレスにマップされますので、それに応じてUSB_DFU_MEDIA Interaceを設定します。ここではMX25R6435Fを64Kのブロックが128ある構成であることも示しています。USB_DFU_XFER_SIZEは少し大きめの4KBに設定してみました。
![](https://blogimg.goo.ne.jp/user_image/04/c7/062a8f248f10ed4602719a8cf725380d.png)
Device Descriptorの内容はCubeMXのディフォルトのままとしました。この設定だとシリアルは固定になってしまうので、後ほどUniq Device IDから導出することを考えてみたいと思います。
上記のように設定しただけでコード生成を行なって、ビルドしてみると、とりあえずEnumeratitonまでは動作するようになりました。
![](https://blogimg.goo.ne.jp/user_image/48/5a/f027d6507ce67a5cbf48046f9a2354b3.png)
まだDFUクラスのインタフェース部分のコードは何も書いていないので、実際にSPI Flashにアクセスすることはできません。この部分を追加で作ってやれば、実際にフラッシュへの書き込みができるようになるはずです。
![](https://blogimg.goo.ne.jp/user_image/32/86/5668fa74f7b39ef79dcb34731e1a828d.jpg)
拡張コネクタのBOOT0ピンの上がVDDになっているので、この2つの端子をジャンパした状態で追加実装したUSBコネクタからE5V端子に5Vを供給してやれば、USB DFUで ブートローダが動きます。dfu-utilで確認してみると...
![](https://blogimg.goo.ne.jp/user_image/71/88/e168d1cc43f8815e102689e371898193.png)
フラッシュのプログラム領域だけでなく、オプションバイト等もDFUで統一的にアクセス可能になっており、Alternate Interfaceを切り替えることで、どの領域にアクセスするかを決められるようになっているのですね。Serial番号はUniq Device IDレジスタを読みだして使っているのだろうと思い、該当領域(0x1FFF7590からの3ワード)を確認してみると...
![](https://blogimg.goo.ne.jp/user_image/68/c9/76bff70f599110aafcbec124f84a29f3.png)
うーん、なんか違うようです。ちょっと気になったので、STM32のフォーラムで検索してみたら、答えが見つかりました。
0x00230017+0x20323634 --> 0x2055364B 0x5736500F --> 0x5736
と、合成しているそうです。
STM32風のDFUの流儀がわかったので、次に実際にSPI FlashにアクセスできるDFUを組み立て始めましょう。幸いなことに CubeMXを使うことで簡単にDFUクラスのインタフェースの枠組みを生成することができますので、まずはCubeMXでの設定から作業を開始します。
![](https://blogimg.goo.ne.jp/user_image/16/1f/060dfd7206e5f7f3d10269fe27d01652.png)
QSPIのメモリ空間は0x90000000からのアドレスにマップされますので、それに応じてUSB_DFU_MEDIA Interaceを設定します。ここではMX25R6435Fを64Kのブロックが128ある構成であることも示しています。USB_DFU_XFER_SIZEは少し大きめの4KBに設定してみました。
![](https://blogimg.goo.ne.jp/user_image/04/c7/062a8f248f10ed4602719a8cf725380d.png)
Device Descriptorの内容はCubeMXのディフォルトのままとしました。この設定だとシリアルは固定になってしまうので、後ほどUniq Device IDから導出することを考えてみたいと思います。
上記のように設定しただけでコード生成を行なって、ビルドしてみると、とりあえずEnumeratitonまでは動作するようになりました。
![](https://blogimg.goo.ne.jp/user_image/48/5a/f027d6507ce67a5cbf48046f9a2354b3.png)
まだDFUクラスのインタフェース部分のコードは何も書いていないので、実際にSPI Flashにアクセスすることはできません。この部分を追加で作ってやれば、実際にフラッシュへの書き込みができるようになるはずです。