[OpenTRV-dev] EEPROM amnesia investigation

[Deniz Erbilgin]

I found the cause...We were accidentally erasing it whilst initialising the
secure frame code. *facepalm*

Once again, thanks for the help.

On Tue, Jun 28, 2016 at 1:15 PM, Deniz Erbilgin <deniz.erbilgin at gmail.com>
wrote:

> I can't do any testing today, but I've checked our library functions for
> setting and clearing the key by running them in isolation (on the same
> device) and they seem to work fine.
>
> The code paths for  setting and clearing the key in our main firmware look
> fine as well. It seems we're either doing something really stupid somewhere
> else, or something is interacting poorly.
>
> I'm going to try running the minimum possible config of our firmware that
> can transmit secure frames and work upwards from there.
>
> Thanks for all the input guys.
>
> Regards,
>
> Deniz
>
>
> On Mon, Jun 27, 2016 at 4:45 PM, Joseph Heenan <joseph at heenan.me.uk>
> wrote:
>
>>
>> On 27 Jun 2016, at 15:01, 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?
>>
>> Yes, very similar. (Adrian's suggestion is a good first step on this
>> process.)
>>
>> 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.
>>
>>
>> I'd just focus on keeping the very latest understanding clear. I think an
>> iterative debug approach is inevitable.  I'd hope that each time you
>> perform a new test you end up with new information that rules out a number
>> of possible causes. (If you can't figure out what possible cause a
>> particular test rules out, don't bother doing the test!)
>>
>> Joseph
>>
>>
>> _______________________________________________
>> 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/20160629/6b6c2b58/attachment.html>