Recover/repair unresponsive Noctigon KR4 linear driver after avrdude flash?

Flashlight Modding and DIY Parts
1

I’m afraid I might have bricked/zapped the linear driver for my Noctigon KR4 (with E21A 2700K)… Try as I may, it won’t respond to avrdude at all.

Context and diagnostics

Using the Intl-Outdoor D4V2 flashing kit with my Linux computer, I flashed a new build using the flash-tiny1634.sh script from the Andúril repo, avrdude reported a verification error, then, no matter how many times I’ve tried, I cannot get anything other than error: program enable: target doesn't answer. 1 (see logs in Addendum A). The driver no longer operates like expected - no aux lights, no response to button presses.

while ! avrdude -c usbasp -p t1634 -n ; do
    sleep 1 # Wait to try again
done
# …just gives "avrdude: error: program enable: target doesn't answer. 1"
# Forcing with "-F" results in a random device signature
# Full logs in Addendum A

Trying many tens of times (in a loop while prodding with the pogo pin adapter) has not brought about success, nor has disconnecting from power for 30 minutes and trying again after that. I’ve even installed Microchip Studio in a Windows VM, but had troubles passing through the USBasp adapter (I can retry that if needed).

I can still flash my D4SV2 and D4V2 (which has a KR4 linear driver) without issue. And I’ve confirmed with my multimeter that the KR4’s V- pad is connected to the outermost ring of the KR4 driver, and the MI pad connects to the e-switch, as expected. (Shout out to SiteRelEnby on IRC for suggestions.)

I’ve heard the Attiny chips are really hard to brick and accidentally interrupting the ISP during flashing shouldn’t cause problems. I’ve flashed my KR4 tens of times since I got it November 2020 without issue.

I generally ground myself by touching the flashing kit’s USB A connector shield before flashing, though I can’t recall if I did that every time I touched the pogo pins. It is possible that I might’ve zapped something.

Next steps - recovery, repair?

At this point, are there any further options for recovering the MCU without disassembling/desoldering?

If not, for someone comfortable with through-hole soldering but brand new to SMD, and having never removed the driver from one of Hank’s lights, how involved is replacing the MCU?

Alternatively, does anyone offer repair services within the United States?

(And if diving into the insides anyways, are there better driver options for E21A LEDs, e.g. this KR1/KR4 thread?)

Addendum A: avrdude logs:

Tap/click to show full console logs of the failed avrdude flash, then resulting errors 
$ run-one-until-success ./bin/flash-tiny1634.sh "/path/to/2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex"

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 = 0x1e9412 (probably t1634)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex"
avrdude: input file 2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex auto detected as Intel Hex
avrdude: writing flash (10632 bytes):

Writing | ################################################## | 100% 7.06s

avrdude: 10632 bytes of flash written
avrdude: verifying flash memory against 2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex:
avrdude: load data flash data from input file 2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex:
avrdude: input file 2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex auto detected as Intel Hex
avrdude: input file 2023-11-06-anduril.digitalcircuit-noctigon-kr4-nofet-e21a-2700k.hex contains 10632 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.50s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x24
avrdude: verification error; content mismatch

avrdude done.  Thank you.


avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: error: program enable: target doesn't answer. 1 
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.


avrdude done.  Thank you.
[…trimmed many further repeated failed attempts…]
2

You could try using HVP in-circuit, but there’s a chance this might just release the magic smoke from the driver as it involves applying 12V to the MCU, and it might also need access to pins that aren’t exposed via flashing pads.

The most helpful post I read about it with what seems to be the same issue (although on a t85) is Removing a Curse from ATtiny85 Fuses.

When this happened to me, in the end I just got a new driver because it was going to be more time and expense for non-guaranteed results, but it’s interesting to look into anyway.

3

Thank you! That makes sense.

Ah, yeah, I might have seen that - quite an interesting exploration, but that would be after repairing, to satisfy curiosity.

At this point, the way forward seems to be getting a new MCU, or an entire new KR4 driver (especially if there are nicer options compatible with E21A LEDs), and I’ll need to either learn to do SMD (I’m willing to investigate), or find someone to pay to handle this alongside dealing with shipping (United States).

4

I just had jlhawaii do it on my light, probably the most reasonable price around, plus if you had any accessories you were planning on picking up you can save some money by combining that with the return shipping.

1 Thank
5

Yeah, there’s a high risk of frying something. Even if the MCU is fine with the extra voltage, other components on the driver might not be. Like, on old FET+1 drivers, the +1 generally gets fried when doing anything over 6V or so… and occasionally the FET does too. The driver I’m using for development right now has a hard maximum of 4.4V, so I can’t even use a 5V flashing adapter… I have to use 3.3V instead.

So usually HVSP requires pulling the MCU off first, recovering it, then soldering the MCU back onto the board. And that’s not feasible for most people. It needs IR or hot-air reflow tools, high-voltage flashing equipment, and a relatively high level of skill.

I’m glad we have UPDI now instead of AVR ISP… and I’m working on getting Hank updated to a newer MCU. But older models are still stuck with an older protocol which is less convenient and slightly less reliable.

3 Thanks