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


Yes - these are the modes used in the original BLF VLD as far as I know. I had to use some time, to understand how Tido sets up modes - but it is actually quite clever…

I hope Tido can help here, as I am not expert on avrdude and its many options :slight_smile:

sixty545, please try the following command to dump the firmware:

avrdude -pt13 -c usbasp -P com2 -u -Uflash:r:flash-dump.hex:i -Ueeprom:r:eeprom-dump.hex:i -Ulfuse:r:lfuse-dump.hex:i -Uhfuse:r:hfuse-dump.hex:i

This should create four files, one each for the program flash, eeprom, high fuse and low fuse.

OK, I can give it a try tomorrow evening. Then I need a way to pass the files to nkildal.

I just sent you a PM with instructions.

Btw: I just now spent 2 hours resoldering my SOIC clip - it turned out, that 5 of 8 connections had broken.

Some of the pins had pulled back yesterday - I guess I must have broken them in the process of pushing them out again - sigh :-|

I think the 6 pin ic is a PAM 2803 or similar ,DC DC converter which must start first to feed the atmel chip.

To start pin 4 must be in high state as in simples driver without modes.

I took another picture of the driver board, showing the 6-pin chip, but the number on it is not easy to see - it may look like CF80Q...

Is the same as in the C78 and Hugsby P31 , pam 2803, the last letters are year and month,

Two components was obstructing the clip. Had to unsolder them. Not an easy task for them old eyes.

But success!

4 files made:

flash-dump.hex

eeprom-dump.hex

hfuse-dump.hex

lfuse-dump.hex

Hope you can use them, nkildal.

The 6 pin circuit on my driver clearly reads: CFB0Q

! Edited dec.9:

The above dumps cannot be used because the chip prevent reading!

Hi sixty545

Thank you for the files - they have safely arrived.

If anyone is interested in the original files - they can be downloaded from here as a zip file.

I will now try to flash my blf driver board back to the original software and see what happens :-)

Ok - this is weird:

I flashed the chip using sixty545's files - now the light just gives out 2 bright flashes when i turn it on, and then is constant on, at what seems like full level.

Here are the results from verifying the chip after flashing it with sixty545's files - perhaps you guys can see something from the fuse settings:

avrdude -P /dev/tty.usbserial-A600aSmp -p t13 -b 19200 -c arduino -v

avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01

Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "/usr/local/CrossPack-AVR-20100115/etc/avrdude.conf"

User configuration file is "/Users/nicolai/.avrduderc"

User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/tty.usbserial-A600aSmp

Using Programmer : arduino

Overriding Baud Rate : 19200

AVR Part : ATtiny13

Chip Erase delay : 4000 us

PAGEL : P00

BS2 : P00

RESET disposition : dedicated

RETRY pulse : SCK

serial program mode : yes

parallel program mode : yes

Timeout : 200

StabDelay : 100

CmdexeDelay : 25

SyncLoops : 32

ByteDelay : 0

PollIndex : 3

PollValue : 0x53

Memory Detail :

Block Poll Page Polled

Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack

----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------

eeprom 65 5 4 0 no 64 4 0 4000 4000 0xff 0xff

flash 65 6 32 0 yes 1024 32 32 4500 4500 0xff 0xff

signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00

calibration 0 0 0 0 no 2 0 0 0 0 0x00 0x00

lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00

hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00

Programmer Type : Arduino

Description : Arduino

Hardware Version: 2

Firmware Version: 1.18

Topcard : Unknown

Vtarget : 0.0 V

Varef : 0.0 V

Oscillator : Off

SCK period : 0.1 us

avrdude: please define PAGEL and BS2 signals in the configuration file for part ATtiny13

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9007

avrdude: safemode: lfuse reads as 79

avrdude: safemode: hfuse reads as EF

avrdude: current erase-rewrite cycle count is 808531511 (if being tracked)

avrdude: safemode: lfuse reads as 79

avrdude: safemode: hfuse reads as EF

avrdude: safemode: Fuses OK

avrdude done. Thank you.

However - no real harm has been done - as I tried flashing back to the BLF-VLD without problems :-)

Edit: I forgot to write, that the light actually turns on with both NiMH and Li-ion with sixty545's files now - even if it first blinks twice and then is constant on...

nkildal, looking at the flash-dump.hex I would say that it is not program code. I will try again when I get the clip to stay put on the uP. It slides off all the time.

OK, it sits.

When I repeatedly dump the flash, every time one or two bytes have changed at random places.

I'm afraid there is some timing issue here.

Every time I also get: avrdude: warning: cannot set sck period (see earlier in the thread).

I removed two components at the ends of the uP. Could they be needed for proper functioning?

I also had problems getting the clip securely positioned on the chip - I ended up cutting a tiny bit of plastic away from one of the corners on the clip.

It is my impression, that reading & writing the chip should be possible regardless of its surrounding components - but perhaps Tido knows more on this subject ?

However - you don't have to mess too much around with this, if it is too tricky and you risk killing your driver board.

Thank you for your effort so far :-)

I tried to dump an AK-47 driver also. The same pattern here (not the same bytes, but almost).

Edited dec.8:

The chip prevents reading.

Hmm - that sounds weird.

I just got hold of another BLF AA-Y4E from a friend of mine, and he has allowed me to try dumping the data from it.

I will try this out tonight and report back my findings :-)

Unless the firmware does some silly things like self-modifying code (which would wear out the flash memory pretty fast), there should be no difference between dumps.

Components are, in general, not added purely for aesthetic reasons . If you removed the brown-ish capacitors, the driver will probably still work, but you might experience some instability due to voltage spikes. The black components look like diodes and I doubt that the PCB will still work without them.

So the PCB works with NiMH when programmed with sixty545's files but not with the BLF-VLD. That's weird. Could you check if there is a trace from the ATtiny to the driver chip? If it's really a PAM2803 (thanks to arenat for the tip, BTW), the µC could disable the boost circuit if it detects that it is run off a Li-Ion battery. If possible, please check if the chip's pin 4 (closest to the PCB's centre) is connected to a pin on the µC.

Well, I did'nt remove any components from the AK-47 and it had the same behaviour.

Now I have seen some hope in the horizon:

I took the 2.8Amp regulator from KD that I programmed the other day with BLF-VLD2-variable. It still has the leads with plug in the end soldered to it. And I tried to dump that.

I think that it was a success, because the flash dump starts with the same bytes as the original hex file and the fuses dump look just right.

Either I still have a clip issue or the KD print behaves better than the others. I will persue the clip failure thought.

Edited dec.8: It was not an clip issue.

Yes - that is weird. But perhaps the files from sixty545 was corrupt - cause the driver did not at all act like it should.

I will try to read out the 4 files from another BLF AA-Y4E I borrowed from a friend today, and see if I can get consistent files out of it.

Hmm - it is hard for me to see, whether pin 4 of the PAM is connected to the µC. It looks as if it is connected to a through hole - right on the "+" mark.

(The big blob of solder right above the "+" sign, is the positive connection to the LED)

I think I may have mislead you guys :-( :

I just now tried to flash my driver board again, with the BLF-VLD software. I used my own 5-mode version (1/255 -> 32/255 -> 255/255 -> Strobe -> "Soft Beacon") and all of a sudden it worked with both NiMH and Li-ion.

Searching for a possible explanation, I saw that there perhaps had been a short - between pin 4 of the PAM and the positive LED pad (see picture below).

This evening I unsoldered the wire from the positive LED pad, and removed a bit of excess solder - this may have shorted the two previously.

The good news is that Tidos BLF-VLD seems to work fine with both NiMH and Li-ion, in the BLF AA-Y4E :-D

But I succeeded in getting my friends BLF AA-Y4E read out 3 times in a row, every time generating identical files.

If anyone is interested in these files, I have placed them for download here (Removed the link again, because it showed up, that the files were invalid)

So - sorry for - sort of - wasting your time sixty545, having you try to read out your driver board, when it was probably a mistake on my part, for the BLF VLD driver apparently not working on NiMH's...

And now I have found out, where pin 4 of the PAM is connected to:

It actually is connected directly to the positive battery spring on the other side of the board...