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完全破壊状態のようです…☠
そんな故障モードもあるのか…


ここで落ち着いて復活の呪文を唱えます
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で遊びますよぅ!








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

STM32F7を使ってみる15 -工業用SDカードからSMART情報をスマートに読み出そう-

あれ?ESP-WROOM-32が秋月から発売されて絶好のチャンスなのにESP-WROOM-32の
記事書かないのですって?
あああれね…去年の時点で飽きました・・・今更になって弄ってるとか時代遅れですよぅ!(挑発


今回はS.M.A.R.T.(以下SMARTと記)対応のSDカードからSMART情報を読み出してみます。
別にF7じゃなくてもよいのですけど次回以降のネタに繋がる内容なのでしばし御静観願います。
今回もSTM32F746G-Discoveryを使います

工業用のSDカードの中にはSSDやHDDのようにSMARTの情報が取れる希有なものが存在
しております。残念ながら一般に購入出来る民生向けSDカードではそのような機能は
搭載されておらず、SMART対応どころか工業用SDカードも入手がごく限られております。
もちろん値段も民生品に比べ極めて高価です。

なんで高価かと言うとカードの動作に関する"信頼性"を保証しているからにつきます。
皆さんご存知の通り2017年現在市販で流通しているSDカードは明記が無い限りはTLC
タイプのNANDフラッシュメモリが使用されており、TLCというのはSLCやMLCに比べて
大容量が取れる割にデータ保持のための寿命が短い、また書き換えできる回数も極端に
短いという代物となっております。

一方工業用SDカードは4GB以下はSLC,それ以上の容量でもMLCを保証しており(容量を
犠牲にして疑似的にSLC風の動作をするpSLCやaMLCなんで奴もありますが) さらにSDカ
ード内コントローラのファームウェアもデータ保護に特化した特別となっております。
たとえばECCチェック機能とかパワーダウンプロテクションとかオートリフレッシュ機能
とかバッドブロックマネージメント、ダイナミック+スタティックウエアレベリング等々
いろいろありますが、実はこれTLCカードを世に出すために必須の技術でそれが耐久性が
もともと高いSLCやMLCを使用した工業用製品にフィードバックされて最強に強まった
信頼性を謳うわけです。

というわけでこれらの機能実装は最早当たり前となった今、カードの健康情報を
把握するための機構を仕込む事が新たな付加価値として注目されており、各社で
SMARTもしくは独自の寿命診断を組み込んだ工業用SDカードが販売されております。


で、われわれホビイストが問題となるのはその工業用SDカードの入手から始まりさらに
SMART情報を取得するための"情報"を入手し利用せしめるまでに多くの壁がある
ことです!

まずDigikeyやmouser,RSの海外在庫くらいからしか工業用カードの入手法が日本
国内からではまず困難で、さらにSMART対応と謳っていてもカタログの隅っこに(※オプシ
ョン対応)とか書いてあったりして高い金出して購入したのに目当てのSMART機能が
実は搭載されてなかったとか悲惨なことがほとんどです。

それでやっと入手にこぎつけたとしてもSMART情報を取得するための手段やツールは
公開されておらずメーカに直接問い合わせることになりますがほとんどの場合対企業間
の問い合わせにしか対応してなかったり(もちろん個人事業主として問い合わせても
THE・シカト)、SDAのライセンスに加入していないと情報を渡すことができないよなど
つっけんどんの反応しかもらえません。

ねむいさんも方々に手を尽くしましたが個人レベルではなしのつぶてて困り果てていまし
たが灯台下暗し、DELKINというメーカの工業用SDカードを扱っている代理店が日本
国内に存在しておりました
。こちらは在庫があれば一枚から対応(無ければ受注生産
20枚単位)というホビイストにもうれしい対応でしたので早速1GB品を注文し、ゲッツ
しました。



でかいDELKIN箱に小さいMicroSDが対照的です。


今となっては微々たる容量の1GB、見た目も普通のMicroSDカードですが…
このDELKINのU331というシリーズは中身は某粉飾決算にチャレンジしたおかげで
倒産寸前の日本メーカのSLC型NANDフラッシュが使用されております!
なにルネサスより先に死んでんだよ東芝!!11!11!!1!!!!!!
動作温度範囲もやたらと広くて-40~+85度まで保証しております。

ひとまずUSB接続のカードリーダーに接続してパフォーマンスを見てみました

規格的には"2GB以下のSDSC"に位置するカードなのでUHS-1とかには対応しておらず
理論上最大でも25MB/Secの転送スピードとなりますがマイコンで使用する限りでは
ハイスピードモード(最大SCLK=50MHz)に対応さえしてれば全く問題ないです。


SMART情報をPC経由で取得するために"USBカードリーダ"を用いて"DELKIN DashBoard"
なるアプリケーションを使用する必要があります。
ねむいさんの持っているTranscend製のUSB3.0カードリーダーは無事にSMART情報を
読み出すことができました。やったぜ!
どういう理屈でSMART読み出してるかしらないけど(伏線)

ちなみに"DELKIN DashBoard"の動作保証しているDELKIN製カードリーダーは上記の
ねむいさんのもってるTranscendのとまったく同じチップが使用されております。



お次はSTM32を使って動作させてみます。

FatFs module test terminal for STM32F427IIT6
LFN Enabled, Code page: 932
AppVersion : W.I.P
Build Date : Dec 6 2016
>fg piano
rc=0 FR_OK
>fo 1 ftbt.mp3
rc=0 FR_OK
>fr 132949600
132949600 bytes read with 14338 kB/sec.
>ds 0
rc=0
Drive size: 1947648 sectors
Erase block size: 8192 sectors
Default r/w block size: 512 bytes
Card type: SDv2(Byte)
SpeedMode: HighSpeedMode(51.43MHz)
DataBusWidth: 4bit

CSD:
00000000 00 5E 00 32 5B 59 A3 B6 FF FF FF 80 0A 40 00 6D .^.2[Y.......@.m
CID:
00000000 58 44 44 44 44 49 4E 43 30 6D 6D D4 59 01 0C 49 XDDDDINC0mm.Y..I

Parsing SD CID Register
Manufacturer ID :0x58
OEM/Application ID :DD
Product Name :DDINC
Product HwRev :3
Product SwRev :0
Serial Number :0x6D6DD459
DateCode.Month :12
DateCode.Year :2016

OCR:
00000000 80 FF 80 00 ....
SD Status:
00000000 80 00 00 00 00 00 00 28 03 03 90 02 00 AB 00 00 .......(........
00000010 00 00 00 00 00 00 00 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 25 80 00 01 00 00 00 .%......

Parsing SCR
SD Spec Version :2
SD Spec Version 3 :1
SD Spec Version 4 :0
SD Spec Version X :0
SD Security :2
SD Bus Width :5

SD_Spec V3.0x!
Detected as SDSC Card!
Available NS(or HS) Mode Only.
>

先ずはいつものでSDカードの情報を読み出してみました(これだけSTM32F429を使用)
2016年製!
ATPの工業用カードでもそうでしたが現在はW/R性能はSDカード内コントローラの
ファーム次第なのでSLCとはいえ転送速度がめちゃくちゃ早いとは言えません。
どちらかと言うとSLCを使う理由は速さよりもデータの確実性を求める方向に概念が
遷移していると感じます。


そしてついにSTM32F7-Discoveryを使いSMART情報の読み出しに掛かります!
このDELKINのカードはSDカードに昔から存在するCMD56という"汎用コマンド"を用い
てSMART情報の取得を行います。SMART情報を取得する方法は各社バラッバラで門外
不出の所もありますがDELKINは"CMD56でSMART採れるYO!"と公言しているためかなり
フレンドリーと感じます。

この"CMD56"は引数によってデータの受信送信を変えることができるコマンドでCMD17等の
シングルブロック転送と同様最小512Byte単位でやり取りをおこないます。
DELKINカードにおいては特別な引数で、ある一定の順番で、CMD56の送受信動作を
行うことにより目的とするSMARTの情報を得ることができました。





DelkinDashboardとCMD56で読みだしたSMART直値をUARTに吐かせて値の
比較です。カードに何らかの書き込み動作を行うと電源再投入時にDashboardの
"TotalPowerupCount"に相当するSMART直値が更新されているので正しく
SMARTが読めていると判断しました。
ところで具体的にどうやってCMD56投げたのと知りたい方がいると思いますが対価を
払って得た情報ゆえこのぶろぐ上で詳しく公表できませんが…
…おや?このデータシートDELKINと関係ないのになんだかそっくりだー(棒読み


詳しくは言えませんが512バイト分のSMART情報のフッタに相当する部分のデータが
CIDの情報と一致しておりました。何かのvalidationに使うのでしょうか(棒読み
まぁあまり重要な情報ではないでしょう(伏線




このDELKINカードを選んだ理由は拙作のSTM32Primer2を使ったGNSSロガー
信頼性向上につきます。一度Primer2の筐体中に組み込んでしまうと構造上
ケースの中にカードが封印されてしまうため簡単に取り出せなくなるのでSDカードの
寿命診断を何らかの形で外部から行いたいと思いSMARTが取れるカードを選んだ…
と言う経緯です。
次回のちょっとネタバレになりますがこのGNSSTrackerのマスストレージモードでも
DelkinDashboardを使いSMARTの取得に成功しています。
なんでCMD56発行してないのにSMART採れるんでしょうね(意味深


願わくばSMARTを利用した寿命診断機能がSDAで正式に規格化され、民生用の
SDカードでも気軽に寿命診断できる素敵な時代が来るようになることを願います。

だからSDAの中の人のPanasonicさん頼みますよ!
なぜか不自然なくらいパナ推しのねむいさん。






ここでねむいさんFAQ特別編
Q:ねむいさんねむいさん、確実にSLCのカードを見極める方法を教えてくださいっ!
A:
 SLCってカードにでかでかと書いてあるカード選べばOKです☆

OpenOCD小ネタ20 - V0.10.0正式リリースされる -

一年前、V0.9.0の次はついにV1.0.0かと思っておりましたが残念ながらV0.10.0に
バージョンアップしていまい、まるで5,4,3,2,1とカウントダウンしたあとに0.9,0.8,0.7
・・・・と続きドリフのコントみたいな展開になっていましたが先日にその
V0.10.0がようやく正式リリースとなりました

今回バージョンアップについて、私の貢献は以下の黄色で囲った部分となります。

NuvotonのNumicroというCortex-M0マイコンの同じドライバが二つもあったので、
それを統合しパワーアップさせました
それとごく一部だけですがKinetisKEシリーズのサポートの面倒も見ました。
私のOpenOCDバイナリにはKEシリーズ書き込み用のスペシャルcfgファイルがあり
ますので(kexx_swd_flash.cfg)ご利用ください★
KinetisKEはOpenOCD対応時の評価用にFRDM板を入手しているので何かの機会に
ご紹介できたらと思います。

その他目立った変更点はJ-Link操作用のライブラリ"libjaylink"がOpenOCDの中に
スタティックに取り込まれたことです。このlib"jay"については昨年からねむいさん
含めたJ-Linkマニアの有志がびしばし改良を重ねておりますが最初はdllの形にて
OpenOCDから呼び出す形式を取っておりましたがOpenOCDとは切っても切り離せ
ない関係のためとうとう内部ライブラリとしてJimTCLと同じように統合される運びと
なりました(オプションで従来通りのDLL化も可能)。
これもいずれは解説記事を書きたいと思います。

あと2015年初頭あたりから目立ってきましたが・・・gerritの使い方が分からなかったり
英文の意志疎通ができないのか私にパッチの提出を代理でしてほしいという不届き
な方の不届きな一方的な連絡を受けることがありちょっと困ってます。
OpenOCDが各種IDEに組み込まれたからでしょうか少しはソース弄れる方が日本人の
間でも徐々に増えてきてるのはうれしいのはやまやまですが…申し訳ありませんが
そういう不届きな方から頂いたパッチはうっかりねむいさんの手柄として提出させて
いただきますので覚悟して下さいね(いやらしい口元で)
んなもん自分でヤレコノヤロなんて心の綺麗なねむいさんは絶対に言えないものでウフフ♥


話は変わりますがこの一年でARMマイコンの情勢も大きく変わりました。FreeScaleが
NxPに喰われ、さらにそのNxPもQualcommに喰われる事態となりダイアログセミコンダ
クターがAtmelを喰うと思ったらなんとPICでおなじみMicroChipがAtmelを食う事態と
なってしまいました!とどめにARMそのものが禿に喰われてもはや上を下への大騒ぎです。

そんなわけで私のぶろぐのエントリメニューがちょっと変わったのにお気づきの
方もいると思いますがブログ記事も時勢に合わせてなるべく最新の状態に保とうと
努力は続けております。昔の記事も手を加えております。

その一方で企業が統合してもマイコンの特性はてんでバラバラなので私が配布して
いるOpenOCDバイナリ付属のすぺしゃるコンフィグファイルにつきましては従来と
同じような感覚で使用できるように整備を続けていく方針です。

V0.11.0以降の私の方針ですが基本的には他の人の提出したぱっちの評価に専念
しますが、新規品種のマイコンのフラッシュドライバを実装できる機会があれば
すぐにでも対応したいと考えております。

以上長々と前置きが長くなりましたが、OpenOCDのWindowsバイナリは逐次更新
してまいりますのでばしばし使ってください!

STM32F7を使ってみる14 -HS ULPIでUSB-MSCを使ってみる-

みなさまあけましておめでとうございます

今年もねむいさんほか虹裏メイドたちをごひいきにm( )m
今年はねむいさんのイラストが100枚くらい増えますように
↑本音




さて新年早々ですがHALライブラリにバグを見つけたので解説しようと思います。

遡る事約一ヶ月前、ねむいさんはSTM32F7で新しい事をやろうとCubeF7に同梱されて
いるUSBライブラリとそのExamplesたちに手をつけ始めていました。
STM32F746G-DiscoveryにはULPIとかついているのでUSB-MSC(MassStorageClass)の
実装を試みました。もちろんUSBのバス速度はHighSpeed(480Mbps)です。

幸いにもSTM32F746G-Discovery向けのサンプルコードもあったのでそれをねむいさん
謹製のいつものをベースに実装しようとしましたがUSBライブラリがDMA使ってるくせに
キャッシュの事全然考えてない作りでそれにブチ切れながらGCC向けに移植していまし
たが最終的にL1キャッシュがないと足を引っ張るSRAM1,SRAM2を使わずにノーウエイト
でアクセス出来るDTCM領域だけでがんばることにしました・・・orz

Ac6STM32用のプロジェクトファイルのリンカスクリプトもそうなってますし・・・フォーラムでも
奇跡の積み重ねで動いてると情けない指摘をされています。
HALライブラリみたいなバグだらけの変なものリリースしっ放しにしてないできっちり
バグつぶせYO!←って言ったらたくさん非難されていっぱい哀しい…


と言いつつも何とか動いて認識しました♥


もちろんeMMCとかもしっかり認識しちゃいます★


とおもったらまだ問題がありました…幾つかのカードでデータが正常に読み込めない
事がありました。


64GBのカードでも容量はしっかり見えてるんですけどね…なんか4GB以上データを詰め
てるカードで動作がへんなのです…

…4GB…?これって…

かつてUSB付きのARMマイコンでMSCのサンプルではカード容量を示す変数が
uint32_tで現わされていて4GB以上の容量を正しく表示できないという4GB問題が
ありました。対策は単純に容量を示す変数をuint32_tからuint64_tへ変えるだけの
ものなのですがUSBライブラリを見る限りではそれはちゃんと64ビット変数に
なっており問題がありませんでした。


しかしブロックアドレスにブロック容量を掛け算し代入してやがる式を見つけました。
指定するブロックアドレスによってはuint32_tで扱える範囲を超えてしまう可能性
があります。このscsi_blk_addrって奴なのですがまさか…まさか…


デデーン

思いっきりuint32_tじゃん…

ば っ か じ ゃ ね ぇ の ! ?
ねむいさんのむなしい叫び越えが夜の闇にこだまする。


ていうわけでscsi_blk_addrをuint64_t化すると4GB以上データ詰めている奴でも正常に
読み書きすることができるようになりました…なんちゅう初歩的な。

一応フォーラムにも報告しておきましたがSTM32フォーラムのguruとも呼ばれている
clive師より「ブロックアドレスをいれた変数にバイトアドレスに変換した値を放り
込むSTの昔っからのコーディング姿勢自体が愚。scsi_blk_addrの安易な64bit化は
不必要」と指摘されましたがねむいさんもごもっともだと思いました。



そんなわけで漸く正常に繋がるようになったので読み込み比較です。今回はUSBの
転送用に確保していると思われるバッファの容量を増やすことで転送スピードが
どこまで変わるか見てみました。


条件STM32F746G-Diacovery,USB-HS ULPI,最適化オプションは"-s"
132MBのmp3ファイルをFastcopyを使ってPCのRAMDISKへコピーする時の平均転送速度を記録。
SDのクロックはNS(24MHz)とHS(48MHz)で比較。


ある程度分かっていたことですがやはり容量を増やしていくと転送スピードは上がっ
ていきましたがある程度(16kb以上)以上で転送スピードは横ばいになることが分
かりました。これはNSとHSもほぼ同様の傾向なので16384byte以上パケット容量確保
してもそれ以上は余り効果がないことが分かります。まぁこれだけ速度出せたら御の
字でしょう。とにかく16384byte分確保しておけば何の問題もないですね。


ちなみに今回はお仕着せEclipse環境のAC6STM32で一旦プロジェクトをビルドして
ねむいさん環境に移植しましたが(単にリンカスクリプトをDTCMしか使わないように
しただけですけど)もっと性能の高いF769I-Discoveryで何で試さなかったの?と言う
話になるでしょうけど理由が…


CPUが対応してない・・・このせいでボード対応しててもビルドが通らないorz



やっぱ自分でmakefile書いてコマンドラインビルドが最強ですって☆

Go to top of page