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じゃなくてもこれらでいいかも…！

Transcend様提供のSD SMART Toolboxの可能性を探る

前回は民生用で安く手に入るTranscend製のmicroSDカードのS.M.A.R.T.
(以下SMART)を取得するためのいろいろを公開いたしました。

今回はSMART情報を取得するためのツール｢SD　SMART　Toolbox｣の可能性に
ついてさらに掘り下げていこうと思います！

ソフト紹介のページではSDC340S/USD340Sしかサポートしてないような
文面となっていますがSMARTのデータから解析するにもしかして過去の
Transcendの産業用SDでも読めるんじゃねぇの！？と思い立ち実際に
試してみることにしました！！！


ところでインストーラーで出てくる言語選択はインストーラーしか対応してなくて
実態のプログラムは強制的にOSが使用してる言語環境に合わせられるのいいよね…
…
よくねぇ！！


それはさておき2020年からほぼ1年ずつ買ってきたTranscend製の産業用microSDを
試していこうと思います！！！
カードリーダーはTS-RDF5(2022年生産モデル)を使用します。


まずは前回のおさらい、TS64GUSD340S 民生用microSDカードの
SMART情報です。


お次はTS32GUSD230I…ですがありゃりゃ…
だめですね…


今度は大容量のTS256GUSD430Tです…！！
おおっ！読めたっ！！

NDA結ばないと使えないSoftScopePRO使わないでも簡単にwebで
ダウンロードできる民生用のソフトで見えた！
やったぜ…！


今度は上記の進化系のTS256GUSD460Tです…
こちらもしっかり読めてますね…！！


最後はpSLCモードで動作する現時点で最強のTS20GUSD240Iです…！
こちらもちゃんと見えていますね…！

近年のTranscend製産業用SD/microSDについては2021年以降製造の品種より
SD SMART ToolboxとTS-RDF5でSMART情報が読めるようです。




ところでなんで2020年に入手したTS32GUSD230Iだけはぶられているのか
ちょっと調べてみました。
なんでかTranscendの産業用SD/MicroSDはネットに詳細なデータシートが
落ちているためSMARTの構造体の詳細も知ることができます。
で、データシートを読み比べてみるとUSD230Iシリーズとそれ以降に製造
された産業用SD/MicroSDは一部の構造体の定義が微妙に異なっていました。

USD460T,USD240Iのものと比べるとUSD230Iは一部の定義が異なっているのが
わかります。多分これのせいでソフト側ではねられてSMART読めなくさせて
いつのだろうとおもいます。


SD SMART Toolboxはかなりチェックが厳密なのですがTranscendEmbedded様
から超ご厚意で提供してもらった"SD SMART Tool"の方はその辺の判定は結構
ガバガバで多少の不整合があっても無理くそ表示してくれます。



ていうわけで今回のまとめ
・Transcend様提供の｢SD SMART Toolbox｣は民生用だけじゃなく一部の
　産業用SD/MicroSDカードでもSMARTを読み取ることができる！

・現時点で実際に確認している産業用MicroSDの品種は以下
　USD430T,USD460T,USD240I
　
・USD230Iシリーズはソフトで跳ねられてしまったのか｢SD SMART Toolbox｣
　ではSMART情報が読めない。

・おそらく2021年以降発表のモデルならSMART情報の構造体がすべて同一に
　なっているため、｢SD SMART Toolbox｣でSMART情報が読み取れることが
　できると考えられる！
　
・SMARTを見るためには2020年以降製造のカードリーダーTS-RDF5が必須。
　見分け方はデバイスマネージャで見るデバイスストリングが
　"TS-RDF5A"となっていること。
　
・☝パッケージからでは何時の製造が見分けがつかないので、カード
　リーダーの選定は結構なぎゃんぶるになってしまうかも…



今回、さりげなくTS20GUSD240Iが出てきましたがこちらについては
次回にでもみっちりと解説させていただきます…！！

S.M.A.R.T.が採れて安価なTranscendの民生向けSDカードを試す！

あけましておめでとうございます(もう1月末ですが)

今年は節目となるイベントがたくさんありますのでよろしくお願い
いたします…！！


さて、新年一発目はTranscend製でS.M.A.R.T.(以下SMART)が取れる
SDカード、それもいつもの産業用じゃなくて民生用で安価なものを
紹介させていただきます…！！



TranscendのHPに記載があってびっくりしたのですが民生品で
SMARTに対応しているのを明記してるのが出てきておりました。
Ultra Performanceと呼ばれるUSD340S/SDC340Sシリーズです！


このシリーズはSD SMART Toolboxなるもので上記カードから
SMARTの情報を読み取り使用量を把握できるものとなっているそうです。





ねむいさんもさっそく購入して試してみました！
大阪日本橋のPCOne'sで購入したのは128GB容量のTS128GUSD340Sです。

しかし…


ﾁｰﾝ

使用USBカードリーダーがTranscendのTS-RDF5でしかも2019年以降
製造のロットじゃないとダメだったようです…



てわけでRDF5の2020年以降製造と思われるカードリーダーを
購入してまいりました…！！！



ﾁｰﾝ


…

なんでだYO！！１！！



念のためねむいさんのFatFs実装例(STM32H5版)でCMD56放ってみましたが
全部0が返ってくる状態でSMART情報は得られませんでしたorz


もしかしてカードの方もほんとに最新のやつじゃないとSMARTに対応して
いないのでは…2022年製造の奴は古いってことですか…

念のためSDカードの情報を引っ張っておきました。

FatFs module test terminal for STM32H563ZIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jan 17 2025

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 17869 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 32717

Sectors/FAT = 16384

Number of clusters = 923424

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is 128GUSD340S

Volume S/N is 0977-190A

...

1 files, 132949600 bytes.

0 folders.

118198272 KiB total disk space.

118067456 KiB available.

>ds 0



rc=0

Drive size: 236462080 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 03 86 07 7F 80 0A 40 00 BD  @..2.y.......@..

CID:

00000000  74 4A 60 55 53 44 55 31 20 28 0A 09 9B A1 69 7B  tJ`USDU1 (....i{



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x280A099B

DateCode.Month     :9

DateCode.Year      :2022



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 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 87 00 00 00 00  ........



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 32 Supported

A2 Cache Supported.

なんかすごい気になったのはSD Securityの値が"0"になってて
CPRMサポートしていないようなんですよね…。
SD Securityビットの値でSDSC/SDHC/SDXCの判別してたのでちょっと
困ったことになりました…
ちなみにSDUCではCPRMサポートは完全除外されSD Securityビットも
0となるでしょうから別の方法でカード種別の判別するしかないですね。






気を取り直して店変えて買いなおしました…
今度はAMAZONでTranscend直売のTS64GUSD340S買ってみました…
これならたぶん古くとも2023年くらいでしょー…(願望)

そして…

！！
やったぁ！SMARTが取れた！
2024年10月製造のモデルでした！


ちなみに5年前、TranscendEmbedded様より超ご厚意でいただいた
"SD SMART Tool"でも無事にSMART情報を得ることができました。
やっぱこっちのほうが詳細が分かってよいですね〜
そしてこちらは2019年以前のRDF5でも普通に使えます。
なんで製造年数縛りでソフト作ったのでしょうか…???


ていうわけでこっちのカードもSDの情報抜き出しときます。
FatFs module test terminal for STM32H563ZIT6

LFN Enabled, Code page: 932

AppVersion : W.I.P

Build Date : Jan 31 2025

>fg piano



rc=0 FR_OK

>fo 1 ftbt.mp3



rc=0 FR_OK

>fr 132949600



132949600 bytes read at 20381 kB/sec.

>fs



FAT type = exFAT

Bytes/Cluster = 131072

Number of FATs = 1

Root DIR entries = 28621

Sectors/FAT = 16384

Number of clusters = 471032

Volume start (lba) = 32768

FAT start (lba) = 49152

DIR start (lba,clustor) = 4

Data start (lba) = 65536



Volume name is 64GUSD340S

Volume S/N is FBDE-D5FB

...

1 files, 132949600 bytes.

0 folders.

60292096 KiB total disk space.

60161664 KiB available.

>ds 0



rc=0

Drive size: 120649728 sectors

Erase block size: 8192 sectors

Default r/w block size: 512 bytes

Card type: SDv2(Block)

CSD:

00000000  40 0E 00 32 DB 79 00 01 CC 3D 7F 80 0A 40 00 47  @..2.y...=...@.G

CID:

00000000  74 4A 60 55 53 44 55 31 20 76 0B 46 98 A1 8A 27  tJ`USDU1 v.F...'



Parsing SD CID Register

Manufacturer ID    :0x74

OEM/Application ID :J`

Product Name       :USDU1

Product HwRev      :2

Product SwRev      :0

Serial Number      :0x760B4698

DateCode.Month     :10

DateCode.Year      :2024



OCR:

00000000  C1 FF 80 00  ....

SD Status:

00000000  80 00 00 00 08 00 00 00 04 00 90 00 08 11 39 1E  ..............9.

00000010  00 08 00 00 00 02 FC 00 00 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 45 84 87 00 00 00 00  .E......



Parsing SCR

SD Spec Version    :2

SD Spec Version 3  :1

SD Spec Version 4  :1

SD Spec Version X  :2

SD Security        :4

SD Bus Width       :5



SD_Spec V6.xx!

Detected as SDXC 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 32 Supported

A2 Cache Supported.

ん？こっちはちゃんとSD Securityのところが4(SDXC)になってる…?
う〜〜むSDカードは水物でほんとによくわからん

そんでもってCMD56で抜き出したSMARTのデータも置いておきますので
ご参考に…512バイトのSMARTのデータのフォーマットはかつての
産業用SD/microSDと同じでした。だから同じツールが使えたのですね。


そんなわけで2025年になってようやく民生品レベルにもSMARTを搭載した
SD/microSDカードが浸透し始めた段階です。
まさに民生向けSDカードのSMART元年とでも言いましょうか…
願わくばSDの規格にSMARTが正式に搭載されることを祈り続け今後の
発展を見守ることにしましょう…


今回のまとめ
・Transcendの340Sシリーズは安価な民生品だがSMARTを搭載している。
・SMARTを見るためには以下の条件が必要。
　��2024年以降製造のカード必須。それ以前のものはSMARTが無いかも。
　��TS-RDF5が必要。しかも2019年以降製造のモデル必須。
　　※マイコンとかで直接CMD56を放つ場合はTS-RDF5不要。
・CMD56の引数やSMARTのデータフォーマットはTransendの
　2021年以降新規発表・販売モデルの産業用SD/microSDと同一。

・SMARTの詳細は過去記事も参照のこと。

いろいろ試す64　- 2024年反省会 -

あっという間に2024年もおしまいです…。

副業(本業は虹裏メイド)が多忙になってしまい出来ることが少なく
なってしまいましたができる限り拾ってまいりました…！


●arm-gcc更新
arm-gccが12月10日付で更新しておりました。


今回のリリースからWindows向け64bit版のツールチェインも追加と
なっております。x86_64ってやつですね。i686が32bit版です。


なお、前回詰まってしまったGDBの挙動がおかしかった件ですが、上記の
64bit版ツールチェイン付属のARM-GDBでは修正されていました。

"tbreak main"がしっかり効いてデバッグ開始時にmain関数の先頭で
ちゃんと停止してくれます。一方で32bit版は相変わらずダメでした。
これからは64bit版を使っていきましょう。

昨今のOSは64bitが主流なので特に強い理由がない限りは64bit版の
ツールチェインを選択していくことになりますね。

…これでやっとARMマイコンデバッグ手順の更新ができる…かな？


●FatFsが0.15aに更新
ChaN'師のFatFsも先月末に更新しておりました。
小規模な変更だったので移植もスムーズにすることができました。

私のFatFs移植例にも反映しておりますのでどしどしご利用ください！
*STM32H7
*STM32H5
*STM32F7
*STM32F4


●OpenOCDのSTM32U0正式対応
ついにやってきましたね…半年以上待ちましたがー！

書き込み時のログはこんな感じです↓

> "C:¥Devz¥Coreutils¥bin¥make.exe" program

openocd  -s C:/Devz/ARM/OCD/tcl -f interface/stlink-dap.cfg -c "transport select dapdirect_swd" -f target/stm32u0x_swd_flash.cfg -c "mt_flash main.elf"

Open On-Chip Debugger 0.12.0+dev-00823-g4f2744d0f (2024-12-31-14:06)

Licensed under GNU GPL v2

For bug reports, read

	http://openocd.org/doc/doxygen/bugs.html

WARNING: interface/stlink-dap.cfg is deprecated, please switch to interface/stlink.cfg

Info : STLINK V2J45M31 (API v2) VID:PID 0483:3752

Info : Target voltage: 3.234510

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : Unable to match requested speed 500 kHz, using 480 kHz

Info : clock speed 480 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x6ba02477

Info : [stm32u0x.cpu] Cortex-M0+ r0p1 processor detected

Info : [stm32u0x.cpu] target has 4 breakpoints, 2 watchpoints

Info : [stm32u0x.cpu] Examination succeed

Info : [stm32u0x.cpu] starting gdb server on 3333

Info : Listening on port 3333 for gdb connections

[stm32u0x.cpu] halted due to breakpoint, current mode: Thread 

xPSR: 0xf1000000 pc: 0x08002b28 msp: 0x2000a000

Info : device idcode = 0x10006489 (STM32U073/U083xx - Rev A : 0x1000)

Info : RDP level 0 (0xAA)

Info : flash size = 256 KiB

Info : flash mode : single-bank

Warn : Adding extra erase range, 0x08004d20 .. 0x08004fff

Info : wrote 19744 bytes from file main.elf in 0.969477s (19.888 KiB/s)

Info : verified 19744 bytes in 0.512074s (37.653 KiB/s)

shutdown command invoked



> Process Exit Code: 0

> Time Taken: 00:02

以前と変わりはほぼありませんね。


もちろんデバッグも自由自在です。

これでSTM32U0も(正式に)バリバリ開発ができるようになります！
わたしのおきぱにもOpenOCDバイナリを置いていますのでこちらも
大いにご利用ください！
…あとは昨年から放置状態のSTM32H5のフラッシュ対応待ちですね…！

また、夏にコミットされたgdbコマンド体系の再編への対応について、
ねむいさん特製フラシュ書き込み用cfgファイルは対応しておらず
書き込みとかデバッグするたびにwarning出まくりで放置状態でした。

今回のブログ記事を書くにあたりようやっと対応させてみました。
もうwarningは出ませんので安心してご使用ください。


●avrdudeがいつの間にかV8.0に
かつての停滞が嘘のようにまさに日進月歩の進化を遂げるようになった
AVRマイコン書き込みプログラムavrdudeですがV8.0まで上がっております。

ちなみに上がったの8月だったんですが更新したの紹介して
ませんでした。かなりの修正と機能追加がされております。
AVR-EBシリーズ使うならV8.0以降が必須となります。

こちらも私がビルドした最新のバイナリを挙げていますので
ご利用ください〜！


●2024年反省会
…ぇっと…今年はやりたいこと全くできなかったのですが来年は…

��2025年度版のarmマイコンビルド・デバッグ手順の作成
��STM32H5を使ったmp3プレーヤーの作成

の達成を目標にがむばっていきたいとおもいます…！！

それでは皆様良いお年を〜

Go to top of page