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

[Jeremy Poulter]

Just re-read this could be a bit confusing ;-) 'it' in this case is the
problem of the key not being written.

Jeremy

On 21 March 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?
>
> 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?
>
> Jeremy
>
> On 20 March 2016 at 10:50, Damon Hart-Davis <dhd at exnet.com> wrote:
>
>> Hi,
>>
>> OK, some a link for you.
>>
>> The affected routines are:
>>
>> setPrimaryBuilding16ByteSecretKey()
>> getPrimaryBuilding16ByteSecretKey()
>>
>> here:
>>
>>
>> https://github.com/opentrv/OTRadioLink/blob/master/content/OTRadioLink/utility/OTV0P2BASE_Security.cpp
>>
>> 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?
>>
>> 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.
>>
>> Rgds
>>
>> Damon
>>
>>
>> > On 20 Mar 2016, at 10:30, Stuart Poulton <stuart at poulton.org.uk> wrote:
>> >
>> > Damon,
>> >
>> > You might get a better response if you post the code.
>> >
>> > Stuart
>> >
>> > On 20 Mar 2016, at 07:25, Damon Hart-Davis <damon at opentrv.uk> wrote:
>> >
>> >> I have posted a question on the Arduino forum here:
>> >>
>> >> http://forum.arduino.cc/index.php?topic=387790.msg2672097#msg2672097
>> >>
>> >> Rgds
>> >>
>> >> Damon
>> >>
>> >>> On 18 Mar 2016, at 20:12, Damon Hart-Davis <damon at opentrv.uk> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> 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).
>> >>>
>> >>> Lots of use of my favourite search engine is failing to show any
>> evidence of this being a common problem.
>> >>>
>> >>> I have reviewed the code repeatedly and found a minor wrinkle which
>> is merely an inefficiency, not an error.
>> >>>
>> >>> Anyone fancy doing some detective work and then pointing out exactly
>> why I shouldn’t be allowed near a keyboard any more?  B^>
>> >>>
>> >>> Rgds
>> >>>
>> >>> Damon
>> >>> _______________________________________________
>> >>> OpenTRV-dev mailing list
>> >>> OpenTRV-dev at lists.opentrv.org.uk
>> >>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>> >>
>> >> _______________________________________________
>> >> OpenTRV-dev mailing list
>> >> OpenTRV-dev at lists.opentrv.org.uk
>> >> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>> >
>> > _______________________________________________
>> > OpenTRV-dev mailing list
>> > OpenTRV-dev at lists.opentrv.org.uk
>> > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>>
>> _______________________________________________
>> 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/20160322/6a7ba039/attachment.html>