I bought some esp8266 boards for an IoT project to work with FRDM-K64F board and realized quickly that they are not responding as expected. I wanted to upgrade the firmware to the latest so as to test further, leave no stone unturned. These are the steps I followed to upgrade the firmware in Ubuntu 18.04.
- Clone esptool repository from github
- Get into the esptool directory
- Connect your esp8266 board to the computer via a TTL-232R-3v3 cable
You need to connect four wires: Rx[yellow]->ESP_Tx, Tx[orange]->ESP_Rx, GND[black]->ESP_GND and CH_PD->CTS[brown: this provides 3.3v signal]. While flashing, you will need to hold the ESP_GPIO_0 line to ground using an extra wire.
The power of the esp8266 board comes from the 5V[red] line of the cable, through a proper 3.3v output voltage regulator. I am using a small perfboard circuit with LD1117AV33 from ST Microelectronics. Any fixed 3.3V linear regulator can be used, I just got this one locally at a shop. I am using a breadboard to be able to share the ground line using the female to male jumper wires.
The reason for this separate power is because I plan to use it with a micro-controller later, which may not be able to provide enough current to the esp8266 board. The computer USB provide 500mA of current and that’s way over the rated highest values of about 300mA. I soldered two capacitors on the 5V input to ground and 3.3V output to ground according to the datasheet typical circuit.
- Launch a serial terminal application on the computer and connect to the TTL-232R-3v3 cable.
I am using Coolterm for this as it has a line mode feature that allows me to type in the whole command and appends \r\n when I hit enter before sending. This is important because otherwise the AT commands will be malformed and the esp8266 board will not respond. This feature is not available gtkterm, which has been so far my favorite serial terminal application. Coolterm installation in Linux requires to install lots of 32-bit libraries, which is explained in another post.
- Check current firmware version
Once the cable is connected, mine shows up as /dev/ttyUSB0 or /dev/ttyUSB1 depending on whether I quickly unplugged and replugged the cable, run the GMR AT command in Coolterm so we have a reference of what the initial firmware version was.
- Check the flash memory size
Now back to bash[or whatever commandline terminal you use], we can also investigate the chip that we have on the esp8266 board so that we can figure out how exactly to flash it.
From this we have a flash size of 512KB and the mac address of the WiFi radio, it might come in
handy if you need to whitelist your esp8266 board on your router or something similar.
- Download the latest firmware for the esp8266 board from espressif
I got V1.6.2 from this link. Extract the zip file and note the files inside. I put my files in a directory called bin inside the ~/src/esptools directory for ease of typing commands. I can move the files eslswhere later.
- write the latest bootloader binary into address 0x0
- Write the default RF parameter values to 0x7C000
[for 512KB module, others require different address and flash_size parameter: 0xFC000 for 1MB(ESP8285, PSF-A85, etc). Better use the flash_id command to find out before flashing]
- Write default system parameter values to address 0x7E000
- Write the WiFi firmware to address 0x01000
- Test the new firmware with the AT command.
To get back in normal mode we have to release the ESP_GPIO0 pin from ground [by removing that jumper wire entirely] and reset the board. To reset the board, I just unplug and re-plug the VCC jumper wire. You could also take reset line to ground and then VCC. Running the AT command shows the board is fine:
- Check the new firmware version with the GMR AT command.
We now have a newer firmware in the board, hopefully running better than the old one it came with.
- Connect to the esp8266 UART microcontroller UART and try to send values to thingspeak.com.
So I had this test channel setup on thingspeak.com a long time ago but never used it. I will try to see if we can send the values [10, 30, 60, 90 and 99] programmatically in equal intervals, about 20 seconds apart. If that works, then I will lower the delay between GET /update? commands until it stops working. This is just to figure out how fast we can upload individual data points, for the K64F microcontroller can surely scan and read ADC values much faster than 20 seconds intervals. The other thing is uploading data to several fields within one channel at the same time. If that is not consistent still after the firmware update, it will be time to move on to 3G connection and forget the WiFi. In my testing so far I have realized that the success and consistency of the data upload depends heavily on the WiFi network and there are many things that can go wrong.
So I did some simulation test in MATLAB and figured out how often we can push data to thingspeak.com to avoid failure.
After a lot more playing around with the ESP8266 module both through the USB to RS232 cable and connected to the FRDM-K64F KIT, I conclude that the new firmware is much worse than the older firmware in terms of inconsistent response when you run AT commands and disconnects from the WiFi network. The module basically disconnects even in the middle of an update. Sometimes there are also issues with thingspeak.com being overloaded, but thats just thingspeak.
Also, sometimes things go flawlessly on the ESP sides but nothing gets updated on thingspeak.com. This module is a hustle to rely on in an IoT project, unless someone else can convince me otherwise. I have reliably sent data over to thingspeak from Matlab in a loop with very limited hiccups but not the ESP8266 module. Sometimes it works, sometimes it just doesn’t.
One cosmetic difference in the AT commands is that the response now lacks that extra \r that is, you get \r\n\r\n instead of \r\r\n\r\n. So if you had implemented that in your microcontroller firmware, you need to change the code and remove that extra carriage return from the expected response, or you will pull your hairs out from debugging. Just analyze the response from a proper serial terminal that can show you a hex view of the response, like coolterm.