The D4 driver uses Attiny85 and as an electrical engineer (EE?) you should be able to do the flashing part. But be warned that it is NOT easy to get to the mcu. The driver cavity of this light is very narrow, and the wires used to connect driver and LED board are pretty short. You have first to open the head (should be no glue there) and unsolder the wires from the LED board. The driver board is glued in, so you probably have to press the driver board out with some hard stick through the hole for the LED wires. Be careful to press the board and NOT any electronic components on this board!
Then you can pull the driver carefully a bit - but beware, there are still 2 wires connected to the switch. These are ripped off the switch board easily and it’s a hard job to resolder them. I would unsolder this wires at the driver side and take the driver out of the light completely.
Then you could easily build a simple test circuit in order to check if flashing - and the firmware itself - work out. For sure you don’t want to disassemble and reassemble this light more than once!
Here’s a photo of a D1 with the driver removed to illustrate what Flashy Mike is saying about the switch’s two white wires. The D4 looks about the same.
I’ve reflashed three D4s, a D1, and a D1S without damaging anything or desoldering the white wires.
I desolder and remove the LED board as Flashy Mike describes, then place the D4 with the driver facing the table. This hopefully prevents the driver from being pushed out too far and yanking on the switch’s wires.
Look through the hole and find a blank spot on the driver board to push against. I use a shortened bamboo skewer and tap it with increasingly heavier taps to push the driver loose. Once the driver starts to move, you can pull gently on the spring and wiggle it out.
Three out of five of the Emisar drivers I’ve removed popped right out. Two were more stubborn due to a tight fit and/or excess adhesive.
Be gentle while manipulating the driver to position your SOIC clip for reflashing, and be careful not to pinch the white switch wires while reinstalling the driver.
I have a cheap clip that sometimes needs several attempts to seat it properly, but I’ve used it successfully dozens of times.
I pinch the clip open, place it over the chip with the ends touching the driver board, and slowly close it. The clip moves away from the driver board slightly as the pins attempt to engage with the chip.
I run a command to test the connection before attempting to push firmware.
Yes, EE = electrical engineer. I have recently been interested in the magic of firmware, so maybe this is a good opportunity to get my feet wet. Once I get my D4 I will see how it looks for my 55 year old eyes and hands to work on. I do have access to good tools and microscopes at work, which should be a big help.
Thanks for the tips and encouragement both of you!!
It may also be worth filing down the edges of the driver a little, to make it easier to put back in. Sometimes the glue sticks out and makes it difficult to put back in as deep as where it originally was. I usually do this with a cheap diamond file, gently going around the edges, but not enough to remove a significant amount of material.
Also, once the glue is broken, it’s a good idea to keep the body tube tightened and only unscrew the tailcap. The body tube is effectively a giant retaining ring for the driver.
Well, I made the plunge in buying the parts to flash my D4. Maybe next weekend I will be able to give it a shot. Decided to buy a small board with a ATTiny85 on it to practice and get the setup right before I disassembly my D4. I would hate to get into this and have a multi day delay for some reason and have to leave the light laying around in pieces.
I recommend something like this:
It’s a RGBW setup with some additional channels (indicator, ultra low moon …) though, a dual channel setup as in the stock D4 is much simpler. I recommend 1 through hole LED per channel (7135 and FET), driven with resistors directly by the mcu. It helps to see what’s going on.
Got any suggestions for a test/dev setup for thermal regulation? That’s pretty much the only thing I find is obnoxious to develop, since it seems to need a fully-assembled host for testing.
Maybe it wouldn’t be so bad if I had a driver with pads/vias on the spring side for flashing without disassembling the host.
I designed a D4 driver with vias for programming pins for my RGBW mod (see below), but the driver is made for Attiny841 in QFN package, so I guess this won’t help here.
If it’s sufficient to have a fully assembled head, you could try this approach with the stock driver:
drill a little hole through the driver (next to the 7135 is no copper) and connect the programming wires through this hole to the mcu, GND (and probably BATT+) might also be connected at spring side.
Should also work with tube if you use strong wires to connect the cell through the tube.
Just an idea though, I haven’t done this by myself.
Well, my experience was just the other way around. I started with 3M (not good), switched to Pomona (not good) and I’m using now this cheap ebay clips. In the last two years I flashed hundreds of times with about 3 cheap clips (which together are still much cheaper than a single 3M or Pomona).
Really, maybe not all cheap clips are the same, mine started to start slipping off the chips and just got progressively worse and it would not stick to anything. The metal pins became misaligned. The Pomona clip fits way more square so it is so much less prone to doing this. The 3M clip looks like it suffers the same design flaw as the cheap ones.
So the adventure of flashing has begun. I have worked through a couple small issues and appear to have connectivity to the ATTiny85. I have not tried to erase yet, as when I look ahead to the next command (to flash) it appears I need to know some
when I search the .c file for “fuse”, no hits. Is this fuse mapping required to reflash my D4? If so, where do I find that info?
Don’t bother with the erase step. It’s not necessary at all.
I’d suggest using bin/flash-85.sh or copying the commands from that file. It has the fuse values and other options most projects use, and is known to generally “just work”.
to reveal a bit of my knowledge on this subject, I have no idea where to find the file flash-85.sh Is this a command somewhere in the programming line, like
avrdude -p t13 -c usbasp -u bin/flash-85.sh ?
Note the ‘t85’ option. This sets the chip model to ATtiny85. Your example shows ‘t13’, which is erroneously specifying an ATtiny13.
I mentioned in your other thread that before sending your new firmware, you can test your connection between the ATtiny85 and your programmer with this command:
If the connection test is unsuccessful, you may need to fiddle with your clip. I have a cheap one that sometimes needs a couple of tries.
It looks like you’re getting close to a successful reflash. Keep at it, and keep us posted! :+1:
Hey goshdogit, thanks for all your help. I guess I really should have kept all this in one place, it would have helped me keep track of it.
I was able to connect using the ‘t13’ command, but got some minor errors. using the t85 came out a bit cleaner it seemed. I still get a warning about ‘cannot set sck period. please check usbasp for firmware update’, but the device signature comes out ok and I get the safemode Fuses ok message, much better. :+1:
I have been practicing with a demo board with a t85 chip on it before disassembling my D4. I connected the clip backwards to the demo board yesterday :person_facepalming: but it seems like it survived that.
After a couple of false starts on gettting ‘filename.hex’ correct, it looks like I successfully flashed the demo board.
