Interesting, thanks for the new information
Yeah, it’s a known issue. And an annoying one.
Simon wanted new firmware, so he sent me some drivers to use for development. Nanjg 105d drivers, specifically. I got things working, even though the drivers had particularly bad 7135 chips, and I sent Simon a proof of concept to test. I wanted to find out if he liked it, if he noticed any issues, etc. It wasn’t really finished, but it was far enough to ask for feedback.
I guess there was a misunderstanding, because he then sent that version to production. :person_facepalming:
Not long afterward, I found a bug which occurred on an infrequent random basis, causing the issue described in this thread. It didn’t sample enough bits of SRAM, so some drivers would fail. On some hardware it never happens, on other hardware it happens almost every time, based on random luck. And I fixed it. But that was too late, because Simon had already made a lot of drivers.
Making all this worse, production used different driver hardware. And different fuse values so it ran at the wrong clock speed. And the production hardware seems to have a lot of variation between individual circuit boards, which messes with the button timing. And MCU pin 5 is connected to ground, which makes reflashing difficult.
So… a lot of things went wrong. And now, a year and a half later, it’s still biting people. 
Some of it can be fixed by reflashing, but that’s not something people can really be expected to do. Some of it may be fixable by changing or removing components from the driver. But, again, not something people shold have to deal with.
If you do reflash it though, gchart’s Babka has more features. It’s worth a look.
Thanks for providing some background.
Next time I get around to flashing stuff, I’ll definitely consider Babka. 
That’s some background information that explains what’s happening. Thanks again ToyKeeper!
Hmm… does that mean even the newer recent batch of Biscotti (Convoy S2+ and Convoy C8/C8+) would still have this bug? Simon did not try to fix the problem that’s affecting some Biscotti drivers?
I think he fixed it a long time ago, but I’m not totally sure. He might just still have some of the old drivers around, and they could get mixed in randomly.
Generally the easiest way to tell whether a driver is from the first batch is by measuring the speed of the bike flasher. If it pulses once per second, it should be good. If it pulses twice per second or more, it’s probably a first-batch driver. The first batch ran at about 2.3X the intended speed, due to the factory accidentally overclocking the MCU.
- Check this pre-alpha version that almost works when Hermes in on Scorpio, background temperature is 24c and you are wearing black belt and give me feedback…
…
…
a few days later
…
…
- So, did you checked it?
- Sure, it works fine, I pushed it to production
- …
Been there, lived that 
Not quite that bad, but I did have someone send one of my betas to production once. Fortunately, it stood up to “unscheduled production testing”, so all we had to do was send the “new minor version upgrade release” a couple of months later
So what’s the “real” final hex/source for biscotti? It could be that I flashed an older version or something.
TK has the flashlight firmware repo in her signature. Simply dig there, it contains a precompiled hex file that works well.
Yeah, I’m more wondering which branch is “final”. I’m not familiar with bzr at all, so I’ve been using the stuff at flashlight-firmware with no extra on the end.
I have recently received a purple S2+ with biscotti and it has stuck on memory mode and will not change. Apart from reflashing is there any other fix for it apart from a new driver?
I have messaged Simon as I have two of these with a third on the way and don’t want to find they all have the same issue.
I’m very unimpressed with this … in late 2018 Simon is still sending out flashlights which are too fast, and also apparently he is still sending ones with broken memory toggle. The pruple is a brand new model and these are problems known for over 1 year.
On this site many praise him but this is really terrible QC, or lack of regard for customers, or both. Maybe he was better in the past?
To answer your question, there is no trick or workaround that I am aware of. You need to reflash or get a new driver.
So, been reading through this thread (and a few others) and I count my lucky stars that the two Biscotti Convoys I have, both with the overclocked first-batch boards, work perfectly fine for me.
Legit the only issue I have (and it affects both torches) is that on the mode group select, starting on group 7 all groups blink one less time than their respective group number (group 6 blinks 6 times, then group 7 also blinks 6 times, group 8 blinks 7 times, and so it goes), so I’ve gotten used to counting the second-long lulls between groups and it’s worked well by me thus far, so I can live with it.
My new drivers arrived yesterday, so hopefully I will be able to work something out. I do have to admit that while I love what Convoy is making, Simon’s lack of “QC” is bothering me. Getting a S2+/XPL HI with biscotti, a brand new offering, shouldn’t result in busted drivers being sent.
If you want a precompiled version with the right calibration, I’d suggest using the convoy branch.
Anyone know a good way to contact Simon? I’d like to find out what the story is with the first-batch drivers still going out.
Thanks! And I’ve had great success with the AliExpress messaging. I can PM you an email he gave me too.
I got mine S2+ orange today. Accidentally turn memory on and now can not turn it off.
Vary sad.
Now I have piece of junk.
That sounds pretty over the top there, bud.
I solve the problem. Just throw it way. Eagle Eye X5R will replace it.