I bought an emonTH off ebay, it would not connect (or rather the emonHP did not see any radio comms from it), suspected that the emonTH firmware was JeeLib (sp?) and not the later LPL, which my recently purchased emonHP would have. So downloaded the latest 4.1.8 from git,… programmed using the ICSP and atmel programmer & studio. No USB serial data on startup, no LED on startup. Tried again in case hex was corrupted on download, again nothing. Downloaded and installed 4.1.7 and it ‘flashed’ the led & spat out serial data on startup and connected to emonHP. So is ver 4.1.8 a working version? My emonth hardware is ver 2.0.2, 2016.
That’s the latest emonTH hardware version. @TrystanLea posted the update earlier this year, there hasn’t been any other reports of it not working. Odd that the LED isn’t lighting up, that’s the very first thing (aside from Arduino’s startup) that happens. v4.1.7 is fine, but you could try compiling your own v4.1.8 and see if that works.
Sorry, not a lot of help but at least a place to start.
Angus, thanks for the reply. Well i programmed 418 (.hex), it didn’t work (as i described) then reprog’ed with 417, then 418 and did this 2 or 3 times and 410 was dead on all occasions (re-downloading 418 in case there was any issues with the downloaded hex file). On the last occasion where it had 417 and I again wanted to program 418, the programming interface had trouble part ID (0xc, the thing that identifies the uP to the programmer, 328P from my memory), it could read the voltage 3v3, although that is likely a feature of the programmer than the emonth board. So i ended up with a working 417 in the hardware and unable to reprogram it!
On the plus side 417 is in and working, on the neg side I can’t reprogram, whether I compile or not.
I guess this will be the first report of 418 not working!
Do we know if there have been other successful deployments of 418 via the Atmel programmer (ICSP)? (iow, have all successful deployments used USB programming)
Was 418 tested on actual 2.0.2 hardware or on an Arduino?
I could try to compile a new hex, but, if it works, then the hex on git is non-working; if it doesn’t work, then both the code and hex on git are non-working?
I will try to compile and see what I get, watch this space.
Ah, I suspect that you have removed the Arduino bootloader if you’ve used the ICSP with a dedicated programmer, rather than just a UART. The .hex file has the application entry at 0x0000, but the normal Arduino fuse setting means the bootloader is first called at 0x3F00 - as this does not exist, the application is not entered. That v4.1.7 worked this way somewhat contradicts that 
but that’s my hypothesis right now. If you can get your programmer to identify the board again (it is an ATmega328P) you can flash the bootloader back on to it and then upload the v4.1.8 firmware using the methods described in the documentation. You’ll also need to be sure you’ve set the fuses correctly.
I’m entirely sure it has been tested, but I don’t have an emonTH2 to work with so @TrystanLea or @glyn.hudson would have to confirm.
Edit: the ATmega328 has the bootloader at the top (higher addresses) of flash, changed accordingly.
Yes, I can’t understand why 417 would work, then install 418 and it does not, then install 417 and it works and install 418 and it does not? Does the eeprom need programmed with any data,… I only programmed the flash. Don’t think the docs made mention of it.
It’s a bit of a paradox, that a stable release would have to programmed into the emonth via the uart, given i have the atmel studio and programmer, I realise this is perhaps a gathering of data suggestion.
Are you in effect suggesting that 418 might indeed work when a bootloader is present, but may not work when bootloader is absent? In that case we need a 419 that does both, or, or the bootloader needs included in the 418 .hex? or 2 version, with or without bootloader.
Does 417 have a bootloader in the hex and 418 not?
I very much doubt the v4.1.7 includes the boot loader - that’s not how the Arduino compilation works, you would have to stitch two .hex files together (which is fine, but not standard). The EEPROM does not matter as that is not executable.
The normal ATmega boot flow depends on the value of the the BOOTRST fuse. This is set to 0 for a normal Arduino configuration. When it’s 0, the processor’s reset vector is set by the value of BOOTSZ[1:0] fuses. When BOOTRST is 1, the processor’s reset vector is 0x0000 where the application is.
I think my recommendation (without having access to any hardware, reference or your’s) is to restore the ATmega328 to its as shipped state (Ardiuno bootloader and fuses), then upload the v4.1.8 firmware through the UART.
I’m happy with a working 417, albeit with slightly reduced battery life. I am reluctant to break a working system,.. that is, somehow get round that fact that the programmer can’t ID the 328P and get 418 into the hardware, then discover it does not connect to my emonHP,… and risk the ID issue again and end up with hardware with installed non working 418 and no ability to reprogram to 417.
I’m thinking, why:-
release hex files without bootloader, if they absolutely need it. I would suggest that agnostic code would be better, it does not care if it has a bootloader is there or not.
Because, if some smarty-pants like me comes along with a ICSP programmer, we spot a hex file and pull the trigger….but we can’t in fact program… I just think it complicates something that does not need further complication.
For the ATmega328, it does not matter - the boot loader is entered according to the chip’s setting, rather than the firmware itself. However, if the chip is configured to reset into the boot loader and the boot loader has been been erased then it won’t work.
The assumption (and it’s a reasonable one) is that the majority of users are not in the position to be using specialised programmers (other than a common UART adapter), compiling their own firmware, or deviating from the user guide.
Sounds like a good idea 
The changes between 4.1.7 and 4.1.8 are fairly small, and as noted it is not easily reproducible. Of course if you feel like going deeper into the problem, it might be of future use.
1 Like
Yea, it would be nice to properly diagnose the issue, I may come back to it, if i can get hold of another 2.0.2 hardware, then i would certainly test.
My last post made some assumptions, but that are just that, re. the bootloader. perhaps we need independent conf or otherwise that 418 (hex) is a working version, it will indeed work without a bootloader, TBC.
Just to confirm, I changed no setting (fuse or others) between programming versions. If the bootloader is a config setting at the programming stage, it was certainly not changed between programming 417 and 418.
1 Like
Using Admin → Update on an emonPi (original) and an OEM Shop serial-to-FTDI programmer, then monitoring the FTDI port with the Arduino IDE:
17:55:31.763 → OpenEnergyMonitor.org
17:55:31.763 → emonTH FW: V4.1.8
17:55:31.862 → Loaded EEPROM config
17:55:31.862 → Group 210, Node 24, Band 433 MHz
17:55:31.862 → pulses enabled = 1
17:55:31.862 → pulse period = 50 ms
17:55:31.862 → DS18B20 enabled = 1
17:55:31.862 → RF on
17:55:31.862 → Serial on
17:55:31.862 → RF power = 7 dBm
17:55:31.862 → RadioFormat: LowPowerLabs
17:55:31.862 → Init RFM…
17:55:31.862 → RFM Started
17:55:31.862 → Int SI7021..
17:55:31.895 → SI7021 Started, ID: 21
17:55:31.995 → temp:19.09,humidity:69.39
17:55:32.658 → DS18B20 found = 1 of 4
17:55:32.658 → , with addresses…
17:55:32.658 → 28 81 43 31 07 00 00 D9
17:55:32.658 → tempex0:166,
17:55:32.658 → Serial on
17:55:32.658 → ‘+++’ then [Enter] for config mode, waiting 3s…
17:55:35.643 → Continuing without entering config mode…
17:55:36.439 → temp:190,tempex0:166,humidity:693,batt:25,pulse:1
17:56:34.959 → temp:192,tempex0:166,humidity:692,batt:25,pulse:1
17:57:33.472 → temp:193,tempex0:166,humidity:686,batt:25,pulse:1
17:58:31.990 → temp:194,tempex0:166,humidity:684,batt:25,pulse:1
Yes.
Is the answer yes if you deploy the update directly to the hardware using the atmel studio & programmer?
Does 418 run successfully if there are no config parameters in eeprom?
As Angus intimated, if the emonTH is updated as anticipated by the designers and therefore as documented, then I think I’ve produced reasonable evidence the answer to your original question is indeed yes. I don’t have the IDE and programmer you used, so I can’t experiment to attempt to find out what you did that wasn’t compatible with that. My emonTH V2.0.2 had V4.1.5 previously.
You should find the answer to that in the documentation for emonEprom library. If the ‘signature’ is used properly, then with or without data in the EEPROM, the sketch should initialise properly.
1 Like
It would appear that (from my ‘experiment’) 417 behaves differently from 418 when programmed directly via the atmel studio and programmer. I tried it 3 times and used a freshly download 418 hex in case it was somehow corrupt.
Is this just not important?
Neither Angus nor I had a direct involvement in the release of V4.1.8. We have done our best with the information available to us to address your concerns, but this would not appear to satisfy you. You need to ask @TrystanLea
I really don’t think it needs to be like this. Anyway you’ve certainly put me in my place.
From my experience 417 can be programmed directly via the atmel studio & programmer, yet 418 can’t (I emphasise, from my multiple attempts).
Anyway thanks for what you were able to do, given you don’t have the same kit. I understand that I strayed from the path,… I could find no advice/warnings on this method of programming; I do not think it is unreasonable to attempt to program via the Atmel Studio & programmer an open source Arduino Uno based product!
@awjlogan has put forward some suggestions for where to look for what you had or hadn’t assumed – and the same goes for @TrystanLea when he published the .hex file, so the ability to use or not use the Microchip IDE and ICSP is something that I think should be at least documented somewhere.
I agree I’d expect the Atmel/Microchip tools to be able to upload to their own device, and the reason you failed is almost certainly one or more oversight and/or assumption somewhere along the line. I’ve been an IEE member for over 50 years, mostly as a projects/systems engineer, so I’ve seen plenty problems as a result of those.
I don’t have a good reason to think you won’t get a fully working emonTH with V4.1.8 if you have a “OEM Shop” programmer and the Arduino IDE or an up-to-date emonCMS on a Raspberry Pi. But you might need to install the right bootloader first. Use anything else and I won’t be quite as certain.
Ditto & Bingo.
In sequential programming sessions (within minutes of each other), 417 goes in and worked, 418 did not, so diffy to understand what those oversights & assumptions would be.
As I said earlier, happy with a working 417.
I’m going to disagree with you and @Robert.Wall here - I do not think that the vendor IDEs should be documented at all. For example, you are using Atmel Studio which is now completely unsupported by Atmel (which no longer exists as it’s now a part of Microchip) and the new Microchip IDE (MPLAB-X) is a pain to use. Things like fuse settings, the build parameters and paths etc are often in obscure places with different values, so for the vast majority of users it represents another set of conditions to identify and for us to diagnose. If people insist on using the vendor tools, it’s on the understanding they are doing so with no reasonable expectation of support.
I would fully endorse documentating tools not tied to the vendor’s IDEs - in this case, avrdude would be the utility of choice. That’s actually listed in the existing documentation already, so I’d be happy to stop there.
I would just be careful here not to conflate Arduino with a “normal” microcontroller development setup. Arduino, for better and worse, made developing and programming microcontrollers accessible for a much larger audience and comes with its own set of conventions and expectations, one of which is that you use the serial bootloader. If you flash the chip using the Atmel tools, unless you maintain the exact settings that Arduino uses and understand exactly what the tool is doing, there is potential to end up in conflict when running software that expects to be running in the Arduino environment. In addition (and one of the reasons I don’t like working with things like Arduino) is that it does things without you knowing (without looking through the logs) - for example here, there is no guarantee that whatever happens before setup() is the same when v4.1.7 and v4.1.8 were compiled.
Anyway - glad you’ve got something running @Staedford, the mystery remains unsolved for the time being. My last suggestion before moving on would be to try to flash the file using the avrdude method in the documentation. If the bootloader is still there and the fuses haven’t been changed (accidentally), this should work to get you to v4.1.8 as that is what the emonCMS updater is running behind the curtain.
I must point out the exact wording I used:
and that explicitly includes, if it is indeed the case “The use of the Microchip IDE and ICSP is not supported.” which at least serves as a caution to anyone contemplating the path that @Staedford went down and indicates that further research might be needed. And rather than a ‘blacklist’, it would undoubtedly be better to take a positive view, e.g. “We can only support the use of the Arduino IDE and emonPi when uploading firmware to the emonTH2”.
I recognise others here would wish to include Platformio, but my experience of that, well documented previously here, is it is malware.
1 Like
Yes, fair points Rob
I’m happy with a makefile and no more (mostly!).