<p dir="ltr">Hi,</p>
<p dir="ltr">On 22 Mar 2016 10:01, "Damon Hart-Davis" <<a href="mailto:dhd@exnet.com">dhd@exnet.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> > On 21 Mar 2016, at 12:13, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
> ><br>
> > Have you confirmed that the value of  newKey being passed to setPrimaryBuilding16ByteSecretKey is as expected? As in it is definitely the storing of the key?</p>
<p dir="ltr">> We were so short of code space that I had not written the code to do so at the time, and wanted not to let someone retrieve the key via the CLI, though I have added a suitable verification routine now.  Yet to be tested.  And I suspect that it won’t see anything useful given that after a reboot the the first time values appear to have reverted to all erased!<br>
><br>
> (The key read routine returns failure if it sees the values as *all* 0xff, and I have never seen an apparently partially-programmed key where the device would try to transmit but the receiver would be unable to decrypt.)</p>
<p dir="ltr">It does sound like the issue is with the writing of the key to the EEPROM but just a debug print of the key first thing would give the confidence that the problem is with the storage of the key.</p>
<p dir="ltr">> > 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?<br>
><br>
> No.<br>
><br>
> But it works fine in all sorts of other contexts!  For example, the RTC has been using the technique since very near the start of V0p2’s life, and the message counters also use it.</p>
<p dir="ltr">And yet it is still failing ;-)</p>
<p dir="ltr">On a serious note there look to be two paths that can be taken one that tries erases the byte and then writes the new value the other that does not do the erase as bits are only cleared.</p>
<p dir="ltr">By disabling the V0P2BASE_EEPROM_SPLIT_ERASE_WRITE option you are making this a single path and hopefully eliminating an area of code where the problem could be.</p>
<p dir="ltr">What build options do I need to enable this section of code? Is this also just literally a one shot deal where the issue is only on the first attempt inbred board and the  never again or can you get the board in to a state where the issue can be reproduced? If so how?</p>
<p dir="ltr">Jeremy</p>
<p dir="ltr">> 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"> http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</p>