OCTOSPIによるQSPI Flash/PSRAMの接続

現在作業中のNucleo-U575ZIを使ったDoomPlayerの開発ですが、ようやくと音楽、効果音、ゲームの再生、実行機能が動くようになってきました。音楽の再生時には、SDカードとDACを使っており、効果音の再生とゲームの実行時にはQSPI FlashとQSPI PSRAMの両方へのアクセスが発生しているので、Bluetooth部分を除いて基板上に追加実装したパーツのひととおりの動作確認が取れたことになります。

GUIとして使っているlvglは もうすぐv9.0がリリースされる予定ですが、今のところはv.8.3.11を使っています。

Music Playerでは、Timerで生成した44.1KHzのクロックをトリガとしてDACで変換することで音楽を再生。

効果音については、従来通り11.025KHzの8bit PCMを4倍して44.1KHzに変換して再生します。

BluetoothのモジュールであるBT860とはUARTを介してHCIのリセットコマンドを送り、その応答が返ってくることは確認したのですが、BTStackの移植作業は未着手となっています。そのため、Doomの実行時にはデモ画面が流れるのを見ることができるだけで、操作は一切できない状態となっています。

今回のプロジェクトの大きな目的のひとつは、STM32U5のOCTOSPIインターフェースを使って、QSPI FlashとQSPI PSRAMをつなげてアクセスすることでしたので、この目的は達成できたと言えます。おさらいしておくと、2年近く前にはNucleo-H7A3を使ってPSRAMをつなげてみましたが、シリコンバグを回避するために大きな制約を受け入れてようやくなんとか使えるというもので、不満が残っていました。STM32シリーズではデバイスによりQSPI PSRAMの読み書きができるかどうかが異なるので注意が必要です。STは公式にはその一覧を出していないようですが、フォーラムではAP MemoryのAlexさんがデバイス別の対応表を出してくれており、参考になります。

QSPI FlashとQSPI PSRAMは、OCTOSPIMのマルチプレックス機能を使ってIOnとCLK信号を共有することで使用ピン数を削減しています。実際のところNucleo-U575ZIを使えば、FlashとPSRAMにそれぞれ独立したIOnとCLK信号ピンを割り当てることも可能なのですが、マルチプレックス機能を使って問題なく動くようであれば、将来的に100ピンのパッケージを使った基板を作成してみようかとも妄想しているので、確認することにしました。試行錯誤の結果、現在動くようになった設定は...

• 当初は、FlashとPSRAMのどちらも80MHzのクロックで問題なく動くように見えたのですが、いざDoomを動かしてみると両方へのアクセスが頻繁に発生するためか、動作が不安定になり、hardfaultが頻発。160MHz/3 = 53.33MHzに落としたところ安定して動いているようです。PSRAMの方は 80MHzで問題なく動いています。
• 使用したQSPI Flash W25Q256JVはDTR (Double Transfer Rate)をサポートしているので、設定を試したみたのですが動作を確認できませんでした。DelayBlockを使ってやれば、うまくタイミングを調整できるのかもしれませんが、80MHzでの動作が不安なこともあり、あまり期待できないように思われます。

今後は、BTStackを動かしてPS4/PS5のコントローラをつなげる計画なのですが、現在残りメモリが少なくなっており、使用メモリを削減しないと苦しくなりそうです。。

1/17 追記

80MHzで動いていたPSRAMですが、ソフトを作り進めるうちにPSRAM上においた効果音データをDACで再生しようとするとノイズばかりになるようになってしまいました。Flashと同じ53MHzにクロックを落としたところ、問題解消。

Nucleo-U575ZI-Q用基板を作成した

Nucleo-U575ZU-Qを使用したDoomPlayerを開発すべく、プリント基板を作成しました。プリント基板を作成するのは、何年ぶりでしょうか。

使用する部品数が少ないので、スカスカの基板です。手半田づけ作業も短時間で終了。基板右側の上下に欠けがありますが、これはNucleoボードと重ねた時に、リセットとユーザーボタンが覗くようようにするためです。

主要パーツは、 

• 左上には、オーデイオジャック。ハードウェアを極力簡素化したかったので、オーディオ出力にはCODECを使わずに、STM32U575のDAC出力を使うことにしました。音源は16ビットあるのに対し、DACは12bit出力までしかサポートできませんが、そこは諦めます。DACのバッファー機能を使えば、充分な音量でイヤフォンを鳴らせます。ジャックの周辺のCRはDAC出力後のLPFになっています。
• 左中央にあるのは、BluetoothのUART HCIモジュールであるBT860. Nucleo-U575ZIがUSB ホスト機能をサポートしていないので、UARTモジュールを使うことにしました。小さく基板の上に載せられるのも好都合です。
• 中央上側のチップは、W25Q256JV. 256MbitのQSPI NOR Flashです。
• 中央下側のチップは、APS6404L-3SQR. 64MbitのQSPI PSRAMです。
• 右側、縦向きのコネクタは、LCD基板を接続するためのもの。今回はFSMCを使って16ビットパラレルでつなぐことにしました。

基板右側には、バックアップ用電池とLEDを実装できるようにしてありますが、今のところは未実装のままで作業を進めることにします。

3.5インチのLCDを載せたてみた様子です。使用するのはいつものER-TFTM035-6. しばらく前にIPS液晶を使用したバージョンのボードが発売されたのですが、手持ちで未使用のものが眠っていたので、これを使っています。

LCDボードの裏側にはSDカードスロットやFlashのパターンも用意されているのですが、これらは全て同一のSPIバスを使っており、4ビット幅をサポートしていないので、残念ながら使えません。

Nucleo-U575ZI-Q

久しぶりに新しいNucleoボードを購入しました。表題のとおり Nucleo-U575ZI-Qです。以前のNucleoボードはブリスターパックでしたが、見てのとおり紙箱に変わっています。これも時代の流れですね。正面からはどのMCUを使ったボードが入っているのかわかりません。箱の裏側に貼ってある製品ラベルを見ないと判別できなくなりました。以前はのブリスターパックは、吊るしもできて売る側には好都合でしたが、この紙箱は商品陳列には不向きですねぇ。

USBコネクタがType-Cになりましたが、USB-PDの関係もあってか、デバイス側しかサポートできないハードウェアになっています。

当初はSTM32H5のNucleoを買おうと思っていたのですが、使わないEtherは邪魔なだけだし、OCTOSPIがひとつしかないことがわかったので、STM32U5に方針変更。STM32H7A3では、Quad SPIでPSRAMを使おうとして、シリコンバグの罠にハマりました。STM32U5では問題なくQaud SPIのPSRAMの読み書きができそうなので、Quad SPIのフラッシュとPSRAMの両方を使うことに再挑戦してDoomを動かしてみるつもりです。

AVRCP Cover Art -- その２

AVRCP Cover Artは、200x200画素のJPEG データとして送られるという仕様になっています。STM32H7B3I-DKでは、LCDの画面サイズが480x272ですので、JPEG展開してそのまま表示してやるのにはピッタシの画面サイズになっています。また、MCUがJPEGデコーダをハードウェアとしてサポートしているので、展開も簡単に行うことができます。

そんなわけでLVGLを使って簡単なプレーヤ画面を作成して、アルバム画像を表示してみました。音楽のアプリとしてはAndroid携帯で Sportifyの無料バージョンを使ってみました。ところが、曲名やアーティスト名は正しく表示できるのですが、アルバム画像が１曲遅れて表示されてしまいます。

Bluetoothで接続後、最初の１曲目は正しくタイトルと画像が表示されているのですが、２曲目ではタイトルとアーティスト名は正しく表示されるものの、画像が変化せず。３曲目以降では１つ前の曲の画像が表示されてしまうのです。

Spotifyアプリの問題だろうと思い、Pulsar というアプリも試してみたのですが、同じ症状でした。使用端末の問題かとも考えたのですが、検索してみたところspotifyのコミュニティで同じ問題が報告されていることがわかり、どうやらアプリ側の問題のようです。アプリの問題であれば、Google純正であれば間違いがないのではと考えが至ったところでで、「そういえば、YouTube Music というサービスがあったなぁ」と思い出し、試してみました。

やっぱりGoogle純正アプリだけのことはあって、ちゃんと正しいアルバム画像が表示されます。しかし、無料サービスではバックグラウンド再生ができないというのが、致命的でとてもスマホで使う気になれませんね。

なお、曲名とアーティスト名の表示には、Zen Maru Gothic を使っています。

AVRCP Cover Art

LVGLでTrueTypeフォントを使って容易に漢字表示もできることが確認できたので、これを使ってBluetooth経由での音楽プレーヤを作ろうかと思っていたところ、BlueKitchenのブログでまさしくやろうと思ったことが紹介されていました。おまけに、カバーアートの画像表示まで実現されています。

最近のスマホはAVRCP 1.6に対応しており、最新のBTstackを使えば画像データのダウンロードも可能とのこと。動画で使われているのは、Pico wを搭載しているCosmic UncornというRGB LEDボードです。Pico wでは今年の6月に更新されたSDKでBluetooth対応が追加されていますが、ここで採用されているBluetoothスタックはBTstackに他なりません。

Pico wは元々Wifi/BTのモジュールと3本の線だけで通信しており、WiFi機能の通信も通信方向を切り替える半２重通信となっています。BTのサポートを追加するための信号が別途用意されているわけでもないので、どうやってサポートするのかと思っていましたが、ファームウェアが頑張って、WiFiとBluetoothの両方の通信を同じ信号線を使ってやりとりしているようです。まぁ、Pico w のようなボードでは実用上WiFiとBluetoothの両方を使った高速通信が求められることもないでしょうから、こういった思い切った割り切りでも良いのでしょう。ただし、通信のリアルタイム性が求められるBluetoothのSCOチャネルをサポートするのは流石に無理なので、Pico wでもHFPを使って電話の通話をすることはできません。

Pico wでは日本語のTTFフォントまで載せてLCD表示させるのは苦しいので、DoomPlayerで使ったSTM32H7B3I-DKにUSBドングルをつなげて実現する方向で作業中です。