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

[Bo Herrmannsen]

remember to post that on the arduino forum also

2016-03-20 11:50 GMT+01:00 Damon Hart-Davis <dhd at exnet.com>:

> 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/20160320/f8a9ff24/attachment.html>