I’ve tried to upgrade the WiFi gateway using the web interface from 4.1.5 to 4.1.6, and it seems I may have bricked my module.
I’ve upgraded the wifi firmware in the past using the web interface with success. However this time I’ve run into issues. During the upgrade it looked like it had gone correctly, and I restarted the gateway via the web interface, and never heard from it again. After about 1/2 an hour later I noticed on the EVSE display that it had upgraded it’s wifi firmware,(I can’t remember the exact message) so I powered off the unit, and powered it back on again, still no joy.
I’ve attempted to load the firmware (and older versions) as per the instructions on ESP32_WiFi_V4.x/wired-ethernet.md at 4.1.4 · OpenEVSE/ESP32_WiFi_V4.x · GitHub.
Currently I only have a red power light on the unit, with no other obvious lights active.
I suspect that from this point I’m needing to re-load the Boot Loader and partition bin files, but don’t want to go further down the rabbit hole before running this by someone else.
If someone is able to advise a path forward, that would be great.
Thanks in Advance for your help.
==============8<--------------------
Output from manual install of firmware
sudo esptool.py --before default_reset --after hard_reset write_flash 0x10000 openevse_esp32-gateway-e-4_1_5.bin
esptool.py v4.3
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting…
Detecting chip type… Unsupported detection protocol, switching and trying again…
Connecting…
Detecting chip type… ESP32
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 8c:4b:14:83:d4:80
Uploading stub…
Running stub…
Stub running…
Configuring flash size…
Flash will be erased from 0x00010000 to 0x0017afff…
Compressed 1485904 bytes to 978410…
Wrote 1485904 bytes (978410 compressed) at 0x00010000 in 86.4 seconds (effective 137.6 kbit/s)…
Hash of data verified.
I haven’t used that specific method of flashing an ESP32 from, I presume a Linux ststem. As you note the bin file looks to have uploaded OK. Are you able to connect a terminal program, something like ‘Coolterm’ to the serial port of the ESP32? If you are you will then see what the ESP32 is doing at boot up and any status codes it emits. It should boot up and then go to the code location you loaded and run the code it finds there. I would start there. If that fails you can erase the device and start again. Esptool.py can do the erase operation. There is also a tool called ESP flasher 2 that can be used to flash and erase ESP’s.
I upgraded my wired Ethernet version the other day (via the interface for the first time rather than programmer since that is now supported) and got the same message on the unit and a seemingly unresponsive unit.
A power cycle did however bring it back to life fortunately and it is showing 4.1.6 and has been running fine over the weekend.
Thanks for the pointers @bobcroft . I’ve attempted to put a serial port onto the TX pin of UART0 of the ESP, but not got any useful information out of it. I suspect I’ve not got the serial parameters correct, and not sure what the defaults are, or the serial interface I’m using does not like the ESP, but have used it before for programming, so should be Ok.
I’ll look at erasing the device and starting again. Do you have a link to a good set of instructions I can follow to achieve this, on one of these devices? I’ve not done that before so need to do some research before I dive into it.
Does anybody know if GPIO pin 1 is on the board, or is it only on the ESP chip, and not presented anywhere else. I’ve not found anything on the board layout to indicate a location.
I’ve also tried to load the ‘f’ firmware, but that had the same result, so suspect it’s more fundamental than that.
Hi Neil, I use ‘Coolterm’ to monitor my ESP devices. The baud rate on the ESP32 boot up is 115200. Some ESP8266 devices also use an odd baud rate of 74880, that can be set in ‘Coolterm’ as a custom baud rate. You could try that with the ESP32 as well if 115200 doesn’t work.
On the ESP32 GPIO-1 is the Tx pin and GPIO-3 is the Rx pin. If you are using a USB to serial adapter You very often have to link Tx - Rx and Rx - Tx =, ie cross over the wires. The labelling of Tx and Rx does not, unfortunately, follow any standard with pin labelling, so a bit of trial and error is needed.
For all things ESP the www.randomnerdtutorials.com website is a very good source of information.
I do not have a link to a tutorial on erasing an ESP device but if you Google ‘ESP Flasher 2’ it should bring up the software and other information.
I really think you need to get the boot information from the device to see what it is doing.
Thanks for the pointers. I’ve managed to get a feed from the TX port, and I get the following on repeat. One thing that I’ve not mentioned, is I’ve been in the IT game for way too many years so well familiar with serial, once I know what the settings are (115200n81 in this case), but these ESP units are new to me. I find it a good thing that it’s broken, gives me a chance to learn how to fix it for some other upcoming projects I’ve got in the pipeline.
I’ve have a look at the https://randomnerdtutorials.com and see what I can find out. (BTW, your link above is missing the s from the end, but all good, found it quick anyway.
Question. With these Olimex boards, does anybody know if the TX & RX pins are present on the board somewhere, or am I limited to working in the space between the chip and the Ethernet port?
Thanks all for the pointers, I’ll be back in a day or two when I get a chance to research and digest this information, and have a go at flashing.
@glyn.hudson Sorry for taking a few days to report back. Life happened and I’ve only just managed to get a chance to go through the steps.
That has worked perfectly, and I’ve now re-established coms with the WiFi unit. I’ve (at the time of typing) to plug it back into the EVSE, but I’m not expecting any issues once that has been done.
Thanks for all your help, it really is appreciated.
Neil