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

[Jeremy Poulter]

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?

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?

Jeremy

On 20 March 2016 at 10:50, Damon Hart-Davis <dhd at exnet.com> wrote:

> Hi,
>
> OK, some a link for you.
>
> The affected routines are:
>
> setPrimaryBuilding16ByteSecretKey()
> getPrimaryBuilding16ByteSecretKey()
>
> here:
>
>
> https://github.com/opentrv/OTRadioLink/blob/master/content/OTRadioLink/utility/OTV0P2BASE_Security.cpp
>
> Obviously there's a lot of code behind that, but the point is that EEPROM
> has been working well up and as expected until this point, and this failure
> mode is bizarre and worrying.  Does the EEPROM logic flake out if you try
> to write more than about 8 bytes in quick succession?  Do I need to inject
> pauses or sleeps?  What did I miss in the data sheet?
>
> I haven’t isolated a small test case from this large lump of code yet (and
> won’t have time to for a while); I wanted to see if this was already known
> about.
>
> Rgds
>
> Damon
>
>
> > On 20 Mar 2016, at 10:30, Stuart Poulton <stuart at poulton.org.uk> wrote:
> >
> > Damon,
> >
> > You might get a better response if you post the code.
> >
> > Stuart
> >
> > On 20 Mar 2016, at 07:25, Damon Hart-Davis <damon at opentrv.uk> wrote:
> >
> >> I have posted a question on the Arduino forum here:
> >>
> >> http://forum.arduino.cc/index.php?topic=387790.msg2672097#msg2672097
> >>
> >> Rgds
> >>
> >> Damon
> >>
> >>> On 18 Mar 2016, at 20:12, Damon Hart-Davis <damon at opentrv.uk> wrote:
> >>>
> >>> Hi,
> >>>
> >>> We are seeing some bizarre behaviour where when we try to write a
> 16-byte key into EEPROM it fails to ‘stick’ properly the first time.  If
> the board is power-cycled and the key is written again, it appears to stick
> as expected.  (There’s some subtle sub-wierdnesses also.)  This uses some
> ‘careful’ update routines that we use extensively elsewhere and seem to be
> fine with blocks as large as 8 bytes long (node IDs).
> >>>
> >>> Lots of use of my favourite search engine is failing to show any
> evidence of this being a common problem.
> >>>
> >>> I have reviewed the code repeatedly and found a minor wrinkle which is
> merely an inefficiency, not an error.
> >>>
> >>> Anyone fancy doing some detective work and then pointing out exactly
> why I shouldn’t be allowed near a keyboard any more?  B^>
> >>>
> >>> Rgds
> >>>
> >>> Damon
> >>> _______________________________________________
> >>> OpenTRV-dev mailing list
> >>> OpenTRV-dev at lists.opentrv.org.uk
> >>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >>
> >> _______________________________________________
> >> OpenTRV-dev mailing list
> >> OpenTRV-dev at lists.opentrv.org.uk
> >> http://lists.opentrv.org.uk/listinfo/opentrv-dev
> >
> > _______________________________________________
> > OpenTRV-dev mailing list
> > OpenTRV-dev at lists.opentrv.org.uk
> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
> _______________________________________________
> 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/20160321/bd2d13c7/attachment.html>