Anduril ... 2?

Tulpenzeit · October 19, 2023, 3:56pm

No hardware issue. As I had said, I used the same setup and hardware to then flash rev767 and no problem.

dmenezes · October 19, 2023, 4:18pm

Thanks for setting me straight, I missed the part where you stated that.

Amazing, this is the first time I hear about avrdude successfully flashing a certain HEX file but then failing the verify, I wouldn’t thought it possible.

Anyway, there’s a chance it could be hardware: your MCU’s flash could have an address with a stuck bit, and the HEX that worked could have that same position with the same bit the flash is stuck at, while the HEX that failed verify could have a different value there (that’s not hard, 50% chances, and I’ve seen stuck bits many times with other kinds of write/erase memories – UV EEPROMs did that with annoying frequency).

This is very easy to check: next time you have a failed verify, please read the flash using avrdude itself immediately afterwards and save the result to a separate file. Comparing that file with the HEX that failed the verify will show the stuck bit, and checking that same bit in the HEX that worked would 100% corroborate that hypothesis.

If you do the above and send me both files, it will be my pleasure to do the bit-comparison and reply to you with the results.

SammysHP · October 19, 2023, 5:43pm

That can happen. Writing works mostly in one direction only. If you have a bad MISO/MOSI connection it will happily write, while the MCU doesn’t receive any data. The verification will fail.

The Intel hex format can be very different. Checksums, line length, addressing etc. So a comparison is a little more complex than just comparing the files.

dmenezes · October 19, 2023, 7:15pm

Interesting, but I’m pretty sure USB ASP is bidirectional (the transmitter won’t send the next block without receiving an ACK from the receiver), and therefore a messed path from the flashlight to the computer would have resulted in an error during flashing itself, not verification.

The Intel hex format can be very different. Checksums, line length, addressing etc. So a comparison is a little more complex than just comparing the files.

Of course, binary and hex files can’t be directly compared. The way to compare them is to first transform the HEX into a BIN (that’s what HEX2BIN is for), and then compare. That’s why I offered @Tulpenzeit my help, otherwise a simple diff -b (or FC /B in DOS/Windows) would suffice.

andrx · October 19, 2023, 8:28pm

where is the police strobe? i cant find in my Ts10

wolfgirl42 · October 19, 2023, 8:29pm

The cfg.h doesn’t have it enabled. It probably should be though. I’ll make a build with it.

Edit: done. 30.4 KB file on MEGA

wolfgirl42 · October 19, 2023, 8:33pm

Nope. You can take the pins entirely off and it will keep trying to write, it calculates all the pages etc first. Maybe the t1616 with UPDI but I’ve never done it on that MCU. Sometimes you just get the connection dropping for a second during verifying, and the verify fails, but if you rerun the verify only (-Uflash:v:${image}, then it passes the next time if you keep good contact and the initial flash was good.

andrx · October 19, 2023, 9:15pm

it does not work. maybe I found another bug(??) there is a strange flashing when you are in turbo and you go down (while holding the button down)

wolfgirl42 · October 19, 2023, 9:24pm

Are you sure? I just flashed that hex to one of mine and it works (after tactical strobe). Also can’t reproduce the flashing - is your light’s head on tightly?

Edit: Do you have the new TS10 (v2, with RGB aux) or the original TS10? That hex is only for the new one. If you have the original, do you want the police strobe to use main and aux?

andrx · October 19, 2023, 9:33pm

yes ts10ti, with your firmware i have candle-bike-party-strobo- nothing- lightning

EDIT: the strobe only works in simple UI

EDIT2: you cant reproduce the flashing because you are on simple UI (so no turbo and no flashing)

eckyeckypikang · October 19, 2023, 9:36pm

“Police Strobe” with alternating main & high-aux sounds like a little bit of fun for the single-color versions…

Not that you’re not already busy with a multitude of other mods or anything!

Light_Veteran · October 19, 2023, 11:29pm

With the phone is not in this way. If you don’t touch the pins correctly and firmly with the pogo there is no write. And it says you have to check connection. The verify is always automatic next the write and if you leave the pogo the procedure is ended with errors. So, no successful

wolfgirl42 · October 24, 2023, 2:30am

Ah, you’re right, TK fixed it today. I guess that’s what I get for normally running a build with default ceiling at 150 and simple UI disabled, I forgot to get out of simple UI when testing. Thanks

Patch: ~toykeeper/flashlight-firmware/multi-channel : revision 785

Build: 30.4 KB file on MEGA

wolfgirl42 · October 28, 2023, 5:21am

@ToyKeeper tested the default hex from the merged changes for t1616 LT1, SP36, and Q8, all seem to work fine. Ping me when there’s an updated ramp and I can get that tested and collect the data.

Garik_F · October 28, 2023, 8:27am

Yesterday I updated anduril2 version on all of my anduril flashlights (bunch of d4v2, ff e12r, ff now-mu, fw3a) to the latest non-multi-channel version of anduril2 (rev. 657 from 2023-03-28, https://bazaar.launchpad.net/ ~toykeeper/flashlight-firmware/anduril2/revision/657?start_revid=657) and noticed serious oddities with the thermal control algorithm on ALL FLASHLIGHTS.

All configuration files have DEFAULT_THERM_CEIL 50 in it, all lights were calibrated using an infrared non-contact industrial thermometer to current room temperature. All flashlights have with freshly charged batteries in it.

The strange thing is the following - the flashlight practically does not heat up, but at the same time it does not provide much light, it instantly ramps down.

Further steps to reproduce are:

Turn on the flashlight, ramp up to ceil (not turbo)
Then wait, see how the light becomes dimmer and dimmer (2-3 steps of stepped ramp if it’s stepped ramp)
The flashlight is barely warm (35-40 degrees according to the infrared non-contact thermometer and according to the readings of the flashlight itself)

What it is? Some kind of bug? My mistake in configuration file setup? Any new changes in the thermal control algorithm? How to overcome this?

Quadrupel · October 28, 2023, 8:39am

Host can be dead cold but if driver gets hot it will drop output.

Garik_F · October 28, 2023, 11:45am

Yes of course, it’s take time for host to heat up, but what about flashlight blinking temperature readings? Shouldn’t it be close to 50C, not 40C? Also, I got this behavior in continuous testing (20-30 min) → output is low and flashlight body barely warm (40C), heat from emitters definitely should reach host body for 20 min

wolfgirl42 · October 28, 2023, 2:14pm

Check your thermal calibration. Let it sit without being used for at least 4 hours or so, preferably overnight, then do a tempcheck (ideally without holding the light in your hand, it goes up by a few degrees within a minute or so when held). If it’s reading above room temperature, redo the calibration.

The thermal management is designed to (ideally) prevent the light going above the thermal limit, so it starts pulling output back before it reaches it, based on projected temperature change indicating that it will cross the limit. Try setting your limit 5 degrees or so higher than what you actually want the light to reach.

Garik_F · October 30, 2023, 5:13pm

I did some extensive research - I get this barely warm dim flashlight behaviour only on fireflies (e12r and nov-mu), all emissars acting normal (and getting HOT on high levels):

Configuration that I used on build

#define MODEL_NUMBER «0443»	

#include "hwdef-fireflies-lume1.h»
// ATTINY: 1634

#ifdef USE_INDICATOR_LED_WHILE_RAMPING
#undef USE_INDICATOR_LED_WHILE_RAMPING
#endif


#define USE_SIMPLE_UI 0
#define DEFAULT_THERM_CEIL 55 
#define USE_AUX_RGB_LEDS
#define RGB_LED_OFF_DEFAULT 0x29
#define RGB_LED_LOCKOUT_DEFAULT 0x10
#define DEFAULT_AUTOLOCK_TIME 10
#define DEFAULT_LEVEL 27
#define DEFAULT_MANUAL_MEMORY DEFAULT_LEVEL
#define DEFAULT_MANUAL_MEMORY_TIMER DEFAULT_AUTOLOCK_TIME

#define TURBO_TEMP_EXTRA 7 

#define THERM_FASTER_LEVEL 139 // was 116
#define MIN_THERM_STEPDOWN 69         
#define THERM_NEXT_WARNING_THRESHOLD 16
#define THERM_RESPONSE_MAGNITUDE 96

#define RAMP_LENGTH 150
#define PWM1_LEVELS 1,2,3,3,3,3,3,4,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,12,13,14,15,16,17,18,20,21,23,24,26,27,29,31,33,35,37,39,41,43,45,48,50,53,56,58,61,64,67,70,74,77,80,84,88,91,95,99,103,108,112,116,121,125,130,135,140,145,150,156,161,167,173,178,184,191,197,203,210,217,223,230,238,245,252,260,268,275,283,292,300,308,317,326,335,344,353,363,372,382,392,402,413,423,434,445,456,467,478,490,502,514,526,538,551,563,576,589,603,616,630,644,658,672,687,702,717,732,747,763,778,794,811,827,844,861,878,895,913,931,949,967,985,1004,1023,0
#define PWM2_LEVELS 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1023

#define MAX_1x7135 149 // was 69

#ifdef BLINK_AT_RAMP_MIDDLE
#undef BLINK_AT_RAMP_MIDDLE
#endif

#ifdef USE_DYNAMIC_UNDERCLOCKING
#undef USE_DYNAMIC_UNDERCLOCKING
#endif

#define RAMP_SMOOTH_FLOOR 3
#define RAMP_SMOOTH_CEIL 149

#define RAMP_DISCRETE_FLOOR RAMP_SMOOTH_FLOOR
#define RAMP_DISCRETE_CEIL RAMP_SMOOTH_CEIL
#define RAMP_DISCRETE_STEPS 7

#define SIMPLE_UI_FLOOR 3
#define SIMPLE_UI_CEIL 139  // 139 for 5A max
#define SIMPLE_UI_STEPS 5

// Turn on Buck from level 1 to 149, but not 150
// Level 150 is when Buck is off and FET is ON 100%
#define LED_ENABLE_PIN_LEVEL_MIN 1
#define LED_ENABLE_PIN_LEVEL_MAX 149

#define PARTY_STROBE_ONTIME 4
#define USE_VOLTAGE_LOWPASS

#define USE_SOFT_FACTORY_RESET

Changes, that I make in source code (same as loneoceans’s)

THERMAL MODIFICATONS

   Some modifications were made to enable the following scenario in Fireflies E12R.
   The FET has 3.9kHz PWM, and thermal gradual stepdown causes a whine.
   Change behavior so that thermal stepdown is a step response directly to 6A.
   Levels 1 to 149 are CC, 150 is turbo at 100% no PWM. 
   In addition, since body and sensor temperatures have a lag, add TURBO_TEMP_EXTRA.
   So only when temperature >temp_ceil+TURBO_TEMP_EXTRA && ramp is at 150, then drop.
   Otherwise, thermal regulation remains at user set temp_ceil (either default or in EEprom).

   Modified fsm-adc.c at line 422
            // send a warning
        >>  if ((temperature < (therm_ceil + TURBO_TEMP_EXTRA))&&(actual_level==150)){;}
        >>  else{emit(EV_temperature_high, howmuch);}
            //emit(EV_temperature_high, howmuch);

	And, modified ramp-mode.c at line 298
	        #ifdef USE_SET_LEVEL_GRADUALLY
            //set_level_gradually(stepdown);
        >>  if (actual_level == 150) {set_level(149);}
        >>  else {set_level_gradually(stepdown);}

Also I have tried old precompiled hex from lume1-fireflies/lume1-fireflies-Anduril2/bin at main · loneoceans/lume1-fireflies · GitHub - everything about thermal control working as expected (and flashlight gets HOT).

Any ideas what am I missing?

I think it’s something in:

#define THERM_FASTER_LEVEL 139 // was 116
#define MIN_THERM_STEPDOWN 69         
#define THERM_NEXT_WARNING_THRESHOLD 16
#define THERM_RESPONSE_MAGNITUDE 96

But cannot figure out what exactly…

thefreeman · October 30, 2023, 5:24pm

The Lume1 in TK’s branch is for the FW3A, the Fireflies Lume1s are different and not supported.

those change were made on 3 years old code, it’s not surprising that they broke something on today’s code.