マイコンでSDカード使うときは必ずプルアップしてね☆

なぜなら！
SDAの規格で！絶対に必要と！明記されてますから！！




SPI互換モードでは使用しないDAT1,DAT2も放置せず絶対に
プルアップしてください！これもちゃんと明記されています！!


ちなみに"SHALL"の解釈をめぐって英語教室繰り広げる奴対策の
ためにSDAは用意周到できっちりそういう連中の逃げ道塞いでいます…！
"SHALL"は欠くことができない絶対に必要な事柄と定義されています！

そんなわけでマイコンでSDカードを使う際はCLKを除くCMDとDAT0~3は
ネイティブモード・SPIモード関係なく必ず外付け抵抗で
プルアップしましょう〜！
マイコンの内蔵プルアップ機能でごまかすの絶対にダメですよぅ！
MMC/eMMCの場合はCMD&DAT0~7ね

過去の記事になりますがSTM32F4でSDカードを使う際に安定して動作
できるまでのノウハウを記載しております…ご参考に！

また、NexperiaのAN10911はSDカードとその前身のMMC、そしてeMMCの
ハードウエア設計についての情報が満載です！こちらも必ず目を通して
おいてください！




というわけでずっと議論が続いてきたSDカードにプルアップの件は
明確すぎる根拠がどっかからリークされてきたSimplifiedじゃない
ほうのSpecificationで判明しました。まじかよフリースケール最悪ですね
これで完☆全☆決☆着です…！
以上！！終わり！！閉廷！！皆解散！！
(やけくそ)


















以下自分が納得するために調べた補足情報と想定される漫才問答です。
●なぜ信号線にプルアップしないといけないのか？
➡バスフローティング(入力開放)状態防止の為です。
　一般にCMOSプロセスのロジックICは入力を開放(=ハイインピーダンス=Hi-z)
　状態で放置すると外乱の影響を極めて強く受け、VCC/2の中間電位が印可
　される状態も簡単に起こりえます。

　中間電位が印可された場合、入力バッファを構成するPMOSとNMOSの両方とも
　ONになる危険な状況が発生しシュートスルー電流が流れてしまいます。
　その結果デバイスを恒久的に破壊する可能性があります。

　破壊まで進まなくても意図しない異常な動作状態がランダムに発生します。
　一般的にいうと動いたり動かなかったりする状態です。
　この動いたり動かなかったりするというのが実に厄介なのです。

　
　仕様にもプルアップが必須なことを示唆する図があります。
　御覧のとおりSDカードの内部バッファには一般的なCMOS入力の構成に
　なっているため、プルアップしないと中間電位が印可される可能性が
　あります。

　
　その前身マルチメディアカードはほぼ同じ感じです。
　CMDはSDカードと違いオープンドレイン出力可能な構造になっています。

　てわけでプルアップCMD,DATの論理レベルを"弱く"HIに固定化することにより
　Hi-Z状態を防止します。これはSDカード側だけでなくマイコン側入力にも
　同じセオリーとなるため、プルアップは必ず必要ということになります。


●なぜプルアップなのか？プルダウンではダメなのか？
➡SDカードとその前身となったマルチメディアカードの仕様です。
　後でも述べますがSPIデバイス＝プルアップではないです。
　SDカード/MMC/eMMCにおいてはプルアップと心得ときましょう。

　仕様には明確な記述がないのですが、仕様で書かれている事柄を集約
　すると、ネイティブモード/SPIモードに限らず論理HIレベルがCMD/DATの
　無通信時のデータ線のアイドリング状態であることを示唆しています。

　特に電源投入シーケンスではCMD/DATの論理HIに固定して保つのは
　仕様上必須と記載されています。これはMMCから続く仕様です。
　
　というわけでプルアップが必ず必要ということになります。

●で、プルアップに何kohmの抵抗使えばいいの？
➡ねむいさんは22kohmで1608or1005の面実装抵抗使ってます
　
　
　私の根拠としてSDカードとMMCそしてeMMCのすべての仕様を満たせる範囲
　かつMMC/eMMCのオープンドレインモードの動作もカバーできるように
　配慮しています。
　カードとホストが1対1で繋げることを想定し、
　CLK=400kHz, CL=20pF(STM32の最大), Rpu=22kohmであるときのL->Hの
　立ち上がり時間は約1.01uSecとなりこの立ち上がり時間はCLK=400KHz
　時の1/2周期である1.25uSecの範囲内を満たします。
　以上の結果から22kohmの正当性が証明されることになります。

　なおかつねむいさんは手持ちとして22kohmの面実装抵抗を大量にストック
　しているのでSD/MMC/eMMCのプルアップとして最終的に22kohmを選びました。
　JTAGKey2Compatibleの回路でも22kohmでプルアップしてます。

　SDカード限定で使用するなら10kohm~33kohmで選べばまず問題はないで
　しょう。それ以上の高抵抗は正直選択するべきではないです。
　仕様上100kohmだからと言って端っこの100kohmとか使うとノイズを
　極端に拾いやすくなり、動いたり動かなかったりする厄介な不良になるので
　そういう実装はなるべく避けてください。

　まずは確実に安定して動作する状態・動作パターンを構築する！
　それぞれの環境・用途への最適化はそれから！


●ところでCLKはどうすればいいのか？プルアップ？プルダウン？
➡それよりも先ず信号の終端が必須です。
　SDカードのクロックはカードから見て入力専用、マイコン側からみて
　出力専用になるのでちょっと扱いが違います。過去の記事でも記述
　していますがCLKは特にプルアップしてません、仕様上もCLKに
　ついては具体的な指示は一切無いです。

　理由は（ホストの)電源立ち上がり後にCLKに相当するピンは常時
　出力固定もしくは"直ちに"出力に切り替わることを想定してるからです。

　一方高速信号の伝送路としてみた場合、信号の反射を防止するために
　シグナル・インテグリティの概念が避けられません。
　CLKについては倫理レベル固定よりも前にこの対応が最優先で必須になります。
　これはSDカード側だけではなくホスト(マイコン)側の仕様と基板パタンの
　設計まで含めて理解し、じっっっくり取り組まないといけません。

　
　STM32のSDMMCの回路設計リファレンスAN4488の例をとると…
　"Trace the impedance : 50ohm±10%"に注目です。
　これ単にテスターで測った抵抗値を50ohmにしろって意味じゃなくて
　回路の特性インピーダンスを50ohm近傍に合わせろという意味です。
　この措置をインピーダンス・マッチング(整合)といいます。

　大前提として基板のパターン設計の時点でインピーダンス整合を考慮
　するべきですが、外付け部品で終端回路を構成してさらに細かい調整を
　行えるようにする措置を行うのが通常の設計で常だと思います。

　FPGA屋さんならこんなの私が言わずとも既にご存じの今やこれは常識レベルのことだと
　 思います…が、なんでかマイコンだけしか経験が…とかフィジカルコンピューティング
　 しか経験がない人との"常識"が異常なレベルで乖離してて結局毎回こうやっt
　すみません脱線しました。

　
　STM32のSDMMC/SDIOの回路例です。
　ねむいさんはSDMMCのCLKの終端として直列終端(ソース終端)を実施
　しています。これはCLKの出力側近傍に抵抗を直列に配置することに
　よってインピーダンスの整合を図るやり方です。
　抵抗一個でできる簡単さでなおかつ結構な効果があります。

　もちろん単にCLKに直列に抵抗入れば良いというわけではなく、
　出力端つまりマイコン側の最近傍に抵抗を必ず配置する必要が
　あります。理想的にはマイコンのSDMMC_CLKピンの真近くです。
　これを守らないと効果が無いばかりか最悪逆効果となります。

　
　
　
　↑STM32F407で実施した例。ね？簡単でしょ？
　 この基板上ではオシロ見ながら調整して47ohmとしました。
　 STM32H5/STM32L5とかは33ohmにしてます。(いずれも最大周波数50MHz想定)。

　この抵抗値はこれだといったものは存在せず、オシロスコープの波形と
　実際のデータの整合性を観ながら0~47ohmの間で調整する必要があります。
　それで調整できない場合は根本的になんか変なので基板のパターン設計
　からやり直しです。

　本当はCLKだけではなくCMD,DATにもすべて適用すべきですが一番激しく
　動くのがCLKなので回路面積的に余裕が無い場合でもせめてCLKだけは
　このような"調整代(しろ)"を入れてください。



　そして長々と終端について書きましたがCLKが出力に"直ちに"切り替わら
　ないケースの場合について、中間電位がカードのCLK端子に長時間叩き
　込まれる危険性があるの何らかの形で電位を固定する必要が生じます。
　
　SDAの仕様上は指示は無いですが産業用SDカードを製造するswissbitの
　アプリケーションノートに有力な情報がありました。
　この状況が起こる場合は100kohmでプルダウンせよとのことです。
　この100kohmも適当に配置せずCLKの受信端、つまりカード側で最短で
　配置すべきです。これも変に配線を引き回してしまうとそれが信号線の
　分岐路となってしまいそこでまた反射が起こってしまうので最短経路で
　GNDにプルダウンするよう配線してください。

　仕様では直接の言及はありませんがこれらの情報を総合すると…、
　CMD,DATは論理HIでCLKは論理LOが無通信時の
　論理状態ということになります。
　尤もCLKに関してはSDMMCではパワーセーブなどを使用しない場合は
　延々と垂れ流し状態となるので論理レベルに関してはそこまで気にする
　必要はなく、上で述べた信号の終端のほうが最重要となります。

　シグナル・インテグリティの一般の解説ついては英語の文献となりますが、
　High Speed Digital Design Handbook of Black Magicと
　Signal and Power Integrity - Simplifiedがわかりやすくまとまって
　いますので必読です！

　ぇえ･･･?英語わからないですって…じ、じゃぁ日本語文献なら…
　マクニカさんの解説文書とか参考にしてください。
　正直英語圏で情報拾ったほうがよっぽど速くて正確ですよぅ##

STM23H5を使ってみる7〜SAIを駆使してPCM5102Aを動かす胎動編〜

今気づいた…STM32H5の記事1年半くらい更新してなかった…
ていうか世間様はラズピコとかESP32をArduinoIDEで開発するのが主流になっちゃって
STM32マイコンは関った時点で負け犬確定のオワコンとなってしまいました…

でも私はこれしかないんだ！！
私にはこれ(STM32+makefileのコマンドラインビルド)が最高なんだ！！！


さて･･･2023年からSTM32H5を使いはぢめてはや2年となりますが
やっとこ自前のSDMMCドライバも安定してきたので新しい分野に
ちゃれんぢすることになりました！！！！

とりあえず巷で安く販売されているI2Sインターフェースを持つ
DAI(デジタルオーディオインターフェース)PCM5102Aを駆使して音楽を
SDカードから読みだして再生するのが目標です！！

ていうか実はもうとっくに実装しちゃってwav,mp3,aac,m4aの再生も
ばっちりカバーしてるのですがそれは置いといて話を進めます…



あたらめてデジタルオーディオの世界に突入するにあたり電子書籍でなく実体の
書籍を購入して勉強しております…！

ブルーバックスの「デジタルオーディオの謎を解く」はI2Sなぞまだ影も形もない
1982年に刊行されたほんとに黎明期の書籍ですが始まりを知るにはうってつけです…
通勤時間利用して読めますからね〜…ねむいさんの脳みそにはちょうど良いです。

もう一つの｢音のプログラミング｣はこれから絶対先避けては通れない
信号処理に関する書物となります…がいきなりΣを含む計算式が出てきた
のでこちらのほうは内容を理解できるのはまだまだ先になりそうです。

とにもかくにも歴史の始まりをひも解いて今ではcommon-senceとなった
概念ががなぜそう決まっていったかを理解していこうと思いました。


*自分なりに解釈した大前提
デジタルオーディオの三大要素は以下の通り
・標本化　(サンプリング)
　　☞ 一番最初の要素。
　　　 ある一定の周期(もしくは周波数)でアナログ信号を取り込むこと。
　　　 44.1kHzとか48kHzとかの値はこれを指す。
　　　 連続した値をとらず、とびとびの値を持つ。
・量子化　(クォンタイズ)
　　☞ 標本化した音の強弱をある一定の値の範囲内で分割すること。
　　　 16ビットとか24ビットとか言われてる値のこと。
　　　 こちらもとびとびの値を持つ。大体8の倍数。
・符号化　(エンコード)
　　☞ 量子化したデータを二進数で表現する方法のこと。
　　　 表現で用いられるデータの幅は上記量子化のビット数に倣う。
　　　 CDの例(リニアPCM)では符号付16bit変数(-32768~32767)で表現される。

ところで"とびとびの値"って表現は離散値と呼ばれているようですね。
量子化学だとまんま"とびとびの値"って言っていました。


*その他
*なぜ44.1kHzっていう周波数に決まったの？
☞"信号成分の最大周波数より2倍以上大きいサンプリング周波数で
　取り込めば原音は十分再現できる"とするシャノンの標本化定理に
　倣うと人間の可聴周波数領域最大は20kHzなので20kHz*2=40kHzとなる。
　なのだがこれよりもちょっと高い周波数にしてやることで高音領域で
　サンプリング周波数の折り返し雑音の影響を受けなくなる。
　なので40kHzよりももうちょっと高い値が求められる。
　
　んでもって最初にCDの規格が出来上がるときにすでに一般に普及
　していたVTRを利用してデジタルデータとして取り込むことになったが
　このVTRの装置の都合上より最終的に44.1kHzの値が決定した。
　
*48kHzとか似た周波数もあるがこれは何か
☞規格立ち上げの際にもめて最終的にこういう形なりました。
　業務向け機器でよく使われる周波数。
　実は最初は50kHzだったのですがこちらもいろんな大人の事情があり
　48kHzが正式な値としてきまりました。


　現在ではサンプリング周波数は大きく分けて44.1kHzの倍数と48kHzの
　倍数が使用されています。
　さらに昨今では192kHzとか非常に高いサンプリング周波数のハイレゾ
　なんかも出回っていますね。



てわけでだいたい歴史がわかったので(ガバガバですが)これから改めて
これらの概念を用いてSTM32H5を使いDAI(デジタルオーディオインターフェース)
に音激をたたきこんでいく方法を次回もじっくり模索していきます…!

いろいろ試す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第二弾です。
EXPERT S.M.A.R.T. Micro SDXC メモリーカードですって〜
なんというか9年くらい周回遅れですｎｹﾞﾌﾝｹﾞﾌﾌﾝ





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

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


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


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

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

結論から言うと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パススルーする
特殊な方法は使っていません。
ていうか汎用のカードリーダーではTranscendのような技はできません。
実際やっていたの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製の専用カードリーダーが必要みたいです。
汎用性考えるとやっぱり無理して買う必要もないかなと思います。

話は前後しますがSTM32H7のいつものでカード情報を引っ張っておきます。

FatFs module test terminal for STM32H747XIH6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Mar 11 2025

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 21935 kB/sec.

>fs 0



FAT type = exFAT

Bytes/Cluster = 262144

Number of FATs = 1

Root DIR entries = 0

Sectors/FAT = 32768

Number of clusters = 945816

Volume start (lba) = 65536

FAT start (lba) = 98304

DIR start (lba,clustor) = 4

Data start (lba) = 131072



Volume name is TTCS256GIA2

Volume S/N is 1DF1-C03B

...rc=5 FR_NO_PATH

>ds 0



rc=0

Drive size: 484388864 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 59 00 07 37 CB 7F 80 0A 40 00 89  @..2.Y..7....@..

CID:

00000000  45 2D 42 53 74 6F 72 61 07 7B 77 45 B9 71 85 F3  E-BStora.{wE.q..



Parsing SD CID Register

Manufacturer ID    :0x45

OEM/Application ID :-B

Product Name       :Stora

Product HwRev      :0

Product SwRev      :7

Serial Number      :0x7B7745B9

DateCode.Month     :5

DateCode.Year      :2024



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 10 05 39 1E  ..............9.

00000010  00 08 00 00 00 02 0F 00 03 00 00 00 00 00 00 00  ................

00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

SCR:

00000000  02 05 84 8F 33 33 30 39  ....3309



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :0

SD Bus Width       :5



SD_Spec V6.xx!

Detected as Not SD Card!

Available UHS-I Mode.

Available UHS Speed Class U3.

Available SD Speed Class 10.

Available Video Speed Class 30.

Available Application Performance Class2, A2 Card.

A2 CommandQueue Depth 2 Supported

A2 Cache Supported.

A2 Host-Initiated Maintenance Supported.

A2 Card-Initiated Maintenance Supported.

>

このカードのコントローラはSA3309というコントローラで
動かしてるようですね…DDR200対応のはずなのに通常の
DDR200移行の手順をさせなくしてるのほんとﾀﾞﾒ


20250911追:
なんと9月に入ってHardDiskSentinelというSMARTを解析できる
ツールがTeamのこのカードに対応しちゃいました！！！
これはアツい！！アツすぎる…！！！！遅れてきた夏が始まる！！

とりあえず見てみました…！ダメダメな公式ツールからでは見えなかった
総書き込みセクタ数やPowerCycleCountなどの値が反映してるじゃあーりま
せんか！！！！なんという価値のある資料だッ…！！！そして…


ﾝｱｰｯ!!TeamGroupの懐が(ｶﾞﾊﾞｶﾞﾊﾞすぎて)広すぎるよもぉおおん！！！！

…すみません表示してる数字に特に深い意味はないですが…
"smartデータハイジャッキング"でこんなお遊びできちゃいます♪

そんなわけでねむいさんが解析したEXPERT S.M.A.R.T. Micro SDXC256GBの
SMARTデータに情報を追記したものを改めて上げました…
Teamの中の人から刺客が来たら返り討ち処しますので取得はお早めに…！！
20250911追 終


●話は変わるが開発環境構築の記事更新の件どうなったの？
ギ ブ ア ッ プ
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ロガーとして末永く
使っていこうと思います！

Go to top of page