Did you un-edit your post just because I quoted the original version instead of the edited one? … the timing just worked out that way — I hit quote, got distracted, finished my post, then found I had an out-of-date version. But now it seems to be re-edited back to the original.
Just curious. There are, of course, plenty of other explanations which have nothing to do with me. 
I don’t think I saw that post, but I’ve seen issues sometimes under high load. The symptom I see is different though — the MCU appears to suddenly reset or reboot and acts like I did a short-tap on the button. And the issues only happen with a full high-amp cell on a high-output mode; it works fine with weak or low-voltage cells and on lower modes.
I don’t know if it’s at all related to brownout detection. Like, maybe the sudden emitter draw pulls enough power that the MCU briefly starves or overloads? I really don’t know. The easiest way to trigger it is to go to a strobe mode with a full 30Q cell.
Oh shoot, thought Dale said you were look'n into it. He was doing a triple quad mod on I think a sample X5 (maybe?) with the 25 driver, and ended up swapping the driver, then it all worked fine. It might have been in the big X6/X5 V2 thread, not sure now... Darn should try to find it...
Found it!! Post #1966 here: https://budgetlightforum.com/t/-/34532
Haven't had any glitches with the 85v & Tom's eswBrOutCfg 10-28 firmware, but I haven't tried it with a multi-emitter high-amp setup yet.
After reading the few posts above on my 'phone today at work, I thought I'd open up my 5* XML2 SRK with the BLF DD driver in it, & swap out the 13 for the 85v when I got home.
... in my haste to try it out, after doing the swap & re-flashing, I realized that it wasn't a Fet+7135 driver... I'll have to go through the code & change all the values to suit the single channel FET, & see how it goes. 
No. It’s the use of variables in the “ attribute ((section (”.noinit”)))” variables that survive short/medium off-time presses that can cause issues if brownout detection is disabled.
If I removed “noinit” variables, resorted to EEPROM writing and disabled brownout detection: No issues.
Or if I kept using the “noinit” variables but turned on brownout detection fuses: No issues.
It’s the combination of using “ attribute ((section (”.noinit”)))” variables without brownout detection that caused weirdness under some conditions. I’ve now stress tested both of the above working combinations with no issues what so ever. So no, no serious problems at all.
Yep, that’s typical me… I write a post, and then edit several times, hoping no one quotes me in the meantime. I wasn’t fast enough this time, so to keep consistency I just copied back the original text.
Glad I’m not the only one who might do that. 
Funny how it usually looks good in preview.
And I though a was alone!
Yeah, that preview window must have some sort of hallucinative effect.
Agree
I do this all the time too, it is like i see what i thought i wrote and then i post it and read it as someone else would read it as just another post in the thread, and I see lots of errors of what i though i expressed and have to edit again………
Me too - I'm guilty of multi-editing posts all the time 
.
For my 85 driver problem, did a little more testing last night - it's definitely only happening with PWM modes on the FET. Modes for the 7135 only work fine (PWM or full) and the FET full works fine. I did try it on 2 LEDs, not 3, and it's still having the problem. Gotta try this with another driver - really need to eliminate this driver (hardware/board) as the cause, it's just difficult for me to be swapping around piggyback'ed drivers, unless I can get a better open, bench test setup for it.
Update:
Got some real good suggestions from the EE's I work with, so this eve I'll be trying out a couple things. Seems to have to do with the higher rate of PWM's on the 25/45/85's when we run them at 8 Mhz. I'm gonna try doubling up the cap (adding a 10 uF in parallel), and/or changing the PWM mode to the slower PHASE mode from FAST. Our thinking is it's the combo of the higher speed PWM's we get on the 25/45/85's combined with high amps - could be the spike is too much for the cap to handle, causing a sudden drop in voltage to the MCU. Dunno til I try these things out first -- then we'll see a little better. Getting it on a scope of course would be the real deal, but I would probably need help with that for sure...
What I'm seeing when switching into the 3rd mode below, the light goes flaky: blinks, sometimes resets, sometimes locks up in a continuous blink state. So that 3rd mode is FAST PWM's on the FET. The PWM's on the 7135 work fine.
// 4 modes (2-10-40-max) 1-2% ~10% ~40% max
PROGMEM const byte modeFetSet4[] = { 0, 0, 80, 255 }; // Must be low to high, and must start with 0
PROGMEM const byte mode7135Set4[] = { 30, 255, 255, 0 }; // for secondary (7135) output. Comment out if no secondary output
PROGMEM const byte modePwmSet4[] = { FAST, PHASE, FAST, PHASE }; // Define one per mode above. 0 tells the light to go to sleep
^
Nice intell you gathered. Thanks for sharing it. Hope it pans out. The earlier versions of your FW are very rock solid for me. Can you square that with the what you have learned about the high PWM rate, caps, and such?
I have to say this. I hear absolutely no whine in any of my 25/45/85 lights (running at 8Mhz). Just loving that.
Forgot what the #'s, were but someone measured or calc'ed the rate we are using, and it's pretty insane - think FAST is bout 30-35 kHz? I think you take 4.8->8, and factor up PWM rates the same? Not sure...
I love the 8Mhz operation of timing. On the 13A's, I'd see some occasional whacky timing inaccuracies for the CPU speed - not sure if it's the msecs delay function, and possibly the WatchDog interrupt timing. But with the 25/45/85's, the 8Mhz seems always dead-on accurate.
I continue to test the firmware on several lights now and yes, seems pretty rock solid. This high amp issue though I really gotta get a good solution for. I'm also continuing to find good e-switch mod host candidates.
I bought/rcv'd a UltraFire UF-T18 from TinyWind.com and doesn't look good - poor feel'n button and no clear way to get the driver out, and the LED has a solid plastic cover. I did order a Olight S30 from BG for $27 before points, and it sounds like it's moddable. Been look'n for a e-switch small tube 18650 light. Also got a Sunwayman C20C coming in from Illumn for $30 - great deal. Heard it's moddable as well, but hoping the Rocher driver will fit, but want to upgrade the MCU on it, so, have to some how meld the Rocher F6 firmware with mine - I'll see how that goes.
If you want any specific boards designed it they are odd sizes and shapes let me know
K, thanx!
That was probably me. I found a way to measure it directly.
From post 1801:
Multiply PWM speeds by 2 to get the FAST version instead of PHASE.
Also, to calculate what the PWM should be…
8 MHz * 1000 kHz/MHz / 256 cycles per PWM loop = 31.25 kHz (fast PMW)
8 MHz * 1000 kHz/MHz / 512 cycles per PWM loop = 15.625 kHz (phase-correct PWM)
… and to get the ideal “bogomips” factor for the delay loop, take the MHz * 1000 / 4. So, for 8 MHz, the bogomips should be 2000. For 4.8 MHz, the bogomips should be 1200. But the attiny13a actually averages closer to 3.8 MHz, so the value is actually more like 950 instead of 1200.
I’m anxious to see if you can fix the overload issues by modifying C1. I figure it’s probably either C1 or D1 or maybe something about the board layout itself, but I don’t know much about how it actually works.
Thanx for the timing info! Ok - just back from my dnstairs flashlight lab - nothing seemed to work.
- Tried PHASE lock loop - no change
- tried doubling up the cap (in parallel) - no change
- sanity test: ran only one LED - worked great
- went back to 2 LED's (that was not working before), removed the diode replaced with wire - no change
So... 
Maybe a bigger cap is needed. Just seems like the power transitions from the PWM's are effecting the MCU. I got the LED+ wires connected to the M6 driver (driver is bare), while the LED- wires are stacked on the 22mm driver LED- pad. This is the driver I'm using, sitting on top of the stripped M6 driver: https://oshpark.com/shared_projects/0vrfkFpR.
I'm not using a resistor on the SIR800DP FET, like I usually do, but that helps knock down the blink/flash when transitioning from FET to 7135 from what I've seen, so not sure if it's relative to this problem.
This seems like something comfychair or DEL would be good at debugging.
+1 - I was definitely think'n of comfy's setup with that low cost scope tool he had - think it was USB based and used the PC as the display.
Hopefully can get more tips to try today @work. I know texaspyro has a working Tiny85 based SRK (post #116 way back here), but I'm sure different driver setup, probably different FET, and probably not a FET+1.
Certainly someone with more driver/design knowledge could possibly help, but I'm assuming no one else seen this issue so could be tough.
Tom, are you using the 85 or 85V on this driver? Also, have you tried without PWM at all? By simply turning the FET pin on/high?
I have the 85V bought from Mouser I believe. No PWM's work great, i.e. value of 255. So full FET or full 7135 works great, also PWM's on the 7135 only works great. In post #430 above, of those 4 modes, it fails when switching to the 3rd mode either from 2nd mode or 4th mode - my UI (Werner style) can go in both directions.
Ooops - Ok, found texaspyro's thread on the tiny85 SRK mod: https://budgetlightforum.com/t/-/18833. So it's 7135 based, no FET's at all. Hhmm... Gotta review that thread when I get a chance.