Last week i received the BLF X6 driver from Banggood; sadly the MCU was locked down, so i couldn’t try Crescendo with it 
According to this post i received the old version. I could try to replace the MCU, but i think it’s a bit too much of a hassle…
I just ordered a driver….hope it arrives unlocked.
Are the attiny 13/25 based drivers sold by mtnelectronics locked down or can they be reprogrammed?
It should be fairly obvious. If you see firmware options, then it has to be unlocked. If their is a specific driver your not sure about, just list what it is and maybe someone can tell you for sure.
Oops, I got gChart’s babka mixed up with his ramping UI in an earlier comment. Fixed.
Mtn’s drivers are reflashable, but the presence of various firmware options doesn’t mean that they must be. It’s chosen by the fuses at flash time, and Mtn sets the fuses to make it reflashable.
FWIW, making it reflashable is legally required for anything with my code on it, since it’s licensed under GPLv3. So you can usually assume a driver can be flashed if it ships with anything I made. But not always — as adrianoab1 found, banggood used the wrong fuse values on some of their drivers. :person_facepalming: I have asked them to never do that again, and tried to explain the legal requirements, but due to the way business works there I can’t guarantee anything.
No, BLF-A6 doesn’t work on a Convoy driver. It needs an extra capacitor in order to do medium-press detection, and it also assumes the driver has two power channels instead of one. However, Biscotti and Babka work and are somewhat similar to BLF-A6.
Crescendo can also work on a Convoy driver, and I used to keep the default build configured for that purpose, but you’d probably be better off using gChart’s ramping UI or a tiny25-based driver.
On my Convoy-driver lights, I normally use the S7 (or brass-edc) firmware. It has no runtime config options, and uses that space for a bunch of fancy blinky modes instead. It’s pretty old, and primitive, but I still like it. One of my favorite lights (a Convoy S7) has S7 firmware and a 4x7135 driver with Nichia 219b emitter.
You might want to take a look at MtnElectronics’ “Moonlight Special” driver. It sounds like it’d be right up your alley, and comes pre-flashed with a variety of UIs. Not sure if he offers it with tiny25, but if so, it should also work well with Crescendo.
Thank you ToyKeeper; I thought mtn’s driver would likely be reflashable. Therefore that would be an excellent choice especially for anyone in the US.
Thanks Toykeeper, I’ll check them out. 
Update:
I was just wondering whether is it possible to change the firmware for tiny lights like the BLF A01?
To be honest TK, this is one little thing that has put me off slightly working on bistro derivatives and I've even briefly contemplated rewriting parts for this reason and for the large parts I have re-written I'd probably allow them to be used even in LGPL or possibly even BSD or MIT if someone asked (and while as part of bistro they fall under bistro license, I own copyright to those parts and can relicense those parts). I find gplv3 is VERY antagonistic and very heavy handed. There is an issue, like with web software, where people can make changes and allow use of those changes through a web interface without "distributing" binaries and thus avoid sharing the changes, and I'm partially sympathetic to fixing that. I believe there are licenses now that deal with that for web software, but I don't know details, and I'm not sure if in GPLv2 distributing hardware with a binary on it counts as distributing a binary for the purpose of requiring sharing the code, but I believe that yes it already does and covers that which is why android code is made available (but I'm not expert here, could also just be because they need to distribute updates).
GPLv3 goes much farther. It doesn't say the software must remain open, it tells people what they have to do with the hardware and that's going too far to me. It's also shooting itself in the foot because HUGE amounts of money that could support GPLv3 projects have been quickly cut off and that support evaporated in many cases. This didn't cause hardware to open up, it caused software to close off. There are actually good reasons to lock down devices for security, although I'll say, as much as it irritates people Samsung's knox fuses are a good compromise. You loose your keychain if you reflash and secure payment software won't trust your device ever again, but you do get to reflash. Still I have no desire to force anything about this onto anyone. The big companies already had incentive to give back and they mostly did, because by playing along they kept a community of people working on stuff that they would in turn find use for again in the future. Ok, that wasn't always pretty, but I think in long run social shaming and need for that relationship put some limits on the problems.
I also take issue with some of the linking stuff. Just because my code is free, I don't feel the need to tell anyone who uses it that their code should be and it's not even really clear that my license has authority over their code. There's a recent low level preliminary judgment against HANCOM that may set precedent for licenses acting as contracts which would strengthen the possibility of such authority, but that is still far from settled. If not for the need to include header files, or maybe this contract interpretation, it wouldn't even be a debate. It would be like BLF or maybe Thorfire declaring we dictate rights relating to any lantern cover that "links to" and requires a Q8 to do its thing. FSF philosophy goes too far.
Is there a beginner’s tutorial on flashing flashlight firmware? I’m interested to learn (not sure if it would be too difficult for me or not…)
I’ve ordered some tools (from AliExpress) mentioned in above message:
- “USBASP USBISP AVR Programmer USB ISP USB ASP ATMEGA8 ATMEGA128 Support Win7 64K”
- “Programmer Testing Clip SOP8 SOP SOIC 8 SOIC8 DIP8 DIP 8 Pin IC Test Clamp”
- “10cm 2.54mm 1pin female to female jumper wire Dupont cable”
Not sure if those are complete or anything else needed?
Also, for a beginner (no experience) like me, is a Convoy S2+ flashlight (w/ old firmware 5/3-mode group) be a suitable ‘subject’ for flashing firmware? If so, which firmware is applicable?
Is soldering required? (I think my soldering skill is poor… I don’t have advanced tools, just a basic 40-watt soldering iron)
Also, I think I need a pair of tweezers to remove the head/pill (sorry I don’t know the correct terminology yet but will review them…) of the Convoy S2+?
~
The Convoy S2+ Desert Sand (Biscotti pre-installed) I bought from Simon’s AliExpress store (sometime September 2017), had a too-fast driver, so maybe it’s not fixed?
(I was hoping to get this fixed by reflashing Biscotti onto it). But prior to doing that, I want to experiment flashing on the cheaper (from flash sale) Convoy S2+ (old firmware) — I wonder if the old flashlight driver also accepts Biscotti?
I thought the first post in this thread covered that part, didn’t it?
Note: I recently contact Simon and he confirmed that the new drivers he use have their MCUs locked so you can’t upload your own firmware. Not a problem for me since I can easily replace the MCU with my own unlocked one, but if you’re not good at soldering SMD components then I suggest get an unlocked driver.
About the firmware most firmwares that are stated as reverse clicky will work, if they don;t slight modification in the code will make them work.
That’s a sad news…
Thanks for clarifying some of the points… I haven’t done my homework, I did read the first post, but haven’t checked out the linked pages, plus I have little (or almost none) knowledge at the moment about flashlight drivers… (my notion of “flashing firmware on flashlights” is like flash-updating a PC’s BIOS firmware, or updating the wifi-router firmware, or updating the firmware of YZXStudio USB meter… which I have a little experience of)
So it seems I couldn’t fix the too-fast ‘timing’ issue of my Convoy S2+ Desert Sand Biscotti if that’s the case… 8-( That was one of the first reason I want to learn about flashing flashlight firmware.
The Convoy S2+ (old firmware) uses reverse-clicky tail-switch (this Convoy comes from GearBest flash sale, so I’m guessing they might be older stock and maybe have the still unlocked variant?) How do I confirm if they can be flash-updated with a different firmware? (pardon if there are some points I still don’t understand about flashlight firmwares…)
I think you can buy flashable drivers in 17mm for only a few dollars.
It’s a shame you can’t buy from MTN Electronics. You could get a new 17mm 3A qlite driver for $4.20 plus can get it custom flashed for $1 more.
I put a Qlite driver in my S2+ with Guppydrv. It’s great.
Maybe you could buy a driver directly from Convoy with the latest version of Bicotti installed?
Then learn to reflash later.
You could fix the timing issue for your S2+ biscotti, there was another thread here in blf explaining about that, just some modifications in the code it seems.
How do you know if your mcu is unlocked? just upload the code and see if it works. 
even if it is locked, you can simply swap the mcu with an unlocked/blank one like I do.
Beware that the S2/S2+ has the driver soldered to the pill (there’s a pic in this review thread) and it can be an absolute pain in the butt to get it removed! (The pill acts as a heatsink pulling away the heat from your soldering iron.) The mcu is on the underside of the driver so you have to remove it from pill to flash. I would suggest you try something like a Convoy M1 that uses a retaining ring to hold the driver rather than solder. For practice and testing purposes you can also simply mount an LED to an old computer heatsink and wire a Nanjg driver to it leaving it dangling (I do this to test my flashing results). Yes, you will want a selection of good tweezers and possibly “”snap-ring pliers”:Amazon.com .
I would recommend trying out “STAR” firmware as it’s pretty basic and easy to adjust modes and such.
-Garry
Um, but my Convoy S2+ Desert Sand w/ pre-installed Biscotti firmware (that has the too-fast timing issue) was bought direct from Convoy directly (Simon), how would I know that the driver will not have the same issue?
In contrast, the Convoy C8 Clear (also pre-installed with Biscotti) that I bought from Banggood had a normal timing. That was how I discovered that my S2+ Desert Sand operates a bit differently — its timing is too fast, making it very difficult to change modes (because the time in-between-clicks when in ‘configuration mode’ is too short), unlike the C8’s Biscotti where there’s no problem changing modes.
But I’ll try checking out Simon’s Convoy store again for the drivers you mentioned…
~
I have another question, from the flash sale/discount code (I’m spending too much on flashlights now…) in GearBest, aside from the Convoy S2+ (old firmware: 5/3-mode groups), I also got Convoy C8 with old firmware: 5/3 mode groups. Any idea if these C8 old firmware can also be flashed to Biscotti or other firmware? How easy/difficult are they to remove for flashing? I’ll start to get some tools as mentioned above, and hone a bit of my soldering skills…
I thought you said you bought it from Gearbest in post 352. My bad. If it came from Convoy then that is worrying. They got the C8 drivers slowed down and fixed, now it seems the same issue is happening with a different light. Have you contacted Simon about it? What did he say?
The C8 use a larger driver with a retaining ring so they are easy to remove compared to the tiny drivers that are soldered into place on the little lights. Snap ring pliers make it easy to work with. You may need to unsolder the emitter wires to get the driver to drop down enough.
Sorry, I’m not much help here. Maybe others will give more exact advice.
Regarding the “locked” driver - it might be this issue, and you can easily fix it:
If the mcu is really locked, it can be fixed with a high voltage programmer, which you can build on a breadboard with a cheap Arduino Nano:
http://www.rickety.us/2010/03/arduino-avr-high-voltage-serial-programmer/
:+1: :+1: Thanks for the link to high voltage arduino programmer, saves me the effort to replace the mcu. This is most likely the case since I’m sure I have seen others complainin about incorrect fuses being set making the mcu unprogrammable.
Are you talking about Convoys 8x7135 driver? I only heard from wrong fuses regarding the BLF A6 driver from Banggood. To reset this driver with high voltage programming it is necessary to remove the OTC (capacitor) termporarily.