Yeah, you are both right, it’s corruption I was thinking about. When working with the OTC less design I had some intermittent issues while stress testing that I couldn’t explain or weed out, no matter what I did. I saw erratic behavior maybe once in 20 or 30 continuous off presses of different durations. I finally managed to figure out that it was flash corruption after one of my mode bytes got corrupted from 10 to 255 (or close). During this test I was not using EEPROM at all, all modes where hard coded, and having the light off for extended period didn’t reset it. So that particular mode byte in the FLASH memory had been corrupted while everything else was OK. Other times the light wouldn’t start, wouldn’t change modes etc etc, even after having it off for ages, and I couldn’t figure it out. That single corrupted mode byte was the key.
So I enabled brown out detection at 1.8V (I am using 85Vs) and have stress tested it for ages, and all those weird issues I’ve experienced are a thing of the past. Now I’ll get a brown out induced reset as soon as the voltage drops too low. Brown out detection does draw power though, so I’ve had to increase cap capacity. 100uF can give me a second or so, but almost all of my driver designs can actually fit 1206 caps so I can go higher. Only one driver couldn’t fit a 1206, but it could fit another 0805 so on that one I’ll be using 2 x 100uF 0805 caps.
In a normal flashlight when you switch the voltage off, the MCU looses power rather quickly. With the OTC less design the MCU lingers a lot longer in that low voltage danger zone, increasing the chances of these kind of issues, but it got me thinking that the corruption probably still can happen on a standard OTC driver with 2.7V MCU, perhaps with near drained cell, turbo mode and/or multiple off clicks after the other. The chance of corruption issues with a normal OTC driver is much smaller than with the OTC less design, but still possible I think.
Depends on the firmware, and I haven’t looked into the other firmware versions that are out there. If the above is what happened to your driver, than you would have to be using the standard 2.7V MCU. You could set brown out detection at 2.7V instead of 1.8V by setting the high fuse to 0xdd. I’m guessing that there won’t be any changes to overall functionality of your driver, but I won’t guarantee it so you’d have to do some testing.