[OpenTRV-dev] AVR (328P) EEPROM puzzler

[Jeremy Poulter]

Hi,

On 22 Mar 2016 10:01, "Damon Hart-Davis" <dhd at exnet.com> wrote:
>
> Hi,
>
> > On 21 Mar 2016, at 12:13, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> >
> > Have you confirmed that the value of  newKey being passed to
setPrimaryBuilding16ByteSecretKey is as expected? As in it is definitely
the storing of the key?

> We were so short of code space that I had not written the code to do so
at the time, and wanted not to let someone retrieve the key via the CLI,
though I have added a suitable verification routine now.  Yet to be
tested.  And I suspect that it won’t see anything useful given that after a
reboot the the first time values appear to have reverted to all erased!
>
> (The key read routine returns failure if it sees the values as *all*
0xff, and I have never seen an apparently partially-programmed key where
the device would try to transmit but the receiver would be unable to
decrypt.)

It does sound like the issue is with the writing of the key to the EEPROM
but just a debug print of the key first thing would give the confidence
that the problem is with the storage of the key.

> > On the assumption that it is definitely storing the key I would assume
that in the fail case the EEPROM has been erased and hence the existing key
is 16 0xFF. Therefore when writing the key the eeprom_smart_clear_bits
would be used to set each byte, so have you tried disabling
V0P2BASE_EEPROM_SPLIT_ERASE_WRITE?
>
> No.
>
> But it works fine in all sorts of other contexts!  For example, the RTC
has been using the technique since very near the start of V0p2’s life, and
the message counters also use it.

And yet it is still failing ;-)

On a serious note there look to be two paths that can be taken one that
tries erases the byte and then writes the new value the other that does not
do the erase as bits are only cleared.

By disabling the V0P2BASE_EEPROM_SPLIT_ERASE_WRITE option you are making
this a single path and hopefully eliminating an area of code where the
problem could be.

What build options do I need to enable this section of code? Is this also
just literally a one shot deal where the issue is only on the first attempt
inbred board and the  never again or can you get the board in to a state
where the issue can be reproduced? If so how?

Jeremy

> Rgds
>
> Damon
> _______________________________________________
> OpenTRV-dev mailing list
> OpenTRV-dev at lists.opentrv.org.uk
> http://lists.opentrv.org.uk/listinfo/opentrv-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20160322/165b7d81/attachment.html>