STM32F7を使ってみる18 -CubeF7がv1.7.0になった(ついでにCubeF4も上がった)-

当らないミサイルやGWが日本に迫る中、STマイクロがリリースしている統合ファーム
ウエアパッケージ群のCubeF7
がアップデートしV1.7.0になりました。
ややこしいですがCubeF7中のHALライブラリ本体は1.2.1(CubeF7v1.6.1時)から1.2.2
へとバージョンアップしています。


変更点はCANのライブラリのバグが修正されたことくらいで前回私が指摘していた
幾つかのSDMMC関連ライブラリに関するバグの致命的な部分はそれより前のCubeF7v1.6.1で
修正されていますがまだバグが残ったままとなっています。
でもねむいさんはCubeF7v1.6.1v1.5.0をベースに最新の奴にアジャストしてるので何も影響あり
ませんけどー!!!

ちなみにCubeF4とかの他の品種もアップデートしているようですがHP上で数字だけ
変わっても変更直後はまだ従来の奴だったりする罠がありますのですぐに落とそう
とせず一日ほど待ってからの方がよいです。
ねむいさんは新しモノ好きなのでよくSTマイクロの罠に引っかかるたちです。
この件は昔からフォーラムでたびたび指摘されていますが今に至るまで真剣に対処
されず連携の取れて無さが見て取れるようでちょっと悲しいです。


ちなみに私は現在もDropboxの画像表示できなくなった問題にひたすら対処して
いる段階なのでマイコンその他のアイテムに関する深い解説記事が取れずお預け
状態となっておりますがおきぱのプロジェクトファイルの更新はライブラリの
アップデートとともに月一ペースで更新しておりますのでよろしくお願いします。
今月もちょっと早いですけど5/1版のいつものを更新しました。OpenOCDも新しい
のがマージされたら常に更新掛けてますのでよろしくお願いします。


やる気を保つために次回更新予定のネタを少しお見せします。
OpenOCDのSTM32L0への対応が漸く使い物になるレベルになったので解説を絡めながら
Discovery基板を動かしていく予定です☆

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

そんなこんなで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はねむいさんが品質管理の証拠写真取る際やトレランで大活躍のでぢかめです!

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

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

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

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


"1."はともかく"2."と"3."については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()で総ブロック数から1を
引いた数をホストPCに送っています。

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


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

ESP-WROOM-32を使ってみる5 -ESP-WROOM-32が物故割れた!1!1!!-

ESP-WROOM-32の目次に戻る



ESP-WROOM-32はとっくに飽きてしまったのはずなのですがKimio Kosaka氏のブログ
とてもとても気になるエントリを見つけました。

以下引用

色々なタイミングでのプログラムの書込みをやっていたら…ESP32挙動不審な動作を
はじめ、” flash read err, 1000 “が出現しプログラムの書き込みにエラーが
発生するようになった。

引用終り

もう一つ、wakwak_koba氏のブログでも・・・・
以下引用
WiFi.h を include するだけで、漏れなく halt してしまう ESP32 に成り果ててしまいました(涙)
やったことは、2.2〜2.8V 付近の電圧で起動と停止を繰り返しただけ。(それぞれ数秒ずつ置いて)
電源の逆接とかハード的なミスならば自業自得で諦めますが、仕様範囲内の電圧で起動しなくなるってのはどうよ。
動作中に電圧を弄ったとは言え、Δ0.1V/秒 くらいの、超ゆっくりな操作だったのに。
(ハードな試験をしていたわけでもなく、実運用中にも起きえる程度の動作条件下で壊れた)

引用終り

やっぱりねねむいさんそう思ったんですよぅ電源がドロップして動作保障電圧の2.2V
どころか3.0V以下になると何か変な動作になるんじゃないの・・・って


両氏に共通する事象はESP-WROOM-32が意図せず不可逆変化を起こしたことに尽きます。


ESP-WROOM-32のメインチップESP32にはeFUSEと呼ばれるメモリ領域があり、ここに
MACアドレスやChipのID、さらにJTAGやSDIOの使用可・不可を設定できるように
なっています。AVRのヒューズビットやKinetisのFSEC領域のようなものですね。

これが何らかの原因(SPIフラッシュ書き込み時の急なドロップ・電源断)で不意に
書きかえれてしまうとヤバイ方向に転がってしまうのではないかと考えました。
何か電源の不安定な変化でeFUSEの秘孔を突いてしまうのではないか・・・ト・・!ピプー


Kosaka氏はESP-IDFv2(もうv2になってるのか)にあるespsecure.pyなるpythonスクリ
プトで復帰を試みました。ねむいさんもまずは健康な状態のESP-WROOM-32のeFUSEの
値を読み出しました。eFUSEの値は下のコマンドでパースされます(COM3の場合)。
ねむいさんの解説を読んでESPTOOLのパスは通しておいてください。
また、全てUARTブートモード下の操作となります。
espefuse.py --port COM3 summary


まだ健全なモジュールなので全部ゼロになってますね〜
Flash encryption mode counter の値は0です。


さて、ここからESP-WROOM-32を潰しにかかります!!
基本のLチカのプログラムを書き込んでる最中に給電元のUSBのケーブルごと引っこ
抜いて
書き込みを故意に失敗させまくります。
この時は上記のようなエラーになります。昔はPCごとお堕ちてたもんだ〜。


ちがう・・・これじゃない・・・
強化した電源ラインが仇になったのかなかなか事象が再現しません・・・
試行すること2時間と20分・・・


―――――――――!
秘孔突いた!テーレッテー
(flash read err, 1000)ってメッセージで無限ループしてます。
(実際はhaltがかかってその後ウオッチドッグリセットで無限ループにみえる)
たしかにSPI-ROMの書き換えが出来ないです・・・
20170220追:
Kosaka氏と同じエラーメッセージ出てますが氏の元で発生した不具合は
ねむいさんとこと違ってSPI-ROM完全破壊状態のようです…☠
そんな故障モードもあるのか…
20170220追:

20170521追:
Facebookで私の記事に対し「eFUSEのプロテクト外したから化けたんじゃね?」という
指摘がありましたが私は何も触ってないまっさらの状態で試しこの現象を
確認しました。SPIROMの書き込み動作中の電源断で何故eFUSEが化けたかは深いところ
まで調査を詰めてないので保障は出来ませんが中途半端に低い電源電圧がその原因の
一つにあることは間違いないです。

逆に言うと電源さえしっかりしてたらeFUSEが化ける確率をゼロに近い値まで大幅に
引き下げる事が出来るのですが・・・・
ねむいさんが何故ADP3338選んだかを無視して「***さん(←何故か別の人)お勧めの
ADP3338とか値段高いから中華通販で買った1117系のLDO使いました(^^)
高価なLDO使わなくても大丈夫だと"思います"」とか言う人まで出る始末でちょっと
頭痛がしてきましたがなんというかmgo-tecさんのブログで私がコメントした通りの
展開になってきてますがまぁ売り物作るわけじゃないから自己責任の範囲で当人が
満足すればそれでいいんじゃないかな〜と思います♨
尤も本当に困って私に泣き付いたときにはESP8266の時も遭遇しましたが私は
何聞かれても「馬鹿野郎」としか返答しませんのであしからず。
ていうかこのwifiモジュール関連はどうもいつもと違う客層のあんまし素性がよろしくない
山師みたいな輩ばっかり寄ってくるので以後はご意見無用といきたいところです☠
20170521追:


ここで落ち着いて復活の呪文を唱えます
espefuse.py --port COM3 burn_efuse FLASH_CRYPT_CNT


Flash encryption mode counter の値は1→3になりました。


makeの際にsdkconfigのsecure boot configurationの項目でdisable encryptionに
なってることをしっかり確認してビルドしなおします。



やった!書けた!もちろんLEDは再び点滅をするようになりました。
無事復帰しました・・・



・・・といいたいところですがこの復帰動作は何度も出来るわけではなく制限があり、
Flash encryption mode counter の値が7の状態でもう一度復活の呪文をとなえたら
秘孔が炸裂して"Bricked(ひでぶ)"してしまいます。お前はもう死んでいる

ねむいさんの英語力は中学生レベルですのでかなり怪しいですが原文を読む限りは
復活の呪文を3回となえたら4度目はない
と思ったほうがよいですね。

公式のgithubESP32のForumでも話が持ち上がっていますが結構な確率で意図せずに
この状態に入ってしまうのでしょうか???ねむいさんも"電ぶち"で再現させまし
たがこれ貧弱な電源使って書いた貼ったしてると秘孔突き捲ってしまうのでは・・・
とくにVCCが2V付近でうろちょろするような状態がかなりやばそうです。
・・・
でもまぁいっか!あと半年くらい待てば安定するでしょう・・・
それまでSTM32F7で遊びますよぅ!








新しい事が分かったらちゃんと追記修正していきますか怒らないで〜♥

Go to top of page