ねむいさんのぶろぐ

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

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度目はないと思ったほうがよいですね。

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








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

• 2017.02.18 Saturday
• 00:28
• ネムイ・トリノミアス
• Wirelessなアレ
• comments(2)
• -