Perfect, just as I suspected, R5 is 4.7 ohms (ok, I said 5 ohms . . .). I found a 3.3 ohm resistor at home this afternoon. I would prefer a chip if I can find one, but I’ll likely fool around with the leaded one tonight to see if I can get it to fit.
Thanks! 
So I have replaced R5 and still don’t have a driver that works. I had reflashed the driver a few weeks ago, and it reported going well. When I put the light back together, no light. I am making voltage measurements on the driver board.
MCU has voltage on pin 8, I see pin 2 go from about 0.8V to ground when the switch is pressed, I see pin 3 go from around 0.6V to Vcc when the switch is pressed, pin 5 does nothing when the switch is pressed, nor does pin 6. Pin 5 should drive the 7135 and start high after the switch is pressed and released, as that would fully turn on the 7135. Pin 6 is a bit dicey to probe so I did not try much there, as pin 5 is not working either.
Wondering if I should reflash? I recall using the file http://toykeeper.net/torches/fsm/anduril.2018-09-07.EMISAR_D1.hex
with the command
avrdude -p t85 -c usbasp -Uflash:w:ANDURIL.2018-09-07.EMISAR_D1.hex:a -Ulfuse:w:0xe2:m -Uhfuse:w:0xde:m -Uefuse:w:0xff:m
Or at least that’s what I think. Try again maybe?
Next issue with this driver ( and my test ATTiny85 is that I can not connect with the chip. I am able to measure continuity from the IC pins through the clip, so I don’t beleive it is a bad clip. If somehow I “bricked” the chip would it just stop responding when I try to communicate with it using the command avrdude -p t85 -c usbasp -n
It’s probably bricked. I bricked my q8 and the chip wouldnt respond after with that command. Kept saying failure to connect. I used wrong fuse values.
Yeah, that is what I imagined, but best I can tell I used identical fuse values as when I flashed the first driver I have. I thought the fuses were device specific, not load specific, perhaps I am wrong? If so, where do I find the right fuses for the latest Anduril load?
yep, that is very different than what I used. still confused why it worked with an older Anduril load. Time for a new chip or driver board . . .
BTW, thanks for the quick responses all :+1:
Where did you get the other fuse values from? Is there documentation somewhere leading people to the wrong answers?
Oh no! It appears I pasted the ‘BOD disabled’ fuse values specified in the flash-85.sh script.
The difference is just one digit in the ‘hfuse’ value, but I really hope my error isn’t the cause of your trouble.
TK, would this difference cause such an issue? Should I edit my post?
Your script matches TK and others so it should have worked for sbslider. The ‘BOD enable’ was just a recommendation from TOM E (or was it TOM TOM?) if i recall. in my case i rushed it and used a script from a random post which was more of a question so i should have did more research and further reading. i was too excited to try out the candle and lightning mode.
The values I see in post 5 look like they should work fine.
It doesn’t really matter whether BOD is enabled. It could in theory reduce risk of weird behavior at very low voltages, but I haven’t found a way to actually trigger the things it’s supposed to protect against, and it increases standby power by about 0.02 mA. So I haven’t been using BOD.
However, one benefit of turning BOD on is that the MCU will actually reboot after a battery change. Without BOD, the standby power is so low that the user can have the battery out for like a full minute before the MCU runs out of power. So forcing a reboot may involve loosening the tailcap then clicking the e-switch.
The behavior described in the last paragraph is how my one working D4 works. I actually prefer this, as if I want to do a quick battery change my last mode is still remembered. If I want to “reset” it, a click of the e-switch will accomplish that.
So, I programmed a test board and my 2nd D4 with the text used in post 5 except with the 2018-01-24.hex file. Now I can not communicate with either one using my setup, even though I can verify continuity from the IC pin through the programming clip to the USBASP. One poster suggested this is a confirmation that the MCU is “bricked”.
Is there any other test I can run before I go through the process of swapping driver boards (if I can find one available) or swapping out the ATTiny85 (I do have the capability to do this)?
I hope someone else chimes in with some other testing ideas, but Hank sold me a replacement driver for my D1S after I damaged the board.
The driver cost just a few bucks more than a bare ATtiny85, but will take a little longer to arrive.
You can find his email address by visiting the website and clicking ‘contact us’ at the bottom.
If a driver is already working, there should be no need to set the fuses at all. Just omit those options and things should be fine.
If you have any scrollback available, it might be revealing to paste the entire text of the flashing process to see if anything weird happened. Each value should be written and verified, and if the verification fails, it needs to be flashed again.
I’ve only ever bricked one MCU, and it was from under-clocking it too far. This can technically still be recovered, but the usbasp doesn’t support speeds that slow, and I don’t have the hardware required to do high-voltage reflashing. I might be able to wire up a raspberry pi to do slower-speed reflashing though.
No on the scroll back, that computer died and is gone.
I have two boards I am working with. The ATTiny85 on the D4 driver board does not appear to react to the eswitch inputs. This is tested with a DVM and looking at the control pin for the 7135. And I can not communicate with the D4 driver or my spare test board. I use the spare test board to be sure I have connectivity working before I use the D4 driver board. My test board is similar to one of these
I suppose it is remotely possible that somewhere between my cable harness and the USBASP something happened, but it seems unlikely as I used that part of the setup once already and successfully flashed the one D4 board which I have working. It is still all connected from that successful flash event.
I guess it is sounding like I may still have a setup issue, as opposed to two bricked ATTiny85s. I will add the clarification that I programmed them both with the same command (as in post 5) and they both behave the same now as best I can tell.
What is the benefit of flashing your D4?
I prefer Anduril to stock ramping UI
Ok, I have my new driver board for my D4 and am about to reflash it. If I did what I said I did earlier I screwed up and tried to flash with a D1 version of the firmware. anyway, this is the command string I think I need to use to flash the new D4 driver:
avrdude -c usbasp -p t85 -u -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -Uflash:w:anduril.2018-09-30.EMISAR_D4.hex
Is this correct?
One thing I notice is the first time I did this I recorded the command in post 5 and it showed a small difference, hfuse:w:0xde:m VS efuse:w:0xff:m
When I communicate with the driver it says,
avrdude: device signature = 0x1e930b
avrdude: safemode: Fuses OK (H:FF, E:DE, L:E2)
avrdude done. Thank you
FWIW, there’s a newer version available:
http://toykeeper.net/torches/fsm/?C=M;O=D
Also, those fuses don’t look right. Looks like the “FUSES OK” part has two values swapped. The command I use is:
avrdude -c usbasp -p t85 -u -U lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m -Uflash:w:myfile.hex