[OpenTRV-dev] EEPROM amnesia investigation
Joseph Heenan
joseph at heenan.me.uk
Mon Jun 27 14:27:14 BST 2016
Hi Deniz,
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'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?
Cheers,
Joseph
> On 27 Jun 2016, at 13:16, 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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20160627/19a91628/attachment.html>
More information about the OpenTRV-dev
mailing list