Convoy S2+ new firmware (biscotti) memory mode jammed

I understand, tried shorting the DC input last night but this didn’t work. Thanks for the tip though

I have changed mode options on it many times without issue, it was only when I changed the memory that the memory got stuck. I even changed the modes to other ones to see if it would help with the memory but no matter what it stuck on.

I have same problem with my Convoy C8 Clear w/ Biscotti.

Today I required to change the mode, but accidentally pushed on the second ‘buzz’ and therefore toggled memory to on. I don’t want this, so subsequently tried to toggle it off but it is impossible. Mode memory is stuck on no matter what I do.

It is about 15-16 months old, I didn’t use it much, in fact it spent most time in storage. I have used the mode change just a few times (under 10 surely); I cannot recall if I ever attempted to toggle memory.

Anyone find a solution for this?

Did you follow the UI?

Yes. I can change modes fine, but I can’t change mode memory no matter if I do short, long, etc during the 2nd buzz

Unfortunately not. I might try to reflash the firmware but currently I don’t have the equipment.

In Banggood reviews I see this:

So that is you, me, eggmang and at least one other guy. The problem may not be widespread but it is not unique, maybe some bad batch of drivers or a component which is failing prematurely.

It is definitely not a problem with what I am doing. I have several Convoy with Biscotti and I can successfully toggle mode memory on all but one. One simply doesn’t change. It changed from OFF to ON at least once, now it refuses to change back.

That’s the craziest thing. I have re-flashed! It behaves with memory mode straight out of the programmer!

If there is a part on the driver, capacitor or something else, for memory, maybe it is no good.

That’s what I thought, but mode changing works fine. I’ve ordered a few replacement drivers that come pre-flashed, so I’m going to dump the ROM and compare to see if the code is different. I’m also thinking about manually compiling biscotti without mode memory support. Lol.

That sounds like a dead memory cell to me. The EEPROM cell storing the setting has failed, so the MCU always sees a one or a zero despite all efforts to set it to the other value. In this type of failure, other EEPROM cells - like the one storing the mode setting - can still be perfectly fine.

If you know what you’re doing with the firmware code (I don’t), you might be able to move the storage location to a different EEPROM cell. Alternatively, you could just hard-code the setting you want and render the EEPROM irrelevant.

My next to last s2+ failed but when it happened it went to only single mode. It would not enter into the mode selection at all. Had to make a video for Simon and he sent me out a new driver. That light was only 3 or so months old and I only keep it in mode 2. Pulled it out of my pocket one day and it only had 100%.

I also have a C8 that is stuck in “always on” mode, but I fried that one myself while swapping parts. I need to probe it with my scope, but I’m going on vacation next week and have to pack more than just my flashlights :slight_smile:

I am wondering if it might be a fried diode or something, as I didn’t do too much to it, and I inspected it under a magnifying glass.

PWMing 7135s :facepalm: in a practically unregulated driver (when high frequency switching 7135s, they lose most regulation voltage margin and efficiency). Screw it!

Believe as you wish and undergo its consecuences, period.

Cheers ^:)

So exactly how does one disable next move memory? I recently received a light with biscotti and the mode memory was off, but now it is one and I can’t figure out how to disable it.

I have tried no click and a short click during the second buzz, has not seemed to change the behavior. My first light with biscotti in it, have only had it a couple days.

Edit: I guess what I am finding is if I leave the light off long enough (have not figured how long) it will go back to the first mode. Guessing that is just a characteristic of biscotti. If I turn the light off, then back on even 10 seconds later, it starts at the next higher mode. Maybe 2 minutes off and it’s reset. Guessing the timeout is somewhere in between. Actually, what I am finding is the mode set also reset to number 2 mode set also. Hmmm . . . . I had moved it to mode 10 when I found I could not reset the mode memory.

- memset(0) manually if needed

- port(:)=0 manually if needed

  • change the backdoored compiler

For me: the looped counter ?D? because above

Actually, there is a bug in those drivers. I’m the one who posted the BG reviews and so far I’m 4 for 4 when it comes to them getting stuck in memory mode on.

A reflash fixes the problem, so it’s not a broken memory cell, since it doesn’t move any of the storage locations for config or mode.

All in all, just a software bug.

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

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

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?