I think you should read my post #1523. If you have, read it again.
I wasn’t doing any writes, and I proved that flash memory got corrupted. I don’t think it’s worth arguing that it can’t happen, the datasheet specifically says it can and addresses the issue on page 145. Their recommendations are: Use BOD, or don’t run code.
While weeding out these issues I wasn’t using a fancy full featured firmware, it was as simple as it could be. A few modes and off time detection with OTC less design. No EEPROM usage, LVP or anything else really.
hmm seems I might have misunderstood e-switches. I can't say you're wrong. Anyway, still does it matter? Mike C's sleep numbers even with BOD are something like 0.8 mW of power draw if I did that right.
1/2 CV^2 / t
C= 1E-4F (100 uF)
V=4V (actually less)
t=3s ... ish (edit: should be more like 1, correcting below)
and I get that all comes to about 0.8mW, rounding up (using 1 s).
A single 18650 has about 10Whr of energy. So that's about 12,000 hours or aout 1.5 years. Ok, that's short enough to matter, but maybe isn't a deal breaker. My drain estimate is pretty high since I did it as if the cap fully drains from from 4V in his sleep mode, which it doesn't.
So definitely the standard should be 2.7V BOD or V-variant chips with 1.8V BOD and essentially nobody should ever have BOD off except maybe in protected cell lights with high cutoff values.
So 100uf caps then. "a second or so" sounds good enough to me. 1.5 would help. Beyond that, not sure it's useful anyway. It seems like this is where things are stuck then.
Probably less, but as I have 1206 or 2 x 0805 capacity I don’t really need to bother about it. I can do a quick test on it later.
BOD is the biggest power thief in the OTC less design. I was asking Flashy Mike earlier about his firmware I was interested in stress testing it to see if I could get the same issues. This was just before I found BOD to be the solution. As far as I know, Flashy Mike is the only other person that has been running OTC less firmware, I’d like to hear what his experiences are.
I have been stress testing a lot, for “normal” usage you might get by without BOD. I don’t have to, so I’ll have it on as I hate any chance of issues.
It seems atmel is well aware of this. You can start reading around the second paragraph of page 6. I haven't digested it all. I think the solutions discussed there refer to hardware advancement and probably can't be implemented by software alone. The gist of it is that BOD should run when code is running but be off during sleep. Maybe it's possible to add this functionality in through an external oscillator?
However, see page 35 of the regular manual for the "BOD disable" feature. However, notice that it implies a longer wake time. So this may rob power back if wakes are too frequent?
I don't know maybe these tricks are already factored in. Sorry for the noise if it's all known.
Your numbers assume that the cell is full to begin with. The battery can be run down by using the light and then left for months. Depending on the light and even with a full battery, parasitic drain time to deplete a cell range from 4months(nitecore tip or some 6v drivers without LDO) to 3 years. However, there is self discharge involved as well.
Anyway, if a light is used and the battery is low, it is definitely possible for the parasitic drain to deplete a cell. It seems I’ve been seeing this though I am not certain. This is why I ask if there is software or hardware to account for this.
Interesting stuff about picoPower. Something to look into, in particular the “sleep walking” feature. Personally I’ve been working with solving the OTC less issues a little too long, now that I have PCB boards on the way from OSH Park I want to focus on actually building some lights when I return from work traveling in two weeks.
In regards to BOD software disable, I think TomE does that in Narsil. E-switch only drivers are not my cup of tea though. I need BOD enabled during sleep with OTC less design because the MCU only sleeps while the cap is powering the MCU during off press, and that’s when these corruption issues can happen.
As I understood it, the claim is that this BOD disable is the last thing to happen when entering sleep and the first when waking and no code is executed while BOD is disabled. So BOD should be disabled only between your wakeups, but not during them.
"If BOD is disabled by software, the BOD function is turned off immediately after entering the sleep mode. Upon wake-up from sleep, BOD is automatically enabled again. This ensures safe operation in case the VCC level has dropped during the sleep period."
That lines up with the description from the white paper too.
It's just a rough ballpark. I oversitmated drain significantly anyway, and yet this also assumes that sleep is similar to how Mike C has his setup, BOD and all. Yes, 1.5 years is not so huge to be irrelevant.
Ahhh, now the penny dropped. I missed that in the datasheet. If that works, then that solves the need for higher caps and ensuring stability. Definately worth giving a go.
well, the longer wake up time still sounds like trouble. This is probably meant for leaving things off for hours/days/months, not for a quarter of a second. Only testing can see probably. Although, there's still the digital trick which it seems may be capable of waking on demand?
From what I can see, startup time would be same as from reset. In my fuses I already have a long startup time, so maybe it won’t be so bad… But, as you say, can only find out by testing.
"In some devices it is possible to save power by disabling the BOD by software in Power-Down sleep mode."
My bold. I missed that before. So maybe this is only available in devices listed as supporting "picopower" or maybe some other subset of devices. Will it work with a vanilla chip or does it require one of the automotive grade chips for instance? I can't say at the moment.
Seems like it should work on these chips (was right there on next page of datasheet), but was difficult or impossible in practice.
And it looks like if anyone ever got this working, it would have been Tom E, so probably best to get input from him or dig into narsil.
Edit: and it seems that thread re-emerged in post 949 of this thread, a page or two later and it looks like Tom gave up. That's as far as I got so far.
Here we go, this guy seems to think he got it working, with code posted:
And in fact he has one chip where it works and one where it doesn't. You'd think all these years later maybe all the old stock would be used up, but who knows.
Even the note about revisions seems to have been revised:
There he quotes 7.2.1 of the datasheet as saying all attiny 45 revisions should work. The present data sheet though only says attiny 45 revision D and newer work.
I still doubt whether using ADC to poll for power loss detection is a good idea.
I have been using 2 EDCs with OTC-less-design for a couple of weeks now and never faced any issues (modified BLF X6 driver with Attiny 25 and 105D with Attiny 13A). But my drivers don’t poll for power loss, they use pin interrupt on a dedicated pin. I also tested pin interrupt on the voltage divider before and it also worked clueless. I don’t even fuse BOD (with BOD disabled during wake up) since I had some problems there.
The sleep periodes during power loss are rather short, only 30 ms for fast reaction. My driver detects two switching durations: shorter than 250 ms for short clicks and from 250 to 600 ms for long clicks. When clicking longer than 600 ms the driver firmware initializes as from setup.
I noticed the driver needs a buffer cap of 100 uF when cell is depleted to 2.8V in order to survive the long click period. Bleeder value is 1k in one light and 2.2k in the other one.
There is no noticable temperature dependency anymore with OTC-less design. Switching behaviour is identical with cold and burning hot light.
