STM32H7を使ってみる9 〜I2Sの処理の所で大バグを仕込み、しかもSTM32F4の頃から通算で13年間くらい放置してた件〜

←前回


ねむいさんのぶろぐ史上最長のぶろぐタイトル！！！
…はどうでもいいです

前回、SDカードの初期化で大バグを仕込んで長期間放置してた
ことを発見してしまいましたが…
またまた超特大の致命的バグを発見してしまいましたorz



●罪状
➡ねむいさんのFatFsのSTM32H7向けの移植例において、
　MP3/AAC/WAVファイルのサウンド再生機能はSAIを
　I2Sとして使い、さらにサーキュラDMAモードで
　連続してデータを送信する仕組みで実現しているが、
　そのルーチンがめちゃくちゃ！

何がどうめちゃくちゃかというとCircularDMAの概念が全然理解
できてなくて適当にコード寄せ集ましたレベルのめっちゃくちゃ

なんでこれで音が出てたかって？
そんなのねむいさんが知りたい。




実例として、主にmp3_support.cを挙げてダメなところを解説
していきます。

ダメなところその��
割り込み後のDMAバッファの切り替えがなんか変なのだ…

メインルーチンでは主にMP3データの読み出し・デコード・
そしてDMAバッファにコピーする役目があります。

SAIのサーキュラDMAモードによりそれらを効率的に実行できる
ように実装し(たつもりでい)ました。I2SデータをDMAで転送
してる間にMP3データのデコードをやって準備しちゃおうと
いう思惑ですね。

DMAの初段キック後のサーキュラDMAのSAIの割り込みは先ず
"ハーフコンプリート"割り込みがかかります。
その割り込みルーチン内でハーフコンプリートのイベント
フラグを立て、mp3のメインルーチンへ戻ります。

本来ならばハーフコンプリートのイベントフラグを見てDMAが
送信用バッファの後ろ半分のデータ領域を転送中であることを
想定して、デコードされたmp3のデータの書き出しポインタを
送信用バッファの先頭に切り替える処理をを行うはずです。
しかし…


☝なんでやねん！
なんでこんなことやってたのか不明。後でも説明しますが、
キャッシュのクリーンもここでやるのは不適切です。
ポインタ付け替えた直後にクリーンしても後からデコード
後のデータがコピーされてキャッシュのダーティビットが立ち
無意味。フルコンプリート状態の時の処理も同じ感じに変ですorz

さらにAACやWAVにも同じ感じで横展開したのでほぼ同じ感じで
間違って変になっていましたorz


ダメなところその��
転送用DMAバッファの確保量が不適切。無駄に多すぎ。

HelixMP3/AACデコーダーのデコード後データのサイズは実質
固定となっており、一般的にはそれぞれ下記のようになります。
*MP3の場合
1152(sample)*2(channel)*2(Byte:16bit-PCM) = 4608(Bytes)
*AACの場合(2Channel,16bit限定)
1024(sample)*2(channel)*2(Byte:16bit-PCM) = 4096(Bytes)

つまりSAIのI2SモードのサーキュラDMA転送用バッファとしてそれぞれ
MP3: 4608 * 2 = 9216(Bytes)
AAC: 4096 * 2 = 8192(Bytes)
だけ、確保できていればよいことになりますが…


☝なんでかそこからさらに2倍確保していたorz
　なので関数初めのDMAバッファサイズのチェックも不必要に2倍


☝その原因はたぶんここ。
g_pMp3DmaBufferとg_pMp3DmaBufferPtrは16bit-PCMデータの格納を
想定しているのでint16_t*で宣言しています････。

はいもうおわかりですね。ポインタの基礎を理解していなかった！

int16_t*のポインタ変数の値を1増やしたらポインタが示すバイト
アドレスの値は当然2増えますが(arm-gccの場合)、ワードじゃなくて
バイト単位を想定して定義しているDMAバッファの値をint16_t*の
ポインタの計算に使ったら想定の2倍に増えるのあたりまえですね。

なんでこんな基本的なこと理解できてなかったんだ私は？？？


さらにAACのデコードに関してはHelixのcvsから取ってきたそのままの
状態でビルドしていて本来不要なマルチチャネルぶんまでメモリ確保
していたのでさらに3倍不要なRAM領域を…


そしてメモリ確保のために苦しみ紛れに屁をこいたような対策(?)で
お茶を濁してました…苦しみ紛れに屁こきすぎて屁こき虫状態。


本来必要なDMAバッファの量は最高でもMP3向けの9216Byteとなるので
STM32F407の作例でも本来は変な小細工しないで済んだわけです。

ちなみにSDIOとかSDMMCでDMA使ってSDカードからデータを読む回路
構成で、高いビットレートで再生してる時にエラーでこけるとか
過去に抜かしていましたが上記の必要メモリ容量の最適化で一切発生
しなくなりましたとさorz
たぶんDMAの干渉とか全然関係なくて転送バッファRAM確保のため
無駄にmallocした結果肝心のデコード時のmallocでRAMが枯渇して
しまってたせいだと思います。



●ところで実際何が起こるの？
➡MP3、AAC、WAVEファイルが再生中に突然中断する
　"ことがある"。
　もしくは再生すらできずいきなりファイラ画面に戻る
　"ことがある"。
　WAVEに至っては再生のたびに音の左右が入れ替わる、
　再生直後にﾌﾞﾋﾞﾁﾁとか水っぽいおならみたいな
　汚い雑音が入ることが"あったりします"。

再現率100%じゃなくて障害が起こる"ことがある"というのが問題で、
"これはそういう物なのだろう"と重要視せず見過ごしてしまったのが
すべての原因です…すべては私の責…！！

ただねむいさんが悪い！！ただねむいさんが悪い！！


●バグの影響範囲は？
➡ねむいさんのおきぱで紹介しているFatFsの移植例では
　STM32H7,STM32F7,STM32F4のものが対象。

MP3,AAC,WAVEの再生に関してはソースコードは分かれていますが
上述の通りコードの基本構造は同じにしていたため仲良く全滅orz

基板別としてはI2SのオーディオコーデックICを搭載した下記の
評価ボードがまんべんなく被弾。
NUCLEO向け作例はCodecICが乗ってないのでそもそもサウンド再生
機能を実装してなかったので免れています。
*STM32F4-Discovery
->CS43L22
*STM32F746-Discovery
->WM8994
*STM32F769I-Discovery
->WM8994
*STM32H747I-DISCO
->WM8994


また、放置していた期間としましては累計約13年間となります。
2012年11月末、STM32F4-Discovery向け(STM32F4はSAIじゃなくて
I2Sそのもの)として公開したのが最初です。
最初っからバグったコードを公開し約13年間位バグを放置してた
ことになりますorz

なお、AAC再生機能実装によってメモリ周りのバグをパワーアップ
させてしまったため、2015年からさらにバグが強化されましたorz

前回のSDカードの時より全体攻撃になってます。
しかもほとんどねむいさん自身が仕掛けた攻撃で自分自身に大ダメージ!
アリアハン脱出作戦大失敗！！


ただねむいさんが悪い！！ただねむいさんが悪い！！



●実際の被害は？
➡実質ねむいさんのみ。それもごく限定的。
STM32F4の頃から通算して13年間経過しているので被害がかなりの
範囲にわたっていると予想されますが、意外なことに他の方から
うまく再生できないという報告が1件しかなかったです。

その1件も内容をよく聞くとSDカードの動作の段階で躓いていたのが
原因(プルアップしてない)で、MP3の再生まで行きついてませんでした。

その時音源ももらったのですがねむいさんのSTM32F4-Discoveryの
構成では問題なく再生できてたので問題なしと判断しソースコードを
精査してなかったのでバグをつぶすチャンスを逃しましたorz

そしてエゴサーチした限りでは私の作例をもとに製作されてる方も
ちらほらみられましたが問題に気付かれてる方は見られず普通に
利用？できていたようです…

ねむいさんはともかく他の方の被害は表面上に出てきていなかった
と思われます。よかった〜…

…
なわけねぇだろ！こら！(ｺﾞ　ｯ)


●対策は？
➡主に下記4つとなります。
��STM32におけるSAI/I2Sの動作の基本から見直してサーキュラDMAを
正しく動作する合理的なコードに修正しました。

12年前最初に元にしたコードはmikrocontroller.netで公開されてた
STM32F4向けのHelixMp3decoderの実装なのですが…
なんでねむいさんがいじったらこんなに歪んでしまったのか…

�▲機璽�ュラDMAで使用するRAMの量を正しく見積もる
ことにより必要十分な量だけ使うように修正しました。

STM32F407向けの作例ではFatFsの送受信用汎用DMAバッファRAM
として16kByteを確保しています。
今回の修正でサウンド再生用のDMA転送で必要な最大量はMP3の
9216Byteとなるので16kByteあれば十分に余裕があります。

また、DMAの制約上STM32F4では4バイト、さらにSTM32F7&H7では
キャッシュ操作のため32バイト境界でバッファのアライメントを
揃えています。


��キャッシュのクリーンを適切な時点で実施するようにしました。

デコード済みのMP3のデータがDMAバッファの全体の半分ちょうど
コピーされた直後にその部分のクリーンを実施します。

STM32F4はキャッシュが無く、STM32F7はキャッシュコントロールが
不要なDTCM領域をDMAバッファとして使っているので実質H7専用の
操作となります。

ちなみにCortex-M7のキャッシュコントロールの前提条件でメモリ
アドレスのアライメントが32バイト境界にありさらに32の倍数で
転送を行う制限については各転送バッファサイズは…
MP3: 4608*2(32の倍数)
AAC: 4096*2(32の倍数)
WAV: 1024*2(32の倍数)
と綺麗に32の倍数になっているのでこちらも安心です！

�い修梁哨宗璽稿發埜�つけた意味不明な処理や記述を修正しました。

かつてSTM32F7-Discovery系ボードで再生したら2倍速の速さに
なってしまうとかいう変な不具合があってPLLの分周比を2倍にして
対処したことがあったのですが、単に私がSTM32F7のSAIの仕様と
CodecIC(WM8994)の仕様を理解してなかっただけでしたorz
そーいう細かいのも全部潰しておきました。


他にも音楽再生以外ではエラッタ対策の見落としや現在では誤った
概念に基づく記述やビルド時のワーニングを厳格化したことで表面化
したきたバグに繋がる変数の扱いのあいまいさ等、できる限りで修正
を掛けたのですがこれらの解説はより一般的な内容となりますので
後日"いろいろ試す"のトピックとしてぶろぐ記事を書くつもりです。


修正適用時期(いつまでに修正したソースを公開するか)ですが、
問題が起きた下記の品種
STM32H7
STM32F7
STM32F4
は2025年7月31日付ですべて修正完了しました！もう安心です！！
ついでにChaN師のFatFsがR0.16にバージョンアップしていたので
そちらも反映しております！

私の作例を利用して派生物を作られていた方は2025年7月31日以降の
日付の物に差し替えを早急にお願いいたします！！！


●ところでなんで13年間放ってたの今更気づいて直したの？
➡自分のやってきたこと振り返ってダメなの見つけたら
　改善しようぜ運動の一環です。
前回のSTM32H7のSDカードの記事と同じく過去にやってきたことを見直し、
新たな進歩につなげるために"分かったつもり"で逃げてたオーディオ処理の
ところも腰を据えて検討したのです…！

自身の詰めの甘い部分がいろいろ露呈して辛かったですが何とか
改善することができて苦労以上に得られるものがたくさんあったと
実感しております！！！！(ヤバイ思想に染まった目で)

あと情けないミス他人に指摘される前に今回も先んじて気づけて助かっ






さて！

SAI使ったI2Sも理解がだいぶ深まったので次の一歩を進めましょう！！
目標はSTM32H5のSAI使ってサウンド再生機能の搭載DA!


っていうか実はもうすでに市販のPCM5102Aモジュールで動作するように
H5にも実装しちゃってるんですけどね〜…うふふ♥
もちろん今回の修正を反映した上での実装です！！！


次回！こうご期待ッ！！

Go to top of page