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

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

Really no need to be sorry. I do this for my pleasure and the BLF light was going to be disassembled and modded anyway.

Congrats with your progress!

As I said above, I had my doubts about my clip, but there were no faults in the connections all the way to the tip of the clip.

I tried to read the BLF light (as you know) and a functioning AK-47. They gave faulty dumps. But the KD 2.8 Amp board that I programmed earlier I could read with soldered leads (not clip).

I have another of the KD, not programmed by me, which I could not read with the clip either, and I programmed it to my own fixed 4 mode version of BLF-VLD.

THAT ONE I CAN READ NOW!

I thought it could be the fuses that need to be set the "Tido-way" before I can read data back? You can see that I don't know the Atmel processors very well.

Then again, You could read your friends BLF, but with another programmer than mine.

Now I have to check if the drivers I programmed really work. If they do, the only thing I am missing is a possibility to take a backup of the original driver program.

nkildal, I'm sorry to say that I don't think that the code you read from your friends light is program code!

Could theese processors have been made unreadable by any settings from the factory?

I guess you might be right:

Even though I succesfully read out the files 3 times in a row (that is the files where identical each time), I have not yet succeded in writing them back to the microcontroller again.

The writing seems to go fine - but the flashlight will not turn on afterwards and is just unresponsive...

Perhaps - I don't know enough about AVR's to say.

I tried looking at the fuses of the original image (lfuse:6A hfuse:FD) using this AVR fuse calculator - but I did not learn much :-)

Tido has already mentioned, that the the original image seems to be running with internal clockdivision by 8 in contrast to his BLF-VLD - is this the reason why I can see PWM flickering in the original image, but not with the BLF VLD without the CKDIV8 fuse setting ?

The original image seems to have BODLEVEL0 set and not have SELFPRGEN set - can someone explain what these settings do ?

I tested my AK-47 driver with my own fixed Lumen levels of:

100% - 25% - 6.3% - 1.5% but I got approx:

100% - 21% - 1.5% - glow

This could be due to the fast PWM, the narrow pulses do not look nice on an oscilloscope. I think that the circuit including the LED is not designed for such narrow pulses. I would be very interested in trying internal clockdivision but am afraid to fiddle with the fuses. I will try low fuse = 0x6A (or 0x69) and high fuse = 0xEF or 0xED

The BODLEVEL0 (=0) sets the Brown-out reset to occur if the voltage sink below 1.8 V to prevent destroying data in the EEPROM.

The SELFPRGEN bit could be the reason that we cannot dump the program. As I understand this bit is important for upload and download of program. Perhaps programming high fuse to 0xED will enable us to dump the original program.

Another point is that it seems to be a draw of luck to get the light to switch to next level (sorry Tido). Perhaps the timing of clicking is specified too narrow.

At least, it works - thank's Tido!

Now there is a lot of reading to do in the ATtiny13A manual.

Yes, using the lock-bits.

With this settings the core runs at 1MHz, which is still fast enough to give flicker-free PWM (~5kHz with fast PWM, ~2kHz with phase corrected PWM). To see flicker the frequency would have to be scaled down more by setting a prescaler on the timer/counter or doing PWM in software (and implementing it very inefficiently, too).

Setting just BODLEVEL0 enables the brown-out detection at 2.7V. SELFPRGEN allows the program to alter the flash memory.


Ah - I guess I could have read out the lock bit setting from the BLF AA-Y4E before trying to reprogram it then :-|

Is it correct that an additional "-U lock:r:lock-dump.hex:i" to our dump command would have done this ?

There are some losses due to capacitance of the components and leads and also switching delays by the linear regulators. If you want to have a lower PWM frequency, you could either set the system clock prescaler via the fuses or change the timer/counter prescaler set in the program code. You'd have to recompile the source in both cases (update the F_CPU compiler flag if you change system clock).

I'd recommend changing the timer prescaler. Look for the line "TCCR0B = 0b00000001;" and change it to "TCCR0B = 0x02;", this will slow down the PWM frequency by a factor of 8. I already made this a #define in the current dev version.

Nothing to apologise for, this is exactly the kind of feedback I need to improve the driver.

Two seconds should be plenty of time to switch the light off. Maybe the AK-47 is equipped with very large buffer caps, so the µC won't reset if power is switched off for a few milliseconds. Will it switch modes reliably if you keep the power off for a second during switching? If so, things may improve if you activate the brown-out detection by setting the high fuse to 0xEB.

You're welcome :)