[OpenTRV-dev] EEPROM amnesia investigation

[Deniz Erbilgin]

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/20160628/34e09f77/attachment.html>