いろいろ試す66

先月修正して公開したコードに細かい修正ずっと加えてたら
あっという間に1か月過ぎてしまいました…


●Picoscope7のソフトアップデート！ようやく安定
…か？

7になってからあちこちが不安定になって使いづらくなってしまった
Picoscopeのソフトですが7.1.50にバージョンアップしております。
バージョンアップのたびに修正項目に"improvements to stability"
の文字列が出てきますが一抹の不安を胸にインストールしました・・。


orz
固まった…
マウスのホイールで時間軸カチャカチャ変えてただけなのに…
ねむいさんはよくいらん事してシステムとかプログラムとか人間を
機能不全にさせてしまう能力があるようです。
でもそれがバグ出しの役に立ちません。いらん事してるからね。

で、無駄だとは思ったけどPicoscopeに英文で発生条件の詳細を
添えてバグレポート提出してみたのですが、意外にも向こうでも
再現確認取れたようで対策も2点教えてくれました。
対策1. 'File' menu ->
　　'Startup settings' ->
　　'Load factory default settings'を実行

➡全然ダメ

対策2.C:¥Users¥%USERNAME%¥AppData¥Local¥Pico Technology
　の中にあるファイル全部削除
　
➡完全とはいきませんがなんでか不具合の発生確率がだいぶ
　下がりました…もうこれでいいや…
　
てわけで会社で使用しているPicoscpe7のソフトは次のバージョン
アップまでこれで乗り切ることにしました…次に期待…


どうでもいいですが便利なダウンロート直リンクがクリック
したら404にリダイレクトしやがるようになりましたファ〇ック!



●LAP-Cのソフトが神対応！有償のハードウエアトリガが無料に！！
かつて秋月電子でも販売され、改造もできたりして一世を風靡した
台湾製のLAP-Cというロジックアナライザがありました。

そして2025年になった今もソフトはアップデートされており、Win11にも
対応したV3.14.14が新たにリリースされたのですがななんと！
有償だったハードウエアトリガが無料解放となりました！！
ハードウエアトリガはプロトコルアナライザ機能のひとつで特定のデータ
でトリガをかけることができる超便利機能です！！

販売初期はプロトコルアナライザすらも有償だったのですがハードウエア
トリガが無料開放になったこれはまさに神ですね…！
ちなみにねむいさんこのロジアナ(LAP-C162000)を持ってるのですが
残念ながら私の頭が悪く正直ほとんど使いこなせていません。
Picoscopeのデータ解析機能でほとんど用が足りちゃうから…

でも持ち腐れてるのもよくないので使用記は一つ書いてみたいです。


●TEAMGroupのS.M.A.R.T.が見れるMicroSDカード



S.M.A.R.T.(以下SMART)が見られる非産業用MicroSD第二弾です。

最近のUHS-1では当たり前になった100MByte/Sec越えの転送と
寿命がわかるSMART機能を搭載したカードです。
最近は2TByteモデルも追加されています。

ねむいさんも256GByteモデルのTTCS256GIA2V3003購入してとりあえず
メーカーが提供しているWindowsの寿命判定ツールとやらで寿命を見て
みようとしましたが…


死ーん…
寿命判定用のツールがなんだかちょっと作りが悪いです。
ねむいさんの環境ではUSB接続のHDDを複数つないでいるですが
その状態だとツールからドライブは認識してるのになんでか
SMARTのデータが捕れません。エラーも出ません。


ほかのUSBドライブを全部外してこのMicroSDつないだUSBカード
リーダーだけにしたら認識して寿命が出てきました。

ねむいさんの興味はマイコンからCMD56発行してSMARTのデータを
引っ張ってこれるかどうかなのです。
Teamにストレート問合せしたら最速でストレートに意思の疎通を
断られたのでねむいさん独自に調べた情報を当ぶろぐ上にて全公開
させていただきます！！！！

結論から言うとCMD56の手順はDELKINとまったく同じとなります。
以下の手順でSMART情報を得ます。
1.まずCMD56コマンドの引数に0x00000010を取り、
　512バイトのデータ(ゼロフィルでよい)を書き込みます。
2.その後CMD56コマンドの引数に0x00000021を取り、
　512バイトのSMARTデータを読み出します。

CMD56のデータのとり方としてはいわゆるDELKIN系で、
書き込み(プリロード)->読み出しの二段階アクセスが必要な
タイプとなります。

取得したSMARTの生データをこちらに置いておきます。

生のSMARTデータが得られたのは良いのですが寿命を示すデータの
オフセットはどこなのか！？今度はそれを調べることになります。

Windows上のツールからSMARTデータを引っ張ってくる仕組みが
わかればSMARTデータのハイジャックも可能かもしれないので
まずはWindows上のツールからどういうデータのやり取りしてるか
調べてみました。

ひとまずWireSharkでUSBバルク転送のデータのやり取り調べたら
大体何やってるかが分かりました。
このWindowsツールではTranscendみたいにCMD56パススルーする
特殊な方法は使っていません。ていうかできません。
実際やっていたのDELKINのものと同じく特定のアドレスに特定の
順番で読み書きしてSMARTデータを得る"開けゴマ"方式のやつです。

ねむいさんが買った256GBの奴は実際の流れはこんな感じでした。
1 ReadCapacity
2 ReadCapacity
3 ReadCapacity
4 READ LBA:0x00000100 0データ
5 READ LBA:0x00001000 0データ
6 READ LBA:0x00000300 0データ
7 READ LBA:0x00000800 0データ
8 READ LBA:0x00000500 0データ
9 READ LBA:0x00000600 0データ
10 READ LBA:0x00005380 0データ
11 READ LBA:0x00007374 SMARTデータ(モロ)
12 ReadCapacity ☜ここで通常モードに戻ってる

最後らへんのLBA:0x00007374にアクセスしたときに何の暗号化も
していないCMD56の時と全く同じSMARTの生データを得ています。
DELKINはこの辺しっかりしていてデータに何らかの暗号化をしている
らしく、読み出しだけじゃなく書き込みも交えており2025年の今も
何やってるか不明です(代わりにCMD56があるので問題ないですが)。

さて生データのやり取りしてるのならSMARTデータのハイジャックも
簡単です。STM32F7のUSB-MSCプログラムを引っ張り出してきてツールが
LBA:0x00007374を読みだそうとしたらこちらが用意した偽SMARTデータを
お出しするプログラムを仕込めばよいわけです。簡単ですね〜
そして寿命を示すアドレスオフセットも大体当たりつけておりまして
ツールは99を返しているので0x63って値がある192番目のをわざと値を
変えて試してみました…

はい勝利。偽SMARTデータは78にしましたがドンピシャですね。
あとはねむいさんのおもちゃです。

100%超える値ぶっこんで見たら100%上限にしてるみたいですね。

0にしたらこんなんになりました。

というわけでかなりガバガバだったおかげでこのカードでいろいろ遊べて
だいぶ溜飲が下がりましたのでだいぶ満足してしまいました。
でもSMART捕りたいだけなら安くて入手しやすいTranscendのやつ買えば
断然良いので無理してTeamのこのカード使う意味はないです。


ちなみに転送速度100MByte/Sec越えはDDR200の規格外規格の手順を使って
ない独自規格のようで、DDR200対応のカードリーダーでも100MByte越えは
できませんでした。Team製の専用カードリーダーが必要みたいです。
汎用性考えるとやっぱり無理して買う必要もないかなと思います。


●話は変わるが開発環境構築の記事更新の件どうなったの？
ギ ブ ア ッ プ
CodeLiteをGDBのGUIとしてなんとか使いこなそうとしましたがSIGINT発行による
HALTがどうしても出来ず、それ以前に安定してステップ実行することすらできず
諦めました…orz

しかし…
orzしたねむいさんの目と鼻の先には救済がありました。
マルチプラットフォームIDEのCode::Blocksです！！！！
最小構成のサイズは100MB以下と小さくGDBのGUIとして使うならこれで十分です。


runしてる最中にいつでもHALTがかかる！
IOVIEWも直感的で見やすい！なにより直接変更ができる！
GDB-Insightでできたこととほぼ同じ！

というわけでCodeBlocksに乗り換えてデバッグ環境を構築し、ねむいさんの
いつものではSTM32F4,STM32F7,STM32H7,STM32H5ですでにCodeBlocks環境に
乗り換えています！

Win10では安定してデバッグできるのが確認できたのでWin11環境へとアップ
デートして同じように動作確認が取れたら今度こそ開発環境の構築手順の
更新ができそうです…！！！

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(Byte)
*AACの場合(2Channel,16bit限定)
1024(sample)*2(channel)*2(Byte(16bit-PCM)) = 4096(Byte)

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


☝なんでかそこからさらに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にも実装しちゃってるんですけどね〜…うふふ♥
もちろん今回の修正を反映した上での実装です！！！


次回！こうご期待ッ！！

いろいろ試す65

●ブライアン・ウィルソン氏死去
ビーチボーイズの創成期のメンバーでロック・ポップスの巨匠、
ブライアン・ウィルソンさんが2025.06.11に亡くなりました…。

ねむいさんとビーチボーイズ&ブライアン・ウィルソンの出会いは
故郷の大学に進学して少したった頃の事です。
高校のころからビートルズのアルバムほぼ全部をソラで歌えるくらい
聞きこんでいた私は同年代に活躍した他の(洋楽の)アーティストも
聴いてみようといろんな人の意見や雑誌をみてビーチボーイズを
選んたのです…最初に買ったアルバムはキャピタルレコード時代の
AllSummerLongとToday!のリマスター版でした。
米ロック・ポップスの一つとして軽く聞き流すつもりでしたが…

そこからねむいさんがハマっていったのは言うまでもない展開です。
ヒットを飛ばした曲を作り続けたブライアン・ウィルソンの世界に
もうどっぷり頭の先まで漬かっていったわけです…！
気が付いたらSeaOfTunesとかのコレクターズCDとか買い漁ってて
就職活動の時も西新宿のレコード屋に必ず立ち寄ってから静岡に
帰ってました…!!

近畿圏で就職した後も2002年のブライアンの2回目の来日公演となる
PetsSoundsツアー、2005年のSmileツアー、2012年のビーチボーイズ
50周年記念来日コンサート、そして2016年のオリックス劇場で私が
最後に生で見たコンサートとブライアンの来日公演は私が彼を知る
前の初回の1999年の来日公演を除き、ぜーんぶ行ってました!

今も変わらずビーチボーイズ&ブライアン・ウィルソンの楽器を
聞きこんでいますがどんな曲でも聴くたびに新たな発見があるという
ことに驚かされます。

ブライアン作曲の曲の中で私が好きな曲、どれも全部好きなんですが
挙げるとしたら全部！になっちゃいますがあえて一つ上げるとしたら
やはりアルバムFriendsからの"Busy Doin' Nothin'"でしょうか…
1960年代末、熾烈なヒットチャート争いからすっかり脱落しちゃった
ビーチボーイズのいろんな意味で力が抜けた感じのアルバムですが
その中でも最もゆるい、日常生活を歌ったゆるい系の曲です。
何十年も私のお気に入りの曲です。

ブライアンの作ってきた曲はいろんな人にこれからも受け継がれて
これからも世界中でいろんな人たちにずっと聞かれていくことになるでしょう…

R.I.P.


●なひたふさんのMitouJTAGがFTDI系デバイスに対応してフリー版を！
なんと今年の春になひたふ師がMitouJTAGをFT2232D/FT2232Hとかの
MPSSEが使える奴に対応してなおかつフリーで使えるVerをリリース
してくれました！！！

良い時代になりました…もう必死の思いでUrJTAGビルドして無理して
使わなくてもバウンダリスキャンをヴィジュアル的にできるんですね
フリーで…！ヤッター！！！

しかし…


私、FPGA持ってない！！


そう、ねむいさんは2018年に正社員への転職した折に自分が今後精神力を
注ぐべきリソース対象としてARMマイコンを、とりわけSTM32へ選択と集中を
行っておりFPGAの評価基板とか一切合切を前の会社に捨てて寄贈して
しまっていたのでした！！！
(ちなみに逃れられず結局今の会社でもAlteraのFPGA使って開発やってます…)
だめだぁ…もうおしまいだぁ…

…でもあれだ、STM32F407が乗った改造紅牛基板にはOpenOCDのJTAGトランス
ポート経由で書き込んでるから何か見えるんじゃないか…

というわけで気を取りなおして試してみます。
その前にねむいさんが持っているのJTAGKey2 CompatibleなのでPIDとVIDを
すっぴんのFTDIのやつに戻さないといけません。

(まだ詳細は教えられませんが)コマンドラインでFT2232Hにつながる外付け
EEPROMを消去書き込みできるlibftdiのサポートツールを駆使してJTAGkey2
ではなくて普通のFT2232Hに見た目は戻します。

ちなみにねむいさんのJTAGKey2 Compatible Rev.5の回路は手動で出力バッファを
強制イネーブルにできるモード搭載なので回路多少合わなくても安心です。
TMS,TCK,TDI,TDOの信号線(もちろん電源系統も)さえつながればなんとかなる
そして…


☝JTAGKey2 CompatibleでSTM32F4とJTAGで通信する


144PinデバイスとしてSTM32F407が見えた！
やったぁあああああ！！！！
ちなみにSTM32系のMCUは御覧の通り二つ見えます。でかいほうがバウンダリ
スキャン用のIDだそうです。
フリー版ですが簡易ロジアナ機能も使えて入力の変化もよくわかります…！

いやもうめっちゃ満足しました。なひたふさんありがとうございます…！
JTAG本pdf版で買いました。通勤のお供にしてます。




さぁてOpenOCDとかUrJTAGとかFlashROMとかavrdude使いたいから
ドライバをlibusbに戻ｓ


●危険物取扱者乙種4類の免状を取得した
ま　さ　か　国立大で物理化学専攻だったねむいさんが乙四の試験に
落ちるわけないですよねえ特に物化・性消は100点取って当たり前
ですよねぇ〜〜〜

…

満点とって当たり前の物化で2問も不正解出して鬼門の法令はぎりぎり
じゃいっ！！

ちなみに法令の9割その他0.5割+0.5割くらいの時間配分で勉強しました
が法令マジで苦手です…とにもかくにも一発合格してよかったです。

勉強については年初から初めて通勤時間の往復2時間を利用して覚えて
いきました。ねむいさんAndroidのタブレット持ってるのでそれに要点を
まとめたPDFを入れてひたすら読み続けた感じです。
そのPDFですがかわっち様が公開しているまとめ教材を利用させていただきました
マジでありがとうございます…！

GNSSモジュールを試用する21 -SAM-M10Qが壊れた…!?と思ったら直せた(おまけあり)-

●突然の死…
さる4月上旬、ねむいさんは東海自然歩道復路攻略の第一歩を踏まんと
闘志に胸を燃やしておりました。

が、その数日前にublox製のSAM-M10Qを使用した自作のGNSSロガーの
ファームを差し替えてついでに動作チェックをしていたらなんと一切の
衛星を捕捉しなくなっていたことが発覚！！

いつもなら長くとも1分で捕捉してるはずなのに一晩中放置してもダメ!
次の日副業先(本業は二次裏メイド)近くの川べりの空が開けた土手で
昼休み一杯使って衛星を捕捉しようとしたけど全然ダメ！
その日の昼から帰宅する夕方までこれまた空が開けた会社の屋上に
放置したけど一切衛星が捕捉せずダメ！
結局山行の前日まで粘ったが何やってもダメ！

…というわけで2023年6月で現役を引退したGms-G9さんに急遽前線復帰
してもらって東海自然歩道・復路の第一歩を進むことになりました。
まさか12年前と同じGNSSモジュールで高尾山に向かうことになるとは…



その後、復路第一回も無事済んで時間も余裕ができたので衛星を
捕捉しなくなったSAM-M10Qモジュールを調べてみました。



ねむいさんが実際に使用しているのはublox社製SAM-M10QにLDOや
その他周辺回路を搭載して電源とUART(TTL)を引き出して気軽に
使用できるようにしたMATEKSYS社のモジュールです。


んでもって今回の調査にあたりMATEKSYS社のSAM-M10Qモジュールの
回路を解析して回路図起こしてみました。また、このモジュールで使用
されているV_BCKP用の電池らしきものは電池ではなくSII製のスーパー
キャパシタXH414HGでした。こういうのたいていはリチウム二次電池
使っているのですが…エフェメリスデータ保持する3~4時間程度くらい
持てばよかろうという設計なのでしょう。

一つ上の写真にもあるように私は基板上に乗った5V->3.3VのLDOを
無視して直接3.3V投入する使い方をして約2年ほど使用しておりました。
結構乱暴ですがSAM-M10QのVDD/VIO/V_BCKPの定格は3.6VMAXなので
まぁ直接の問題はないでしょう。XH414HGの内部抵抗も100ohmもあるので
電源投入時の電流もそこまで大したことはないと思います。


これはSAM-M10Qに3.3V印可して起動直後のNMEAのログのスクショです。
この中で、
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,1*33
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,2*30
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,3*31
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,4*36
$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99,5*37
っていうのが見えると思うんですが本来は衛星を捕捉すると
ここの文字列ががどんどん変わっていくのですが開けた場所に
何時間置いててもずーっとこのまんまでした…。


V_BCKP用のスーパーキャパシタがおかしいのかなぁと思ってたの
ですがテスタで測る分には大本の+3.3V印可5分後くらいには充電も
フルに完了してるようで電圧も3.0Vは保持している感じでしたが…
SAM-M10QのV_BCKPは1.65Vが内容保持の保証下限となっています。
それ以下になったらどうなるかはデータシートやリファレンス
マニュアルからは(ねむいさんのおつむでは)読み取れませんでした。

ubloxのフォーラムとかもくまなく調べてみたのですが突然衛星を
捕捉しなくなった系の質問はいくつか引っかかったのですが有力な
回答はなし…いくつか指摘されていたのはRF回路部に静電気がかかり
破壊されたのではという見解でした。
まぁ確かにコアは生きてるのはSAM-M10Qから吐き出されえるUARTの
出力から分かりますのでSAM-M10Q内のRF回路が静電気でやられた
のかな…と思っていました。ねむいさん素手でほぼ触ってなくて
しかも使用時は対電防止エアキャップに包んで使用してたのに〜…

話はそれますがフォーラム見てるとublox製のGNSSモジュールでも
中華製ぱちもんが猛威を振るっててM10より前の世代あたり特にNEO-6とか
AmazonやAliexpressで異様に安い値段で買えるのは99%ぱちもん
のようです…う〜〜む

で、結局数日にわたり衛星の捕捉を試みたのですが一切衛星を捕捉
しないのは変わらなかったのでAliexpressのMATEKSYS公式ショップから
同じ製品を再購入しました…。

そして動かなくなったのは静電気で潰しちゃったからもう捨てるしか
ないのですがその前に分解してやろうと画策してまずは基板上の
スーパーキャパシタを取っ払ったのですが、この時に(そういえば
ネット上の記事でもubloxのGNSSモジュールを長期間使ってる人で
バックアップ用二次電池交換してる人多かったな…)と思い返し、
ダメ元でこのまま動かしてみようと電源投入して定位置のベランダに
適当に放置したら…2分もかからず


衛星を補足するようになった


????



ちなみにデータシート/マニュアルの指示ではV_BCKPを使用しない
場合はOpenにすべしと書いてありました。M10ではここOpenとなって
ますが過去のubloxのモジュールだとGNDに落とせって書いてあったり
VCCに吊れって書いてあったりまちまちなのでしっかりデータシートを
読み込んで誤った回路を組まないようにしましょう…
とにかく、SAM-M10QではV_BCKP未使用時はOpenです！


そんなわけで指示通りV_BCKP関連の回路を全部取っ払ってみました。
V_BCKPの機能を一切使わないようにしました。
そして…


復ッ活ッ！！
ベランダからかつV_BCKP機能殺してるので常にColdStartなので
70秒ほどかかっていますが完全復活です！！！！！

う〜〜む…つまりSAM-M10Qは電気的に破損はしてなくてV_BCKP用の
スーパーキャパシタが2023年~2025年の春まで使ってきてへたって
きたせいでV_BCKPへの電圧の維持が適切にできなくなってしまい、
保証下限の1.65Vを微妙に下回った変な電圧の時にVDD/VIOが投入
されたらRF部が全く機能しなくなる"地蔵モード"に転んじゃった…
ということなのでしょうか…

スーパーキャパシタ取り除く前にオシロで電源投入時の過渡応答を
せめて記録しとくべきだったか…反省･･･!!

ねむいさんもublox教団に入信してまだ2年弱のひよっこなので
ublox製品を長年ビシバシ使い倒している猛者の方々の意見を広く
拝聴したく思います…！！！




(おいおい天下の阪大でもこんなくそみたいな輩が跋扈してるのか…)

というわけでSAM-M10Qが復活したっぽいので今度はフィールドで
実際に稼働試験してみました…場所は大阪大学豊中キャンパスです。
ちょっと野暮用があったので阪大に来たのですがその用事済ませ、
ついでにV_BCKP無しの常時コールドスタートのパフォーマンスを
見てみます。


テスト地点は教養学部棟のこの広場にしました。


使う機材はAndroidタブレットAlldocubeとSTM32Primer2を使った
GNSSロガーです。今回はロガーをUSB-CDCモードでAndroidタブレットと
接続しUSB-Serial変換として使います。

Android側アプリは2023年のときと同じくGPSConnectorを使います。

衛星をFIXするまでの時間はガラホのストップウオッチで測りました。


まずはAndroidタブレット内蔵のGNSSモジュール。
捕捉時間は5回平均で70秒ほどでした。
ていうかなんでか私のAndroidパッドでは運用停止してもう電波が出て
ないはずの初号機(PRN193)が見えてるんですが…


んでもってお次はSAM-M10Qモジュールです…
捕捉時間は平均45秒とコールドスタートながらもかなりの健闘です。

私の使い方、登山/自然歩道攻略で使うならこのV_BCKPをOpen状態
で運用しても必要十分ですね･･･

そんなわけでSAM-M10Qが壊れたと思ったら意外な方法で復活(でいいのか?)
できましたが私の過去の記事をもとにMATEKSYSの同じモジュールを
買った人もタフな使い方してるとスーパーキャパシタがへたってくる
頃合いだとおもいます。
ある日突然衛星が捕捉しなくなった！と気づいた方はモジュールを
捨てる前にスーパーキャパシタを新品と交換するか、V_BCKPの周辺
回路を取り除いてOpenで運用されることをお勧めします!


上記の試験も全部終わって大阪大学から阪急で西院に帰る前に駅前の
インドカレー店で腹ごしらえです…！ぁー食った食った…🍛

●おまけ・十数年越しにSTM32F1のUSBライブラリの
　致命的バグの原因判明、そして解消へ
☝で使用しているSTM32Primer2を使ったGNSSロガーのファームウエア
ですが、マスストレージモードでPCに認識する段階で突然プログラムが
デッドロック、ウオッチドッグリセットが発動してしまう"ことがある"
という結構最悪な不具合が10数年存在しておりました…
こちらも今回の検証の折にソースコード見直しで発覚し、対策しました。

不具合の個所はSTM32F1向けの旧USBライブラリのusb_int.c内のCTR_HP()
という関数です。これはUSB_HP_CAN1_TX_IRQHandlerのコールバック
として設定されています。
ねむいさんのGNSSロガーではマスストレージではダブルバッファを
使用していますが、STM32F1ではダブルバッファを使用する際は優先度の
高いUSB割り込みを同時に有効して対応するようリファレンスマニュアル
に記述があります。この時にUSB_HP_CAN1_TX_IRQHandlerを有効にして
CTR_HP()が呼び出されるようにします。

そのCTR_HP()内でねむいさんは見ちゃいけないものを見てしまった。
なんと割り込みルーチン内でwhileループ、そして存在しない関数
ポインタを選択し実行してしまう可能性があるコード…

このCTR_HP()にはEP0のコントロールパイプの割り込みも普通に
飛び込んできやがるのですが旧USBライブラリではそれが考慮されて
おらず、EP0の割り込みが来てしまった際に実態が存在しない関数
ポインタを実行してしまうためプログラムが暴走してしまうことと
なります。HardFaultになるのではなく暴走です。

やっとからくりが判明したので後はそれを修正するだけです。
CTR_HP()にEP0の割り込み要因が飛び込んできても無視してEP0は優先度の
低い割込みUSB_LP_CAN1_RX0_IRQHandlerで処理してもらうことに
すればOKです。どう修正したかはこちらを参照してください。

何はともあれ10年来の不具合にケリがついたのでだいぶ溜飲が下がり
ました…！

そんでもってダブルバッファが中途半端だったマスストレージモード
でIN/OUTとも両方ともダブルバッファ化することに成功しました！！
STM32のフォーラムいくら探しても見つかりませんでしたがその前身の
STR7のUSBライブラリにそのものずばりの実装が発見されました。

この作例を参考に実装してさらにシングルブロック転送しかでき
なかったのをマルチブロック転送化して実装した結果がこちら↓

相変わらず書き込みがだめだめですが過去のものと比べるとかなり
改善できてきたかと思います。読み込みについては0.8MByte/Secと
フルスピードでできる限界に近づいてきましたのでこれで良しと
します。


なお、SDカードのクロックは24MHz(DefaultSpeedモード)で動かして
てますがHighSpeedモードだともうちょっと速度上がるんじゃないかと
お思いの方がいるでしょうがSTM32F1のHSモードの上限はエラッタの
都合上36MHzまでしか上げることができず、ごらんのとおり屁のつっぱり
にしかなりません。しかも不安定になるので安定性を考えると24MHzの
ままのほうがよいですね。



SDカードじゃなくてeMMCだとちまちま書き込みがかなり改善されます。
F1でも安定してeMMCが動作する。さすが私。


…そんなわけでSTM32Primer2を使い続けて15年以上が経過しましたが
これからもFatFsのSTM32F1の実装例として、GNSSロガーとして末永く
使っていこうと思います！

東海自然歩道・復路を征く1(高尾山口-西野々)

とうとう始まってしまいました…

今をさかのぼること１２年前、自作GPSロガー(現在はGNSSロガーに強化)
の動作検証の目的で開始した東海自然歩道という無謀な挑戦を
知恵と無知と勢いで大阪から東京まで1700�匐遒曳瓦韻泙靴燭�…、

12年の時を超えて期は熟したので再びちゃれんぢすることとなりました…！
このぶろぐ記事が日本でも数少ない東海自然歩道の往復路攻略者の復路の
攻略の第一歩となります…！

今度は東京から大阪までがんばるぞい！

今回の記事は12年前の記事と見比べるとわかりやすくて面白いと思います。

●2025.04.05 東海自然歩道(高尾山口➡西野々(➡三ヶ木))


虹裏メイドの朝は早い…
前日に京都からわざわざ大阪に降りて夜行高速バスで新宿の
バスターミナル"バスタ"へ…
12年前はこんな便利なのなかったなぁ…(しみじみ)
そしてさすが首都圏ですね・・新宿駅がデカすぎる…


運よく高速バスが早く新宿についたので身支度もゆっくりできる
…と思ったらなんと駅周辺のコンビニが閉まってる！！

やっぱ都会ば恐ろしかところばい！！


新宿ダンジョン…大昔に就職活動の帰りに西新宿のレコート屋で
BeachBoysのコレクターCD買いあさってたっけ…


何とか空いてるコンビニ見つけて朝飯も大量に買ったので
京王線で高尾山口駅に向かいます。VISAタッチ決済使えて便利ですね。
車内は朝から登山目的の人が多いかったです。


高尾山口駅に到着です…
12年前に実際にこの場所に来てるはずですがなんか実感がわきません・・



それもそのはず、高尾山口駅は12年前と比べて大幅に変わっていました…
登山ブーム効果なんでしょうか…
この時間帯でも登山客がたくさんいますね…

ところで目の前のSTM32Primer2のGNSSロガーですがなんと前日に
SAM-M10Qモジュールがまったく捕捉しなくなってしまい急遽代役の
Gms-G9モジュールを引っ張り出して稼働と相成りました。
Gms-G9はかつて2013年から東海自然歩道を往路終盤の高尾山口駅まで
駆け抜けてさらに2023年6月まで10年以上活躍してきた歴戦のモジュールです。

Gms-G9は退役したはずですが今回の復路の第一回目に急遽現役復帰して
東海自然歩道復路で参戦となるとは宿命を感じます…
12年の時を超えて同じ場所に戻ってきたことになりますね。

また、今は亡きCanmore社のGP-102+もバックアップ用として使用します。

注:20250405当時はSAM-M10Qが死んだと思っていたのですが実は死んで
ませんでした…これは来月のぶろぐ記事で詳細を書きます。




話が長くなりましたがすっかり様変わりした高尾山口駅から
東海自然歩道の復路の第一歩を進めました…！

ここから大阪を目指した人間は日本で何人いるのだろう？
私もまた、その一人に…



進んですぐに東海自然歩道の東の起点が出てきます。
これは近年設置された起点となります…。本物はもっと
奥にあるのですが…とりあえず証拠のSTM32Primer2GNSSTr@ckerを
おいてみる…

これで大阪と東京に東海自然歩道の起点がそれぞれ2つ、合計４つも
存在することになってしまいクソ間際らしいですね…



12年前はあっさり駆け抜けてスルーしてしまったケーブル高尾山駅です。
ちょうど桜は見頃。


高尾山は人がいっぱいいるのでトレラン野郎には厳しいぞ！
これは12年前と変わらず。


そしてここに12年ぶりにやってきた…！
あの時私はこのゴールは新しいスタートと言いました…！
今このゴールから新しいスタートを開始します…！
日本でも数少ない東海自然歩道往復路のチャレンジャーとして！！



その前に記念にGNSSロガー置いときます。


12年前と同じ構図じゃいっッツ！！


時間が押してるのでさっさと先に進みます。
東海自然歩道は高尾山登山道1号路を上ります。

手前のおばあさんとんでもないペースでめっちゃ早いんですが…
…ていうか私が足が遅くなってるのか…



はぁはぁ…いきなり足がパンパンになってやっとこ平坦部につきました…
ここからケーブルで登ってきた観光客と合流してにぎやかになります。


ひっぱり蛸回収です。



高尾山頂上手前は高尾山の寺領となり寺院がたくさんあります。



ぁーここは覚えてるわ…！！何もかも懐かしい…


12年前に購入した健脚守りも新しく買い換えました!
運気も万端！



うぉー懐かしい…
以前は冬でしたが今回は春。桜が見事です。



奥の院と浅間神社です。



あっさり高尾山頂に到着です…！！
土日は人でごった返し超満員らしいですがこの時間はまだ
それほど混雑していませんでした。


とりあえず三角点にロガーをおいて12年前のネタ回収です…！




そして…なんとうれしいアクシデントが…！
12年前は暴風雪で見るのが叶わなかった高尾山からの富士山が
今回はばっちり見えています…♥
来てよかった…！


最初のピーク高尾山頂をクリアしてどんどん進んでいきます！



もみじ平より桜富士です。富士山はいつ見ても見飽きません。



一丁平から見る富士山が今回の山行の最後の全体図となりました。



小仏城山山頂に到着です。あれ…天狗の頭があったはずですが…


かつては猫さんがいましたが今は犬が大量にいます。


天狗の頭は南方向に移動して健在でした。


この茶屋も健在でした…今回はばりばり営業中です。



そして東海自然歩道は東京都を離れてすでに神奈川県の領域に入っています。


神奈川の東海自然歩道は道標がしっかりしていますが道は危険かつ極めて
苛酷です！！ここから先は心してかかります!!


いきなりやばい角度の下り坂…
12年前は暴風雪食らいながらここ上ってたっけ



ひたすら下って千木良の東海自然トイレです。
あの時は気づかなかったですが…
離れてみると見事な桜が…！


12年前と同じ構図で甲州街道をクリアーです！！


弁天橋が見えてきました。



弁天橋の手間はかつてはにわとりが住んでいましたが…
今は…ねこさんの楽園になっていました。


ﾓﾌｵﾌﾓﾌﾓﾌ


ネコニウムを十分摂取して次のステージに向かいます。


弁天橋を渡ります。


嵐山への登りです・・
がぁああ…こんなきつかったっけ…！？



はぁはぁ・・かなり消耗して嵐山です・・


なんと12年前になった鳥居がなくなっていた！！


嵐山から降りて相模湖リゾートプレジャーフォレストの横を通ります。


鼠坂(ねんさか)チェックしていきます。


なんと野生の雉を発見しました…！


お次は石老山に向かいます。



石老山への登山口です…ここも見事な桜ですね。


その手前の病院に自販機とベンチがあったので
ここで大休憩としました。


石老山登山口がある顕鏡寺への参道を登ります。



さて顕鏡寺につきましたが…2019年の土石流でこのルートが破壊されてしまい、
長らくの間通行不能になっていましたが12年前と同じルートは破壊されて
なくなってしまったようですね…ていうかお地蔵さんの首がもげてる…


今は通行可能になった迂回ルートを通る…
12年前見た大木がぶっ倒れています…
このあたり地形がだいぶ変わっちゃってます。



今は桜の季節なので復路ではさくら展望コースで進みました。
山桜が見事ですね〜


融合平展望台です。



登りがだいぶきつくなってきてますが何とか石老山です。
富士山も下のふもとだけですが一部だけ見えました…！


ここもクマ出るようになったのですね…



篠原集落に降りてきました…
バスがなくなったので道標が一部隠されていますね
そしてここも桜が見事です。


篠篠原原のみ里里？？？


LOVEROAD



カメラを構えてる人がやたらいると思ったらギフチョウ狙いの
人だったようです…ねむいさんは満開の桜を収めました…！


そして今回最後のピーク石砂山に挑みます！！


がぁああああ…！！
足がもううごけへん・・・


がぁあぁぁぁぁぁあああぁぁ…！
今度は両脚攣った…！！



早くも人間を捨てて四足獣歩行体制で進んで石砂山頂上です…
両足ぷるぷる言ってて下りで突っ張り効くだろうか…


ぇえええナニコレ…
12年前こんなヤバイところ進んだっけ・・？

(…記録見返すと12年前のねむいさんは悪天候下であっさりクリアしてました)



伏馬田分岐です…
ここまで来たら大丈夫…


忘れてた…まだヤバイゾーンあった…！！


庚申塔のところまで来ました…今度こそ大丈夫…


石畳を降りてアスファルトの安全地帯に到着です…
ここから先はすべて舗装路…！


バカンス村も健在でした！！


見事な桜を見ながら通志川を通過します。


この看板も12年ぶりです…よく生きのこっていた…！


あとは舗装路なのでお気楽です♨



ゴールの西野々バス停に到着です…が…
現在時刻15:02…
…
走って三ヶ木営業所まで行くか！！(12年ぶり)


ちなみにこちらが次回のエントリポイントとなります…！
次回は東海自然歩道最大の難所です…



旧通志道を通ります。




お次は現行の通志道に移ってひたすら三ヶ木に向かって走ります。
道中でみられる桜が見事で飽きません。



見覚えがある長い坂を上りきって道志道の終点まで来ました！


かえりはたぶんお土産買う余裕がないので地元のスーパーに寄り道して
地元のお土産をゲッツしておきました！！



神奈川中央交通津久井営業所/三ヶ木バス停でゴールとしました…！
今回も長い一日でした。

ていうか12年前は神奈川中サービスセンターって名前でしたが…???


あとはバスに揺られてJR橋本駅へ…
津久井ダムの桜もきれいですね〜


そしてJR新横浜駅で新幹線待ちでほっぽり出される…
家族の分のお土産買う余裕出来たのでシウマイ買いまくっておきました
もちろんねむいさん専用お土産も買っております！！


帰りはのぞみで京都まで…
寝落ちしたら博多まで連れていかれるので最後まで気が抜けません…！



というわけで東海自然歩道・復路の攻略の第一歩を終えました。
一度始めたからには大阪まで到達する覚悟で進めていきますが…
昔と違って今は近畿自然歩道、中国自然歩道、中部北陸自然歩道の
多方面作戦となっておりますので手持ちの資金と配当金と
相談しながらじっくり確実に進んでいこうと思います…！


●2025.04.05 東海自然歩道(高尾山口➡西野々(➡三ヶ木))　GNSSログ


神奈川ルートはほぼ全般的に山蛭天国なので次の超難関・丹沢山塊攻略は
11月ごろを予定しています。
その間に近畿自然歩道・中国自然歩道・中部北陸自然歩道の攻略を
進めていく感じで行こうとおもっています。

STM32H7を使ってみる8 〜SDカードの初期化で大バグを仕込み、しかも6年間放置してた件〜

←前回　　　　　　　　　　　　　　　　　　　　　　　次回→


北神雄太さんのZennの記事を読んでてねむいさんも少し気を付けようと
思いました。ソースコードの確認ミスや仕様の見落としで誤った結果を
世に出してしまわないようにと･･･。


…と気を引き締めた矢先、自身が公開しているソースコードに
とんでもない爆弾を発見してしまいましたorz


●罪状
➡STM32H7のFatFs移植例(SDMMCインターフェース)で、
　"CMD6発行によるHigh Speed Modeへの移行処理"を
　せずにSDカードのクロックを25->50MHzに上げていた。
　それをソースコード公開時から約6年間放置した上
　さらにSTM32L5,STM32H5に同じバグを拡大させた。


ねむいさんの公開しているSTM32H7(STM32H747I-Disco)向けのFatFs
実装例はSDMMCインターフェースを使ってSDカード/MMCとデータの
読み書きをするようにしております。

その初期化の部分でSDカードのクロックをデフォルトスピードの
25MHzから50MHzに引き上げる操作を行っているつもりでした。

本来はCMD6コマンドを発行し、SDカードがハイスピードモードに
切り替わったことを確認して初めて50MHzに引き上げることができるの
ですがその操作を行わないままいきなり50MHzにクロックを上げて
しまっておりましたorz


SDXCの初期化の例をとると本来の初期化は下記を想定してました。
CMD0発行、カードリセット
↓
CMD8発行、SDv2初期化
↓
CMD55+ACMD41をレスポンスが有効になるまで実行
↓
CMD2発行、CID取得
↓
CMD3発行、RCA取得
↓
CMD9発行、CSD取得
↓
CMD7発行、RCA設定
↓
CMD55+ACMD13発行、SCR取得
↓
CMD55+ACMD6発行、4bitバスモード移行
(ここで4bitバスアクセスに変更)
↓
CMD6発行、ハイスピードモード移行
(ここで供給クロックを50MHzに変更)
↓
CMD16発行、ブロックサイズを512バイトに設定
(ここで読み書きのための全部の準備が完了)
↓
以後CMD17/CMD18とかCMD24/CMD25でデータ読み書き

☝バグのコードでは上記のCMD55+ACMD6とCMD16の間でCMD6の発行を
せず、ACMD6発行後に4bitに切り替えと同時に50MHzにクロックを上げて
しまっていました。

なお、"SDカード"を使用した際のみこのバグが発動し、MMC/eMMCの
初期化の際はCMD6が正しい順序で発行したうえでクロック周波数を
引きあげていたので問題はありません。



●何が起こる？
➡読み書きの操作(CMD17/CMD18やCMD24/CMD25実行)
　を行った時に以後の応答を一切しなくなる可能性がある

"可能性がある"というのはすべてのSDカードで発生するのではなく、
ごく一部のカードで起こっているからです。
ていうか私の持ってるカードの中では1枚のカードだけが操作不能に
なることに気づきました…！


それがこのカード、TranscendのTS20GUSG240Iです…。
SLCモードを搭載し、230Iと比較し書き込み耐量がさらに上昇した
カードとなります。2024年の秋に購入していました。

最初にSTM32H5-Nucleoで使った際に"認識"できず、STM32H7-Discoで
使っても"認識"できなかったのでこのカードはハイスピードモードでは
使用できない"個体不良"なのだろうと思い込みソースコードレベルの
デバッグも行わないまま捨ておきましたが…

冒頭の北神さんの記事を読んでこのカードのことを思い返して
改めてソースコードレベルのデバッグにて初期化の流れを一から
追ったら自身の大チョンボを発見してしまった次第ですorz


ちなみに発覚前はCMD17/18とかCMD24/25の発行時に10uSecくらいの
待ち時間を突っ込むとなんでか読み書きできるのを発見したので
それで茶を濁しておりました…今思えばなんて愚かしいことを…

最初にSTM32H7を触ってSDMMCを使い始めた時にデバッガでソース
コードレベルでプログラムの流れ追っかけて確認するの面倒くさがって
やっておらず、当時の手持ちのカード全部認識できてるし"動いたから
これでよし"と思い込んだのがすべての原因です…すべては私の責…！！
ただねむいさんが悪い！ただねむいさんが悪い！



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

何でこうなったかというと最初にSTM32H7で作成したバグ入りのSDMMCの
アクセスライブラリをSTM32L5,STM32H5にスライド移植させてしまったが
ためにバグまで仲良くスライド移植してしまったからですorz

STM32F7のSDMMCについては正しい手順でCMD6を発行してハイスピード
モードに移行した上でクロックを上げているため問題はありません。

STM32F1,F4についてはSDIOにエラッタが存在し、ハイスピードモードの
速度でクロックが実質使用できないのでDefaultSpeed(25MHz)までとして
います。(実験的にハイスピードモードにできるようにはしています。)

LPC4088はMCIのクロック上限が25MHzまでなのでこれも問題はありません。

LPC4357についてはSDカードのクロック上限はソフトウエアで25MHzまでと
しているのでこちらも問題はありません(MMCv4は50MHz)。

その他、SPIモードで読み書きするものについても、そもそもSDの仕様上で
SPIモードではハイスピードモードは使用できないのでこちらも問題は
ありません。(※SPIモードでもハイスピードモードが存在する説があり)


●実際の被害は？
➡現状私一人だけが被弾している状態です。
私の知る限りでは他の方が私の作例を使用し、SDカードの
読み書きができないという報告や記事はありませんでした。

しかしSTM32H7/L5/H5の私の対策前の作例をもとにTS20GUSD240Iを
使うと、確実に被弾します。再現率100%です。


●対策は？
➡"CMD6発行によるHigh Speed Mode移行"を確認してから
　SDカードへのクロックを50MHzに上げるよう修正します。

本来ならばこの記事を書く前にいち早く修正コード上げるべきですが
検証に使用するカードの種類や対応マイコンの範囲が広いので時間かけて
慎重に再検討しております…。完了したら追記で連絡いたします。

20250328追:
STM32H7の作例で上記のバグを修正し、
全体的に動作を見直し大幅更新いたしました！
20250328追:

20250421追:
STM32L5の作例も修正して更新しました！
20250421追:



古のハイスピードモードが無いSDV1.01カードとか4bitモードが無い
MMCv3カードからはじめて最新のA2対応のSDXCとかeMMCに至るまで、
洗いざらい今一度！とにもかくにも全部動作確認！


STM32H7で問題ないことを確認したらSTM32L5(更新停止してますが
今回だけ)とSTM32H5にも今回の修正を反映します。

また、STM32F1,F4,F7,LPC4000系の実装例についてもSTM32H7の修正で
気づいた点についてはフィードバックして最新化させる予定です。

多分夏いっぱいくらいかかるかと思いますが焦らずに対処いたします。



●ところでTranscendのTS20GUSD240Iですが…

このカード、UHS-2ではないのですがなんでかSDR104の限界を超えて
100MB/sec超の読み書き性能を誇っております…

UHS-2には勝てないですがコストパフォーマンス考えたらすごいです。
おそらくこれは規格外規格のDDR200ってやつですね…
検証に使ったUGREENのUHS-2対応カードリーダー(CM265)も何気にDDR200に
対応してるのが分かったので掘り出し物だったのわかってラッキーです…♥


なお、今年初頭に紹介したUltraPerformanceのカードもぶっちふぎりの
性能見せてくれてます…
もうUHS-2じゃなくてもこれらでいいかも…！

Go to top of page