STM32F7を使ってみる17 -とっくの昔ですがCubeF7がv1.6.0になっていた-

前回少しだけ触れましたが、STM32F7向けのHALライブラリCubeF7のバージョンが
v1.5.0(CubeMXの場合v1.5.1)からv1.6.0に上がっておりました。

主な変更点はARMv8系コアのSTM32F7x2・7x3シリーズのレジスタ定義が追加された
事と、SDMMCドライバの大変更、さらに悲願のマルチメディアカード&eMMCサポート
の追加です。

eMMCのサポートはねむいさんも歓迎すべき事柄なのですがソースコードを読み解くと
その期待は完全に裏切られました☠なぜなら…

１.初期化シーケンスさえしっかり記述したら同一のソースコードで読み書きできる
　　はずなのになぜかSDカードとMMCのソースコードがわざわざ分離されている。
　　(↑まじふぁっく)

２."１."のおかげでSDカードとMMCが同時に使用できない。
　　(↑まじふぁっく)

３．MMCの処理中でMMCv4以降のカードで必須のExtCSDレジスタを取得していない
　　ため4GB以上のeMMCが全く使用不可能。昨今のeMMCは最低8GBからなので全く
　　無意味。
　　(↑まじふぁっく)

４．DMA転送のコードが適当で使い物にならずデフォのポーリング版しかまともに
　　動作しない。v1.5.0の時は私が手を加えなくともある程度まともに動いていた。
　　(↑まじふぁっく)

５．SD/MMCとも両規格で指定されている電源投入->動作電圧到達後1mSec待ちその
　　後74クロック空撃ちする処理が無くたまにイニシャライズすら失敗するカードが
　　出る。eMMCは一部カードでbootシーケンスの際に74クロックが必須。
　　(↑まじふぁっく)

６．まともなはずのポーリング版でも一見動いてるように見えるけどランダムで
　　ReadもWriteもエラー発生するのが判明orz v1.5.0に戻すと全く問題なし。
　　(↑馬鹿野郎)

私を含め外人さんたちも憤慨していますが最終的にねむいさんのコードで動いたYO!
とのことで胸をなでおろしております。
CubeF7とは関係ないですがこちらの方は歓喜の絶叫を上げております。


ねむいさんはChaN師の｢xxの上手な使い方はxxを使わないことである｣と言う
格言に倣いCubeF7v1.6.0にv1.5.0のSDカードのドライバ(ややこしいですがHALライ
ブラリ自身のバージョンはv1.2.0)を無理やり移植してやりましたよｵﾗｰ！

無理糞移植なものでねむいさんの環境以外で使用するには多少コツが要ります。
１．"stm32f7xx_hal_conf.h"内の"#define HAL_SD_MODULE_ENABLED"をコメント
　　アウトし"#define HAL_MMC_MODULE_ENABLED"を有効にする。

２．ねむいさん謹製の無理糞ドライバ"sdmmc_stm32f7.c"をプロジェクト/makefile
　　のビルド対象にする。

３．"diskio.c","ff_gen_drv.c"はv1.5.0の物を流用する。

４．内部変数はDTCMからとるようにリンカ/スキャッタファイルを設定しておく。
　　(アライメントずれとデータキャッシュ不整合対策です)


"１．"で何故本来は不必要なはずの"#define HAL_MMC_MODULE_ENABLED"を
有効にしているかと言うと、これを有効にしておかないとstm32f7xx_ll_sdmmc.c
で必要なローレベルの関数がビルドされずエラーになるからですファッ●ク！
ちなみに"#define HAL_MMC_MODULE_ENABLED"と"#define HAL_SD_MODULE_ENABLED"
を両方とも有効にしていると定義がぶつかって
またまたビルドエラーになりますフ●ァック！１１！！１

そんなこんなでCubeF7v1.6.0でも安定してFatFsが動作するようになっております。
FatFs0.12cの最新パッチやCMSISv5の最新版ヘッダフィルを適用した4月版のソース
コードも先行ですがアップしておりますのでどしどしご利用ください。


一方でむぎたさんは私のドライバを既に試されており残念ながら上手く動作できな
かったとのことですがv1.5.0時代のコードでも大幅にSDMMCのクロック周波数を落と
さないと駄目とのことでSDMMCの各信号波形そのものが変になってる
可能性があります。

いわゆるインピーダンスミスマッチ状態で各信号の波形に相当なリンギングが発生
している事が考えられますのでオシロで波形を確認したのちインピーダンス整合用の
直列抵抗(最大47Ω)をSDMMC_CKの出力端(MCUの端子直近に)挿入する、それでも駄目
ならさらに全信号ラインにフェライトビードを挿入する等の措置でクロック周波数を
落とさずに改善できるはずです。そこまでやっても駄目なら配線の引き回し自体に
根本的な問題があるのでmicronのeMMC使用時の設計ルールを参照して基板のレイ
アウト設計から見直す必要があります。

RTOSを絡めて使用されている場合はDMA転送用のメモリ領域がDTCMに割り当てられて
おらずキャッシュの整合性が崩れてこけている可能性もあるため切り分けのために
まずはDMA版ではなくポーリング版で動作確認してみてください。

STM32F7を使ってみる16 -USB-MSCを使ってみる応用編-

前回はSTM32F7のSDMMCインターフェースを用いてDELKINの工業用SDカード
からSMARTの情報をCMD56コマンドを駆使し読み出す事に成功しました。

その前にUSBカードリーダーに直接DELKINのカードを接続した時はDelkinDashboard
なるWindowsアプリを用いるとSMART値を読み出す事が出来るのを確認しています。
そこで今回はUSB接続のカードリーダーに化ける奴でDashboardが使えるかどうか、
いくつか試してみました☆

1．OLYMPUS STYLUS TG-4
　->SMART読み出しOK!
　
　TG-4はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです！

２．STM32Primer2 GNSS Tracker(のUSB-MSCモード)
　
　->SMART読み出しOK!!

いわずと知れたSTM32Primer2を用いたねむいさんのぶろぐ唯一の実用品です。
2009年から今に至るまで8年間、-10度〜+40度の過酷な環境を耐え抜き延べ3000km
以上の山道をねむいさんと共に駆け抜けてきたすごい奴です！

３．STM32F746G-Discovery(のUSB-MSC(HighSpeed))
　
　->SMART読み出しOK!!

とりあえずSDカードが読めるUSBカードリーダー(USBマスストレージクラス)なら
何でもいけるような気がしてきましたよぅ･･･


"１．"はともかく"２．"と"３．"についてはUSB-MSCに明示的にCMD56を発行する
ようなルーチンは実装していなかったのでこれはつまりCMD56を用いなくても何か
別の方法でSMARTを読み出せられる手段があるのではないかと考えました。


そこでSTM32F746G-Discoveryを使って何が起こってるか解析してみる事にしました。
USB-MSCのSCSIコマンドを解釈するサブルーチンとSDMMCのRead/WriteにPrintfの
トラップを仕掛けどのSCSIコマンドが発行されているか、またSDカードのどの
アドレスに読み書きを行っているのかを調べます。ファームウェアを柔軟に弄る
事が出来るという市販のUSBカードリーダーでは絶対に出来ない利点がSTM32F7には
あるのです！！



STM32F746G-DiscoveryのSTLinkV2の仮想COMを開いて待機しておいた上で
Dashboardの"GO"ボタンを押すと全てが分かってしまった･･･

諸般の事情で細かい解説は省きますがある一定の順序でSDカードの特定の
ブロックアドレス群に読み書きを行う事によりCMD56による取得方法と同じ
SMART情報を得られることがわかりました･･･！

これなら特別なハードウエアを用意しなくても市販のUSBカードリーダーさえあれば
気軽にSMARTとかSDカードの寿命を確認できますね〜！
それを組み込んだこいつも更なる進化を遂げてさらに最強に強まることが出来たので
ねむいさんはこれからの近畿自然歩道の攻略に向けて燃えに燃えています！
20170308追:
このような工業用SDカードの寿命診断についてですが実際は頻繁なカードの
取り外しが困難な場所や機器に特に威力を発揮します。
性悪説的に言うとケーシングや樹脂化でSDカードを完全に隠ぺいし第三者から
"SDカードを使用している機器"と分からなくして"何らかのメモリデバイス"と
して見せることにより商売上でSDAのライセンス条件を完全に逃れている場合の
リモートメンテナンスの際にも役立ちます。
正攻法でもCMD56なりUSB-MSC経由でSMART取ればいいので品質管理の面から見て
仕事が進めやすくなるのでメリットだらけですね〜♥
20170308追:

でぢかめ向けには大容量品があるUtility+がよさそうですね。これも上記と同じくCMD56&
Windowsツール経由でSMART取れるので特にカードの寿命や動作環境を気にする
プロの人必須のアイテムだと思います。ねむいさんもお金に余裕が出来たら購入して
TG-4と併せて使った感想をレポートしてみたいと思います。


ちなみに民生品のSMART非対応のカードだと失敗しちゃいます。
TDKやApercer配布のSMART取得ツールだと非対応のカード使うと先頭1kb分のデータが
問答無用で破壊されてしまうのですがDelkinDashboardではそういうことはまったく
ありませんが興味本位で非対応のカードで試すのはやめておきましょう！！
とまぁこんなかんじで各メーカごとにSMARTの仕様がバラバラなのでSDAが早く統一
規格作るべきだと思いますよぅ。




さらにおまけですが･･･
解析途中でDELKINカードのパーティションの全容量と実容量が一致してなくてディスク
ユティリティーソフトが異常を検出してておかしいなと思っていたのですが･･･


STM32F7CubeのSDカードドライバ(v1.5.xまで)はSDHCにしか対応してなかったため
SDv1の初期化コマンドすらなかったのは周知のとおりですがUSB-MSCのサンプルも
その仕様を引きずっていたため正しい全容量を返していないのが分かりました。
20170329追:
SDv1どころかSDv2でも正しい全容量を返していないことが分かりました。
別な部分で一番最後の論理ブロックアドレスを示すよう-1している個所があり、
上記の部分で-1してしまうと余分に-1したことになるので実容量より1ブロック
分小さい値が返されてしまいます(ほとんどの場合は512Byte小さい値)。

具体的にはusbd_msc_scsi.cのSCSI_ReadFormatCapacity()で総ブロック数から１を
引いた数をホストPCに送っています。

一方SDHC/SDXC等の大容量のSDカードなら多少の容量の相違は無視できる
ほど小さいので問題はありませんでしたが、Delkinカードは1GBしかないため
ParagonHardDiskManagerではそれを見逃さず無効なパーティションと
見なしたようです。ちなみに値が微妙にずれた状態でもWin7からは普通に
読み書きできてました。
SDナビさん曰く、この値が容量偽装とかでズレが大幅になるとWindowsも
おかしいと検知してフォーマットを促すダイアログが出るようです。
20170329追:


そういえば今年になってv1.6.0が出てSDカード周りが刷新されたのですが待望のMMCが
追加されたのはｲｲのですがなんかいたるところが欠陥だらけで超やばいことになって
いたのですが話が長くなるので次回に続きます･･･

Go to top of page