ESP8266 Community Forum

- Fri Jan 18, 2019 7:49 pm #80143 Hello everyone!

I'm totally new to the ESP8266 and IOT world. I have got couple of ESP8266 modules as I need to add internet connectivity to an embedded project so I can update its firmware and control it remotely.

I have built the necessary power supply circuit and I have been messing around with the module using AT commands over serial communication with PC. I had no problem searching for available APs, setting mode to 1 (Station) or both (Station + AP), however, joining a network with WPA encryption always returns ERROR. WHen I changed the settings in my wifi router to WEP, it worked. This is a big problem for me as I can't keep the settings of the router on the WEP for security purposes. Changing the MAC address, power, and baud rate also return ERROR.

For now, I really don't have much time to dive into the SDK and development of custom firmware. However, if that proves to be necessary to get me where I want, I have no problem going that route. So far, I have read some of the material published by Espressif and got a little bit familiar with ESP8266 and its ecosystem. However, the plethora of info available out there for the ESP8266 is somewhat confusing and I really don't know where to start and what to look at first.

I would really appreciate any info that could help me get a head start in the development of my project. Basically, all I want to do for now is to be able to update the firmware for my STM32F407 based product remotely over the internet. The internet connection has to be configured by customer through his/her smartphone. Once done, the customer can interact/communicate with the product on the smartphone, search for new firmware, and update the firmware if available. I have read something about a similar approach using Ymodem protocol, which is also the one used to send firmware image to my uC, but the firmware update concerned was for the ESP8266 itself and not the host uC.

Like I said earlier, if the above scenario could be done utilizing the AT firmware without getting involved too much into SDK development, I would be better off using that approach in order to get up and running shortly.

Thank you in advance!

- Sun Jan 20, 2019 11:12 pm #80174 Be careful with power supply. Even though your fluke meter would say 3.34VDC, it does not mean it will ALL work. Mine was working EXCEPT on the wifi functionality. I could not ping the ESP8266!!

I learned it the hard way. Good thing I read some threads here and pointed to check your power supply.
Mine was reading 3.34VDC, but the AC part was around 50mV, so there is so much ripple. I made my own power supply but I got lazy on the capacitors. So I jumpered it with an electrolytic with capacitance of 47uF. Low and behold it worked! Now I can ping it and Alexa can recognize my device. Sweet feeling after that!
My AC now becomes 4mV.
Happy designing!

- Mon Jan 21, 2019 5:48 am #80183 In my opinion the standard AT command firmware sucks and cannot really be used in real life applications.
Your best bet is to write custom firmware for the ESP that does all the STmicro firmware update work by itself, as if someone with a programmer is uploading firmware to the STmicro manually.

After a customer has configured the settings inside the ESP:

• The ESP will regularly check for updates for itself (magic word: "OTA")
• The ESP will check for updates for your STmicro
• If found: start update sequence (toggle update-I/O of your STmicro, send data, reset STmicro, ...)

I would drop the AT-firmware update idea immediately since it will be a waste of time.
Normally I would also suggest to drop the other (in your case the STmicro) controller and let the ESP do all the work on its own, but since theSTmicro has a lot more I/O than the ESP8266, this might not be an option (as well as you'll completely have to redesign your product).

Please note that the bigger and younger brother of the ESP8266 (the ESP32) does have more peripherals available, so this might be a nice consideration for future products.

Assumption is the mother of all f*ckups. At least: that's what I'm assuming.

- Tue Jan 22, 2019 5:15 pm #80221 Thank you for the reply. Well, starting from where you left off, I can understand the AT Firmware approach probably won't get me where I want, but I just don't see how you suggest dropping the whole uC that my project and code are built around? How you assumed the ESP32 can replace my uC and give me the same processing power, set of peripherals, and development ecosystem that I have almost mastered long time ago? Of course, the ESP32 is more powerful compared to the ESP8266, but you think it can compete or replace an ARM Cortex-M4 uC? Let aside the firmware investment of my product. Probably for another project starting from scratch, I might consider the ESP32, but for an existing product where I need to just add IOT, I do not think it's a wise choice.

In my opinion the standard AT command firmware sucks and cannot really be used in real life applications.
Your best bet is to write custom firmware for the ESP that does all the STmicro firmware update work by itself, as if someone with a programmer is uploading firmware to the STmicro manually.

After a customer has configured the settings inside the ESP:

• The ESP will regularly check for updates for itself (magic word: "OTA")
• The ESP will check for updates for your STmicro
• If found: start update sequence (toggle update-I/O of your STmicro, send data, reset STmicro, ...)

I would drop the AT-firmware update idea immediately since it will be a waste of time.
Normally I would also suggest to drop the other (in your case the STmicro) controller and let the ESP do all the work on its own, but since theSTmicro has a lot more I/O than the ESP8266, this might not be an option (as well as you'll completely have to redesign your product).

Please note that the bigger and younger brother of the ESP8266 (the ESP32) does have more peripherals available, so this might be a nice consideration for future products.