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

ryukin2000 · 2018-10-04T14:20:22.000Z

goshdogit:

ToyKeeper:

Where did you get the other fuse values from?

sbslider:

post 5 above

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.

ToyKeeper · 2018-10-04T19:47:17.000Z

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.

sbslider · 2018-10-04T21:34:57.000Z

ToyKeeper:

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)?

goshdogit · 2018-10-04T22:23:12.000Z

sbslider:

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.

ToyKeeper · 2018-10-04T22:59:46.000Z

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.

sbslider · 2018-10-05T02:26:10.000Z

ToyKeeper:

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.

wstrachan · 2018-10-05T03:18:22.000Z

What is the benefit of flashing your D4?

sbslider · 2018-10-05T03:22:30.000Z

I prefer Anduril to stock ramping UI

sbslider · 2018-10-27T04:17:46.000Z

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

ToyKeeper · 2018-10-27T06:41:46.000Z

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

sbslider · 2018-10-27T14:23:42.000Z

ToyKeeper:

FWIW, there’s a newer version available:

Index of /torches/fsm

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!

sbslider · 2018-10-27T19:19:12.000Z

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!

ToyKeeper · 2018-10-27T23:59:33.000Z

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.

sbslider · 2018-10-28T01:01:41.000Z

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.

ToyKeeper · 2018-10-28T01:27:22.000Z

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?

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.

sbslider · 2018-10-28T05:29:13.000Z

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

bansuri · 2018-10-28T05:49:18.000Z

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.

ToyKeeper · 2018-10-28T12:28:52.000Z

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.

sbslider · 2018-10-28T18:58:56.000Z

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

ToyKeeper · 2018-10-28T21:31:51.000Z

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.