ESP-WROOM-02を使ってみる3 -そんな電源で大丈夫か-

20161231追:
ESP-WROOM-32ではさらにとんでもない自体に！！１！！！
20161231追:


2か月くらい前にESP-WROOM-02の紹介記事を2点書きました。それを多くの方が
紹介してくださったおかげで閑古鳥が鳴いていたこのぶろぐのアクセスも東海自然
歩道攻略時のころの全盛期まで盛り返し私もモチベもﾑｸﾑｸ盛り返しております♥

多くの人の目に触れるとなると当然質問も多く頂くのですが｢電源投入しても
文字列がずっと垂れ流されるだけでコマンドが全く反応しないor最初は上手く
動いてたのに急にずっと文字列(orゴミデータ)が垂れ流しになった！ESP8266が
壊れたぞ！｣という不具合についての相談を多く受けるようになりました。

●文字列がﾀﾞｰｯっと…
共通項は｢文字列(orゴミデータ)が連続して垂れ流されて制御不能になる｣です。
結論から言うとESP-WROOM-02に供給する+3.3Vの電流容量不足で起こる現象
なのですが、そのプロセスは以下のようになります。

1．電源投入or外部リセット
↓
2.ESP8266のPOR/外部リセットのイニシャライズ
　(このあたりで文字列(デバッグメッセージ)が吐かれる模様)
↓
3.電気喰いのRF部起動
↓
4.電力消費過多で3.3Vがすぐドロップ
↓
5.3.3Vラインがドロップして2.0V付近になるとESP8266リセット状態になる
↓
6.少したってからLDOの保護機能等が解除で3.3V回復
↓
7."2."に戻る

デバッグメッセージがﾀﾞｰと吐かれた直後にリセット掛かってまたデバッグメッセージが…
を繰り返すので"文字列が吐かれ続けて壊れた"ように見えるわけです。


↑
ねむいさん愛用の秋月さんのXbee用のゲタ基板は150mAのLDOが乗っかっています
がESP8266の電源としてこれを使っていると上記のように2.0V近くまでおもいくそ
ドロップしてリセット->その後負荷が軽くなるので回復->また落ちるを繰り返して
しまいます。
根性があるLDOだと最初は最大定格越えても耐えられるのですが使ってるうちに
段々へばってきて上のサイクルを繰り返し、仕舞にEOSで完全に死んでしまいます。


↑
そんなわけでねむいさんは電流容量1AのぱわふりゃーなLDOを換装して多少の
電流の過渡応答にびくともしない最強に強まった電源に満足(LT1963A持ってくる
までもありません)でした。

したはずでした･･･！






勿論今回はこれだけで終わるわけではなく、皆さんの設計の参考として実際どれ
くらいの電流を消費しているのかを調べてみました。


ねむいさんのXbeeゲタ基板に+3.3Vの電圧と電流を測定できるように加工をして
電源投入直後や投入後の挙動別に各波形を見ていきます。
各種パラメータはもちろんすべてデフォルトの購入時のままです。
ESP-EROOM-02においては購入時のデフォルトはフルパワーです。


電源投入直後


↑の+3.3Vの立ち上がり時の拡大


リセット直後


RF出力時

ぱわふりゃーなLDO使ってるくせになんで3.3Vが思いきりドロップしてんだYO!
答えろYO!という突込みは後で解説することにしてRF出力時は平均280mA(ピーク値
は350mA以上)バリバリに使いまくっているのが分かると思います。
またリセット直後も40mSecもの間200mA以上(ピーク350mA強)ゴリゴリ
消費しています。

ご覧の通り+3.3Vラインに供給する電流容量の事を忘れてESP-WROOM-02を使って
いると大きな電圧ドロップによる不安定な動作に悩まされ続けることになります。
しっかりオシロスコープ使って波形測定して確認する癖付けましょうね…。

ハードウエアの設計に慣れた人ならこんなの事前にオシロで電源ラインの波形を
観測して足回りをしっかり固めておいて当然の基本の"き"なのですが…
ねむいさんの懸念はライトユーザーの方たちがこの問題に引っかかり先に進めなく
なってしまうことです。

プロトタイピング用ボードはハードウエアの差異を隠ぺいしてソフトウエア作りに
集中できるようにするために元となるハードウエアはかなりタフに作りこまれています。
ていうかそうなるべきです。全ては信頼の元に成り立っているのです。

でも残念ながらそうなってないのばっかりですのでこれを機にしっかりオシロ
スコープ使って電圧波形くらいは確認する癖をつけましょうね…。

大事な事なので2度言いました。


macsbug氏の記事では各種Arduinoと組み合わせて使用した際の考察がまとめられて
いますのでプロトタイパーな皆様は一読されることをお勧めします。
氏のブログでは+3.3Vを作るLDOにフォーカスして言及されていますが私が以下で
述べるLDOの入力系統(主に+5V)についての考慮も極めて重要です。
必ず読んでください!!!


●USBの+5Vは大丈夫か
上で行った+3.3Vの波形がドロップしちゃいけないのにドロップしてる件も調べて
みました。私の使用環境ではUSBの+5VからLDOで落として+3.3Vを作っています。
そんなわけで今度は5Vと3.3Vの波形を比較してみました。


オイー！！！！！！！！！
安物USB2.0ハブ(しかもセルフパワーなのに)元の5Vがおもいくそへばっていたorz

ねむいさんが使ってるLDOはDIODES-ZetexのZLDO1117ですが最大ドロップアウトが
1.2V(1A時)ありますので元が3.8V近くまで落ち込むくらい電流ひいてる状態だと
そりゃ駄目ですわ…。


↑DIODES-Zetex ZLDO1117データシートより引用
さっきの波形はRF送信時の約300mA近く引いてる時の電圧ドロップの波形ですが
グラフのまんまきっかり1V以上のドロップアウトですねorz
いくらぱわふりゃーなLDO積んでいても元のVinが貧弱だとこうなってしまいます。
あとコンデンサの容量を必要以上にむやみやたらに増やして茶を濁すのはねむいさんは
全くお勧めしません。今度は突入電流で素子が破損する危険性が出ますので。


てわけで大電流を引き出せられるセルフパワーなUSB3.0ハブの方に差し直して
測り直してみました。大分マシにまりましたね。
上半身に比べて下半身が貧弱だとやっぱりダメなわけですね〜足回りをしっかり
固めるのはプロトタイピングにこそ重要だと思います。


プロトタイピング用ボードだとUSBの+5Vを電源供給源としてそのまま利用する
場面が極めて多く出てくると思います。
何も考えないで使っているとこういった罠に陥って無駄な時間を費やしてしまい
ます。これを機にオシロスコープを使って電圧波形くらいはいちいち確認して
行く癖をつけておきましょう。

大事なことなので3回言いました。

20151203追：
ねむいさん的にはバッテリ駆動を見据えるならMAXで1A~800mA位の小型高効率
降昇圧DCDCを組みESP-WROOM-02専用の+3.3V電源とすることを提案します。

逆にUSBの+5V電源からだけしか使用するつもりがないならば超低ドロップアウトな
LDOであるADP3338、値が張りますが攻守共に最強のLT1963Aを提案します。
20151203追：




●おまけ
それじゃ他のWifiモジュールってESP-EROOM-02に比べてどんだけ電気喰ってるの？
というわけで手持ちのモジュールも測定してみました。
もちろん技適はばっちり取れてるのをチョイスしてます♥

その1：Xbee WiFi S6B

電源投入直後


↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジが違うので注意。


リセット直後


RF出力時
IDDの測定レンジが違うので注意。

XbeeWifi S6Bはリセット直後にガッツリ電流もってくようですね･･･負荷の過渡応答性
にすぐれたDCDC持ってこないと製品レベルに落とし込むのは無理だと思います。
ちなみにBが付かないほうのXbeeWifiはなひたふさんですらどうにもできなかった
のでねむいさんが手なずけることは不可能です････そもそもB無し持ってませんし。


その2：GS1011MIC

電源投入直後


↑の+3.3Vの立ち上がり時の拡大
IDDの測定レンジがこれだけ違うので注意。


リセット直後


RF出力時



GS1011MICは今となっては古き世代のモジュールですが瞬間最大電流は低めに
抑えられています。Adhoc等の限定した用途ならば今でも十分に活躍できるモ
ジュールといえるでしょう。

STM32F7を使ってみる6 -タッチパネル入力とQSPIの追加-

もう気づいた方もいるかもしれませんがSTM32F7向けのいつものを9月1日版に
更新しております。
変更点は細かいバグ潰しと容量性タッチパネル入力、そしてQSPIの対応です。

●CTP(容量性タッチパネル入力)対応
STM32F7Discoveryには上記のタッチパネル付きのTFT-LCDモジュールが搭載
されています。型番でググっても出てこないのでおそらく特注品なのでしょう。
CTPコントローラにはFT5336GQQなる物が使用されております。

さて、以前はもっとも単純なADS7843系、ちょっとインテリジェンスな
機能をもつSTMPE811等の抵抗膜式のものを扱ってきました。
容量性の場合はメカニズムが全く違い複雑になるので専用ICに頼らざるを
得ないのですがそれの使い方を把握するのでもこれまた複雑で正攻法で
行くととても時間がかかってしまいます。

そんなわけでSTマイクロ提供のCubeF7ライブラリ群にはBSPとして
FT5336GQQ用のアクセス用関数がちゃんと用意されています。
しかもF7-Discovery用にI/Oの設定も御誂えております。

実装は拍子抜けするくらい容易でした。私の過去のタッチパネル入力の
処理と結合させてGPIOのエッジ割り込みの処理を追加するだけで済みました。
F7-Discoveryのデモではタッチした状態が変わらないと割り込み処理を
抜けられない構造になっていてデッドロックの危険性があったので、
そこだけは省いています。


他の上位のレベルの処理は一切変えていないので過去の抵抗膜式のものと同じ
ような感覚で操作できるようになっています。

本来ならばFT5336GQQのBSPがやってる処理を分解・再構築して自分独自の
タッチパネル入力処理とすべきところなのですが残念ながら私の技術力はそこまで
及ばずあえなく安易な方法、"出来合いの処理"を提示されたライセンスに従って
利用させてもらうことにしました。F7になってからは複雑化も相まってそういう
場面が多数出てきています。
私も巨人の肩の上に乗る小人のうちの一人にすぎないのです…!

前向きに考えるとソースコードを公式のものと互換性を持たせて問題を切り分け
易くするなんてことも言えますがゆくゆくはSeggerのSTemWinとかも使ってみたい
ので何でもかんでも自作にとらわれず柔軟にやってこうと思います。
もなかさんもこう言ってますしでも素のEclipseなんて絶対に使いませんよぅ！！
ｹﾞﾎｹﾞﾎ･･･ﾊｧﾊｧ失礼･･･次に進みましょう･･･


●QSPI-ROMをメモリマップドモードで使う
こちらはLPC4330の時にも紹介した奴と同じですね。SPI-ROMのメモリ領域が
特別な関数を経由せずにリニアにアクセスできるという便利な機構です。

ことSTM32F7に限ってはD-Cacheを挟むので従来のSPI-ROMではどうしようも
なかった速度的なボトルネックはある程度解消されるようです。


F7のHALライブラリにはQSPIの関数/BSPが用意されていますがメモリマップドモード
で使用する場合は一度イニシャライズしさえすれば後は普通の内蔵フラッシュ
メモリと全くおんなじです。


今回もBSPを最大限に利用させてもらっていますが、QSPIのメモリマップドモードでは
読み出し専用で使う場合は割り込み処理は全く不要なので初期化時のNVICの設定
を省いておくこともできます。

私はQSPI-ROMをFONTX2のデータ置場として利用しました。
F746DiscoveryではN25Q128Aが搭載されています。N25Q128Aは一セクタあたり
64kByteずつ分かれていますのでFONTX2ファイルを書き込むアドレスは半角を
0x90000000、全角は0x90010000に配置してみました。


あとQSPI-ROMにデータを書き込む方法ですがSTLinkUtilityのVer3.7からF7Discovery
用の外部フラッシュローダに対応しています。これを利用して書き込みます。


先ずは半角


お次は全角。
なんでか拡張子はbin,elf,hexしか駄目なのでFONTX2ファイル書き込む際は
拡張子をbinに変えて書き込んでください。


こうやってQSPI-ROMに書き込んだデータは上記のようにして参照します。
メモリマップドモードだからできる技ですね〜


無事に起動しました。S-JIS形式のtxt文書もごらんの通りです。
ビルド時に巨大なFONTX2ファイルを組み込む必要がなくなり、フラッシュ書き込み
に掛かる時間も節約できてテンポよくデバッグできるようになると思います。



デバッガからQSPIのメモリを参照するとこんな感じに見えます。
もちろん参照時はメモリマップドモードになっている必要があります。
これは半角のFONTX2です。


こちらは全角です。



現在はまだ限定的かつ実験的な使用にとどまっていますがQSPI-ROMの有効な
活用法が新たに見つかったら紹介していきたいと思います。



●おまけ
いつもののmakefileみたら何をどうすればわかるとは思いますが、デフォルトでは
以下の"ひとまず確実に動く設定"になっています。

1:内蔵フラッシュインターフェース
　->AXIM
2:SDRAM
　->有効
3:タッチパネル
　->有効
4:FONTX2
　->内蔵フラッシュから参照かつQSPIは無効

"4:"のFONTX2のドライバでQSPI-ROMを参照したい場合は当たり前ですが、
あらかじめ半角/全角それぞれのFONTX2ファイルを上で紹介した手順で
QSPI-ROMの適切なアドレスにSTLinkUtilを使用して書き込んでおく必要があります。

Go to top of page