Wow, I didn’t know that. The T1634 must be that new MCU ToyKeeper was working with.
No, it is not bricked. As long as you don’t change the fuses it’s almost impossible to “brick” an ATtiny. You can simply try to flash it again (using the correct parameters and hex file). The flashing app should have noticed that it’s a different MCU.
Glad it’s not bricked. Initially I chose attiny1634, the app said flash successful. Then I tried attiny 85 and the flash was unsuccessful. Did this a few times. I can try again tonight.
I tried using otg adapter using my S10+. It’s saying error. When I looked in the log it said it wasn’t the right format. Does anyone know what I might have done wrong?
I attempted it again afew times with the attiny85 in the settings in the mobile app. Same result. There’s a pop-up with the message ” operation complete with errors!” The last few lines of the log read:
vrdude: verifying …
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0xa9
avrdude: verification error; content mismatch
avrdude: usbasp_close()
avrdude done. Thank you.
If it’s beneficial, I can post the whole log somehow.
Tried the windows method with that command line, same error. Also tried both attiny1634 and attiny85 options on both windows and mobile app, same result, light not operational
I’d suggest re-downloading the firmware. Perhaps your first copy is corrupted?
Maybe try another revision?
EDIT: Spelling error
Just curious, how does the setup work? Are you using an SOIC clip or pogo-type pins to flash the D1?
What happens when you enter this command? -
D1 would require a clip as it does not have flashing pads (on the current version).
I have the official flash kit. My D1 has the same pins as my D4V2.
When I put in the command “avrdude -p t85 -c usbasp -n” I get the following:
When I put in the command “avrdude -p t1634 -c usbasp -n” I get the following:
I’ve flashed the light with setting combinations of two chips (ATtiny1634 & ATtiny85) and four hex files (anduril.2019-08-05.emisar-d1.hex, anduril.2019-09-28.emisar-d1.hex, anduril.2019-08-05.emisar-d4v2.hex, anduril.2019-09-28.emisar-d4v2.hex), using new downloaded hex files in both windows 10 and the android app. Flashing with the ATtiny85 setting gives errors. No errors in the ATtiny 1634 setting. Flashing with ATtiny85 chip setting and any hex do not give a working light. Flashing with either chip and any D1 hex file do not give a working light.
The combinations of settings of ATtiny 1634 and either D4V2 hex file now give me a working D1, however now the light flickers a lot when screwing on the battery tube and sometimes stays on when battery tube is fully screwed on. Do I have a thread problem now? Anodization looks pretty good. A sliver of anode has worn off 
Edit: Or is the flickering/light on due to the software and flashing?
@cuberS
Couple of things:
-never flash a firmware that you KNOW is for a different device, e.g. D4V2.hex on a D1 - doing this usually means begging for trouble
-your 2nd try with the “avrdude -p t1634 -c usbasp -n” command produced the correct results for the D4V2
-if you can repeat that with "avrdude -c usbasp -p t1634 -u -Uflash:w:FILENAME.hex" and the correct firmware you should be successfull
-make sure to hold your hands really still while the flashing is in progress, maybe get a 2nd person to press the enter key for you
Ok…curiosity piqued…
Afraid to try before…but flashed my D1 with 9.28.19 D1 anduril…
Popped out the driver…no problem…unsoldered the black wire…spun the driver around…set up my SOIC clip, used Android phone for flashing…
Failed like 10 times…checked my wiring…wiggled all my wires…some came loose a few times…still errors…FINALLY reseated the clip just right…was always missing a prong or two…
Successful flash!
I did get “operation failed” like 10x though…in the end…was a bad clip on chip connection…
Mine is an ATtiny85 chip…says so right on the chip…so used that setting…
Look closely at your chip to identify it…
Hope you get results soon!
Peace!
Everything you say indicates that your D1 has a D4V2 driver in it. I don’t think there is a proper file for that combination available, although I don’t know the precise differences between D1 and D4V1 drivers for instance (that is, those using the same MCU).
Your other problem of the light flashing as the tube is tightened suggests a physical problem, most likely some wires are pinched between the driver and the body.
I agree with the above, it looks like Hank is now using a new driver in the D1 based on your findings. (Flashing pads, 1634 works, 85 doesn’t, D1 firmware doesn’t work, etc…). This is cool and exciting, but kind of a bummer right now in your situation.
My guess is that you have the newer MCU (ATtiny1634) and your firmware files are for the older MCU (ATtiny85). If the D4v2 firmware doesn’t work (most likely not the exact same driver as the D4v2), you will need to obtain a version of the D1 firmware suitable for use with the new MCU. I would reach out to Hank and see if all this is true, and if he can provide you with the proper firmware (to get you going).
ToyKeeper would be another good resource as she is likely the one to have written the code for the newer driver (unless Hank just modified the D4v2 Firmware, but this seems unlikely).
Does that mean the new D1 now uses ATTiny1634 MCU instead of ATTiny85? And it has the same flashing pad as D4v2 (which uses ATTiny1634)?
Can you take a picture of the D1 flashlight?
Ulp…
That’s different than mine…
I had to open mine up and use a clip on the chip, no flashing pads.
Thanks, cuberS.
Has Hank Wang confirmed that the Emisar D1 now uses ATTiny1634 and has the same flashing arrangement (similar to D4v2)?
Or is this just an “honest error” (D4v2 board installed on a D1 flashlight)?
As another data point, I ordered 2 D1’s from Hank on 10/19. Both utilize the same flashing pads as my D4V2’s. When attempting to flash with anduril.emisar-d1.hex, I end up with a D1 that does not work. When flashing with anduril.emisar-d4v2.hex, I end up with a functioning light.