<div dir="ltr"><div><div><div><div>Could you test :<br><br></div>Write the key<br></div>leave it 'a bit'<br></div>dump the whole eeprom<br></div><div>read the key<br></div><div>dump the whole eeprom<br><br></div>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.<br><br>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.<br><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 3:01 PM, Deniz Erbilgin <span dir="ltr"><<a href="mailto:deniz.erbilgin@gmail.com" target="_blank">deniz.erbilgin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Joseph,<span class=""><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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<br></blockquote></span>I guess this is similar to Adrian's suggestion?<span class=""><br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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?<br></blockquote></span>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.<br><br><br></div><div>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.<br></div><div><br><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 2:42 PM, Deniz Erbilgin <span dir="ltr"><<a href="mailto:deniz.erbilgin@gmail.com" target="_blank">deniz.erbilgin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>Is the whole EEPROM erased or just the key ?<br></div></blockquote></span><div>Just the key.<br><br>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):<br></div><div><br></div>With key:<br><div><pre>:20000000FFFFFF04FFFF0AFF000007FFFFFFFFFFFFFFFFFFBDA7ACE59BB180B7FFFFFFFF66
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:20006000FFFFFFFFFFFFFFFFF1E7470DF1E7470D<b>00112233445566778899AABBCCDDEE01</b>36</pre>After key loss:<br><pre>:20000000FFFF01048D130FFF000003FFFFFFFFFFFFFFFFFFBDA7ACE59BB180B7FFFFFFFFC1
:20002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:20004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:20006000FFFFFFFFFFFFFFFFF1E74311F1E74311<b>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF</b>40</pre><br></div><span><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Do you have any sample code with no other OpenTRV parts : does that also fail ?<br></blockquote></div></span><div>I forgot to write that down. Thanks for the reminder.<br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 2:08 PM, Adrian Godwin <span dir="ltr"><<a href="mailto:artgodwin@gmail.com" target="_blank">artgodwin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Further tests :<br><br></div>Is the whole EEPROM erased or just the key ?<br></div>Do you have any sample code with no other OpenTRV parts : does that also fail ?<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jun 27, 2016 at 1:16 PM, Deniz Erbilgin <span dir="ltr"><<a href="mailto:deniz.erbilgin@gmail.com" target="_blank">deniz.erbilgin@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div>Hi Guys,<br><br></div>I've started trying to isolate our problem with the keys and node IDs not being retained in EEPROM.<br><br>A quick summary and links to an ongoing write up can be found in our wiki:<br><a href="https://github.com/opentrv/OTWiki/wiki/Key-Amnesia-Investigation" target="_blank">https://github.com/opentrv/OTWiki/wiki/Key-Amnesia-Investigation</a><br><br></div><div>Summary copied from the wiki:<br><ul><li>The key is definitely written to EEPROM.</li><li>The key is always lost to all FFs.</li><li>Key loss and retention are independent of resetting and power-cycling.</li><li>Long term key retention only seems to require the EEPROM location to be written to and then cleared first.</li></ul></div>I'd appreciate any ideas and input people can give me because the more I investigate, the more bizarre this seems.<br><br></div>Regards,<br><br></div>Deniz<br></div>
<br></div></div>_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk" target="_blank">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk" target="_blank">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
<br></blockquote></div><br></div>