[OpenTRV-dev] AVR (328P) EEPROM puzzler

[Damon Hart-Davis]

Hi,

> On 21 Mar 2016, at 12:13, Jeremy Poulter <jeremy at bigjungle.net> wrote:
> 
> 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?

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!

(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.)

> 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?

No.

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.

Rgds

Damon