[OpenTRV-dev] EEPROM amnesia investigation

[Deniz Erbilgin]

Hi Joseph,

One approach would be first finding a situation where the EEPROM write of
> the key behaves correctly when writing the key (which may be on say, a dev
> board), and then changing variables in the test of the real system aiming
> to make everything the same as the working case until it starts working,
> then we know what breaks it
>
I guess this is similar to Adrian's suggestion?

I've gone through the docs and tried to figure out what is the simplest
> reproducible situation where the key is lost. I'm not sure if that is
> documented in the wiki or not, but couldn't see it, perhaps you can share
> your thoughts?
>
So far, with our current firmware release, writing the key and waiting a
bit is enough. I'm still working on finding anything more specific.


By the way, I'm not really sure how to structure this properly (as you may
have noticed) so I'd be grateful if anyone can point me to a good example
to go on, or suggest other things that should be included.




On Mon, Jun 27, 2016 at 2:42 PM, Deniz Erbilgin <deniz.erbilgin at gmail.com>
wrote:

> Is the whole EEPROM erased or just the key ?
>>
> Just the key.
>
> Here's a section of the EEPROM before and after key loss, with the key
> location in bold (the rest of it is empty anyway):
>
> With key:
>
> :20000000FFFFFF04FFFF0AFF000007FFFFFFFFFFFFFFFFFFBDA7ACE59BB180B7FFFFFFFF66
> :20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
> :20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
> :20006000FFFFFFFFFFFFFFFFF1E7470DF1E7470D*00112233445566778899AABBCCDDEE01*36
>
> After key loss:
>
> :20000000FFFF01048D130FFF000003FFFFFFFFFFFFFFFFFFBDA7ACE59BB180B7FFFFFFFFC1
> :20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
> :20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
> :20006000FFFFFFFFFFFFFFFFF1E74311F1E74311*FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF*40
>
>
>
> Do you have any sample code with no other OpenTRV parts :  does that also
>> fail ?
>>
> I forgot to write that down. Thanks for the reminder.
>
>
> On Mon, Jun 27, 2016 at 2:08 PM, Adrian Godwin <artgodwin at gmail.com>
> wrote:
>
>> Further tests :
>>
>> Is the whole EEPROM erased or just the key ?
>> Do you have any sample code with no other OpenTRV parts :  does that also
>> fail ?
>>
>>
>> On Mon, Jun 27, 2016 at 1:16 PM, Deniz Erbilgin <deniz.erbilgin at gmail.com
>> > wrote:
>>
>>> Hi Guys,
>>>
>>> I've started trying to isolate our problem with the keys and node IDs
>>> not being retained in EEPROM.
>>>
>>> A quick summary and links to an ongoing write up can be found in our
>>> wiki:
>>> https://github.com/opentrv/OTWiki/wiki/Key-Amnesia-Investigation
>>>
>>> Summary copied from the wiki:
>>>
>>>    - The key is definitely written to EEPROM.
>>>    - The key is always lost to all FFs.
>>>    - Key loss and retention are independent of resetting and
>>>    power-cycling.
>>>    - Long term key retention only seems to require the EEPROM location
>>>    to be written to and then cleared first.
>>>
>>> I'd appreciate any ideas and input people can give me because the more I
>>> investigate, the more bizarre this seems.
>>>
>>> Regards,
>>>
>>> Deniz
>>>
>>> _______________________________________________
>>> 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/20160627/3eab4893/attachment.html>