Flashlight Firmware Repository

hi again,

today I’m trying to flash the blf-a6.hex -file, but I’m getting an error. I’m trying it with a bare MCU, wanted to do that before soldering it to the driver board, don’t know if that makes a difference.

I usually see the verification errors only if there’s a pin not connected during flashing. Six pins are required:

  • 1 RST
  • 4 GND
  • 5 MOSI
  • 6 MISO
  • 7 SCK
  • 8 VCC (don’t forget VCC, even though it’s not in bold in the table below)

BTW, it can still be flashed after soldering to the PCB… but only if you don’t have any extra pins grounded or stars soldered. I reflash MCUs on drivers all the time.

Yeah I agree with TK, usually I only get that error if I bump it while flashing

Thanks Toykeeper (EDIT) and pilotdog,

the connection didn’t seem to be the issue. I checked with following command from Hoop’s guide:

avrdude -p t13 -c usbasp -n

I have tried to flash different firmwares to these new bare MCUs I ordered, everytime I got the same error. When I tried to flash these firmwares to MCUs that were sitting on a 105C already, it worked.

Now I changed the jumper on the USBasp to the 5V setting and guess what… it worked with the bare MCUs. I have no clue why that is, but I’m glad it worked.

I’ll let you know how I like the firmware when I finally manage to get a driver soldered together and have it installed in a light.

Ah, I forgot about the 3.3V / 5V jumper. Mine came configured for 5V and it has never been an issue.

BTW, the avrdude connection check will still pass even with VCC not connected. I flashed drivers for several weeks (with verify errors each time) before I figured out there was a physical connection issue on my VCC, but after fixing that things have been much better.

Not sure if this is the right place but I know TK had seen problems with the OTF cap timing when using a 22K resistor. Would there be the same problem, or worse, with a 36K resistor? I'm seeing awful results - when cold, quick clicks don't change modes, then after a few clicks it starts working, but as a long click (in the BLF A6 driver, moon to hidden turbo, etc.), then after a while the quick clicks work the way they should, but long clicks seem impossibly long... Ugh it's pretty useless in this setup - guess could be a bad part, but again, first time I'm trying a zener mod with the 36K resistor on a 22mm wight FET+1 board (https://budgetlightforum.com/t/-/31559).

Hi

I would like to change the turbo on blf-a6 firmware to a smaller value.Is this possible? I changed “#define MODESNx2 0,0,79,255” to 0,0,79,175 ,the max output was reduced but the turbo timer didn’t work anymore .Should I also change the “line 117 #define TURBO 255 // Convenience code for turbo mode”?

Yes, it changes the OTC values significantly. You’ll need to recalibrate the OTC values and voltage values completely. The tools for this are under ToyKeeper/battcheck/offtime-cap.hex and battcheck.hex.

Voltage is relatively straightforward; connect it to a power source with the voltage you want to measure, read the blinks, put that value into your target firmware. Repeat for each voltage level you need to measure.

Offtime is a bit harder, unless you have a robot to press connect/disconnect power with very precise timing. Basically, connect power, disconnect it, wait for the time you want to measure, connect power again. Repeat a bunch of times to get an average, and use that.

If you keep getting 255, it means the time is out of the MCU’s measurement range (too short), or a 0 means it’s too long. The problem I get is that it stays at 255 for a while before the OTC voltage drops into the usable range (especially when the light is cold).

Ideally, you want both voltage and OTC values to be near the middle of the measurement range for the best accuracy and consistency. The values should ideally center around 128 or so, though really anything between 64 and 192 is good. Probably anything between 32 and 224, really. Outside of that though, it’s getting into the range where it’s hard to measure reliably. The only way I know to adjust this is by choosing different resistors.

But I don't see any consistency, so don't see how calibration could work. Right now when it's cold, long press's are the only thing that work. After playing with the modes a few time, short press's are all that work. It seems temperature related, so how could I calibrate to anything?

Yes, you should also set TURBO to 175 if you want step-down to work. :slight_smile:

Also, if you want the modes to remain evenly-spaced, I suggest running the bin/level_calc.py tool to calculate a whole new set of PWM levels. If you don’t use 255 though, you may need to edit level_calc.py to either set the value there or uncomment the line which asks you for that. Here’s what it does after I uncomment that line and re-run it with a max of PWM=175 for a 960-lm turbo:

> ./bin/level_calc.py 4 1 10 175 960 y 20 10 140
1: visually 2.15 (10.00 lm): 0.00/255, 20.00/255
2: visually 4.72 (105.46 lm): 0.00/255, 192.56/255
3: visually 7.29 (388.17 lm): 64.68/255, 255.00/255
4: visually 9.86 (960.00 lm): 175.00/255, 0.00/255
PWM1/FET  values: 0,0,65,175
PWM2/7135 values: 20,193,255,0

I got 960 by estimating an actual maximum of 1400 lm, then multiplying that by 175/255.

If turbo isn’t 255 you could also try making turbo a little more efficient by putting some of the load on the 7135 chip. On a XP-L or XM-L2 it’ll generally get about 140 lm on the 7135 alone or 1400 lm on the FET alone… so subtract 140 lm from the FET value and set the 7135 at full. In this case, it would mean the brightest mode is 150 on the FET and 255 on the 7135. But that’s totally optional; it’ll make turbo more efficient, make the PWM harder to see, and make its tint slightly warmer.

Temperature is probably an issue, but the two calibration firmwares can at least quantify the issue for you. If it gives you crazy numbers, the hardware isn’t going to work. If it gives you okay numbers, you can be sure the hardware is okay and everything else is a firmware problem.

I'm not sure what good quantifying the problem would be? It's still a problem. Do you know if anyone has ever used OTC with a zener mod with the higher resistor values recommended? I haven't seen much in ways of posted details. Dale mentioned something about adding a cap or resistor on his zener, but with no explanation - never heard of that, or seen anything posted about it - dunno, if it was to address this issue or not.

For now I'll try a NOINIT firmware version, though it doesn't have the FET/7135 support in there now - not enough time to merge it in myself.

I just disabled the Offtim3 presses and it works fine as a normal offtime switching.

Doesn't this mean you lose hidden modes? Are you using value of 190? Are you using a higher R1 resistor, like 36K?

Yes, you lose hidden modes, but tbh I didn’t really want them anyways. I prefer very simple UI’s (all of my lights are either 3 or 4.mode), but I still love Blf-A6 for access to 2 mode groups and memory soft-toggle.

I think i used a 38k in my last one and the value was around 180-190

Quantifying can tell you if it’s a little off or if it’s totally out of the ballpark. Besides, if you want LVP to work you’ll need to calibrate the voltage anyway.

I think RMM has made zener+OTC lights, but I don’t know the details. I’ve mostly avoided serial-config lights and higher-voltage emitters.

BTW, if you can’t get the 3-level offtime to work, you could still use it without blinkies, or you could move the blinkies to the second mode group, or whatever. I could even make the basics work with mem decay instead of the OTC if needed, but note that the OTC interferes with mem-decay timing so it’s a good idea to remove it or ground it or make sure it never gets charged.

Played with it more (the Roche LS01 - XHP-70), amazing how the timing just progress's - 1st time just blinks current mode, then quick clicks do prev mode, then quick clicks go next mode, and holds go prev mode -- works perfect Smile! Then prev mode takes longer and longer holds til they are no longer accessible... Frown

Of course I got the big flicker every time going from turbo to moon - though turbo is PHASE (not FAST) -- forgot to add a resistor on the FET gate, but I can still do that because I only used 20 AWG LED wires, and left extra length so I can get access to program the driver - nice having a light with a screw down retainer ring on the driver...

Truly bizarre. I don’t know what would cause the OTC decay to change so much over time, but I’m not good with hardware.

Thank you so much for help,I will reflash the driver in a few days.Good idea to also load the 7135 on TURBO,will definitely try it.

Hi, it’s me again having trouble getting things done by myself…

I gave the “S7”-firmware a try, because I wanted off-time memory an a nanjg driver without adding an otc.
Basically I wanted a very simple UI. Three modes, high to low, off-time-no-memory. I know I could have gone with “star_noinit” for this, but I like the battery indication mode that’s in the S7 firmware. So I tried to change the S7 firmware to high, med, low, battcheck mode.

I really have no coding skills at all. Just getting started with this. I managed to get the modes like I wanted them.

changed modes array to

In the main, I commented out all “else if”s after SOLID_MODES except the last one for the BATT_CHECK_MODE.

But now I have no clue how I have to change the part after #ifdef VOLTAGE_MON to make the lvp work as it should. I suppose I have to change something there, right? Because I changed the mode order to high, med, low, battcheck, the lvp would step into high when triggered if I leave it that way, right?

Should I change

if (voltage < ((mode_idx == 0 ) ? ADC_CRIT : ADC_LOW)) {

to

if (voltage < ((mode_idx == 2) ? ADC_CRIT : ADC_LOW)) {

and

if (lowbatt_cnt >= 3) {

if (mode_idx > 0 ) {

mode_idx = 0;

to

if (lowbatt_cnt >= 3) {

if (mode_idx != 2 ) {

mode_idx = 2;

???

Please let me know how stupid my approach is, but don’t be too harsh, I am really new to this stuff…

By the way, I managed to build a FET+7135-driver with BLF-A6-firmware. Really nice firmware! But I strongly recommend using it with a reverse clicky, because until now I’m using it with a forward clicky and I feel it was much more intuitive with a reverse clicky.