EmonESP Firmware Upload: Not Enough Space

Hardware emonESP
1

Hello,

I’ve been following the EmonESP README.md instructions to compile firmware via PlatformIO and uploading it using OTA.

Process:

cd ~/path/to/EmonESP  
pio run
# pio builds new .bin file successfully  
pio run -t upload --upload-port <EmonESP-Local-IP>

This updated successfully, however when I connected to the Access Point and went to 192.168.4.1 there was no HTML. (related issue on github)

I tried to resolve this by running the following:

pio run -t uploadfs --upload-port <EmonESP-Local-IP>

When I got to 192.168.4.1 now, it seems to be an older version of AP webapp.

image
image1912×751 23.1 KB

I tried recompiling and doing another upload and I’m now met with this error.

pio run -t upload --upload-port <EmonESP-Local-IP>

Warning! `env_default` configuration option in section [platformio] is deprecated and will be removed in the next release! Please use `default_envs` instead
Processing emonesp (platform: [email protected]; framework: arduino; board: esp01_1m)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/esp01_1m.html
PLATFORM: Espressif 8266 1.8.0 > Espressif Generic ESP8266 ESP-01 1M
HARDWARE: ESP8266 80MHz, 80KB RAM, 1MB Flash
PACKAGES: 
 - framework-arduinoespressif8266 2.20402.4 (2.4.2) 
 - tool-espotapy 1.1.3 
 - tool-esptool 1.413.0 (4.13) 
 - tool-mkspiffs 1.200.0 (2.0) 
 - toolchain-xtensa 1.40802.0 (4.8.2)
Converting src.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 31 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <PubSubClient> 2.6
|-- <ESP Async WebServer> 1.1.1
|   |-- <ESPAsyncTCP> 1.2.2
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|-- <NTPClient> 3.1.0
|-- <ESP8266WiFi> 1.0
|-- <EEPROM> 1.0
|-- <ESP8266HTTPClient> 1.1
|   |-- <ESP8266WiFi> 1.0
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266mDNS>
|   |   |-- <ESP8266WiFi> 1.0
|-- <ESP8266httpUpdate> 1.2
|   |-- <ESP8266HTTPClient> 1.1
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncTCP> 1.2.2
|   |-- <ESP8266WiFi> 1.0
|-- <Hash> 1.0
|-- <DNSServer> 1.1.0
|   |-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS>
|   |-- <ESP8266WiFi> 1.0
Building in release mode
Compiling .pio/build/emonesp/src/src.ino.cpp.o
Retrieving maximum program size .pio/build/emonesp/firmware.elf
Checking size .pio/build/emonesp/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.8% (used 37488 bytes from 81920 bytes)
Flash: [========= ]  87.2% (used 435944 bytes from 499696 bytes)
Configuring upload protocol...
Looking for upload port...
Use manually specified:  <EmonESP-Local-IP>
Uploading .pio/build/emonesp/firmware.bin
16:59:50 [DEBUG]: Options: {'esp_ip': ' <EmonESP-Local-IP>', 'host_ip': '0.0.0.0', 'esp_port': 8266, 'host_port': 10531, 'auth': '', 'image': '.pio/build/emonesp/firmware.bin', 'spiffs': False, 'debug': True, 'progress': True, 'timeout': 10}
16:59:50 [INFO]: Starting on 0.0.0.0:10531
16:59:50 [INFO]: Upload size: 440096
Sending invitation to <EmonESP-Local-IP>
16:59:50 [ERROR]: Bad Answer: ERR: ERROR[4]: Not Enough Space

I’m guessing I’m not flashing it correctly and the old files are still on the EmonESP, so any advice on how I’d make enough space for another upload would be appreciated.

2

It should also be noted that when I run pio run -t uploadfs --upload-port <EmonESP-Local-IP> it will upload spiffs.bin just fine.

3

Try clearing the chip using esptool. Put the device in bootloader mode then run:

$ esptool erase_flash

After that try uploading again. Ensure you have the latest version by running $ git pull in the project dir.

If you don’t need to compile yourself you could just upload the pre compiled .bin's from the releases page: http://github.com/openenergymonitor/emonesp/releases

$ esptool write_flash 0x000000 firmware.bin 0x7B000 spiffs.bin

1 Like
4

That would require a direct connection between the EmonESP and my laptop, yes? Not too sure what is the best way to do that, advice would be appreciated.

5

What you’re seeing is the expected result since the most recent changes to emonESP master branch.
You’ll have to get a direct connection to upload again yes.

If you have a 4MB flash size ESP a repeat of the issue can be avoided by changing the platformio.ini line
env_default = emonesp
to
env_default = esp12e
or specify the env in the run command.

1 Like
6

You’ll have to get a direct connection to upload again yes.

Would it be possible to upload firmware if I had the EmonESP connected to the serial ports of the USB to Serial UART progammer and then the programmer connected to my laptop?

7

I believe that’s how they’re originally programmed, so yes.
UART header pins can be checked: 5v,gnd,tx,rx

Noticing also there’s a flash size linker flag in the .ini,
that’ll need unflagging in the esp12e environment.

1 Like
8

Noticing also there’s a flash size linker flag in the .ini

What line is it on? There’s a few flash related variables and i’m not sure which one you mean.

9

@glyn.hudson, longer term, you will need to adopt the Tasmota/ESPHome mechanism of uploading a minimal bin, then uploading the full bin in a 2 stage OTA upload mechanism.

10

There’re are a few lines with the linker, simpler just to unflag it…
Try replacing the esp12e env at the bottom of the .ini with this:

[env:esp12e]
platform = ${common.platform}
framework = ${common.framework}
board = esp12e
lib_deps = ${common.lib_deps}
src_build_flags = ${common.version} -DENABLE_DEBUG
board_build.flash_mode = ${common.board_build.flash_mode}
board_build.f_cpu = ${common.board_build.f_cpu}
build_flags = ${common.build_flags}
build_unflags = ${common.build_unflags}
                -Wl,-Teagle.flash.1m512.ld
monitor_speed = ${common.monitor_speed}
upload_resetmethod = ${common.upload_resetmethod}
upload_speed = ${common.upload_speed}

Compiled here to:
RAM: [===== ] 45.7% (used 37476 bytes from 81920 bytes)
Flash: [==== ] 41.7% (used 435932 bytes from 1044464 bytes)

11

A simple pio run had it compile just fine. I tried a pio run -t uploadfs --upload-port <EmonESP-Local-IP> just to see if it’d work via OTA but still getting “Not Enough Space”.

I tried wiring the ESP module to the USB to Serial UART progammer that I have so the labelled pins are connected to each other (eg, GND to GND, 5v to 5v) but i’m getting the following error when I try to upload.

$ pio run -t upload
Warning! `env_default` configuration option in section [platformio] is deprecated and will be removed in the next release! Please use `default_envs` instead
Processing esp12e (platform: [email protected]; framework: arduino; board: esp12e)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif8266/esp12e.html
PLATFORM: Espressif 8266 1.8.0 > Espressif ESP8266 ESP-12E
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES: 
 - framework-arduinoespressif8266 2.20402.4 (2.4.2) 
 - tool-espotapy 1.1.3 
 - tool-esptool 1.413.0 (4.13) 
 - tool-mkspiffs 1.200.0 (2.0) 
 - toolchain-xtensa 1.40802.0 (4.8.2)
Converting src.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 31 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <PubSubClient> 2.6
|-- <ESP Async WebServer> 1.1.1
|   |-- <ESPAsyncTCP> 1.2.2
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|-- <NTPClient> 3.1.0
|-- <ESP8266WiFi> 1.0
|-- <EEPROM> 1.0
|-- <ESP8266HTTPClient> 1.1
|   |-- <ESP8266WiFi> 1.0
|-- <ArduinoOTA> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266mDNS>
|   |   |-- <ESP8266WiFi> 1.0
|-- <ESP8266httpUpdate> 1.2
|   |-- <ESP8266HTTPClient> 1.1
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncTCP> 1.2.2
|   |-- <ESP8266WiFi> 1.0
|-- <Hash> 1.0
|-- <DNSServer> 1.1.0
|   |-- <ESP8266WiFi> 1.0
|-- <ESP8266mDNS>
|   |-- <ESP8266WiFi> 1.0
Building in release mode
Compiling .pio/build/esp12e/src/src.ino.cpp.o
Retrieving maximum program size .pio/build/esp12e/firmware.elf
Checking size .pio/build/esp12e/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=====     ]  45.8% (used 37492 bytes from 81920 bytes)
Flash: [====      ]  41.7% (used 435940 bytes from 1044464 bytes)
Configuring upload protocol...
Looking for upload port...

Warning! Please install `99-platformio-udev.rules`. 
Mode details: https://docs.platformio.org/en/latest/faq.html#platformio-udev-rules

Auto-detected: /dev/ttyUSB0
Uploading .pio/build/esp12e/firmware.bin
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
*** [upload] Error 2

verbose upload:
pio_upload_verbose.txt (143.6 KB)

12

That looks like a boot-mode issue. I think hold down the GPIO0 or BOOT button to flash.

Yeah the previous OTA upload would have configured the flash such that OTA won’t work.
Once you’ve got the 4m1m flash on it, which is the ‘esp12e’ board default flash size, OTA should work again.

OTA needs free space on the chip to upload the new program. The 1m512k linker divides the flash into 487k program memory, and 512k SPIFFS, with no room for OTA updates.
. Arduino/eagle.flash.1m512.ld at master · esp8266/Arduino · GitHub

13

That looks like a boot-mode issue. I think hold down the GPIO0 or BOOT button to flash.

I do have it in bootloader mode (hold down GPIO0 and press Reset) if that’s what you mean?

14

Tx/Rx swapped?

1 Like
15

It worked!

16

My original setup was Tx to Tx and Rx to Rx. I think I see my mistake now, the Tx pin transmits data and therefore needs to be connected to Rx which receives data. So the Rx pins were listening to each other and therefore no communication was occurring between the USB to UART programmer and the EmonESP.

17

:notes::fireworks::notes:
Boom!

I’ll have a look at the doco, see what needs updating.

That one’s caught me out a lot!

1 Like
18

CONVENTION says that you connect Tx to Rx and Rx to Tx. It’s been like that for many decades - since modems and serial connections were invented.

OEM on the emonTx does not follow that convention. That’s where the problem has arisen and the confusion has been created.

19

Thanks @Robert.Wall I’ve added an issue to keep track of this here: Reverse RX/TX silkscreen on hardware design · Issue #11 · openenergymonitor/emontx3 · GitHub

1 Like
20

The problem comes up fairly regularly, and I’ve lost count of the times I’ve had to explain that the crossover is done on the emonTx pcb, and must not be done again.

Future Technology Devices uses the magic numbers “232” on the literature, and while TTL signal levels are not strictly RS-232, many people think and assume that anything quoting that will adhere more or less to the RS-232/EIA-232 and CCITT standards. Those are unambiguous: TXD is the pin/line on which the Data Terminal Equipment transmits data, and RXD is the pin/line on which it receives data.

The standards assume that the connection is between a data terminal (a teleprinter back in the day) and a modem, the Data Communications Equipment. The DCE does indeed receive data on the TXD pin/line and transmits on the RXD pin/line.

When you have two intelligent devices communicating, for example the FTDI programmer and emonTx, which is the DTE and which is the DCE? The emonTx connector is labelled as if it is a DCE - a modem. The Future Technology Devices documents, and the programmer itself are labelled as if that is the DTE.

I don’t think many people see the emonTx as a modem, hence they expect to have to do the crossover in the cable, and that’s where the problem lies.

Like the number of times I’ve had to explain this, I can’t remember how many serial cables I’ve made up (on 9-pin and 25-pin ‘D’ connectors) with pin 2 to pin 3 and pin 3 to pin 2.

1 Like