No, unfortunately - no temp monitoring, but still have about a 45's worth of code space left, without much in optimizations done. Soooo, is this voltage spike lockup common? I don't recall seeing this much, if at all? What do you think? Is it ok? Is there a fix? Not many questions.... 
It depends a lot on the layout, etc., but when you've got a lot of batteries and some capacitors in there if you "bounce the switch" or connection you'll generate some pretty big voltage spikes. If you want to take a read, here's a good one.
As long as it doesn't do it with a solid connection and it doesn't blow anything up, then I'd probably just leave it, but if it does it under normal use then yeah I'd say there's a problem. If you remove C1 capacitor then put that 10uF on the C2 cap. location you should have less audible noise in the circuit and it will probably help your switch bounce problem (leave C1 blank).
I’ve got the new version installed, and the ramping updates are very nice. 
I haven’t thoroughly tested everything though. The only “bug” I’ve encountered is something which is likely not easy to do anything about — triple-click for battcheck changes the remembered mode to turbo (since it passes through double-click-turbo to get there). It’d probably require a fair amount of reworking for input handling in order to change that though, so that it won’t act on intermediate steps of an input sequence. What I have in mind is to define a sequence for each action.
At a guess, every complete sequence will have to end in release then timeout to avoid side effects… but intermediate steps could be bound to actions if desired too. For example, on zebralights, battcheck is four clicks from off but it goes through high, medium, and (low or strobe) first:
- “off: click” for high
- “off: click, click” for medium
- “off: click, click, click” for (low or strobe)
- “off: click, click, click, click, timeout” for battcheck
That lets it respond quickly to the earlier actions without waiting for timeout to mark the sequence as complete. It also means going through multiple modes before the last one is reached, which is sometimes not desirable. To avoid intermediate steps firing off, this could be done instead:
- “off: click, timeout” for on (remember last-used mode) (timeout optional)
- “off: click, click, timeout” for turbo
- “off: click, click, click, timeout” for battcheck
And so on. Then the light wouldn’t activate turbo since it doesn’t get a timeout after two clicks.
Or perhaps it could still activate on intermediate steps but not save the new mode until a timeout hits.
- “off: click” for on (remember last-used mode)
- “off: click, click” for turbo
- “off: click, click, timeout” for saving new mode (optional, may not want to save turbo anyway)
- “off: click, click, click, timeout” for battcheck
Haven’t fully worked out the spec language for input sequences though. Some things need to act on button down, some on button up/release, some on down+up+timeout, some on down+timeout (long-press), some on down+timeout+tick (activate every “frame” after long-press is established), some on down+timeout+up, and so on. I’m thinking I might shorten down+up events retroactively to just “click”. Will have to experiment to see what works in practice.
I’m not sure if it would help, but one thing to maybe try is to make the MCU delay for a quarter second or something on initial boot before attempting to do anything else. I think there’s even a fuse setting to give it a longer boot delay, to help it ensure stable power before taking any actions.
(edit: looks like you may already be doing the fuse method if you’re using E2 / DF / FF, which enables the 64ms startup delay)
I noticed the behavior of the triple-click batt check too - thought about it, thought of acting on dbl and triple clicks in a delayed method, pretty much exactly as you said -- great minds think alike! But really, it's a neater way of handling it, downside is potential delay. I sped up the dbl-click/triple-click requirement (dead time went from 16 ticks to 14 ticks), but not really related to this issue. I also don't like having to go thru max and/or an intense strobe in order to get to config settings, as it does now.
For the startup issue, I have delays to do the 2 blinks now. Also, mods I made for possible fixes was to add a 400 msec delay in the WDT interrupt handler initially, and to re-init some key variables prior to entering the main loop, plus start out more cleanly by init'ing components explicitly. My thoughts were that with the caps, that some devices were powering down while others were not, so there was some things getting out of sync.
The 4th byte I added for validating the stored config settings made a real difference - config setting no longer get corrupted - not once, since the mod - it was reproducible.
Richard - interesting proposal! Thanx! Might have to try that! I'll be asking DEL as well. I still need to do more testing on the V3 board also, as per DEL's suggestions.
I don’t remember reading that and I doubt it by what I could find in the specs (0.015 mA for the voltage reference). If it is a problem, it can be disabled in software while powering down. It’s worth at least trying it next time you flash the MCU.
texaspyro told me in this thread here: https://budgetlightforum.com/t/-/34900/371, post #371.
It's not much though, DEL is recommending to try it too, so it's next on the hit list. Populating the zener on the BLF Q8 driver didn't seem to make a difference. It takes as little as 8 secs, or hi as 90 secs to reproduce it of constant power ON/OFFs, and it's not always locked up, mostly operations still work, just the LED came on very bright, maybe max.
K - the brown-out detection set to 1.8V seemed to fix the problem -- 4+ minutes and cannot reproduce it. When it would fail, longest it ever took was 90 secs, and in 4 mins it would fail at least 4 times. Sure would like to try what Halo suggests to shut it off after up and running. Parasitic drain is bumped up, speculating by 2.5 times.
Anyone know if the addition of the zener diode on the MTN17DDm v1.1 bumps up parasitic drain by a lot? Like 40X higher? Dunno, but first time I think I looked at it on a fully assembled MTN17DDm v1.1 and was expecting 0.016 mA but measured 0.69 mA. I checked on other drivers/lights, same firmware and measured 0.015 mA and 0.016 mA on 2 lights with my 85 mods.
I just tested a MTN-17DDm with no load on it, R1: 19.1K R2: 4.7K with attiny25 and Bistro @ 3.6V in: 4.7mA.
For kicks, I measured the same driver before flashing the MCU: 0.81mA. Without zener diode: 0.83mA (I think this is a measurement/meter variance and that the current draw did not really increase). At any rate, the difference is not enough to worry about.
Now, this is through my multi-meter so there is some burden voltage. For accurate and precise small current results we are really wasting time trying to measure it with these meters---you really need something like a uCurrent.
The zener diode will burn a little extra juice when you are in the middle modes especially because that it when it is snubbing the most, but at 100% there should be no difference and at low duty cycles very little difference. There may be a large difference however in reverse leakage current on different diodes, so that may affect your numbers quite a bit.
Anything under 1 mA resting and I'm not worried about it...but that's just me. With a 3000mAh battery in there you will get roughly 4 months before the battery gets low. If it's not going to get used for that long then physically lock out the light! In a soupcan light you're talking about well over a year before they get low.
If I understand correctly, the concern is the effect on standby current in sleep mode with all emitters off, for e-switch lights.
From what I recall, it was about 0.32mA with 19.1K and 4.7K resistors, or about 0.16mA if the MCU’s ADC circuit is turned off first. Raising that to 191K and 47K resistors cut the standby current to like 0.016mA. This brings the parasitic current down to about the level of the cell’s self-drain, so it doesn’t really matter if an e-switch light is locked out or left connected to power while not in use. Pretty nice.
I seem to recall something about using an LDO instead of Zener on multi-cell e-switch lights, due to high standby drain with the Zener. Does that still apply for a MTN-17DDm in a single-cell e-switch light?
My goal is to have and keep parasitic drain as low a possible. A 1 mA drain means 1,000 hours to drain 1 amp, so that's 42 days to drain a full 1 amp, which is 1/3 the capacity of a 30Q cell for example. To me, that's not a good thing for a DD FET based light, and not for a light in an off or standby state. I've measured a few recent model e-switch lights, like Nitecore's, Sunwayman's, etc., and most are below 0.030 mA. The Manker U21 for example is 0.008 mA, posted in my review. I'm using a Fluke DMM to take these measurements, and I think it does a fairly accurate job. All the #'s I've gotten seem to make sense from what we've calculated.
With the 85/Narsil using the higher resistor value (no zener) and brown-out detection disabled, I get pretty consistent readings - light OFF:
MCU running: 4.6-4.9 mA (depending on cell level), on standby: 0.015-0.016 mA
Right now on the BLF Q8 with the zener and with brown-out detection enabled:
MCU running: 6.39 mA, Standby: 1.8 mA
SupFire L5 using the MTN17DDmm v1.1 running 85/Narsil, high value resistors:
MCU running: 4.8 mA, Standby: 0.69 mA
I'll pull the zener from the BLF Q8, since we probably don't need it now, and re-test.
Edit/Update: pulled the zener using the hot air reflow station on the BLF Q8 w/brown-out detection enabled, now I get:
MCU running: 4.96 mA, Standby: 0.037 mA
Standby went down from 1.8 mA to 0.037 mA, so the zener seems to be a significant factor, at least with this driver/firmware.
I also re-tested and still can't reproduce the problem after 3 minutes of constant power fluctuations. So I think it comes down to is the fix worth it? Enabled brown-out detection is a simple change to the fuses - no hardware or code change, but parasitic drain rises from 0.016 mA to 0.037 mA, little more than doubles. It's really not that bad of a bump, considering. When the issue occurs, it's an easy fix, just to cut power and try again, and only happens in normal usage when changing cells, and probably only with lights having non-anodized threads that are much subject to power fluctuations.
0,037mA means ~1100 days to drain 1 amp of 1 cell right?
So on 4 cells 4400 days.
12,5 years seems acceptable to me 
Look at it from another perspective: what if you put the light in a bag, drop the bag hard, cause the cells to momentarily loose contact with the driver and the light gets stuck on when they reconnect? I think 0.020 mA is nothing for peace of mind from a known potential problem. You’re still draining less than 1 mAh per day. Likely less than the self-discharge of most cells.
Besides, you can probably have about 0.013 mA back by removing the voltage divider and getting the cell reading from the MCU’s Vcc. Someone posted about the idea in here a few months ago but I don’t remember if it was actually done. I mean to try it in one of my lights so I should have code to contribute in a few weeks.
Ahh, yes all true. Just fyi though, I'm fast switching power on/off 100's of time to get it to happen once -- but it's still bad when it happens for sure...
Dr Jones doesn't use the voltage divider resistors on his new drivers, so we know it's do-able, but of course, no published details (or source code) on doing so.
Actually we could go even higher on the voltage divider resistors as another option - that's been done also, and I bought the higher value resistors to experiment with, but no time yet. In the datasheet, brown-out detection can be disabled in firmware, so I'll be looking at that, then we get the best of both worlds!
My problems are with limited time, constant battle for getting hours in, so whatever I see as easier/quicker will have to do. Plus pressure to "just get er done"
Brown out detection can be disabled in firmware when setting the light to sleep (I do this in my critical shutdown routine). Have you played around with that at all? I know it was suggested by someone else earlier but I haven’t seen if you’ve done any testing with this at all.
No, I never did play with it. Wow!! So you got it done? Cool! Mind if I beg/borrow/steal?
Does it require the "V" version of the 25/45/85?
Oh I completely understand I began writing firmware to improve the low levels on my astrolux S1 and now, 6 months later, I rewrote the whole thing from scratch and it’s only getting useable.
No worries. This is what I’ve used to turn it off:
uint8_t mcucr1 = MCUCR | _BV (BODS) | _BV (BODSE); // Turn off brown-out detection.
uint8_t mcucr2 = mcucr1 & ~_BV (BODSE);
MCUCR = mcucr1;
MCUCR = mcucr2;
However, I must say that as I have an off switch I don’t have to care about turning it on again as a power off cycle will reset everything back to normal. As an E-switch light is always on you will have to take that into consideration. You can start be checking if the above code makes a difference in parasitic drain at least, if it does you can then start worrying about the rest.
True, but I only did it to fix the problem occurring on power cycling - intermittent issues when applying power, like when you are loading fresh charge cells and tightening up the tail. I think what you got there will do. @work now so will try this eve. Thanks Mike!! Big help!!!
Ohhh - do you know if this works on "V" and non "V" MCU's?
I’m assuming it works on both, but it is an assumption, I don’t know for sure. To be honest I haven’t actually checked if the code really does what it is supposed to do as I only use it for critical shutdown if my light is configured to shutdown (and most of them aren’t).