Flashlight Firmware Repository

Serp · December 2, 2016, 6:39am

I’m use AVR Dude & this *.cmd file
avrdude -c usbasp -p t13 -u -Uflash:w:biscotti.hex -Ulfuse:w:0x75:m -Uhfuse:w:0xFD:m -B 57600

I fussed all morning with one driver. I compile new firmware, downloaded from ToyKeeper hex file. Nothing worked (the first case).
After lunch, I got bored. I took another driver flashed it with the same parameters. And everything was normal once.

On fonarevka.ru and the BLF topic of the New Convoy C8 mention that the driver with the new firmware has been constantly in the Moonlight mode.
Показать сообщение отдельно - Новый драйвер от Саймона
New Convoy C8 – Clearly better - #613 by leglessAlex

I would like to understand the cause of what is happening with the microcontroller.

chouster · December 2, 2016, 6:57am

Oh, that’s strange. Thanks for the links. First time I read about that. I have some 105D laying around, maybe I’ll check biscotti out today… If so, I’ll report back, if it’s working as it should.

Of course, TK would be the person to most likely understand what’s happening there.

I’m really no expert, I just thought you maybe had the fuses wrong, because it sounded like a misbehaviour that could’ve been introduced by not having BOD enabled. I don’t even know what you’re doing with that “-B 57600” in that line, but it seems like you know what you’re doing.

Tom_E · December 3, 2016, 1:16pm

I use TK's recommended fuse settings (0x75, 0xFF), disabling brownout detection, and it's been working fine for me in several lights/driver running Biscotti.

Where did the FD value for brown out enabling to 1.8V come from? Why are you guys using it?

Serp · December 3, 2016, 2:11pm

Who knows
But how does this affect the described problem?
From Simon also came not working driver.

Tom_E · December 3, 2016, 2:44pm

You mean the 2 or 3 issues listed in post #1142? I can't understood the English enough to understand the details of the issues, sorry.

chouster · December 3, 2016, 8:06pm

Tom,

as always, I could be very wrong here…

I thought TK uses the SRAM decay (noinit) trick from alexvh to detect short versus long presses. I thought BOD has to be enabled for that, but you seem to prove that wrong?!

Tom_E · December 3, 2016, 10:27pm

I've been using the same trick for quite a while with brownout disabled in other firmware versions. The 10 uF cap is a big part of that. In fact on the ThorFire BD04 (same as Convoy BD04), I pulled the C1 cap and it tested at ~1.2 uF, so Biscotti worked awful on it. I swapped the cap to a proper 10 uF one, and wholla! Worked great! With the lower cap, you had to be super quick on clicks, and with the normal cap, the timing was much easier, pretty normal.

I got some of the Simon "bad" Biscotti drivers on the way to test/trouble-shoot for Simon, that JDub-74 arranged. Think first thing I'll test is the cap -- pull it and test it's value, it's pretty easy to do. But still don't think that's the main or only problem. Problem is you can't read the fuses (don't think so) or read the programmed firmware.

chouster · December 4, 2016, 1:03pm

Thanks Tom.

And there I was, exposing my incomplete understanding in the firmware thread again.

While I’m at it, I think I read somewhere around here that the Nanjg’s never had a 10 µF cap.

Tom_E · December 4, 2016, 2:21pm

Hhmm, possible the original Nanjg's weren't 10 uF, but it's been our standard since basically day one with OSHPark drivers, and thought we duped the parts. I'm not sure back then if we knew how to measure caps though. Can't recall... The 13A can take a lot more noisy signals than the 25/45/85's can, so probably could have gotten away with it. The basic Nanjg design is kind of a mess, but they get away with it, counting on out of spec tolerances, etc., and keeping the parts count down.

ComfyChair was the originator of a lot this stuff, including the first custom FET drivers where we hacked in a FET on a Nanjg.

gchart · December 4, 2016, 3:16pm

According to this article, you might be able to. I’ve never tried it myself so I can’t vouch for whether or not it actually works.

(If the link doesn’t jump to the anchor, check out the “Download Settings” section)

Tom_E · December 4, 2016, 3:32pm

Yea, I was aware the commands exist to read it all back but I understood they didn't work. Now could be because the factory programming locks it to not allow reading, or the USBAVR dongles we use can't do it, not sure...

Worth trying though on the 105D's from Simon - I'll give that a shot. Should have them early this week based on tracking.

vestureofblood · December 13, 2016, 1:21am

Hi gang,

I am looking at Toykeepers Firmware for Ferrero Rocher driver. Is there some way a junior woodchuck like myself could edit this firmware so that I can start on high? off, high, med low, off?

Thanks

Tom_E · December 13, 2016, 1:30am

Ohhh - this works btw!! I think it did not work with original Nangj's to read the factory firmware, but it works fine on Simon's new Biscotti 105D drivers - I can confirm the fuse values, the code of course is a little harder to reverse engineer (), but it actually looks good. They appeared to use the wrong fuse value in the lower byte: 0x78 instead of 0x75. But... If you use 0x75, the Off value of 0 for PWM lights the LED at a level lower than moon mode. Think this might explain it:

    /* This is no longer needed since we always use PHASE mode.
    // Need PHASE to properly turn off the light
    if ((pwm1==0) && (pwm2==0)) {
        TCCR0A = PHASE;
    }
    */

It's commented out when it probably should be left in. Because PWM is still in FAST mode, the value of 0 seems to leave the LED ON.

Tom_E · December 13, 2016, 1:45am

Ahhh, I've modded the FR firmware before, but think simple stuff - mode levels maybe. Not understand what you are saying there.

You want a click to Hi, then next click is OFF, then next click is med low, then next click is OFF? If so, you got a couple changes there....

reverse direction
go OFF after each mode change

The 1st part looks easy. Looks like a compile switch called LOW_TO_HIGH will reverse it, just comment it out. But of course long holds will do the same thing.

The 2nd part to this is completely breaking how modes transition by adding the OFF state between modes. Dunno how that would look like. Do-able but I think code space is tight in the FR driver. Could add some sort of toggle state of OFF and ON, keeping the mode table the same. Again, not sure how much memory is left though...

vestureofblood · December 13, 2016, 6:56pm

Tom E:

vestureofblood:

Hi gang, I am looking at Toykeepers Firmware for Ferrero Rocher driver. Is there some way a junior woodchuck like myself could edit this firmware so that I can start on high? off, high, med low, off? Thanks

Ahhh, I’ve modded the FR firmware before, but think simple stuff - mode levels maybe. Not understand what you are saying there.

You want a click to Hi, then next click is OFF, then next click is med low, then next click is OFF? If so, you got a couple changes there….

reverse direction

go OFF after each mode change

The 1st part looks easy. Looks like a compile switch called LOW_TO_HIGH will reverse it, just comment it out. But of course long holds will do the same thing.

The 2nd part to this is completely breaking how modes transition by adding the OFF state between modes. Dunno how that would look like. Do-able but I think code space is tight in the FR driver. Could add some sort of toggle state of OFF and ON, keeping the mode table the same. Again, not sure how much memory is left though…

That is what I need I think. I don’t want off between the modes just at the beginning and end of the cycle. I will give this a shot and see what I get.

Thank you

laythaws · January 4, 2017, 1:51am

I want to edit the bistro.c. What line should I delete to remove the “muggle mode” from menu and move the “mode group” to first blink in menu?
I want my menu to be like this

gchart · January 4, 2017, 2:52am

In the section following this:

You’ll see a bunch of calls to the toggle function. Rearrange those in your desired order. Change the second parameter (the number) to match your order - it’s what’s used to control the number of blinks.

laythaws · January 4, 2017, 3:45am

Thanks. I’ll try that.

RotorHead64 · January 5, 2017, 4:50am

gchart:

Yeah, it kinda is. "NON_WDT" is "Non-WatchDog Timer". Essentially, instead of using the native AVR functions for keeping track of timers ("watchdog timers"), blf-a6 firmware is just counting "ticks" (execution cycles). It's relatively easy to code & understand, plus I imagine there are some code efficiency (space savings) benefits.

When you comment out that #define, disables this entire chuck of code. At compile time, it only gets included if that NON_WDT_TURBO is defined.
#ifdef NON_WDT_TURBO
            // Do some magic here to handle turbo step-down
            //if (ticks < 255) ticks++;  // don't roll over
            ticks ++;  // actually, we don't care about roll-over prevention
            if ((ticks > TURBO_TIMEOUT) 
                    && (output == TURBO)) {
                mode_idx = solid_modes - 2; // step down to second-highest mode
                set_mode(mode_idx);
                save_state();
            }
#endif

Total firmware altering noob here. I want to set the turbo timer for it's Max setting.

TK said in the code that 1 tick is 500ms with 255 ticks. I guess that's 127.5 seconds.

What and where do I type in to get the Max timer setting?

gchart · January 5, 2017, 5:16am

Look around line 135, you’ll see:

Change 90 to 255 to max out the turbo timer (as you said, approx 127 seconds). If you’d rather disable the turbo timer altogether, just comment-out this line: