Anyone in the Santa Barbara CA area able to help me flash my D4?

Flashlight Modding and DIY Parts
41

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!

42

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!

43

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 -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.00s


avrdude: Device signature = 0x1e930b (probably t85)


avrdude: safemode: Fuses OK (E:FF, H:DF, L:E2)


avrdude done.  Thank you.

44

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.

45

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.

46

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

47

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.

48

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.

49

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! :beer: :+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

50

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.

51

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:

52

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 :person_facepalming:

I’ve used this command before successfully, but for some reason its not working now . . .

53

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

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