<div dir="ltr">Have you confirmed that the value of  newKey being passed to <span style="font-size:12.8px">setPrimaryBuilding16ByteSecret</span><span style="font-size:12.8px">Key </span>is as expected? As in it is definitely the storing of the key?<div><br></div><div>On the assumption that it is definitely storing the key I would assume that in the fail case the EEPROM has been erased and hence the existing key is 16 0xFF. Therefore when writing the key the eeprom_smart_clear_bits would be used to set each byte, so have you tried disabling V0P2BASE_EEPROM_SPLIT_ERASE_WRITE?</div><div><div><div><br></div><div>Jeremy</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 March 2016 at 10:50, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
OK, some a link for you.<br>
<br>
The affected routines are:<br>
<br>
setPrimaryBuilding16ByteSecretKey()<br>
getPrimaryBuilding16ByteSecretKey()<br>
<br>
here:<br>
<br>
<a href="https://github.com/opentrv/OTRadioLink/blob/master/content/OTRadioLink/utility/OTV0P2BASE_Security.cpp" rel="noreferrer" target="_blank">https://github.com/opentrv/OTRadioLink/blob/master/content/OTRadioLink/utility/OTV0P2BASE_Security.cpp</a><br>
<br>
Obviously there's a lot of code behind that, but the point is that EEPROM has been working well up and as expected until this point, and this failure mode is bizarre and worrying.  Does the EEPROM logic flake out if you try to write more than about 8 bytes in quick succession?  Do I need to inject pauses or sleeps?  What did I miss in the data sheet?<br>
<br>
I haven’t isolated a small test case from this large lump of code yet (and won’t have time to for a while); I wanted to see if this was already known about.<br>
<br>
Rgds<br>
<span class="HOEnZb"><font color="#888888"><br>
Damon<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On 20 Mar 2016, at 10:30, Stuart Poulton <<a href="mailto:stuart@poulton.org.uk">stuart@poulton.org.uk</a>> wrote:<br>
><br>
> Damon,<br>
><br>
> You might get a better response if you post the code.<br>
><br>
> Stuart<br>
><br>
> On 20 Mar 2016, at 07:25, Damon Hart-Davis <<a href="mailto:damon@opentrv.uk">damon@opentrv.uk</a>> wrote:<br>
><br>
>> I have posted a question on the Arduino forum here:<br>
>><br>
>> <a href="http://forum.arduino.cc/index.php?topic=387790.msg2672097#msg2672097" rel="noreferrer" target="_blank">http://forum.arduino.cc/index.php?topic=387790.msg2672097#msg2672097</a><br>
>><br>
>> Rgds<br>
>><br>
>> Damon<br>
>><br>
>>> On 18 Mar 2016, at 20:12, Damon Hart-Davis <<a href="mailto:damon@opentrv.uk">damon@opentrv.uk</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> We are seeing some bizarre behaviour where when we try to write a 16-byte key into EEPROM it fails to ‘stick’ properly the first time.  If the board is power-cycled and the key is written again, it appears to stick as expected.  (There’s some subtle sub-wierdnesses also.)  This uses some ‘careful’ update routines that we use extensively elsewhere and seem to be fine with blocks as large as 8 bytes long (node IDs).<br>
>>><br>
>>> Lots of use of my favourite search engine is failing to show any evidence of this being a common problem.<br>
>>><br>
>>> I have reviewed the code repeatedly and found a minor wrinkle which is merely an inefficiency, not an error.<br>
>>><br>
>>> Anyone fancy doing some detective work and then pointing out exactly why I shouldn’t be allowed near a keyboard any more?  B^><br>
>>><br>
>>> Rgds<br>
>>><br>
>>> Damon<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>
>> _______________________________________________<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>
> _______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>