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

863 posts / 0 new
Last post
Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

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
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

Tido wrote:

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!

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

nkildal wrote:

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 ?

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

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

sixty545 wrote:
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)?
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...

sixty545 wrote:
I will do that. A problem is that today is my wedding aniversary, but I guess I can sneak out to dump the firmware if I have precise instructions on how to do it. Wink
I hope Tido can help here, as I am not expert on avrdude and its many options Smile
Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

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
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

sixty545 wrote:

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 Flat Stare

arenat
Offline
Last seen: 2 years 2 months ago
Joined: 11/22/2010 - 01:00
Posts: 367
Location: Argentina

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.

 

 

 

PAM2803

 

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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

 

driver board

arenat
Offline
Last seen: 2 years 2 months ago
Joined: 11/22/2010 - 01:00
Posts: 367
Location: Argentina

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

 

 

c78 driver

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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 Smile

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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 Smile

 

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
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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 Smile

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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 Smile

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

Quote:

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

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.

 

Quote:

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

Components are, in general, not added purely for aesthetic reasons Wink. 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
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

nkildal wrote:

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

 

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
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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

 

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

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

Tido wrote:

So the PCB works with NiMH when programmed with sixty545's files but not with the BLF-VLD. That's weird.

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. 

Tido wrote:

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.

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)

BLF AA-Y4E

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

I think I may have mislead you guys Sad  :

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 Big Smile

short

 

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

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

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

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

nkildal wrote:

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

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.

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

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?

nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

sixty545 wrote:

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

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

Quote:

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

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 Smile  

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 ?

sixty545
Offline
Last seen: 1 year 7 months ago
Joined: 10/25/2010 - 14:15
Posts: 702
Location: Denmark (GMT + 1)

nkildal wrote:

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 Smile  

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

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

sixty545 wrote:

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

Yes, using the lock-bits.

 

nkildal wrote:

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 ?

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

 

nkildal wrote:

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

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


nkildal
Offline
Last seen: 1 year 1 week ago
Joined: 12/02/2010 - 03:13
Posts: 36
Location: Denmark

Tido wrote:

sixty545 wrote:

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

Yes, using the lock-bits.

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

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

Tido
Offline
Last seen: 3 years 2 months ago
Joined: 05/28/2010 - 15:28
Posts: 189
Location: Berlin, Germany

Quote:

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. Perhaps the values for the original dump, low: 6A and high: FD is safe to try?

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.

 

Quote:

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.

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.

 

Quote:

At least, it works  -  thank's Tido!

You're welcome Smile

Pages