[OpenTRV-dev] EEPROM amnesia investigation

[Adrian Godwin]

Could you test :

Write the key
leave it 'a bit'
dump the whole eeprom
read the key
dump the whole eeprom

Since only the key itself is written to all FFs, and it can be read at
least once (I'm assuming there's no caching involved), I'm wondering if the
read operation is actually performing a write and the above test might
prove that.

Alternatively, it might be writing in some volatile way but failing to
commit it to eeprom. I haven't checked the eeprom data sheet so I don't
know if that's possible. Disrupting the write operation before it's
completed (eg by reading / writing something else without checking the busy
flag) might also do this.



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

> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/dff78b7a/attachment.html>