EmonTx - use of EEPROM

danbates · 2018-11-06T15:05:55.384Z

[Edit - RW]
Preface:
This discussion was moved as it wasn’t directly relevant in the original thread. This post is an answer to this question about the way EEPROM data is handled:

Update to 3-Phase PLL sketch

is there a discussion somewhere that discusses the proposed changes?

[/edit]

@TrystanLea Not really, there was no discussion in the sense of a back and forth.
I understand the confusion a little better now, looking back at my message to Robert. I’d simple stated that I’d made changes and put it on github, which could easily of been interpreted as having changed the ‘master’ branch.
@Robert.Wall I’m leaving it to you Robert. Do you think the issue I raised was important?

Robert.Wall · 2018-11-06T15:14:31.534Z

Your problem was your EEPROM had been initialised to valid (but nonsensical) values, which were accepted. It did not contain the default 0xFF that is expected of unused EEPROM memory.

I wrote a proposal for a comprehensive solution that would have allowed many sketches to use the available EEPROM without conflict, I put this forward to the ‘Staff’ but it received at best a luke-warm reception. I’ve not pursued it (though that doesn’t mean I won’t at some future time).

danbates · 2018-11-06T15:50:46.000Z

It’s strange that my eeprom had values other than 0xFF on a brand new device perhaps. The device was an uno copy, not official arduino, for a budget project… Is there documentation on what the default values are meant to be?

If my problem getting a tx shield to work is a minor issue pertaining to these non-official copies then the value of the work in implementing a signature check has to be reassessed.

danbates · 2018-11-06T19:06:54.017Z

I’ve remembered now, it was actually an official uno I used, not the budget uno from Conrad.
I think the question of whether there really is an issue, and how important it is to address, has still not been answered directly and clearly.

danbates · 2018-11-06T19:57:19.983Z

@TrystanLea apart from discussion of the solution, here’s discussion of the original issue.

Uno. emonTx Shield. 3Phase. RFM69. - - - Recommended firmware? emonTx

That was the problem yes, except mine’s an Uno. … NL & CR works! +++ now lists available commands and all is beautifully intuitive Wonderful work. So the program checks for data in eeprom, and if nothing is found default values are used defined in the sketch… Hence out of the box functionality with emonTx?.. With my uno/TxShield the eeprom values were ‘nan’ but their use was attempted regardless, meaning I had to write to the eeprom to get any usable values transmitted. No big …

The posts before number 15 are a garbled collection of my attempts at getting it working.

Greebo · 2018-11-06T20:18:51.035Z

There is confusing information out there on a “cleared” EEPROM.
If you use avrdude to erase the chip (avrdude -e), all values are set to the factory default of 0xff, unless the “don’t erase the EEPROM” fuse is set (high byte, bit 3). This will also remove the Arduino bootloader, so don’t do this! I mention it only to indicate what the “default” value is supposed to be.

If you go to the Arduino EEPROM library and grab the “EEPROM Clear” example sketch, it will set all EEPROM values to 0x00, which is not “Cleared” by any definition in the datasheet.

ATmega328p Datasheet (Page 308 Section 25.8):

The Chip Erase operation turns the content of every memory location in both the Program and EEPROM arrays into 0xFF

Robert.Wall · 2018-11-06T20:38:06.895Z

That’s exactly as I understand it, the “as manufactured” state of any EEPROM is 0xFF. It is why the ‘erase’ option in the function writes that to ‘erase’ the stored values, and the reason why it looks for 0xFF to signify that the EEPROM is unused.

Greebo · 2018-11-06T21:35:40.399Z

The realisation I came to this morning is that the EEPROM library example code includes a “Clear” example which does not reset the EEPROM to default, instead it actually fills it with zero’s.

Based on that would it be sensible to look for either 0xff or 0x00 in the EEPROM bytes to signify “unused”?

danbates · 2018-11-06T21:56:43.000Z

For whatever reason, this default 0xFF spec didn’t match up with the uno I bought. I can’t say if it was set to 0x00 instead…

I’ll copy in the relevant image from a brand new official uno with the unaltered original firmware installed…

The question here is… What on earth is ‘nan’ representing??

Screen Shot 2018-07-28 at 20.20.26.png983×493 39.1 KB

danbates · 2018-11-06T22:17:44.391Z

I’ve posted on the arduino forum asking to find out what the default values are for their official boards.

Robert.Wall · 2018-11-06T22:20:20.862Z

The 3-phase sketch follows exactly the same methodology as the emonTx V3 sketch in its use of the EEPROM, and backwards compatibility seemed an important consideration. My proposed protocol does consider 0x00 and 0xFF as indicating “unused” status.

Greebo · 2018-11-06T22:32:50.192Z

Update to 3-Phase PLL sketch

My proposed protocol does consider 0x00 and 0xFF as indicating “unused” status.

I agree completely with this proposal, and as far as I’m concerned, it should go into all of the various versions of the emonTx firmware. Did that proposal go any further than that PM you sent previously?

Greebo · 2018-11-06T22:47:38.999Z

Update to 3-Phase PLL sketch

The question here is… What on earth is ‘nan’ representing??

That output comes from the config.ino file here
So the “nan” you are seeing is a direct result of Serial.println() trying to print those float memory locations that do not contain float values. The relevant EEPROM locations may in actual fact contain 0xFF’s but because the first byte of EEPROM did NOT contain 0xFF, the remainder of the values were assumed to be appropriate.

The relevant bits of code are line 48 and the section from lines 55 down to 75 here:

github.com

openenergymonitor/emontx-3phase/blob/fca9f386e72c6cbab6493bb6492cb0634a2ed360/src/config.ino#L48-L77


      
          struct eeprom {byte nodeID; byte RF_freq; byte networkGroup; float vCal, i1Cal, i1Lead, i2Cal, i2Lead, i3Cal, i3Lead, i4Cal, i4Lead;} data;
          
          byte value;
          
           
          static void load_config(bool verbose)
          {
            byte* src = (byte *)&data;
            bool dataPresent = (EEPROM.read(0) != 255);
           
           
            if (dataPresent)
            {
                for (byte j=0; j<sizeof(data); j++, src++)
                      *src = EEPROM.read(j);
          
                nodeID       = data.nodeID;
          //    RF_freq      = data.RF_freq;
                networkGroup = data.networkGroup;
                vCal         = data.vCal;

This file has been truncated. show original

danbates · 2018-11-07T12:51:36.140Z

Update to 3-Phase PLL sketch

The 3-phase sketch follows exactly the same methodology as the emonTx V3 sketch in its use of the EEPROM

I understand now why you went to the effort of a proposal to them both regarding a change to the method.
The emonV3 sketch has not taken all possibilities into account it seems.

.

The response on the Arduino forum:

You will seldom, if ever, see an actual Arduino "factory" response.

A search brings up three different threads on the Arduino forum suggesting 0xFF is meant to be the default.

.

Checking for 0x00 or 0xFF is better I agree. Would there be a problem with backwards compatibility if 0x00 were used as a check?

.

A signature check would be an easy-to-implement change and relatively fail-safe, but isn’t backwards compatible.

Robert.Wall · 2018-11-07T17:47:38.962Z

Greebo:

Did that proposal go any further than that PM you sent previously?

No, is the short answer. As I wrote at the top (post no.2), I might pursue the idea at some stage.

The simple answer to anyone encountering the same problem that @danbates had, is simply invoke the “r - restore sketch defaults” option, which does in fact erase the EEPROM, whereupon the default values will be read from the sketch.

danbates · 2018-11-08T17:44:59.000Z

To move this forward Glyn and/or Trys need to make a decision on whether to implement one of the solutions at a future date, or not if they like.

When I made the signature check change of RW’s firmware Trys seemed to enjoy the idea. Not sure if it was the fact that I’d actually achieved something, or the work result.

Either solution will work, the simplest is the introduction of the 0x00 check, which I think will work fine.

Not in my hands. Unless asked to help.