Anduril Flashlight Reflash Reference (UPDATED FOR 2024)

wilkins1kc · March 3, 2023, 8:45am

Not really helpful but mine worked fine on a Samsung tablet with an old OTG cable

joechina · March 4, 2023, 7:34pm

@LuxWad can you add Narsil lights can be reflashed to Andúril?

Also, when a model number is missing, search in Models.txt from Gchart
For new Sofirn and Wurkkos lights he has probably the newest version.

dmenezes · March 4, 2023, 8:06pm

@LuxWad can you add Narsil lights can be reflashed to Andúril?

+1.

For new Sofirn and Wurkkos lights he [@gchart] has probably the newest version.

I can second this: when I was looking for the newest version for my TS10, the one on his repo was more up-to-date than even ToyKeeper’s.

LuxWad · March 5, 2023, 7:56am

Thank you for linking gchart’s list, it is a very useful resource! I will add it to the guide.

As for Narsil lights, I am not familiar with very many as I did not enter this side of the hobby until around the release of Anduril 2. I will consider adding them to this list, or making a seperate list for them.

DerMaxPower · March 14, 2023, 4:12pm

This is an outstanding guide. Thank you for all that time and effort!
I also thank you for including my D18 guide. I learned very much from other forum members and redditors and I’m glad that I can give something back.

joechina · May 3, 2023, 8:20pm

I just saw that the Wurkkos HD15R has flashpads, dispite it has its own UI.
Picture from zeroair

Has anyone tried to flash Anduril2 on a Wurkkos HD15R / Wurkkos HD15 ?
@ Toykeeper Can it be the UI is an reduced Anduril? Any way to find it out?

Quadrupel · May 4, 2023, 11:13am

And what MCU inside? Anyway is it worth it to run Anduril in trash driver and host?

ToyKeeper · May 4, 2023, 11:17am

I don’t know, but you could try to connect to it and see if it responds with UPDI, then get the MCU ID, maybe dump the ROM, and compare the file to a dumped version of Anduril to see if it’s similar.

BLF-L · May 10, 2023, 6:11am

LuxWad:

Finally, there are an increasing number of Anduril-based lights with ATTINY1616 controllers:

Sofirn SP10s/SP10 Pro, Q8, some versions of SP36, SC31 Pro, LT1 Mini - SP10 pro uses 3-pad pinout (layout variations exist)

Wurkkos TS10, TS25, TS11, FC13, New TS21 - 3-pinout (similar or same as SP10 Pro)

New Lume X1 drivers

Fireflies E07x Pro, E12C, T1R, T9R, NOV-Mu (updated 2022/23 versions) - same 3-pad pinout

Sofirn SC21 Pro - Unique 6-pads with 3 pads in use (this guide covers reflashing the SC21)

These lights will require a different USB Serial to TTL module (Amazon link )

The procedure for these lights will be different, please refer to this guide: Flashing a 3-pin ATtiny1616 Flashlight with New Firmware - pingle.org (includes info on the AVRDUDE and pymcuprog methods)

Thank you very very much for your guidance, I’ve been able to reflash my SC21 Pro to Anduril 2 (it was Anduril 1, don’t remember the version, now it’s 2022 10 12 0632 Anduril 2).
And my SP10 Pro to the latest Anduril 2 available (it was 2022 04 18 0631 , now it’s 2022 10 21 0631) .
Also my TS10 to the latest Anduril 2 (it was 2022 07 18 0714 , now it’s 2023 05 03 0714).

=====

My reflashing setup is with Samsung Galaxy A52 Android phone, ZFlasher AVR app from Play Store,
and USB to Serial TTL adapter CH340.

Not without trouble in the process though, infact I ran into trouble so much so I almost gave up.
I bought USB to Serial TTL adapters that look extremely similar to the one in the Amazon link.
But mine didn’t work. And it was really my biggest hurdle. I bought two and both of them didn’t work.

I spent hours and hours fiddling with jumper wires, pogo pins etc etc etc, thinking my wire connections were loose or dirty.
I even installed AVRDUDE and tried reflashing with my laptop, with the hope of a different result. Nope. Exactly the same failure :
“Chip initialization failed.”
My USB-TTL adapters came with a simple jumper between RX and TX.

=====

Well, basically I didn’t know (or didn’t pay enough attention) about additional resistor and/or Schottky diode for RX - TX of UPDI.

=====

Luckily I found this on github :

SpenceKonde/AVR-Guidance/UPDI

github.com

SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

# SerialUPDI
SerialUPDI is a UPDI upload tool which uses a normal USB serial adapter with the most trivial of modifications directly as a UPDI programmer
It was written in 2020-2021 By Spence Konde and Quentin Bolsee based on the pymcuprog tool from Microchip, which is much, much, slower.

## jtag2updi? Never heard of him
This page was formerly dedicated to discussing jtag2updi. jtag2updi was a program written in some of the most inscrutable C++ it has been my misfortune to work with, and it could be loaded onto a wide variety of AVR microcontrollers, and they could then be used as a UPDI programmer. The code was buggy, and very few people could make sense out of it. It's performance was passable, though, for example, Optiboot performed better at uploads, and both Optiboot and jtag2updi were stuck with baud rates 1/4th to 1/3rd of what the chip could be written at.. In late 2020, the first versions of SerialUPDI were created from pymcuprog, but the performance was very disappointing. In mid 2021, a push was undertaken to make it perform better than jtag2updi. The progress and the short time it took to make it exceeded all expectations. Since the 2021 performance sprint, SerialUPDI - which had write speeds as poor as 600b/s at the time this effort was started, advanced very rapidly. Within just a few days, speeds over 10k were achieved and within weeks it was faster than everything else. 
Since then some further performance enhancements, as well as ways to throttle it's performance to make sure it didn't overflow the part's receive buffer while it was writing

SerialUPDI is not perfect, but it's imperfections are small compared to those of jtag2updi, and less-initiated individuals are better able to improve it as compared jtag2updi - particularly as most of SerialUPDI's foibles are almost entirely due simply to it having not gotten enough attention from people who know how to write python - so things that should retry on failure or print error messages instead print stack traces, because something's throwing an exception and I don't know how to catch it. But the low level core that writes to the chip is largely fine. As of 11/21, we are no longer offering support for jtag2updi. The cores still support it, but it is not recommended. I will fix no bugs. If someone else wants to leap into this dumpster fire, by all means go ahead. I choose not to.. The only way that thing could be salvaged involves essentially rewriting it de novo so it wasn't a posterchild for how incomprehensible C++ can get.

## Brief orientation: What is UPDI
UPDI is the interface used for programming all AVR parts released since 2016 (the "modern AVRs") (and debugging, but that's locked behind a proprietary interface that nobody has bothered to reverse engineer, even though you can snoop on the protocol with just a serial adapter and even though the large scale structure of the protocol is known too - c'mon guys, this is gonna be a walk in the park compared to debugwire). Unlike the old ISP interface, which was very SPI like (in fact, It seemed to be SPI with the reset pin used like SS, and a somewhat odd pattern of communication). This time, we have a somewhat more sophistcated interface that we're connecting to (they call it the  Asynchronous System Interface (ASI)), and the communication method is via what looks suspiciously like they put another copy of the UART in, hardwired to always be in LBME (half-duplex single wire), 2 stop bits, even parity, and autobaud enabled and WFB (wait for break) as soon as it initializes. This talks to the ASI, which initially only lets you reset the chip and read the device ID and SIB (system information block). 

To enable the programming or debug modes, a "key" is sent - there are three in the datasheet (programing mode, chip erase which as usual is how you unlock and erase a locked chip, and program USERROW which can be written even while the chip is locked). There is also a debug key, I don't know what it is, but if I had a working debug setup with microchip studio, it should be trivial to recover by snooping on the communications during debugging. I'd also wager that this is the way they configure what pincount a part is (since most of the AVR dies these days get put into 2-3 adjacent 

Because it's basically a UART, and it looks like they simply copied the UART, only pointed it at the ASI. UARTs have 2 bytes of buffer on receive. Since halting for flash halts the CPU - but not the peripherals like the UPDI physical layer - it will buffer two bytes and lose dataon the third; this results in, at the end of the page being written, the programmer having written more bytes than the target received, causing the programming to fail at that point, because the the part is still treating the next command as data to write, and doesn't respond. 


## Wiring the hardware
Briefly, you connect Rx and Tx with either a 4.7k resistor or a small (signal) Schottky diode (band towards Tx). The RX like becomes the UPDI

This file has been truncated. show original

This part specifically is extremely helpful :
"I recommend the CH340 as the go-to serial adapter for several reasons:

They are dirt cheap and readily available on eBay/ AliExpress /Amazon…"

Connections

“Add either a resistor or Schottky diode between Tx and Rx (in the case of serial adapters without their own TX series resistor, an external one is needed.”

=====

Subsequently, I put additional resistor between RX and TX of the USB-TTL adapter.
Both of my USB-TTL adapters have built-in resistor in series with TX, 1.5 kOhm.
I added 3.3 kOhm to make it 4.8 kOhm, not too far off from the 4.7 kOhm recommended value.
That’s it, no Schottky diode, no resistor between RX and flashlight either.
Only one additional resistor between RX and TX , 3.3 kOhm .
Other value might work, maybe, I don’t know. YMMV.

Another thing :
“Some serial adapters have a dedicated LED to indicate Rx.”
"… LED on RX must be removed … "
“… remove any LED on the RX line, or it will never work.”

I keep one adapter with its built-in RX’s LED,
and disabled RX’s LED on the other adapter. Both of them still work OK for reflashing.
I only use my Android phone (ZFlasher AVR) , never retried with my laptop (avrdude).

=====

For anyone having trouble reflashing with UPDI, getting something like "Chip initialization failed. Check connections… " , you can try adding resistor between RX and TX.
Please read the guidance :

github.com

SpenceKonde/AVR-Guidance/blob/master/UPDI/jtag2updi.md

# SerialUPDI
SerialUPDI is a UPDI upload tool which uses a normal USB serial adapter with the most trivial of modifications directly as a UPDI programmer
It was written in 2020-2021 By Spence Konde and Quentin Bolsee based on the pymcuprog tool from Microchip, which is much, much, slower.

## jtag2updi? Never heard of him
This page was formerly dedicated to discussing jtag2updi. jtag2updi was a program written in some of the most inscrutable C++ it has been my misfortune to work with, and it could be loaded onto a wide variety of AVR microcontrollers, and they could then be used as a UPDI programmer. The code was buggy, and very few people could make sense out of it. It's performance was passable, though, for example, Optiboot performed better at uploads, and both Optiboot and jtag2updi were stuck with baud rates 1/4th to 1/3rd of what the chip could be written at.. In late 2020, the first versions of SerialUPDI were created from pymcuprog, but the performance was very disappointing. In mid 2021, a push was undertaken to make it perform better than jtag2updi. The progress and the short time it took to make it exceeded all expectations. Since the 2021 performance sprint, SerialUPDI - which had write speeds as poor as 600b/s at the time this effort was started, advanced very rapidly. Within just a few days, speeds over 10k were achieved and within weeks it was faster than everything else. 
Since then some further performance enhancements, as well as ways to throttle it's performance to make sure it didn't overflow the part's receive buffer while it was writing

SerialUPDI is not perfect, but it's imperfections are small compared to those of jtag2updi, and less-initiated individuals are better able to improve it as compared jtag2updi - particularly as most of SerialUPDI's foibles are almost entirely due simply to it having not gotten enough attention from people who know how to write python - so things that should retry on failure or print error messages instead print stack traces, because something's throwing an exception and I don't know how to catch it. But the low level core that writes to the chip is largely fine. As of 11/21, we are no longer offering support for jtag2updi. The cores still support it, but it is not recommended. I will fix no bugs. If someone else wants to leap into this dumpster fire, by all means go ahead. I choose not to.. The only way that thing could be salvaged involves essentially rewriting it de novo so it wasn't a posterchild for how incomprehensible C++ can get.

## Brief orientation: What is UPDI
UPDI is the interface used for programming all AVR parts released since 2016 (the "modern AVRs") (and debugging, but that's locked behind a proprietary interface that nobody has bothered to reverse engineer, even though you can snoop on the protocol with just a serial adapter and even though the large scale structure of the protocol is known too - c'mon guys, this is gonna be a walk in the park compared to debugwire). Unlike the old ISP interface, which was very SPI like (in fact, It seemed to be SPI with the reset pin used like SS, and a somewhat odd pattern of communication). This time, we have a somewhat more sophistcated interface that we're connecting to (they call it the  Asynchronous System Interface (ASI)), and the communication method is via what looks suspiciously like they put another copy of the UART in, hardwired to always be in LBME (half-duplex single wire), 2 stop bits, even parity, and autobaud enabled and WFB (wait for break) as soon as it initializes. This talks to the ASI, which initially only lets you reset the chip and read the device ID and SIB (system information block). 

To enable the programming or debug modes, a "key" is sent - there are three in the datasheet (programing mode, chip erase which as usual is how you unlock and erase a locked chip, and program USERROW which can be written even while the chip is locked). There is also a debug key, I don't know what it is, but if I had a working debug setup with microchip studio, it should be trivial to recover by snooping on the communications during debugging. I'd also wager that this is the way they configure what pincount a part is (since most of the AVR dies these days get put into 2-3 adjacent 

Because it's basically a UART, and it looks like they simply copied the UART, only pointed it at the ASI. UARTs have 2 bytes of buffer on receive. Since halting for flash halts the CPU - but not the peripherals like the UPDI physical layer - it will buffer two bytes and lose dataon the third; this results in, at the end of the page being written, the programmer having written more bytes than the target received, causing the programming to fail at that point, because the the part is still treating the next command as data to write, and doesn't respond. 


## Wiring the hardware
Briefly, you connect Rx and Tx with either a 4.7k resistor or a small (signal) Schottky diode (band towards Tx). The RX like becomes the UPDI

This file has been truncated. show original

for a better understanding of UPDI.

dmenezes · May 10, 2023, 11:42am

@BLF-L thanks for the detailed post, but man you really did it the hard way! I just got myself one of @gchart excellent USB-C adapters and it was zero trouble and immediate success right from the start, just touch the pins to the pads and off it went.

OTOH I feel like a weakling for doing it the easy way instead of going through a whole saga like yours

gchart · May 10, 2023, 1:22pm

Yup, that’s a pretty good description of UDPI programming. I’ve referred back to that SpenceKonde article many times, and it has served as the springboard for my design work in creating UDPI programmers. I first started with jtag2updi and a AVR JTAG ICE v2.0 stick, as it was the originally recommended way of doing things. Then I quickly pivoted to using off-the-shelf USB to Serial adapters with a separate pogo pin board with a resistor and diode. Then I finally settled on creating an all-in-one design based around the CH340 chip, inspired by wagiminator’s PyUPDI programmer. At that time, we still needed to use pymcuprog because avrdude did not yet fully support UPDI. Then, after many years’ delay, avrdude7 was released with full UPDI support. And with avrdude7’s release, I was able to work with the ZFlasher AVR developer to get it updated with UPDI support, as well (the app uses avrdude in the background).

BLF-L · May 10, 2023, 6:54pm

Thanks @dmenezes,
hopefully sharing my experience could help someone having connection problem in their UPDI setup.

oo man, I’m pretty sure it’ll be extremely nice to have gchart’s UPDI programming adapter…

But I live on the other side of the globe, I’m afraid shipping won’t be very practical, not only cost-wise but mainly for how long it’ll take to get it to me. That’s why I’m kinda forced to rig up this super-ghetto-style UPDI programming setup.

Not too bad though, USB-TTL adapters are widely available. Otherwise it’ll be almost insurmountable for me to build-from-scratch a USB-TTL adapter.

Std CH340 USB-TTL adapter, simply add female-female dupont jumper wires and pogo pins and it’s up and running.
And a resistor and/or Schottky diode, if needed.

P50-B1 pogo pins can be press-fitted into regular female jumper wires (I think it’s the 2.5mm jumper wire) , it’s nice and tight, no need to solder. Springy pins really help stabilizing the connections to the flashing pads.

=====

I tried my setup with male-female jumper wires. Female-sides connect to the USB-TTL adapter, male-sides directly to the flashlight’s flashing pads,
definitely not as nice as with pogo pins but still semi-usable if you don’t have pogo pins. I mean it’s bad without pogo pins, I don’t wanna do it again that way

BLF-L · May 10, 2023, 7:07pm

Reflashing my SP10 Pro,
definitely nicer with pogo pins :

=====

I only have 2.5mm female header pins,
pulled off the the original pins and pushed the pogo pins through the header “rail” holes, to tie them up together so I didn’t need to hold the jumper wire housings individually.

I’m waiting for 1.27mm header pins on order, guess they’ll make a better alignment with the flashing pads.

An even better setup is to be using 1.27mm 3-pin dupont housing, a one-piece housing instead of single-pin dupont housings. But I couldn’t find that size anywhere.

BLF-L · May 10, 2023, 7:25pm

again, If you have gchart UPDI programming adapter or pogo key, you don’t need to rig up this complicated thingy.

dmenezes · May 10, 2023, 7:26pm

You know about u/m4potofu (on r/flashlight at Reddit), right? I think he goes here by @thefreeman, and he ships gchart stuff from Europe to worldwide for very reasonable prices. I too am overseas and almost purchased from him, but turned out I had a friend on a trip to the US at the time so @gchart shipped it to her and he brought it to me when she came back from the trip.

But anyway, I’m all for the guetto way of doing things more time-consuming and sometimes more aggravating, but frequently more fun and always more instructive!

BLF-L · May 10, 2023, 7:31pm

That’s great!

yup, I believe gchart’s design is the most user friendly.

BLF-L · May 10, 2023, 7:33pm

Thanks so much @gchart, ZFlasher AVR app is really a BIG help for the reflashing. No need for a cumbersome desktop computer or a laptop. We have our smartphone all the time. Super convenient.
It’s almost similar to programming an Arduino board (with ArduinoDroid).

BLF-L · May 10, 2023, 7:51pm

Well, this is beyond the scope of reflashing but
can we compile Anduril hex files using our smartphone?
is there an app for that?

Compiling with that app, and then Reflashing with ZFlasher AVR,
using Android phone, how do we do that?

gchart · May 10, 2023, 7:52pm

thefreeman’s design is slightly different - he referenced mine (after asking, though he didn’t need to) and also added a few pads incase you want to solder on leads for one-off layouts. That said, I don’t think he’s made one for the SC21 Pro like I’ve put together. I dunno if you (@BLF-L) have ever ordered from Oshpark, but they’re very reasonable and I think they even ship internationally for free. I’ve got different styles of adapter boards that you can use with your USB to Serial board:

Not that I have anything against rigged-up solutions! These should be slick and cost effective, though, if that interests you.

That would be really cool, but I’ve never seen it done. You’d need the entire avr-gcc compiler and avr-libc toolchain and some other goodies. I mean, those run just fine on Linux and Android is based on Linux… so it’s probably possible, but not really feasible.