Bought it from banggood…I’ll report it, thanx
The main things were to use the API and to make sure interrupts are disabled during eeprom access.
However, I doubt that’s it. Doesn’t the S43 use a version of NarsilM without the memory bug fixed? There are several different forks named NarsilM 1.3, and IIRC only one of those is fixed.
…
Okay, I just checked. The S43 code I have seems to be an old version without the fix. I don’t think the fixed version has actually been used on any production lights yet. So it’s probably just the known bug, which can randomly corrupt the config data.
If the issue is what it sounds like, a replacement wouldn’t really be any different than using the factory reset function. I’d suggest trying factory reset first.
Two things.
A replacement should definitely fix the issue as the S43 and S43S normally work just fine. Something sounds very wrong on his particular light.
He already tried a factory reset, but the problem returns when power is cut.
Ah, okay. If I understand correctly, the corrupted data can stick around for a while. It uses wear-leveling to make the eeprom last longer, and it may need to re-save the config data enough times to complete a full wear-leveling cycle. I’d have to check the code to be sure, but it could potentially involve saving the config 32 times without disconnecting power. That’d take a while to do, but it’s still faster than shipping an item.
So doing factory reset 32 times maybe could help?
What about the wrong blinkie modes? settings 2 and 3 are both all strobes/beacon mode?
Setting strobe mode to level 2:
I really don’t know… I just read through the code to see if there might be a way to fix it without waiting for shipping. I found that it uses 4 bytes each time it saves, and the wear-leveling region is 128 bytes long. So after saving 32 times, it should wrap all the way around. But it re-detects the position each time it’s booted, so disconnecting power could potentially reset the process. To find out, it’d be necessary to save the config 32 or more times in a single session, without disconnecting power. And I’m not sure what would be the fastest way to do that, or if it would even help.
Did factory reset 34times, then disconnect power, problem still there
Ahhh, TK - can you tell me exactly what the bug is? I'm confused... Maybe I fixed this?
What's the 'memory bug'?
In my latest NarsilM, ints are disabled around this saving of the config settings.
Saving settings wipes out the previous setting, so in theory, in shouldn't get confused and from power up, it should always find the most recently saved settings.
If this 128 byte region of eeprom ever gets corrupted or out of sync somehow, I probably should have the factory reset action clear out the 128 bytes by setting them all to FF -- or at least force the new savings into the first 4 bytes -- this should guarantee they are loaded correctly on the next power cycle. Not sure what problem this fixes, or what the root cause is though.
I could also add verification of bytes written -- not sure if that would help either.
Here is what TK told me earlier.
Hhmm. Maybe it's the int's disabled then, or something else. I can go back rev's and check.
Long story short: Code forks make things messy. The most-upstream version, Tom’s version, has been fixed for a while… but the derivatives are not. And production lights so far have all used either old versions or derivatives.
I’m not sure if that’s the same issue as what was reported here, but it is at least an issue. I have a collection of various NarsilM forks I’ve been meaning to merge together properly, but it’s kind of a pain and I’ve been procrastinating. So it’s still just sitting on a todo list.
If anyone is willing to do the merges, the forks I’ve collected so far are here. I’m not sure if this is a complete set though.
Ideally, the changes in each fork would be split out into a single file for each supported model of flashlight, and then it could treat each one as a build target. And then hopefully any future lights would be trivial to merge in because they would simply add one file.
The S43 and S43S I have are v1.3 and what you have there is marked v1.1. That's good you have all those versions - I haven't been given any. Think Lexel does his own versions.
(NOTE: S43 makred v1.1 is v1.3 firmware - good!)
Ohhh - just went thru dnld'ing all those driver versions and don't have permission to dnld the ROT66 one.
This is a lot to go thru but I'll take a shot at it, probably result in V1.4. Not sure if this is even right - should be evolved into Anduril, using the FSM.
Only issues I know of with Anduril:
- In my E07 as shipped, there's a delay when clicking off the light - not sure if this delay is in the current version
- reports of temp regulation not working - think TA, not sure of something configured wrong though
- not sure but I think all the hardware config options NarsilM supports is not currently in Anduril. New V1.3 has 2 channel support on a 3 channel board - this is important for me.
Sorry about that… had the wrong permissions, but it’s fixed now.
I had to go digging, researching which lights had been released with NarsilM, figuring out who did the firmware, and bugging people for a copy. I’ve probably missed a few though. And I don’t have 100% confirmation about these being the exact versions used for production.
As for the version numbers in those file names, don’t pay it much mind. The contents of the files don’t always match the names of the files. In some cases, even the name of the light doesn’t match. It’s going to be a messy merge process, trying to sort out when exactly each one was forked and what was changed and how to put the pieces back together. When I did some recursive diffs, I found the changes were more than I wanted to deal with.
It waits until the timeout expires for another click. Have been meaning to make this a compile-time option for a long time, but … I’m bad at motivation.
Have been meaning to rewrite that part of the code entirely… but it’s a particularly obnoxious function to work on. There’s a known issue with integer overflows when a light heats up extremely quickly, but it typically only affects really small FET lights, and there’s already a workaround. Regardless, it should be rewritten because the current thermal code is janky.
That’s definitely missing in FSM. I don’t remember exactly how that setup works though, so I’m not sure how best to fix it. Is this it?
Pin 5 = 1x7135
Pin 6 = no connection
Pin 3 = FET
If so, I think it may be sufficient to copy a 3-channel config like the FW3A, set the 2nd channel to all zeroes, and copy the FET channel from a 2-channel driver like the D4. No actual C code changes needed, just some preprocessor #defines in a config file. Maybe. It’s not ideal, but it might at least be simple.
This is the header file from NarsilM I use now with the S42/S43 I/O pin config and 2 channel on 3 channel support. This defines the 2 channels on a 3 channel board:
TWOCHAN_3C_PINS
/**************************************************************************************** * RegisterSettings.h * ================== * ****************************************************************************************/#ifndef REGISTERSETTINGS_H_
#define REGISTERSETTINGS_H_#define PHASE 0xA1 // phase-correct PWM both channels
#define FAST 0xA3 // fast PWM both channels (not used)#define SWITCH_PIN PB3 // Star 4, MCU pin #2 - pin the switch is connected to
#define ADCMUX_TEMP 0b10001111 // ADCMUX register setup to read temperature
#define ADCMUX_VCC_R1R2 ((1 << REFS1) | ADC_CHANNEL); // 1.1v reference, ADC1/PB2
#define ADCMUX_VCC_INTREF 0b00001100 // ADCMUX register setup to read Vbg referenced to Vcc#define ADC_CHANNEL 0x01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0x06 // clk/64//---------------------------------------------------------------------------------------
#if OUT_CHANNELS == 2 // FET+1
//---------------------------------------------------------------------------------------
#ifdef TWOCHAN_3C_PINS
/* Standard triple channel (FET+bank+1) Attiny85 driver:
* —
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Voltage ADC, Indicator LED, or spare
* FET PWM PB4 3 -| |- 6 PB1 Not Populated (bank of 7135s PWM)
* GND 4 -| |- 5 PB0 one 7135 PWM
* —
*/
#define ONE7135_PWM_PIN PB0 // pin 5, 1x7135 PWM
#define ONE7135_PWM_LVL OCR0A // OCR0A is the output compare register for PB0
#define BANK_PWM_PIN PB1 // pin 6, 7135 bank PWM
#define BANK_PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define FET_PWM_PIN PB4 // pin 3
#define FET_PWM_LVL OCR1B // output compare register for PB4#define ONBOARD_LED_PIN PB2 // MCU pin 7#elif S42_PINS
/* S42 FET+1 driver for TA:
* —
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Ind.LED
* 7135 PWM PB4 3 -| |- 6 PB1 Not Used
* GND 4 -| |- 5 PB0 FET PWM
* —
*/
#define FET_PWM_PIN PB0 // pin 5, FET PWM
#define FET_PWM_LVL OCR0A // OCR0A is the output compare register for PB0
#define ONE7135_PWM_PIN PB4 // pin 3, 1x7135 PWM
#define ONE7135_PWM_LVL OCR1B // OCR1B is the output compare register for PB4#define ONBOARD_LED_PIN PB2 // Star 3, MCU pin 7#else
/* Standard FET+1 Attiny85 driver:
* —
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Voltage ADC or spare
* Ind.LED PB4 3 -| |- 6 PB1 FET PWM
* GND 4 -| |- 5 PB0 7135 PWM
* —
*/
#define FET_PWM_PIN PB1 // pin 6, FET PWM
#define FET_PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define ONE7135_PWM_PIN PB0 // pin 5, 1x7135 PWM
#define ONE7135_PWM_LVL OCR0A // OCR0A is the output compare register for PB0#define ONBOARD_LED_PIN PB4 // Star 3, MCU pin 3#endif
//---------------------------------------------------------------------------------------
#elif OUT_CHANNELS == 3 // Triple Channel
//---------------------------------------------------------------------------------------/* Standard triple channel (FET+bank+1) Attiny85 driver:
* —
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Voltage ADC, Indicator LED, or spare
* FET PWM PB4 3 -| |- 6 PB1 bank of 7135s PWM
* GND 4 -| |- 5 PB0 one 7135 PWM
* —
*/
#define ONE7135_PWM_PIN PB0 // pin 5, 1x7135 PWM
#define ONE7135_PWM_LVL OCR0A // OCR0A is the output compare register for PB0
#define BANK_PWM_PIN PB1 // pin 6, 7135 bank PWM
#define BANK_PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define FET_PWM_PIN PB4 // pin 3
#define FET_PWM_LVL OCR1B // output compare register for PB4#define ONBOARD_LED_PIN PB2 // MCU pin 7
//---------------------------------------------------------------------------------------
#elif OUT_CHANNELS == 1 // single FET or single bank of 7135's
//---------------------------------------------------------------------------------------/* Standard Nanji or FET+1 driver layout:
* —
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Voltage ADC, or spare
* Ind.LED PB4 3 -| |- 6 PB1 single FET or bank of 7135s PWM
* GND 4 -| |- 5 PB0 spare
* —
*/
#define MAIN_PWM_PIN PB1 // pin 6, FET or 7135 bank PWM
#define MAIN_PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define FET_PWM_LVL MAIN_PWM_LVL // map these the same#define ONBOARD_LED_PIN PB4 // Star 3, MCU pin 3
#endif
#endif /* REGISTERSETTINGS_H_ */
Has anyone compared this light to the regular S43? This light is much heavier, but I imagine it has better performance. The question is how much better?
Astrolux changed the S43 design to match the S43S in that they switched from single springs on each end to a button on the driver and a dual spring on the tail cap. So now they both draw the same amps. The only big difference in performance is the copper version gives you maybe 10 more seconds of Turbo on a high drain battery. A bit more if using a high capacity battery.
▲ - well said, JasonWW. I have both the S43 and S43S Cu; the copper head makes it significantly heavier. Uncomfortably so. I never carry it out of the house and relegate it to sporadic minor tasks. The S43 weight is far more usable. But on both these lights, the anodizing is really weak and aluminum quite soft. I dropped my S43 and the impact not only scraped off anodizing, but metal as well. This was a “minor” drop too on pavement. I’ve dropped other lights and had far less damage. I’d hate to think what would happen if I dropped the copper version, having so much more mass. 
I love my S43S lights. I have two of them. They’re really not so heavy in a jacket pocket, particularly with using the 18350 tube. The anodizing on mine is perfect. So far not a scratch on mine even after forcing the stiff clip onto the 18650 tube of one of my lights. I didn’t care for the clip and difficulty removing it, but I did with no scratches to the light. Why two lights? I keep one with the shorter tube for easier carrying. I bought the bigger tube for more extended outings. I love the shiny copper. My lights have not tarnished at all. They must be coated because typically,my hands cause all copper to darken.
I have one S43 and an S43S. The weight and feel of the copper is magnificent but not practical. I really don’t find it light enough for an EDC. The 18350 tube makes it way too off balanced for my taste. I keep the 18350 tube on the S43 and the 18650 tube on the S43S. Plus the fragile anodizing and soft metal… kind of has to be expected I guess, for the price.