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
Thanks for the feedback. I acutally have the 10-12 version on my machine too, but didn’t reference it in the line I posted above.
I am in a quandry, as I quadruple checked the display in avrdude and the fuses ok values when I send the command “avrdude -p t85 -c usbasp -n”. This board I am flashing is a replacement from Intl Outdoor for my D4. I bricked the first one and don’t want to do it again. Is the driver wrong, or I don’t want to brick another board, so I am trying to be extremely careful.
thanks!
I so want to flash this driver and get my 2nd D4 back together again. But I don't want to brick another part. The FUSES OK reads as above, which is:
avrdude: safemode: Fuses OK (H:FF, E:DE, L:E2)
The command that TK suggests uses: lfuse:w:0xe2:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
looks like L:E2 matches lfuse:w:0xe2:m
looks like the others don't match.
H:FF does not match hfuse:w:0xdf:m, should I change the command to hfuse:w:0xff:m ?
E:DE does not match efuse:w:0xff:m, should I change the command to efuse:w:0xde:m ?
Or is there some other change that needs to be made? Or maybe it's fine as TK suggests?
The driver board I am flashing is a replacement from Intl Outdoor for the last D4 driver I bricked, so I am super cautious this time. Expert guidance appreciated!
It's also possible the safemode message has the values swapped.
But on mine, that doesn't appear to be the case. It says:
> avrdude -p t85 -c usbasp -navrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructionsReading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e930b (probably t85)
avrdude: safemode: Fuses OK (E:FF, H:DF, L:E2)
avrdude done. Thank you.
Thanks for the help TK, but I guess I still don’t know exactly what I should do. I am assuming my programming command needs to match the fuse values in this particular driver, so I need to adjust the command I use to the fuse readings I got. Is that correct?
As you mentioned previously the fuse values reported on this driver are different than you got.
No.
If you’re concerned about the fuse values, you could just omit that part of the command to leave them as-is. I’d probably try it first without any fuses specified. If it “just works”, then you win. If it acts weird, I’d try again with the command I pasted earlier.
It’s weird that high and extended are swapped. And if those values are accurate, you might not be able to flash the MCU, because a high fuse value of FF means the serial programming interface is disabled. I think the serial programming interface is required to make the flashing process work.
If Hank sent you a driver which can’t be flashed, I’ll need to have a talk with him.
So then I imagine the command without any fuses specified is:
avrdude -c usbasp -p t85 -u -Uflash:anduril.2018-10-12.EMISAR_D4.hex
I had posted about that then deleted because I am just playing the sorcerer’s apprentice with this stuff.
This is the exact write command I used to put the Nichia version of Anduril on my D4:
avrdude.exe -p attiny85 -c usbasp -Uflash:w:D42.hex:a
(I renamed it D42)
I save it all in a text file for future use and reference.
That was the file that TK made for that specific light, available here: Index of /torches/fsm
I’m sure someone with a better understanding will chime in. I’m just a script kiddie.
It should work. If you don’t set the fuses, it should be pretty difficult to accidentally lock the MCU.
If you are unsure, it may be helpful to copy/paste the text the command produces into a text file, so other people could read the log and check for anything unusual.
I’m grateful for the baby steps you have all helped with. I was able to flash the driver with the firmware and communicate afterwards, so it seems all is well. Now to install the driver into the light.
Many thanks! 
:+1:
Yes, victory. The firmware is working properly, now my 2nd D4 with Nichia 219C has the 10-12-18 firmware installed, the Nichia version.
Now that I am set up, I am wondering what the difference (if anything noticeable) between late June firmware and the 10-12 version. I am considering reflashing my other D4 if it seems worthwhile.
I have a D4 with Nichia 219C and a D4 with 2 xpl-hi V2 3A and 2 xpl-hi V2 5D. When I compare the 291C running the 10-12-18 219C Anduril firmware to my D4 2 xpl-hi V2 3A and 2 xpl-hi V2 5D running a early summer version of Anduril I notice the 219C is pulling 1.2mA at the lowest level, and the xpl-hi is pulling 1.4mA at the lowest level. The XPL is definitely brighter. Best I can recall I have not changed the upper or lower level ramping limits for linear ramping, only for stepped changes in output. Guessing this is more just a pwm thing rather than the newer Anduril being a bit more efficient. Also, the xpl-hi is noticeably brighter than the 219C. pictures of the beams can be seen here
In detail, what changed:
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/changes
Or a more readable version of the changes can be seen with bzr log -v -n0 , or with a history visualizer tool. I normally use the “vis” tool from bzr-gtk, which looks like this.
There have been some improvements and bug fixes since June, but I can’t really say whether it’s worth taking things apart to upgrade or not. It will probably do thermal regulation more safely now, and there’s a hint on hold-from-off to indicate the timing for getting moon mode, but I doubt you’d notice any other changes during regular use on a D4.
The 1.2mA vs 1.4mA thing isn’t due to firmware. It’s probably more related to differences in emitter response time, Vf, and battery voltage.
thanks TK, that is helpful. Sort of tempted on the moon hint, but comparing how the old and new look real time its not enough to tear the working one apart. I’ll hold off for now. :sunglasses:
I thought I had this somewhat wired, but I’m having new problems trying to put Anduril2 in my LT1. I am able to communicate with the chip, I get back the device signature, fuse values and such.
C:\Users\swide>avrdude -p t85 -c usbasp -n
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e930b
avrdude: safemode: Fuses OK (H:FF, E:DE, L:E2)
avrdude done. Thank you.
But when I try to program, I get the error below:
C:\Users\swide>avrdude -c usbasp -p t85 -u -Uflash:anduril.2020-09-27.blf-lantern.hex
avrdude: invalid I/O mode ‘a’ in update specification
allowed values are:
r = read device
w = write device
v = verify device
avrdude: error parsing update operation ‘flash:anduril.2020-09-27.blf-lantern.hex’
help 
I’ve used this command before successfully, but for some reason its not working now . . .
Ok, I figured out finally I need the w: option set in the -U command.
so I entered
C:\Users\swide>avrdude -c usbasp -p t85 -U flash:w:anduril.2020-09-27.blf-lantern.hex
and the flashing began. It seemed to be going fine until the end, when I got the message:
avrdude: verifying …
avrdude: verification error, first mismatch at byte 0x0000
0x00 != 0x60
avrdude: verification error; content mismatch
avrdude: safemode: lfuse changed! Was e2, and is now 0
Would you like this fuse to be changed back? [y/n]
I entered y, and hit return. Now the MHV AVR Tools window is not responding. 
I don’t see being able to do anything but close the window and try to establish connection again, as its been a few minutes since this happened and no further activity in the MHV AVR window.
I bit the bullet and closed the window, and then opened it again. It seems ok I think? LFuse seems set back to E2
C:\Users\swide>avrdude -c usbasp -p t85
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e930b
avrdude: safemode: Fuses OK (H:FF, E:DE, L:E2)
avrdude done. Thank you.
But the light usually flashes or comes on when its done, and that didn’t happen. And when I apply power, nothing happens. But I still can read the memory.
Try again . . .
this time with the -u command added
Get a verification error, similar to the one documented here, except its 0x60 instead of 0x50
This time it only took 3 tries to get it, not a million. 
