No, just plug in and it should all happen.
Unfortunately, that covers just about every error imaginable. The likeliest are:
It’s not connected,
There’s a wiring fault,
RTS on your programmer isn’t connected (it resets the emonTx at the appropriate moment)
or it can’t do that
Rx & Tx are crossed
We can dismiss the first and last immediately, because you’re seeing data.
Are you using the “shop” programmer, or another one? - there are some on sale elsewhere that don’t work for us.
I have to agree that it is looking very much like this might be the usb/serial cable’s fault: I’m using a generic which is a knock-off the Prolific PL2303. I’ll get a proper cable and resume testing then …
I did a bit more poking around, because I’m 99% confident my serial cable is ok (I can perform the RF config routine just fine, so transmit and receive are working)
Here’s what I did just now:
D:\dev\arduino\arduino-1.8.5\hardware\tools\avr/bin/avrdude -CD:\dev\arduino\arduino-1.8.5\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM7 -b115200 -D -Uflash:w:C:\Users\heckler\AppData\Local\Temp\arduino_build_471158/src.ino.hex:i
D:\dev\arduino\arduino-1.8.5\hardware\tools\avr/bin/avrdude -CD:\dev\arduino\arduino-1.8.5\hardware\tools\avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -PCOM7 -b115200 -D -Uflash:w:C:\Users\heckler\AppData\Local\Temp\arduino_build_471158/src.ino.hex:i
Using Port : COM7
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: c [63]
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x63
avrdude: Send: 0 [30] [20]
avrdude: Recv: t [74]
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x74
avrdude: Send: 0 [30] [20]
avrdude: Recv: 1 [31]
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x31
avrdude: Send: 0 [30] [20]
avrdude: Recv: : [3a]
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x3a
avrdude: Send: 0 [30] [20]
avrdude: Recv: 0 [30]
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x30
avrdude: Send: 0 [30] [20]
avrdude: Recv: , [2c]
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x2c
avrdude: Send: 0 [30] [20]
avrdude: Recv: c [63]
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x63
avrdude: Send: 0 [30] [20]
avrdude: Recv: t [74]
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x74
avrdude: Send: 0 [30] [20]
avrdude: Recv: 2 [32]
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x32
avrdude: Send: 0 [30] [20]
avrdude: Recv: : [3a]
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3a
avrdude done. Thank you.
If you watch carefully the 10 attempts, you see that the avrdude starts by sending three time the sequence ‘0’ + ’ ’ (a zero, hex code 30, followed by a space, hex code 20), then does a receive, and get a ‘c’ (hex 63). On the next attempt it sends "0 " again and receives a ‘t’, and so on. If you see the characters that it received back during those 10 attempts, they are the serial log emitted by the emonTx: ct1:0,ct2:0,ct3:0,ct4:0,vrms:501,pulse:0
I’m not fully familiar with how a programmer like avrdude interacts with the bootloader in the atmega, but it seems to me that it is sending the string "0 " and hoping for some response from the board that it is not getting.
I also did a similar “verbose” test with an arduino board I have here, and I noticed that the board does respond to the initialization sequence from avrdude:
Using Port : COM4
Using Programmer : arduino
Overriding Baud Rate : 19200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part : ATmega168
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
Any thoughts?
One final comment for today: after seeing in my earlier post that the problem is that the atmega is not entering programming mode, I went looking for the schematics of both the emonTx and the shop programmer.
I see that the programmer that is sold on the online store has the RTS line connected to the pin labeled RST on the emonTx (which shows as DTR on the schematic).
I believe that is my problem: the USB/Serial cable I’m using only has Tx, Rx and GND, no RTS line available. Hence, I’m not sending a reset signal to the micro-processor when programming begins.
I think that is the final word on this.
That is “standard Arduino” method and how the bootloader works for programming mode.
If you can “reset” the atmega at exactly the right time, you can re-program it without an RTS connected to RST. In the very early days of Arduino, that is actually how we used to do it!
So the process for an old Arduino was this:
Hit the “Upload” button in the IDE and watch the output.
As soon as the compiler finished and gave its status, hit the Arduino’s hardware reset button, or short RST to GND.
I faced the same problems as Claudio.
Just bought a emon tx with power supply from the store. Volt reading was 254 instead of 234 V. I got rid of that via calibration.
That leads me to the second problem: uploading to the board.
The UART-Connection reported “not in sync”.
I tried a lot of USB cables aso. The solution came with one of Claudios hints to check the pins.
One can not read the pin allocation of the emon tx when built in the case. So I had the emon tx facing “upside” and the UART facing upside with the blue light. My Mac recognized the USB connection, but no upload possible. Then I took the emon tx board out of the case and it showed that you have to connect the UART-connector “upside down” to get the right pins together. So with the blue light down all worked well.
Regards
Frank
The GND connector on the 6-pin connector should be nearest to the RJ45 connector. (It is shown on the PCB layout drawing emontx3/hardware at master · openenergymonitor/emontx3 · GitHub).