How To Build a Flashlight With Perfect Modes (picture heavy)

Hmmm . . . I originally guessed Pin 1 based on how the text was printed and figuring the chip was right-side up if you could read the text. But when I connected it that way the green LED would turn off. So when I do it with Pin 1 in the lower left, at least the green LED stays lit, but I still get the no connection error in AVRdude. But connecting the six pins that I think are needed for programming still didn't work, though I also tried all the combinations of Pins 2 and/or Pin 3.

The green led probably indicates powered-on. Not all of the wires need to be connect for programming as it's just serial.

Did you recrimp the rest of the wires correctly? Checked continuity w/ meter?

I checked continuity from the USBasp-labelled point to the correct pin on the clip. But I'm not sure the wires in the teeth of the clip are making good contact. Some of the teeth seem a little short. I might have to try soldering the individual ribbon wires to the Atmel chip legs which won't be easy.

You should first check that all the pins make proper contact. You picture shows that, except for RESET (pin 1) and MOSI (pin 5) all relevant pins are connected somewhere on the PCB, so you won't have to probe the chip's pins with needles or something like that. Also make sure that the target receives power from the programmer and maybe check whether the PCB still works. Applying Vcc to the wrong pins might have fried the chip.

If you can find no problem there, it might be that the chip has its clock fuses set to 1MHz or less. In that case you will have to tell avrdude to use a slower bit clock. Default is set at ~1µs and it's suitable for clock speeds of 4MHz and up. Try -B 0.25 or 0.1 (if your programmer is based on the USBasp, you might need to set a jumper somewhere to enable programming of slow clocked targets).

Still nothing. I don't have the AK-47 board hooked up to anything yet, so I can't really check to see if still works, but I did put my NANJG 106 driver back together and it still works (kind of; Low and Medium seem to be the same thing now). I tried the bit rate thing and still got the same error. I also tried soldering to the legs of the Atmel chip and that was pretty hopeless. I actually got one wire on there pretty easily, but when I tried to put a wire next to it, they were bridged. Instead of a clip, it seem like it would be better to have a housing that fits over the chip with wires where each leg goes. Then you could clamp the housing down to make sure there was good contact. Theoretically the clip should work just fine, but it seems so poorly made. Some of the pins are loose so when you pull on the crimped joiner the whole pin comes out of the clip.

OK, brted, I'm slowly starting up now, the USBISP driver and WinAVR is now installed on my XP workstation.

I'm about to make the connections between the plug on the clip and that on the USBISP. I think we have bought the same gear so you can check against this:

Tiny13 pin Clip plug USBISP plug

1 RST 1 5

2 no use 3

3 no use 5

4 GND 7 4/6/8/10

5 MOSI 8 1

6 MISO 6 9

7 SCK 4 7

8 Vcc 2 2

I'm happy if you can find an error here.

It seems like you have it. I'm not sure what your clip plug numbers are though. Going into the USBasp, the only cable I moved was the last one from position 8 to 9. I did all of the mixing and matching on the clip end. So the first wire in the ribbon cable matches up to USBasp 1, then 2 with 2, etc.

The clip plug numbers are for the 8 pin plug at the end of the cable.

I just discovered that the connection from pin 5 on the clip is broken between the tip and the little window at the side of the clip. What a bad quality!

The crimped leads seems to be easy to pull off and rearrange, so I think that I will make a straight connection between the two plugs with a 2x5 pin array and then rearrange the leads on the clip. Pin 9 on USBISP has to be handled separately.

I get exactly the same response from avrdude as you reported on nov.26. The green light (power on) is lid and the red flashes once when sending the command. There are more loose connections in the clip, that pease of sh..

I don't feel like going into micro surgery today, I am more courious of measuring on my newest light, a tiny Black Cat with Osram LED. This is my first Osram and I'm eager to see how it performs, tint-wise.

After a little (very small) soldering, and adding to the command: -P com2 -n (a little program, "USB View" showed me that USBasp was on Port2, the -n is for no writing).

I got this:

But what now ? Tido, can you help? I don't really know what this means. Is it good, or is it very good?

That looks very promising. AVRDude has successfully established a connection to the ATtiny. Now you could try flashing one of the prepared images. Go to the "Programmable" directory and call AVRDude like this:

avrdude -pt13 -c usbasp -P com2 -u -Uflash:w:BLF-VLD.hex:a -Ueeprom:w:BLF-VLD.eep:a -Ulfuse:w:0x79:m -Uhfuse:w:0xef:m

This should result in output like this:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e9007
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is 18088202 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "BLF-VLD.hex"
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: writing flash (1024 bytes):

Writing | ################################################## | 100% 1.88s

avrdude: 1024 bytes of flash written
avrdude: verifying flash memory against BLF-VLD.hex:
avrdude: load data flash data from input file BLF-VLD.hex:
avrdude: input file BLF-VLD.hex auto detected as Intel Hex
avrdude: input file BLF-VLD.hex contains 1024 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.35s

avrdude: verifying ...
avrdude: 1024 bytes of flash verified
avrdude: reading input file "BLF-VLD.eep"
avrdude: input file BLF-VLD.eep auto detected as Intel Hex
avrdude: writing eeprom (64 bytes):

Writing | ################################################## | 100% 0.89s

avrdude: 64 bytes of eeprom written
avrdude: verifying eeprom memory against BLF-VLD.eep:
avrdude: load data eeprom data from input file BLF-VLD.eep:
avrdude: input file BLF-VLD.eep auto detected as Intel Hex
avrdude: input file BLF-VLD.eep contains 64 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.11s

avrdude: verifying ...
avrdude: 64 bytes of eeprom verified
avrdude: reading input file "0x79"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0x79:
avrdude: load data lfuse data from input file 0x79:
avrdude: input file 0x79 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xef"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xef:
avrdude: load data hfuse data from input file 0xef:
avrdude: input file 0xef contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.05s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE

avrdude done. Thank you.

That's it, the driver should now be running the programmable version of the BLF-VLD.

Another screenshot:

Thank's Tido, Will this burn any fuses or can I program the device otherwise afterwards?

In fact I'm more interrested in making a light with fixed modes at my own levels but will try your example first if it is not destructive.

As long as you don't set any lock bits and don't disable serial programming, the chip can be reprogrammed a few thousand times. Just make sure you get the fuses right (that's what '-Ulfuse:w:0x79:m -Uhfuse:w:0xef:m' does).

Done!

So now I have a monster-driver 2.8A (8x7135) with variable setting. Exiting. But what about 1020 bytes instead of 1024 bytes?

I would want to test it without undoing my elaborate soldering work. (must try to repair that clip).

Thank's again, Tido,

I hope that brted also will be successfull.

Nothing to worry about. I just created the example output from a current development version, not the flash image in the published archive.

I got the clip. It's true not the greatest build quality, but it's pretty standard "pomona soic clip 5250" sold at digikey, etc. If any of the pins are short, you can push them out from inside the clip near the hinge.

My problem is that DX won't ship out the drivers. I should probably order some at KD.

Hi All

This is my first post in the forum, and I just want to thank Tido for his work on the flashlight driver.

Using the soic clip listed in this thread and an arduino board as a very cheap avr programmer, I have now reprogrammed my BLF AA-Y4E to have exactly the modes I like.

It has also been great fun to play around with the driver software "inventing" highly unusable modes :-)

Regards

Nicolai

Welcome nkildal. Good to have you here!

It's encouraging to hear people are having some success with this. I'll tinker around with mine some more this weekend and see if I can get it working. Nice that it works with the BLF AA Y4E, Nicolai! I always wonder how many people like you are lurking here, reading the threads, buying stuff, and yet we never know. Glad you've shown yourself.