This almost certainly means it failed to build (ie a compiler or linker error).
I’m on the road now but when I make it back home I can have a look and tell you for sure.
One thing that comes to mind is limited flash. space, doesn’t happen on AT1616 or at1634 MCUs but does on AT85. Is that the case of the pl47g2?
My friend as always take the time you need with calm. I am not in hurry and flashlights are life safer argument only for a miners😌
And for @ToyKeeper because it’s work
Thanks! 
Turns out that’s exactly what’s happening here:
$ ../../../bin/build.sh 85 anduril -DCFG_H=cfg-ff-pl47g2.h
(...)
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: anduril.elf section `.data' will not fit in region `text'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: region `text' overflowed by 4 bytes
(...)
So 8C-Quick_Aux_Switch doesn’t fit, because of miserable 4 bytes… :-/
I should be able to optimize it enough to save those 4 bytes and make it fit. Give me until tomorrow and I should have an HEX ready for you to test.
BTW, I see you mentioned in the other thread about not having tactical mode on the pl47g2; I just checked and this is intentional and due to the same root cause (limited flash space):
$ view cfg-ff-pl47g2.h
(...)
// too big, turn off extra features
#undef USE_SOS_MODE
#undef USE_TACTICAL_MODE
Please also note that the SOS blinky is also undefined right along with it.
So, I was just checking my mod on 812 and found I made a mistake: 8C was implemented only in OFF mode, not in lockout mode (I apparently forgot to patch my mod into the latter 
).
Just fixed it, but then the overflow bytes went up to 64(!) which definitely isn’t going to be as trivial to optimize as 4.
TL;DR, not sure anymore I will be able to meet my self-imposed deadline of “tomorrow”… 
I am happy with 8C from off… but then I seldom use lockout. It is sure better than (potentially) multiple rounds of 7c to get the same thing.
OK, so a few hours into this particular rabbit hole, and all I managed to save were 10 bytes. I don’t think I will be able to reduce code usage the 54 bytes still needed in any reasonable time span.
So @Light_Veteran, what I did was to #undef another feature I’m guessing you don’t use much if at all:
--- cfg-ff-pl47g2.h.orig 2023-10-01 09:47:08.000000000 -0300
+++ cfg-ff-pl47g2.h 2023-11-20 22:48:37.692571734 -0300
@@ -65,3 +65,4 @@
// too big, turn off extra features
#undef USE_SOS_MODE
#undef USE_TACTICAL_MODE
+#undef USE_BIKE_FLASHER_MODE
This takes out the “bike flasher”, and saved more than enough bytes so now 8C_Quick_Aux_Switch fits. Is this acceptable?
Please let me know and I will generate and send you a link to the corresponding HEX.
Yes, ToyKeeper wrote me why there are not specific mode because flash space is limited.
I prefer you remove candle mode if is not a problem for you! In this specific flashlight I don’t need this task
Absolutely no problem, and glad to help. BTW, I went further and determined that undefining USE_CANDLE_MODE saves so much memory I was able to fit not only USE_QUICK_AUX_SWITCH but also USE_SOS_MODE and USE_TACTICAL_MODE that TK had previously #undefined, so you’re now basically able to have everything but candle mode:
--- cfg-ff-pl47g2.h.orig-undef_USE_CANDLE_MODE 2023-10-01 09:47:08.000000000 -0300
+++ cfg-ff-pl47g2.h 2023-11-21 06:07:30.742344826 -0300
@@ -63,5 +63,6 @@
#define USE_SMOOTH_STEPS
// too big, turn off extra features
-#undef USE_SOS_MODE
-#undef USE_TACTICAL_MODE
+// #undef USE_SOS_MODE
+// #undef USE_TACTICAL_MODE
+#undef USE_CANDLE_MODE
With the above, here’s the build report on memory usage:
Program: 8168 bytes (99.7% Full)
Data: 204 bytes (39.8% Full)
So after all is said and done, there’s even a neat 24 bytes of flash memory left! 
I wouldn’t have guessed candle mode was tha big!
Anyway, here’s your HEX: https://durval.com/xfer-only/anduril-ff-pl47g2_-_8C_Quick_Aux_Switch+SOS_Mode+Tactical_Mode-Candle_Mode.zip
Please test it carefully and let me know how it goes!
Yeah, I like 8C-Quick_Aux_Switch so much I even use it myself 
But having it fully available is only a problem on lights with AT85 MCUs like @Light_Veteran’s E07 or the PL47G2 it’s based on; lights with AT1616 (all hail the mighty AT1616! ) like our TS10s, or AT1634 (boo… USBASP…) have more than enough flash memory to fit it all.
And after implementing @Light_Veteran’s request to remove candle mode and seeing how much flash memory it saved, I’m pretty confident it’s feasible to have everything on AT85 lights but candle mode, including 8C-Quick_Aux_Switch and SOS and Tactical mode that TK had originally removed on these lights to make Anduril fit.
If anyone with an AT85 light wants such a build, just let me know and I will compile an HEX.
Thank you so much for anduril code explanation!
I appreciate so much your kind knowledge
Gorgeous 
Edit:
Firmware installed. Awesome!
Thanks for letting us know. Marking this as done!
ANDÚRIL UPDATING HELP NEEDED!
As recommended, I followed along with @liquidretro’s video tutorial for updating Andúril-2 by using @gchart’s Programming Adapter Key with the ZFlasher App with an Android phone.
Unfortunately, after trying everything I could think of, and checking in with @gchart and @jon_slider for suggestions (thanks guys!), I’m still unable to update my Wurkkos TS21v2.
Curiously, has anyone “successfully updated” Andúril-2 on their Wurkkos TS21 (the updated version with flashing pads) by using @gchart’s Programming Adapter Key with the ZFlasher App on their Samsung (Android) device? What issues did you encounter, if any, before succeeding?
In order to eliminate which possible reasons may be preventing the ZFlasher app from recognizing the Flashing Adapter Key, I now ask for your assistance by verifying or eliminating one-by-one, which of the following considerations are “absolutely” or “absolutely not” preventing the Flashing Adapter Key from being recognized by the ZFlasher app.
A) Should I be using a USB-C to USB-C cable “only”?
(I’ve been using my Samsung tablet’s USB-A to USB-C cable with both a cheap USB-A Female to MicroUSB Male OTG ADAPTER along with a cheap MicroUSB Female to USB-C Male Adapter.)
B) Could it be that the Programmer Key’s pogo pins are at best, barely touching the inside edges of the TS21’s two outer flashing pads? (I don’t currently have a way to take a photo of this, but hopefully this screenshot demonstrates the issue.
NOTE: I was under the impression that the dimensions of the pads were the same on both the TS10 & TS21. While the space between the pads may be the same, the pads of the TS21 must be proportionately larger. I don’t have a TS10 to compare.
C) Should my tablet’s “DEFAULT USB CONFIGURATION” (Developer Options) be left as “Charging-Only”, or set to one of the other options for this purpose? (Transferring Files, USB Tethering, MIDI, Transferring Images)
D) Is there anything else to consider?
As someone with very little programming knowledge, and even less actual experience, I would appreciate your assistance! Thank you!
It looks like you’ve got two different potential issues here. The adapter not being recognized by Android is completely unrelated to the pad spacing. You could have the adapter floating in mid-air, nowhere near a flashlight and Android should recognize the adapter. I’m very curious (/suspect) of that cable setup, I’d try to simplify it as much as possible and just use a USB-C to USB-C cable if you have one available. That is by far the most straight-forward option.
Now that pad spacing… it sounds like Wurkkos pulled a Sofirn and used a non-standard layout (I finally found a picture of the TS21 driver here). At least the pads are in the correct order, but that spacing doesn’t look right. Terry should be informed if he hasn’t been - we need to stick with a standard layout. Regardless… might be able to carefully line it up so that they make contact. But only worry about this after you get the adapter connectivity figured out first.
Keep us informed of your progress!
Interestingly enough, the pads have small enough gaps between them that the TS10 adapter works, if you are careful when connecting it.
Either way the TS21 is a model getting discontinued, so I don’t think it’ll get the updated pads, but it’s definitely important to get it fixed for anything releasing in the future.
Blockquote
Ya I would use a USB-C to C cable to simplify things. Not all C to C cables are created equal either, some are just power only, and you need data for this too. The android app has a test mode you can use to test the connection to the programmer, you should get confirmation that works before flashing.
Agreed. I was just hoping to get some feedback from someone who had successfully flashed their TS21, if available, before heading to Best Buy just to get a C-to-C cable. That’s now on Thursday’s agenda.
When I emailed Wurkkos yesterday about this, I asked for confirmation that the TS21’s pad layout was the same as the TS10’s.
Whomever replied, avoided answering that specific question, instead suggesting that I should solder Dupont wires to the key’s pogo pins, then to the pads. Sure thing!
While I have the capacity to solder those connections, it’s not like I have Dupont wires lying around, LOL! Passing the buck like that was not appreciated. I just hope it wasn’t @Wurkkos_Terry.
Will do.
Thank you for your feedback by letting me know that you were able to make the pin-to-pad connection!!!
Even under magnification, getting the pogo pins perfectly aligned to the flashing pads certainly challenges my hand-eye coordination. For Seinfeld fans, I feel like “Shakey the Moyle” LOL!
Anyway, hopefully getting a USB-C-to-USB-C power/data cable will make the difference to get this TS21 updated!
Agreed!
Thank you. I’ll be certain the cable I buy is both Power & Data Transfer capable.
A big thanks for making that video, especially pointing out to make use of the “test” mode.
If you see this, please confirm that when using the “test” mode, the “Action” should be set to “read” or “write”. Thank you!
I use an A to C cable though my adapter is probably the very first batch, and I use AVRdude from my laptop, so I can’t help much with that.
That’s alright, I still appreciate your input, plus I feel confident that purchasing a dedicated USB-C to USB-C Cable will get the job done. Fingers crossed!
I use a small hobby vise to position and hold the pins to the pads. I first saw @jon_slider mention this and I tried it. It works great for me. I had problems with the head moving on the table, or just not having the pogo pins in the right place. The vise solved that.
I whipped through 14 TS10s quickly and without problem using the vise. It is neat as I am using AVRDude on a Windows laptop, when the pins have good contact, the laptop gives the device connect tone. So I know I am ready to go.
I know lots of people hand hold the adapter, but one has to deal with what they have… my hand steadiness and vision just makes hand holding difficult. It doesn’t help that it takes around 26 seconds for the write and for the verify. I might have a better chance without the vice if I was seeing the short time that others report.
Anyway, If you are still struggling with it, maybe figure out some way of mechanically holding the adapter against the pads.
