Attiny25/45/85 FW Development Thread

That’s actually really handy to know about. I had also been trying to figure out whether brown-out detection was necessary. I’ve occasionally seen really strange behavior that I couldn’t trigger again on purpose, and I wonder if this might be why.

Wait, I'm confused. Even with OTC is it standard to turn on brownout detection? I' thinking I've seen flaky probs also with NOINIT, using th power switch to change modes but with my e-switch firmware, but really haven't tested it much. I got it on a X6R and a Y3 now.

Totally unrelated - Dale reported in TK's firmware thread I believe, a problem with high amps and a 25 MCU, think with multi parallel LED's. I'm having problems now with an 85 MCU with high amps in a FET+1 based driver in a SupFire M6: 4P cells with 3P LED's. I haven't narrowed/isolated the problem down, but seems to work fine on a poor cell like a TrustFire. I gotta begin to isolate it - could be anything to do with this driver at this point. It was fully working 100% with an older FET driver, and I replaced it with a 22mm FET+1. Did my usual careful continuity tests on this driver and all looked good. Also the driver tested fine on the bench with 1 LED. I could try:

  • wire up only 1 LED, not 3
  • replace FET (SIR800DP high performance)
  • 85 MCU? Maybe the firmware?

Dunno - symptoms when it flakes out seems to be problems with FET PWM modes, and seems like the MCU goes out to lunch - gets stuck in blinking state, etc. Maybe I should try turning on brownout detection...

To clarify, I’m using the noinit variables for variables that I’d like to keep track of during short to medium off presses (like mode programming and voltage under load). I do not use noinit variables for off time detection at all any more, I found it too unreliable (was getting 10 second decay periods on some drivers). I use the noinit for short term memory storage only, and found that I certainly need to enable brownout detection fuses for stability, atleast when stress testing.

If you are getting brownout errors during normal operation (i.e. cells are good/charged) you have more serious problems hiding in your driver/firmware/hardware.

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. :slight_smile:

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. :smiley: Funny how it usually looks good in preview.

And I though a was alone! :slight_smile:
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... FrownFrown

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.