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.
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
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?
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
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.
@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.
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)
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)
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
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?
Tx/Rx swapped?
1 Like
It worked!
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.
Boom!
I’ll have a look at the doco, see what needs updating.
That one’s caught me out a lot!
1 Like
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.
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
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
All emonTx’s are the same - V2, V3.2 & V3.4. All have the processor’s RXD connected to the pin labelled “Tx” on the FTDI connector silk screen, and the processor’s TXD connected to the pin labelled “Rx”, although on the V3.4 circuit diagram - the FTDI connector is labelled both ways!
Apologies, this is my mistake. I think I was trying to be too clever by doing the crossover on the silkscreen labelling. This made sense in my mind 14 years ago when I first laid out the emonTx PCB, I wasn’t aware of the conversion. Somehow it’s slipped through the net and not been corrected.
1 Like