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

Tido · December 2, 2010, 11:24pm

Hmm, the chip below the red wire is a candidate for a boost control circuit, but I can't really tell without knowing how it's connected to the other components.

One thing you could try is flashing the old program into the ATtiny to see if it will work again. This way we can be sure it's a problem with the software and not just a hardware defect. Of course we'll need a copy of the original driver software... sixty545, don't flash your BLF, we need to make a backup of its firmware first!

Well, it's getting late and need to get up early. We should continue with this tomorrow, maybe via IM or IRC.

nkildal · December 2, 2010, 11:27pm

Yep - I also need to get up early tomorrow - so lets call it the day.

Lets get a copy of the original firmware (from sixty545?) - it could be fun to see, if it will work again.

I guess the original fuse settings are also interesting - perhaps the original clock is set much lower ?

sixty545 · December 3, 2010, 9:25am

I won't, I have found another victim, my WF502-B with an AK-47 set to 3-level. I can understand that the fixed mode BLF-VLD2 has 3 levels, but which 3 of the 9 defined levels is it? Oh- I see it now, is it no. 3, 6 and 8 (MODE_LVL008, MODE_LVL064 and MODE_LVL255)?

I will do that. A problem is that today is my wedding anniversary, but I guess I can sneak out to dump the firmware if I have precise instructions on how to do it.

nkildal · December 3, 2010, 9:29am

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

Tido · December 3, 2010, 7:14pm

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.

sixty545 · December 3, 2010, 9:28pm

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

nkildal · December 3, 2010, 10:04pm

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 :-|

arenat · December 3, 2010, 10:34pm

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.

nkildal · December 3, 2010, 11:08pm

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...

arenat · December 3, 2010, 11:32pm

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

sixty545 · December 9, 2010, 12:23pm

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!

nkildal · December 4, 2010, 5:32pm

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 :-)

nkildal · December 4, 2010, 6:08pm

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

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...

sixty545 · December 4, 2010, 11:29pm

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?

nkildal · December 5, 2010, 7:11am

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 :-)

sixty545 · December 9, 2010, 12:25pm

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.

nkildal · December 6, 2010, 12:50pm

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 :-)

Tido · December 6, 2010, 3:25pm

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.

Tido · December 6, 2010, 3:56pm

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.

sixty545 · December 9, 2010, 12:26pm

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.