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

[Damon Hart-Davis]

> And yet it is still failing ;-)

Indeed.  Reality is such a nuisance!

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

This has been failing on our REV7 boards, but if the problem is code logic then something like a CONFIG_Trial2013Winter_Round2_SECURE_NOHUB should suffice to reproduce it on other hardware.  Running off lower voltage (eg 2.4V rather than 3.3V) may make this problem worse.  Lower supply voltage certainly makes more boards fail until the 32768Hz xtal’s load caps are removed...

I haven’t had chance to attempt to make it reproducible in isolation yet.  And the unit tests I have around this are not yet enough to spot anything.

I have one more major code delivery to try to finish today(ish), then I am going to try to find some way to narrow this issue down.  I’m thinking that locking out interrupts for greater portions of code may help, checking assembler output to make sure that the compiler isn’t migrating code out of such blocks that it should not, putting nap()s between writing bytes, etc ...

Thanks for your thoughts so far.  Keep ‘em coming.  At some point I’ll get the “DUH!” moment…  B^>

Rgds

Damon