The switch LED will light up on some lights when I attach the clip. It depends on which pin it is using.
i just got this, has it flashed?
C:\avrusb>avrdude -p t13 -c usbasp -n
avrdude: warning: cannot set sck period. please check for usbasp firmware updat
.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e8007
avrdude: Expected signature for ATtiny13 is 1E 90 07
Double check chip, or use -F to override this check.
avrdude done. Thank you.
C:\avrusb>avrdude -p t13 -c usbasp -u -Uflash:w:biscotti.hex:a -Ulfuse:w:0x75:m
-Uhfuse:w:0xFF:m
avrdude: warning: cannot set sck period. please check for usbasp firmware updat
.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.05s
avrdude: Device signature = 0x1e9003
avrdude: Expected signature for ATtiny13 is 1E 90 07
Double check chip, or use -F to override this check.
avrdude done. Thank you.
No, that doesn’t look right. The device signature changed, so it probably has a bad connection and corrupt data.
A successful flash generally looks something like this:
http://toykeeper.net/torches/fsm/flash.success.txt
ok, so i desoldered pin 5
do you think that might of changed signature?
or should i just keep doing what i did?
I am not an expert, but it looks different than my successful flash noted above. It appears you at least made contact with the chip, but either it is the wrong chip or something else. I hope someone that knows more than I can comment.
Are you sure it is the correct chip for the correct hex attiny13…If it is, something else is wrong. I understand you would like to know if it is successful before you put it back together and it still doesn’t work.
I was fortunate to flash a D4S and a BLF Q8. Both are super easy to get to the chip/driver without unsoldering or major disassembly. The chip/driver is just a quick flip away.
Here is a picture of the BLF Q8 driver…you just unscrew the driver and it the whole thing tips out, flash the chip and put it back in…so it’s simple to test after a flash:
I do not think it is a successful flash.
I am glad you did not give up!
one step closer driver flashed successfully 
but flashlight modes are erratic now.
i get no beam then moon turbo(i think) and med strobe sos(but as continuous dashes) all in different order every time i switch on.
tapped 10 times to get into config but cant get it to work so i replaced lighted switch with generic one that came with flashlight and now just get one mod.
have i destroyed one of the chips on the board?
Hi TK,
I have a fairly fresh Convoy S2+ with their (I guess) newer driver (no stars, 6 chips) and I couldn’t flash before I cut the trace as mentioned here in the topic. I have successfully flashed nlite.hex and set the fuses to the values mentioned in the repo, and confirmed that the flash was succesful by veryfing the flash and fuse settings. However, the flashlight now doesn’t work - after applying power nothing works, the light doesn’t light up. Do I have to resolder the connection between pin 5 and the cut trace?
EDIT: I have bridged the trace that I have cut earlier on - and the flashlight still doesn’t seem to turn on. I’m unsure on how to proceed further. The ATTiny13A can still be read and flashed, and is responding correctly, I have inspected the board as well and I see no obvious issues here. Any ideas?
Here’s a picture of the driver. I’m deadbugging it for now since I’m waiting for the clip, but it works well so far 
Output from AVRDUDESS (a touch more convenient, the command for flashing was: avrdude -c usbasp -p t13 -P usb -b 9600 -B 0.5 -F -e -U flash:w:F:\PROGRAMMING\CONVOY_S2+_firmware\nlite.hex )
So, nothing here suggests corrupt data or whatever, maybe I’m writing a wrong hex file? Which firmware versions will fit and work out of the box with the Convoy drivers? There are no markings on the board aside from small ‘convoy’ text on the silkscreen.
Thank you for all the help and hard work on these!
It’s weird that it doesn’t light up. I haven’t tried to operate a light with the flashing connections still attached, but I think others did it without issues.
Firmwares which should work include:
- JonnyC/STAR/STAR
- ToyKeeper/STAR_noinit
- ToyKeeper/bistro/biscotti
- ToyKeeper/crescendo
- ToyKeeper/s7
- gchart/babka
- gchart/ramping-ui
I went ahead and flashed gchart’s ramping UI - and it worked! There was no issue powering it on even with the flashing connections attached. I also tested babka, and finally settled on your crescendo firmware - excellent work!
So all in all - the problem was that I couldn’t clearly identify which firmware versions would work for the driver I had (I know presume it is a member of single channel drivers, and such firmware has to be chosen)
Thanks for all the tips!
EDIt: One last thing: I can’t seem to be able to enter config mode on crescendo firmware. I’m making fast taps, tried a lot of then, but the torch just seem to be changing modes, not entering config. Any special tricks here TK?
Config mode is only there if it’s enabled at compile time. I’m not sure if it was enabled in the pre-built hex file.
With attiny13a, it may be difficult to fit config mode, because it uses a bunch of space. It’d probably require removing all the blinky modes, and the only option it could give is whether memory is enabled. There is no thermal sensor on tiny13, so no thermal regulation.
FWIW, the firmware I use on most of my nanjg/Convoy-style drivers is called S7. I made it for my Convoy S7, but have used it on several other lights too. It’s one of my oldest UIs though, and the code is relatively messy. And it has no runtime options. Just a few well-spaced regular modes and a whole lot of blinkies. No memory. Moon mode and voltage calibration generally require tweaking on a per-light basis.
Why dont You just try this avrdude interface: www.yourdevice.net/downloads/avrdudeprog33.rar
AVRDUDE_PROG
Any ideas why I can’t flash my D4? Keep getting “target doesn’t answer” message during connection check. Chip pins look ok and clean. Clip is well seated and all the pins are touching. I managed to flash my D1 without any issues.
On a D4Ti, I had the same problem the other day. I removed the MCU - still would not flash in the air while other new MCU's do. So I had to replace it - flashed a new one in the air, reflowed it on the board. Now it programs fine on the board as well. Behaving almost like the MCU was locked - possible I suppose...
Edit: Ohhh - is that the message we ignore all the time? It's ingrained in me. I forget which message is which...
I’ve had that message all the time but the flashing succeeds
Interesting, I’d be surprised if Hank intentionally locked some but not others. I was tempted to try flashing despite the messages but was worried it would brick it.
No not that one, the other one!
Edit: in case there’s any confusion, the message I’m talking about is “avrdude: error: programm enable: target doesn’t answer. 1”. The message which appears every time and is safe to ignore is “avrdude: warning: cannot set sck period. please check for usbasp firmware update.”.
Try some other commands to the mcu, if it doesn’t answer then go over the pin outs again. Make sure its wired exactly like hoop’s guide.
I had mine wired like the wiki guide and worked fine for years using the attiny13 but when I tried the attiny85 it gave me the message your seeing and would not talk to the mcu.
Took it all apart and wired it up like hoop, no more problems. Just a suggestion, it still could have some other problem…
Do you have any suggestions for commands to test?
Wiring is all good, checked and tested again on a D1 (also uses attiny85 - in fact I think the whole driver is the same but with slightly different firmware config settings).
I think it is this one. Its been awhile since I have programmed anything.
avrdude -p t85 -c usbasp -n
Ah yes, good memory, that’s the command I’m using to test the connection before flashing but it falls over with “target doesn’t answer” warning.