Did I brick my D4V2?

I’ve been trying out a bunch of Anduril variations using my D4V2 as a testbed, using the Emisar flashing tool. Today I went to flash like I’ve done 50 times before with the command:

avrdude -p t1634 -c usbasp -u -Uflash:w:anduril.emisar-d4v2.hex

and got a mismatch on byte 0x00, probably from shaky hands. When I went to try again, and got the “error: program enable: target doesn’t answer. 1” message.

I tried to redo the flash a few more times being careful to align all the pins but kept getting “target doesn’t answer”, so I looked around for troubleshooting tips.

  • Tested all the pins from the ribbon cable all the way to their tips with a multimeter and all of them come back good.
  • Wiped the surface clean with an alcohol wipe
  • Let it sit for a hour or so to let everything discharge or whatever
  • Tried changing the voltage from 5 to 3.3 (worked for someone with a D4S on one thread)
  • Tried reading the pins a different D4V2 (using the -n option to prevent two bricked heads) and got a valid device signature of a t1634, so the flashing tool is obviously working and the pins are aligned enough to make contact

So now I’m stumped, and could use some advice. I don’t want to do a -F override or play with fuse settings since all the other threads say that’s more dangerous than helpful but I might be able to try it if someone can explain why. Also, every thread says bricking a 1634 is pretty unlikely when not messing with fuses and if you don’t literally smoke it.

It’s probably fine, but sometimes some individual lights can get weird about flashing. Most of the lights I have are easy to reflash, but some will take literally a hundred tries before it works. I think there may be something partially shorted inside or something, interfering with the avrisp device.

Like, I have a ROT66 I’d like to update… but I don’t want to spend an hour or more trying to get it to flash. When I finally got it to work last time, I decided to just never touch it again.

So, not sure what the issue is, but it might help to try physically different positions during the flashing process, check for any wires or bits of metal out of place, etc. Then after you get it to work, maybe leave it on that rev for a long time.

I’ve also had this happen when one of the pins on the flashing adapter wasn’t connected quite right. Sometimes it can flash with a pin disconnected entirely, but it takes several tries and usually can’t verify afterward.

@ToyKeeper:

This is pretty minor, but I cannot see your pic of Link in your signature unless I open the image in a new tab.

Thanks for taking the time to reply. I invested another half hour into this tonight and probably did a hundred attempts like you said at a bunch of angles with no luck. I’m out of canned air at the moment but once I get one I’ll give it a few shots from each side to knock anything loose and give it one last try.

I’m showing continuity from the tips of the pins all the way to the solder points on the back of the USB board (and no apparent shorts between them), but that’s about the limit of my diagnostic skills at the moment. I’m guessing that leaves something I can’t see on the flip side of the bottom board in the D4 head.

If I can get any firmware loaded on this I won’t touch those pads again, but that feels a little like false hope.

The server uses a HTTP referer check for images, because my bandwidth was all getting used by random people hotlinking pictures. BLF is on the allow list though, and in the recent logs I see 18865 cases where BLF-related images were allowed and only 33 cases where it was denied… so I think it’s still working. Perhaps your browser is sending an unusual referer string?

Exactly. There may be something shorted inside, like an aux LED wire or switch wire. Or it could be something else entirely. I’ve only had this happen a couple times, and haven’t always managed to figure out what caused it.

On a couple models, especially some of Lexel’s early drivers, flashing wasn’t possible while everything was connected. I had to disconnect the aux LED board in order to flash firmware… because the board did something to the voltage on that pin. It’s possible that even a change of resistance on the LED boards could interfere with flashing. There’s a whole lot of analog voodoo inside that I don’t really understand, so I don’t have any useful answers about it.

It’s also possible that a failed flash could put the attiny chip into a bad mode somehow, like underclocking it so far it can’t talk to the avrisp device. I’ve had that happen, though it was from bad code rather than a bad flash. I wanted to see how much power I could save by underclocking, and didn’t realize at the time that it would have side effects.

So, long story short… There are a lot of ways it could fail. It might be recoverable, or it might not.

Chrome says: Mixed Content: The page at ‘https://budgetlightforum.com/t/-/66786’ was loaded over HTTPS, but requested an insecure element ‘http://toykeeper.net/torches/css/link.png’. This request was automatically upgraded to HTTPS, For more information see Chromium Blog: No More Mixed Messages About HTTPS

Since you don’t have HTTPS bound, they’ll fail on timeout.

I just flashed an old D4S last night, and I kept getting write/verify errors until I added a -B 4 to the flags, to set the bit clock. It’s worth a try ::shrug::

avrdude says it can’t set the sck period. Apparently this is something that the inexpensive USBASP devices aren’t capable of. What are you using?

Oh, yeah, I couldn’t get the usbasp hank sent me to work. I’m using an AVR pocket programmer. Nevermind I guess :slight_smile:

Ah, that explains it. It seems BLF added https, and browsers are trying to convert links even when that means using a protocol the destination site doesn’t support. This isn’t likely to get fixed any time soon. Ever tried to use ssl over a reverse proxy with name-based vhosts and certbot? It’s … complicated. I’ll add it to my list, but I have no idea how long it’ll take.

Does it use the same pinout as the usbasp? Could I just grab one and plug in the pins for the D4V2?

Good to see you ToyKeeper :slight_smile:

Got this same setup at home. Check out certbot-plugin-gandi to make issuing/renewals a lot easier.

Yup, there's not many women on BLF, and most of them aren't brave enough to reveal their gender.

I understand, as I think you might receive a lot of inappropriate PMs on BLF.

Also, you're a really cool person to boot.

I was away from BLF for quite a while and its always nice to see posters from the old days.

It looks like the same pinout, yeah. But, if you can program the other D4V2 with the USB ASP, I don’t think the programmer is the problem :frowning:

I made a GPIO flasher out of my Raspberry Pi and a breadboard to try to get a lower baud rate and every time I got a solid connection the flashlight head would get perceptibly warm, so I’m pretty sure its a short involved. Probably the USBASP is just refusing to even put that much current into the thing and just gives up. Oh well, replacement board will be on the way shortly and I’ll try my luck with the replacement. Worst case is I just leave this D4 head unassembled and turn it into a mini-testbed for tinkering with builds.