東海自然歩道・復路を征く2(西野々-西丹沢ビジターセンター-大滝橋)

今年も秋の登山ラッシュの季節がやってまいりました…！
特に今年は東海自然歩道復路の復路攻略を進めておりますので
必然的に極めて過酷な戦いとなってきます！！

今回は東海自然歩道の中でも最高難易度を誇る北丹沢のルートで
あり、関西から来たら最後の難関、関東から向かう場合は序盤の
難関となります。どちらから向かっても最難所なのです！！
ねむいさんは己の存在を証明するため、再びこの過酷な地に挑む！

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

●2025.11.22 東海自然歩道(西野々➡西丹沢ビジターセンター➡大滝橋)

副業(本業は虹裏メイド)を終えてすぐに新幹線に乗って京都から
新横浜、さらに横浜線で橋本駅へ…！

現地のホテルはリニア建設効果かインバウンド値上げかべらぼうに
価格が上がっており、かつて宿泊したアパホテルは12年前の3倍に！！
仕方なくちょっと外れたところにある橋本パークホテルというところに
泊まりました…。かなりヤニ臭いって前評判あったのですがあんまり
気にならず、よく眠れました…zzz
そして


虹裏メイドの朝は早…い"っ!?
始発の橋本発三ヶ木行きのバスはなんと満員御礼…


三ヶ木から西野々方面行のバスも登山者でいっぱいでした…マジか…
この路線近々整理されるって噂なので記念に来たのでしょうか(←大ボケ



ほとんどの人は焼山登山口で降りていきましたがねむいさんはちょっと
先の西野々バス停に。前回の続きの西野々バス停から死闘開始です…！！



東海自然歩道の最高難易度の道に歩を進める…
12年前と変わらないゲートがお出迎えです。



焼山登山道からの道と合流しぐんぐん進んでいきます。


いやはや、紅葉がきれいです…！
(☝まだ精神的に余裕があったころ)




そんなぬるい登りはすぐに終わり、狂った角度の急登攻撃が
はぢまります…！
でも12年前と違ってロープとか追加されてて安全性はちょっと
上がってるかと思います。


標高が1000m超えたころに焼山への分岐が…




最初のピーク、焼山山頂です…！
まだまだ序盤なのでそそくさと次に進みます…！



開けた場所を進んで平戸分岐を横切ります。


焼山から姫次までは標高差400mをゆっくり上がっていくなだらかな
登りになります。


んでもって植生保護のためにこんな木の桟道が多数出てきます。


そしてお次は黍殻山頂上に向かいますが…


ねむいさんは忘れていた。
ここの木の根っこ道がめちゃくちゃやばかったことを…！
へっぴり越しで木の根っこつかんでゆっくり進んでいく…



めっちゃ時間かかった…
黍殻山山頂です…！



そこから少し進んで自然歩道の合流した先にある黍殻避難小屋にも
寄ってみました。



12年前は建て替え中でしたが今はきれいに使われていました。




さらに登っていく。
標高はいつの間にか1400mに迫っていました。
八丁坂の頭分岐を超えます。




東海自然歩道最高地点に到達です。
12年前は大阪からはるばるここまでやってきて感激しました。
今はここから大阪を目指して新たな闘志を燃やします！



そして姫次に到着です…！
12年前と違って山頂広場が整備されていました。



そしてそこからの富士山！！
ねむいさんはこれを見に来ました…！！
12年前と変わらない景色ですね…！



そこから少し西にある袖平山山頂と富士山です…！


遠くに富士山を見送る…そして
袖平山から神の川に向かって下山にかかりますが…

ここが東海自然歩道最大の難所区間となります…！！！



最初は大崩落地を横に見ながら下っていきますが…



すぐに両手両足を駆使しないと滑落して死ぬ危険な道が
連続します…そいえばこの苔の写真12年前も同じ場所で撮ったっけ…


進んでいくうちに私に異変が起きた…
なんか全然進んでない…
足が攣っただけではなく竦んでしまって足が前に出せない…！

そう、私は高所恐怖症なのです…！


全体的に落ち葉でめっちゃくちゃ滑りやすいうえに滑ったら
そのままいろんなところにたたきつけられて死
しかも12年前は気づきませんでしたがこの土嚢みたいなのに足置いたら
ほぼ確実にすべって死ぬ…！もうやだ…！


あーもーやだよもー！！！！！
下見たらまた足が動かなくなっちゃうのですが下見ないと
滑って死ぬで下を見ざるを得ない地獄…

12年まえは登りだったので下を見なくて済んだのですが…
こんな罠があったとわ…


鎖場を通る…
ここを登った時よりも確実にペースが遅い…




標高1077m、風巻の頭に到達です…
ここからさらに500m一気に下るのですが精神が参ってしまって
なかなか先に進む気が起きませんでした…



なんとか前に進めそうになったので意を決して降りる…
足の攣り止めに天日塩を補給して挑みます。
塩飴じゃ追いつきません！



まれに安全に立てる道やきれいな紅葉が出てきて気を
まぎわらせてくれます…



ちょっとまってなんなのこれ…
12年前こんなひどくなかったってこれ絶対…！
もうやだぁあぁああ１！！１！！！


風巻尾根のルート、危険なので不人気なのでしょうか…
自然に帰ってさらに荒れての無限ループになってる気がしますね…


そしてとどめにめっちゃ斜めった木橋が！！！
滑ったら3m下の岩場にたたきつけられるので四足歩行獣体制で
ちびりながらクリアー…



すっかり汚らしいぼろぼろの格好になって神ノ川林道に
叩き出されます…


うふふ紅葉がきれいだなぁ
うふふふふふふふふふふふふふふふ(錯乱)



12年前と同じく巨大東海自然トイレで休憩がてら体勢を整えます…！
まだ危険区域は脱していません…！お次は犬越路の攻略です！！



神の川ヒコッテは建屋は残って
いたものの、立ち入り禁止となっておりました…



しばし林道を登ります。
12年前の解説看板は朽ちて埋まっており星霜を感じます。



そして沢の右岸に取り付き犬越路の本格的な登りに挑みます…！！
12年前と違って黄色い看板が設置されており、迷いづらくなって
いました。そして昔からある道標は土砂で埋まっており、道の崩壊
具合がわかります…！！


途中で老夫婦を追い越しました…その時話を交わしましたがやはり
犬越路の神の川側は崩壊がかなり激しく地形も変わっているとのこと…
私も"ここから先はものすごい急登になる"と注意して先を急ぎました。



私の記憶通りとんでもない急登攻めが出てきました…！
いっぽう鎖で柵ができてるのでちょっとだけ心強いです…
…でもこんな場所とおったっけ…？？？



風巻尾根の下りで体力を精神力を消費しきってしまったので
何度もスタックしてしまう…落石注意の張り紙に「なもん分かっとらい！」
と悪態をつく。


あと0.4�劼�ぜんぜん進まない…



12年前にもあった崩落は大規模に拡大してるのかやっぱりルートが昔と
違ってる感じです…見覚えがない。


あとちょっとがほんっっっと進まない…
30秒くらい下向いてその場に立ちすくしてしまうことを繰り返す。


もうだめ
標高差あと10mくらいのこの地点でまた1分くらいスタック…
天日塩効果で足の攣りは無くなってますがまた精神的に足が
すくんじゃってます…あと10m登るだけなのに…




完全にズタボロ状態で犬越路頂上部に到達です…
ここは縦走路の中間地点でもあり避難小屋もあります。



最後の補給をして下山にかかります…！
ここから先も藪と岩の沢路で難儀だったはず…


と思いきや藪がなくなってて道もロープが張られてます。
なんかルート変わってる気がしますがちょっと安全そうでした。


峠頂上までは清原コーロボマクタサン状態だったねむいさんですが先が
見えてきたとわかった時点で謎の元気が出てきて紅葉を撮影する余裕が
でてきちゃいました！



12年前はコシツバ沢という岩場にしがみついて通っていたのですが今は
その脇に道が作られててかなり難易度下がっているようですね…！

この勝負、ねむいさんの勝ちです！！(←現金なタイプ)




用木沢の沢筋を進みます。
こちらも黄色看板が至る所にあって迷わないようになっていました！


たまに斜めってる箸もありますがジャンプでクリア！



勝ちが見えたねむいさんを祝福するように夕日と紅葉がお出迎えです…！


12年前にあった橋が流されているところもあり、
靴を脱いで渡渉しました。



そして用木沢出合に…！
もう危険地帯はすべてクリアしました…！
時間はかかってしまいしたがこの戦いを制したっ…！！



あとはお気楽な舗装路だけです♪
3連休効果もあってか道の途中にあるキャンプ場はどこも満員御礼でした。



そして西丹沢ビジターセンターに到着です。
かつては西丹沢自然教室という名でしたが近年名前が変わりました。


当日は登山シーズンもあってか臨時バスが出ているようでしたが
ねむいさんは先を進みます…！いけるとこまで行きます！




箒沢荘と中川の箒杉です。



畔が丸山分岐に到達です。
そしてそのすぐ近くに大滝橋バス停がありました。
さっきの臨時バスがちょうどやってきたので今回は
ここでゴールとしました…！
今回は本当に過酷な戦いでした…！


富士急湘南バスから名前が変わった富士急モビリティバスに乗って新松田駅まで…



そして小田急で小田原に行ってここから新幹線で京都に帰還です…
12年前は小田原の滞在時間3分だったので今回は駅蕎麦食べたりお土産
たくさん買う時間も確保しちゃいましたよぅ…！




というわけで最初の最難関を無事クリアしてまいりました…！
しかしながら東海自然歩道三大難所の丹沢山塊は前半戦が終了しただけなので
後半の大滝橋から平野も激闘必須です！

次回もしっかり装備と体調を整えて挑みたいと思います…！！


●2025.11.22 東海自然歩道(西野々➡西丹沢ビジターセンター➡大滝橋)　GNSSログ


ところで…昨今の円安と物価上昇で遠征費も12年前と比較にならないくらい
かなりかかってます…ここら辺の費用のやりくりも家族を説得しつつ何とか
こなしてまいります…！

マイコンで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の面実装抵抗使ってます
　
　
　私の根拠として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がわかりやすくまとまって
　いますので必読です！

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

●マイコンの内蔵プルアップ抵抗で代用するのは何故だめなのか
➡電源立ち上がり時にHi-Z状態の入力不定の時間を作ってしまうからです。
　マイコンのGPIOの機能で内蔵プルアップを有する機能がありますが
　上記の理由でSDカードのプルアップとするのは不適切です。
　かならずCMD,DATの各線は外付け抵抗でプルアップしましょう。

　STM32とかの大規模マイコンでは特にPOR後にマイコンが内部発振で
　起動->PLLでさらに高いクロックへ設定してそこから周辺回路を設定して
　…とやってると最終的にSDカードのGPIO(の内蔵プルアップ)の設定
　する頃にはSDカードはとっくに内部のコントローラは立ち上がって
　駆動しているのでもはや手遅れの場合があります。
　これはカードの個体差/種類によって大きく挙動が異なるため、それで
　動いたり動かなかったりすることになります。
　
　おまけにマイコンの品種によってはSDIO/SDMMC/SPIのモジュールを
　ハードウエア的に有効にしたら内蔵プルアップ抵抗がGPIOから切り
　離されてしまう仕様のものもあります。
　
　STM32F103のリファレンスマニュアルより。
　入出力が切り替わるAlternateFunction(SDMMCやSDIO)を有効にしたら
　内蔵プルアップが無効になり入力がHi-Z状態になることを示唆しています。
　これSDMMC/SDIOとかでSDバスモードでSDカード動かす際に引っかかって
　る人が多いです！ちゃんとリファレンスマニュアル読まないで
　ネットで拾ったソースと適当に線繋げただけだと絶対安定して動きません。
　このような憂いをなくすためにもかならずCMD,DATの各線はかならず
　外付け抵抗でプルアップしましょう。
　
　また、一般的にマイコンのGPIOに内蔵されるプルアップ用の抵抗は
　金属酸化膜とかで作られてるわけではなく、シリコン上に形成した
　定電流動作のFETをもって"うんちゃらVの電圧の時に**uAの電流が
　ながれてるから等価的にこんだけの抵抗値に相当するよー"という
　代物がほとんどです(電源ICとかの高精度をうたうものは実体抵抗が
　内蔵されてるケースもあります)。
　
　STM32H5のリファレンスより。
　しっかり"equivalent resistor"と明記されていてますね。
　金属酸化膜の実抵抗に比べて抵抗値の値のコントロールができず
　かなり大きなばらつきがあるという弱点も挙げられます。
　上記のSTM32だとある結構範囲は絞れてますが(それでもだめですが)…
　
　ATMEGA1284Pのデータシートより。
　AVRだとかなりばらついてますね。動作電圧範囲が広いせいもあるでしょうけど。

　そして内蔵プルアップ抵抗は一般的に30~100kohmと高抵抗でノイズの
　影響を受けやすくきわめて脆弱です。
　配線を基板や装置の外部に引き出して使うのなら、高速信号じゃなくても
　押しボタンスイッチなどのESDがビシバシはいる入力とかなら外付け抵抗で
　プルアップなりプルダウンなりしたうえでさらにESD保護ダイオードと
　ダメ押しの直列抵抗でガッチガチにガードすべきです！！
　
　
　またまたswissbitのアプリケーションノートからですが…
　産業用SDカードの老舗もこう言ってるからもはやマイコンの内蔵
　プルアップはSDカードのプルアップとして使えませんよねぇ…
　ぁー電源投入直後から恒久的に内蔵プルアップ(50kohm以下)が機能
　してるマイコンなら配線距離1cm以内なら多分大丈夫かと思います。
　そんなのめったに見たことないですけどー！！
　
　てわけで内蔵プルアップ・プルダウン機能を使う際はあくまでも
　そのシステムで使用しないGPIO(たいていデフォルトは入力)のHi-Z
　状態の防止程度にとどめておきましょう！
　SDカードのCMD,DATの各線は内蔵プルアップでごまかさずに必ず
　外付け抵抗でプルアップしましょう。
　大事なことなのでこの項の中でも3回言いました。
　
●ChaNさんも普通に内蔵プルアップやってるけど？何適当言ってるの？
➡貴殿はChaN師にあらず、わらは(私)と同じ技至らぬ者なり！
　至らぬ技量ならばなおこそSDA心得を紐解き精進すべし！
　(若先生風に)
　
　ChaNさんは確かに内部プルアップでSDカードを動かしてる作例が
　ありますが…例えばavrつかったgpsロガーとかですね…
　リンク先画像見てください。こんな細かい最短配線真似できますか？
　サブ�促�ーダーの配線距離ですよ…。こういうことやるのが大前提で
　内蔵プルアップでも成り立ってるのです。
　ねむいさんは逆立ちしても絶対真似できませんしそもそも5年前に目の
　手術したらそんな年になってないのにマッハで老眼加速してゲタ基板作る
　だけでも死にそうになってましたし右手プルプル病でいつもハンダ
　コテ握るきき手が常に震えてる状態です(👈これは登山始めたころから)。

　そんな状態でも1005サイズの抵抗までならハンダ付けできてますので
　横着しないでちゃんと外付け抵抗でプルアップしてくださいね☆
　ねむいさんもがんばるから☆

●いわれた通りプルアップしたら起動モード変わっちゃう奴があるんですが？
➡そ…そんな罠みたいな欠陥品…

　　捨ててしまぇえぇええええっ！

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ですがかわっち様が公開しているまとめ教材を利用させていただきました
マジでありがとうございます…！

Go to top of page