Help trying to upgrade firmware on EmonTx3

I’m trying to upgrade the firmware on my EmonTx3 which is currently at version 1.5. I have a USB to TTL converter not bought from the OEM shop (they don’t seem to have any!). It has 5v, GND,TX and RX lines (and 3v3) but no RST output. I’ve connected it to the EmonTx3 and used tio to list the configuration, check the version etc. No problem. However when I plug it into the EmonPi and use the Admin interface to update the firmware, I get the following:

-------------------------------------------------------------
emonTxV34CM_jeelib Firmware Upload
-------------------------------------------------------------
Downloading firmware from: 
https://github.com/openenergymonitor/EmonTxV3CM/releases/download/2.0.0/firmware.hex

Downloaded file: 
-rw-r--r-- 1 pi pi 78K Dec  7  2021 /opt/openenergymonitor/data/firmware/emonTxV34CM_jeelib.hex

EmonHub is running, stopping EmonHub

Uploading emonTxV34CM_jeelib on serial port ttyUSB0
Attempt 1...


avrdude-original: Version 6.3-20171130
                  Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
                  Copyright (c) 2007-2014 Joerg Wunsch

                  System wide configuration file is "avrdude.conf"
                  User configuration file is "/root/.avrduderc"
                  User configuration file does not exist or is not a regular file, skipping

                  Using Port                    : /dev/ttyUSB0
                  Using Programmer              : arduino
                  Overriding Baud Rate          : 115200
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00

avrdude-original done.  Thank you.

avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: Using autoreset DTR on GPIO Pin 7
ERROR: Not in sync

Restarting EmonHub

Looking through some posts it seems as though I might need to use the RST pin (there are references to ‘wire up the RST pin’ on some topics relating to serial comms out of the EmonTx3) but I can’t find any explanation of what this means, or how to upgrade firmware using a non-OEM USB adapter.

Can anyone point me in the right direction?

I am fairly sure you do.

One thing to note, you don’t cross the TX/RX line when connecting - connect TX to TX and RX to RX (long story - not worth repeating again).

@Gwil could an alternative be suggested from another source on the shop?

I’m certain you do. It is driven by the loader software and puts the processor into programming mode. It’s said that you can do the same by pressing the ‘reset’ button on the emonTx at the correct instant, and timing is quite critical. I’ve never tried to do this, so I can’t give any hints. It’s the same processor as an Arduino Uno, so a search (elsewhere) might find something useful.

Having read a bit more it’s clear that you need mor than a serial adapter, you need something that can toggle that RST pin. So I went and bought a Polulu AVR Programmer. I used their configuration tool to set their pin B (#6, the last on the header) to be DTR-reset and to have the VCC pin deliver 5v power.

Upon loading this device it comes up as two serial ports: /dev/ttyACM0 and /dev/ttyACM1. Neither of these automagically appear in the Admin Firmware update drop-down (why?) so I symlinked them to ttyUSB0 and ttyUSB1. Then they appeared but neither of them work :frowning:

                  Using Port                    : /dev/ttyUSB1
                  Using Programmer              : arduino
                  Overriding Baud Rate          : 115200
avrdude-original: stk500_recv(): programmer is not responding
avrdude-original: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

Repeated another 9 times then failing much as before:

avrdude-original done.  Thank you.
avrdude-original: Using autoreset DTR on GPIO Pin 7
avrdude-original: Using autoreset DTR on GPIO Pin 7
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
ERROR: Not in sync
Restarting EmonHub

There are lots of references to using avrdude and platformio, and to compiling, but my mission is much simpler: just to get firmware 2.0 onto the EmonTx3. I have the precompiled hex, does anyone have an idea on how to get this to work? Am I missing a setting on the programmer? I followed section 6.3 of the manual where it talks about using it as a generic FTDI type programmer (set B to DTR-reset, leave pin A #2 disabled). What else could there be?

I should add that I can use /dev/ttyACM1 as a serial terminal and bring up the EmonTx3 configuration screen, so the serial comms bit is working, just perhaps not the DTR business.

For assembly instructions see FTDI Programmer — OpenEnergyMonitor 0.0.1 documentation

Which is not the case if you use the above adapter.

This is only relevant if you are connecting the adapter via the RPI GPIO Pins - you are connecting via the USB port on the RPi I believe?

Plugging it into what? The RPi?

Which tells you that is the interface you need to connect to.

BTW are you stopping emonhub before attempting this?

Success, although with battles.

TL;DR: Use the TTL serial interface and hit reset on the EmonTx as needed…

I could not get it to work in the EmonCMS Admin Update Firmware interface, even with hitting ‘reset’ a few times.

How I managed it

I installed avrdude on my Mac using brew install avrdude. Then I setup the Polulu programmer as per my original plan. Here’s it’s status:

🍏 ~ % pavr2cmd --status
Name:                                    Pololu USB AVR Programmer v2.1
Serial number:                           00408076
Firmware version:                        1.02
Programming port:                        /dev/cu.usbmodem004080762
TTL port:                                /dev/cu.usbmodem004080764

Settings:
  ISP frequency (kHz):                   114
  Max ISP frequency (kHz):               1714
  Regulator mode:                        auto
  VCC output:                            Disabled
  VCC output indicator:                  Blinking
  Line A function:                       None
  Line B function:                       DTR reset
  VCC/VDD maximum range (mV):            896
  VCC 3.3 V minimum (mV):                2720
  VCC 3.3 V maximum (mV):                3872
  VCC 5 V minimum (mV):                  4128
  VCC 5 V maximum (mV):                  5856
  STK500 hardware version:               F
  STK500 software version:               2.A

Results from last programming:           N/A

Current status:
  Target VCC (mV):                       5120
  Programmer VDD (mV):                   4928
  VDD regulator set point:               5 V
  Last device reset:                     Power-on reset

Then to check that I could communicate directly with the EmonTx3 I issued the command:

avrdude -patmega328p -carduino -P /dev/cu.usbmodem004080764 -b115200 -D -Uflash:r:current.hex:i

This read the firmware. I tried this a few times and noticed that after a successful read, the next attempt would yield the stk500_recv(): programmer is not responding message. However if I hit the EmonTx3 reset button during the (10) retries it would work:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x4e
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x65

avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading flash memory:
Reading | ################################################## | 100% 3.20s
avrdude: writing output file "current1.hex"
avrdude done.  Thank you.

So I downloaded the 2.3.0 firmware (as firmware230.hex) and executed:

🍏 firmware % avrdude -patmega328p -carduino -P /dev/cu.usbmodem004080764 -b115200 -D -Uflash:w:firmware230.hex:i
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x65
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: reading input file "firmware230.hex"
avrdude: writing flash (28104 bytes):
Writing | ################################################## | 100% 3.78s
avrdude: 28104 bytes of flash written
avrdude: verifying flash memory against firmware230.hex:
Reading | ################################################## | 100% 2.75s
avrdude: 28104 bytes of flash verified
avrdude done.  Thank you.

As you can see this worked, although I had to hit the reset button on the EmonTx3 after it failed on the first try. After this I used a serial terminal to check the configuration:

🍏 firmware % tio -m ONLCRNL /dev/cu.usbmodem004080764                                         
[17:32:53.786] tio v2.5
[17:32:53.786] Press ctrl-t q to quit
[17:32:53.789] Connected
emonTx V3.4 EmonLibCM Continuous Monitoring V2.30
OpenEnergyMonitor.org
No EEPROM config
Settings:
Group 210, Node 15, Band 433 MHz

                                Calibration:
vCal = 268.97
assumedV = 240.00
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 9.96
pulses = 1
pulse period = 100
temp_enable = 1
RF whitened
           RFM69CW only Node: 15 Freq: 433MHz Group: 210
 
POST.....wait 10s
'+++' then [Enter] for config mode
Entering config mode...

Available commands for config during start-up:
  b<n>      - set r.f. band n = a single numeral: 4 = 433MHz, 8 = 868MHz, 9 = 915MHz (may require hardware change)
  g<nnn>    - set Network Group  nnn - an integer (OEM default = 210)
  i<nn>     - set node ID i= an integer (standard node ids are 1..30)
  r         - restore sketch defaults
  s         - save config to EEPROM
  v         - show firmware version
  w<x>      - turn RFM Wireless data on or off:
            - x = 0 for OFF, x = 1 for ON, x = 2 for ON with whitening
  x         - exit and continue
  ?         - show this text again

Available commands only when running:
  k<x> <yy.y> <zz.z>
            - Calibrate an analogue input channel:
            - x = a single numeral: 0 = voltage calibration, 1 = ct1 calibration, 2 = ct2 calibration, etc
            - yy.y = a floating point number for the voltage/current calibration constant
            - zz.z = a floating point number for the phase calibration for this c.t. (z is not needed, or ignored if supplied, when x = 0)
            -  e.g. k0 256.8
            -       k1 90.9 2.00
  a<xx.x>   - xx.x = a floating point number for the assumed voltage if no a.c. is detected
  l         - list the config values
  m<x> <yy> - meter pulse counting:
               x = 0 for OFF, x = 1 for ON, <yy> = an integer for the pulse minimum period in ms. (y is not needed, or ignored when x = 0)
  p<xx.x>   - xx.x = a floating point number for the datalogging period
  s         - save config to EEPROM
  t0 <y>    - turn temperature measurement on or off:
            - y = 0 for OFF, y = 1 for ON
  t<x> <yy> <yy> <yy> <yy> <yy> <yy> <yy> <yy>
            - change a temperature sensor's address or position:
            - x = a single numeral: the position of the sensor in the list (1-based)
            - yy = 8 hexadecimal bytes representing the sensor's address
               e.g.  28 81 43 31 07 00 00 D9
               N.B. Sensors CANNOT be added.
  ?         - show this text again
emonTx V3.4 + RFM69CW EmonLibCM Continuous Monitoring V2.30
emonTx V3.4 + RFM69CW EmonLibCM Continuous Monitoring V2.30
emonTx V3.4 + RFM69CW EmonLibCM Continuous Monitoring V2.30
Settings:
Group 210, Node 15, Band 433 MHz

                                Calibration:
vCal = 268.97
assumedV = 240.00
i1Cal = 90.90
i1Lead = 4.20
i2Cal = 90.90
i2Lead = 4.20
i3Cal = 90.90
i3Lead = 4.20
i4Cal = 16.67
i4Lead = 6.00
datalog = 9.96
pulses = 1
pulse period = 100
temp_enable = 1
RF whitened
           Saving...
0F 01 D2 29 7C 86 43 CD CC B5 42 66 66 86 40 CD CC B5 42 66 66 86 40 CD CC B5 42 66 66 86 40 29 5C 85 41 00 00 C0 40 29 5C 1F 41 01 64 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 70 43 

                                       Done. New config saved to EEPROM

[17:39:43.108] Disconnected

I’m not much the wiser, but have re-installed everything and hopefully won’t have to touch it for a while. I could probably have saved £20 not buying the Polulu Programmer but perhaps it’ll come in useful someday…

This doesn’t appear to be necessary with the EmonTx3, just hit its reset button if it doesn’t respond. At least using command-line avrdude not the web interface. See my previous comment.

For completeness let me answer these:

  • Yes, connecting to USB on the RPi.
  • Yes, those devices are auto-created on the RPi
  • Indeed, using the serial device (ttyACM1) and hitting the reset button (sometimes) was the solution - I never did get the programmer device (ttyACM0) to function.
  • Yes. When running the update via the EmonCMS Admin web interface that happens automatically, and when I did the successful firmware upload it wasn’t plugged into the EmonPi, it was plugged into my Mac.

Lastly, thanks @borpin and @Robert.Wall for your input, although it was a combination of brute force, luck and most of the day that cracked the problem.

1 Like

That is interesting.

As I wrote, the RST line puts a reset on the emonTx - the same as pressing ‘Reset’. The difference is the programmer software can time the reset exactly, the user needs to learn the skill needed to get the timing right.

I’d never realised the two things were related :frowning: EDALD

There’s a limited window on releasing the reset during which any data that arrives is treated as code to be loaded, and this continues until done. If nothing arrives during that window, it runs the application sketch. Don’t ask me how it knows the difference between valid code and input intended for the sketch :slightly_smiling_face:
It’s on the data sheet or app notes - somewhere… or it could be a property of the bootloader. It’s not an area I’ve ever needed to know about.

1 Like