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

[Stuart Poulton]

Damon,

If you really wanted an answer / response you could offer a small bounty for preproduction of the problem and a solution.

Sadly too manny people expect the lazy web to do their work for them. At least if you give people the problem they don’t have to respond to say they might be interested in fixing / solving it but need to see the problem first.

Stuart


On 20 Mar 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