ESP8266 (ESP-201) endless reboot
I have followed the guide Building a WiFi Gateway using ESP8266 guide and uploaded the modified sketch (libraries/MySensors/examples/Esp8266Gateway/Esp8266Gateway.ino) to my ESP-201.
I have connected the NRF24L01+ to the ESP-201 according to the instructions in the ESP8266Gateway example sketch:
* The ESP8266 however requires different wiring: * nRF24L01+ ESP8266 COLOR * VCC VCC RED * CE GPIO4 ORANGE * CSN/CS GPIO15 YELLOW * SCK GPIO14 GREEN * MISO GPIO12 PURPLE * MOSI GPIO13 BLUE * GND GND BLACK
except that GPIO15 on the ESP8266 is still connected to ground. Otherwise the ESP won't boot.
The ESP joins my WPA2 access pont and requests an IP address. dhcpd says:
dhcpd: DHCPDISCOVER from 18:fe:34:fc:ee:5f (ESP_FCEE5F) via wlan0
So far go good. The bad thing is that the ESP reboots continuously, which I can see in the log files of my access point. It joins the access point and requests an IP approximately once every 7 seconds.
I have tested to power the ESP from the 3.3V output of my FTDI adapter and from a 5V/2.4A USB charger to 3.3V through this step-down. In both cases I used a 330uF capacitor to assist the power.
Any ideas on what I should do next?
Haven't tried the ESP201 myself. But I see no reason why it shouldn't work. Seems to have the necessary pins broken out.
The Esp draws a significant amount of current. Could very well be that both your attempts to power it are insufficient and cause a power drop, causing the reset.
Try powering it from a more beefy (say 1amp) power supply.
I don't have a strong source of 3.3V but a li-ion battery might be ok? The 3.7-4V voltage would be a bit too high though.
Any suggestions on a good (and affordable) power source capable of delivering 1 amp at 3.3V? A bench power supply might be a good investment for future projects I guess.
http://internetofhomethings.com/homethings/?p=396 suggests at least 500mA for power, 470uF on the breadboard and 0.1uF very close to the ESP8266 chip itself. So insufficient power is likely to be the culprit.
I had a very similar issue, and managed to resolve it by following the quoted process found in the below link (please note I have a ESP8266-12E & it worked for me but do not guarantee it is the solution for all).:
*** ROOT ISSUE - ESPTool.exe is NOT correctly erasing flash, allows module to get "borked" and is then "unborkable".
Above wall of text can be summarized as "sometimes on windows modules get to a state where uploads stop working", and many people suggest many different hardware-related fixes. They didn't work for me, and simply grabbing the esptool.py script and running:
F:\Users\timm\Documents\Arduino\PythonESPTool>python esptool.py --port COM5 --baud 76800 erase_flash
put the module back into an uploadable state.
Manually asking esptool.exe to erase the module did not work.... so esptool.exe as packaged here has a bug wrt erasing that esptool.py doesn't.
So - for all other frustrated windows users, if you bork your module and it stops working, do the following until this bug is fixed:
install Python2.7 (google for instructions)
download esptool.py from this git distro into a local directory (hope this link keeps working - https://github.com/themadinventor/esptool, I could not find in this GIT repo)
open a command window in the same directory and run "python esptool.py --port COM5 --baud 76800 erase_flash"
use your IDE to download your prev sketch, should now work again.
I'm going to try to diddle the platform.txt file to use this instead of the esptool.exe, if it is easy I'll report back.
This may be hard to reproduce, if I find a sketch that consistently breaks esptool.exe I will share, but please comment IF this approach helps you out of a "stuck" module so the smart guys (Ivan, looking at you) can prioritize and look into whether it's worth fixing/replacing esptool.exe.
Thanks @twisted, I'll try that.
Again, make sure to power it from a decent power supply. It hardly has any buffering/filtering onboard.
I use these boards regularly for prototyping but any noise/spikes/dips present on the input will directly be reflected on the output.