Attiny25/45/85 FW Development Thread

Oops, more details added to post #949 above.

I don’t know about the ATtiny85 but the standard Banggood BLF X6 driver has a ATtiny25 mounted. This mcu has problems with high Amps, the ATtiny13a on the same PCB doesn’t. Interesting to hear the ATtiny85 does not show this problem, perhaps I will give it a try. Have you used your high drain cell with this mcu earlier or did you use lower drain cells?
Is it possible to mount the ATtiny85 with a soldering iron in the place of a ATTiny13a or ATtiny25 or do I have to reflow it?

I use hot air reflow, but it's possible to hand solder I suppose - just need to do a good enough job wo you can still clip on to the MCU and re-program, You have to bend the pins of course - can be a challenge - just a warning. With the bent pins, it's actually easier to program in place.

I for one would not use the BLF X6 driver - don't trust the quality. 25/45/85's have all the same problems with our standard circuit design. My fixes include:

  • pull down resistor on the FET gate, from 12K to 20K, high ar 47K or so
  • for C1, double up the 10 uF cap (add one stacked) -- BLF A6 uses a 12 uF cap, not 10 uF!! Pull it and test it if you don't believe me, or, maybe they are sneak'n in 10's now, and that's why it's flaky
  • add a 0.1 uF cap across pins 4 and 8 (grnd to VCC)

The combo of all 3 of these always works, every time, for me. Sometimes you can get away with just the FET gate pulldown, sometimes FET gate pulldown and the 0.1 uF cap. This is why Richard has all these extra parts on his driver (zener and schottky, FET gate pulldown, etc.), and why our BLF Q8 Narsil driver board has all the extra stuff as well, but we have a slightly different approach.

Thanks Tom E, I don’t think I was patient enough to sit the 8secs out… Will test again.

It’s weird, because now it looks erratic at high levels as well. I’ll remove the driver and see whats wrong when I have the time.

Flashy Mike, you can see how I did it here: DQG tiny 4 mod

It worked flawless on 30Q’s and lower drains. Stock X6 driver with only AT25 replaced by AT85 running Narsil without ramping.

Edit: Thanks for the mod list Tom E. I don’t really understand why this FW doens’t work now on the same driver. Just swapped 2 resistors… Guess I got lucky to begin with.
I’ll need some more parts then…
I thought this was the final mod on my DQG. Now I know there are many more to come… I quite like that idea :partying_face:

@Tom E:
Thanks!

@Dutchee:
Interesting mod!
I saw the bleeder resistor in place on your driver there. If you don’t remove it you can’t reduce parasitic drain below about 9 milliamperes in your e-switch light.

Got a new version of Narsil posted, several bug fixes, minor enhancements and tweaks:

Direct link to the ZIP file for Narsil 2016-07-11.zip

or link to the complete folder, where you will find the above ZIP file and the manual in two forms: docx and PDF.

IMPORTANT NOTES:

  • be sure to grab the 2016-07-11 version, while the manual is still dated 2016-06-08
  • In the ZIP you will find a notes.txt that has the list of updates - current version is 1.11
  • Narsil is only configured for FET+1 drivers, using a 350 mA 7135. Of course battery voltage is dependent on the driver design and parts used
  • Narsil requires an ATtiny85, and a ATtiny85, along with 25's and 45's, can be finicky, and best to have some mods made to drivers designed for 13A's. So far, the most reliable drivers to use are Richard's MtnE MTN17DDm v1.1 which is designed to run a 25, but seems to run an 85 just as reliable. Also our newly posted and moderately (lightly) tested BLF Q8 SRK driver.

Here's a full parts list for the BLF Q8 V3 SRK driver:

Note: R5 and ZNR are unpopulated

If you choose to use this, Best to let me know what you are planning on doing. I can answer any Q's you have. This thread has a lot of the history on the 25/45/85's here, all the pain and suffering as well...

Here's the content of the NOTES.TXT file, listing all changes in this version from prior 2016-06-08:


Open Issues:
1: Bug: strange behavior on power fluctuations on power-up (lockup w/LED ON intermittently occurs)
2: Potential Bug: in mode sets, can't get battery check to work (might be from corrupt config settings)
3: posssibly easier/quicker way to toggle between ramping and mode sets
4: utilize 4X and possibly 5X clicks
5: possibly remove memory mode for mode sets
6: add version # reporting - blink out the vers #

------------------------------------------------------------------
UPDATES
------------------------------------------------------------------
Vers 1.11 2016-07-11:
- bug fix: dbl-click or triple-click in Battery Check mode were being acted on (should be ignored)
- in ramping, add a timeout (1.2 secs), after which, to not toggle/change the ramping direction
- bug fix: with turbo-timeout enabled and in ramping with moon mode active,
the turbo-timeout kicks in and turns up the output to turbo drop down level -- fixed this
- slightly speed up multiple click timing (shorten LOCK_OUT_TICKS from 16 to 14)
- in ramping, if you turn the light from OFF to ON to the previous level, the direction will now
default to lo->hi
- add changes in an attempt to eliminate power fluctuations causing a lockup or coming on with the
LED ON (lockup still happens, but doesn't seem to come up with the LED on and light still
operational anymore)

Vers 1.10 2016-07-06:
- add validation marker byte (0x5d) to avoid loading erroneous config settings - seems to work in
fixing the observed behavior (still open issue on lockup)
- add flicker when ramping reaches the limits
- bug fixes: if holding the button for entering battery check, don't allow config setting or strobe
modes to be started
- bug fix: in ramping, when click to last level and last level is moon, the ind. LED was left ON -- fixed this
- add a compile switch to enable reverse ramping direction (toggling)


What progress!

Bug 1 reads like a nasty bugger ( :wink: ) does any other Narsil user encountered it?
Oh man I am so going to dive in this coding thing this winter, want to learn coding anyway.

Seems like you’ve been busy!

Is that power-up as in turning on the LED? Or as in inserting batteries? I’ll try giving it a read as sometimes a fresh pair of eyes helps.

Inserting batteries - meaning powering up the electronics. I've only seen it somewhat rarely when I'm fiddling with a stubborn threaded tailcap and the threads aren't anodized. I can reproduce it, after fiddling around for a while, intentionally trying to cause it.

Dunno the cause yet, or what I can do to fix it - hoping for some help on it. Maybe someone stumbled across it before? Being that the side switch doesn't seem to work at all when this occurs, can't figure what might be happening - almost like the MCU is in a funky reset state, or power-glitch state.

Have you tried enabling the brown out detector? The comments suggest not by default. You could have low power without a proper reset if power is cut for a very short time (likely far less then 1 ms). Then I suppose anything could happen.

(Edited to remove nonsense theory as the LED is on.)

Hhmm, didn' try that. Think someone said though brownout detection enabling is a killer for e-switch parasitic drain?

Since the MCU locks up, you're probably voltage spiking the MCU when the tailcap is getting fiddled around. When connections are intermittent and arc/spark you can generate some pretty big voltage spikes. I'll bet if you hook up your fancy oscilloscope at work to the VIN pin and and ground pin then play around with the tailcap with the trigger set at 6V+ you'll see a pretty nasty voltage spike.

Still no temperature sensor support? Even external?

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

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.