Man, the more I learn about Anduril on other flashlights, the more I love my Wurkkoses TS10 and FC13 – no muzz, no fuzz, good quality, the best MCU and with easily accessible flashing pads, great price and they simply just effing work – and with all code mainstreamed directly into TK’s Anduril sources. What’s not to love? 
1 Thank
I am old and stupid when I am tired 
Thank you
A question about why the hex file I read with Zflasher AVR is smaller than the hex file I wrote.
Based on my limited experience using “Zflasher AVR for Android”, the “Read” Action (which is used to make a backup hex file directly from a flashlight) creates a hex file that is very different in size compared to the size of the original hex file that was used to flash the light with the “Write” Action. I would have thought that the two hex files would have been the same size.
As an example, I downloaded “anduril.2023-05-30.wurkkos-ts11.hex” from Index of /torches/fsm/anduril2 and the file size was 29.60 KB on my Android tablet.
I then used the “Write” Action to flash my “Wurkkos TS11” with this hex file. The flash completed successfully and the light worked as expected, but when I used the “Read” Action, the file size of the hex file created was much smaller at only 25.00 KB and I had not changed any Anduril settings on the “Wurkkos TS11” between the “Write” and “Read” Actions.
My main use of the “Read” Action will be for backing up an “as delivered” light before flashing a new hex file to it if I do not have access to the original hex file in case I want or need to revert back to the original hex file after the flash.
Since I cannot get the “Read” Action to return the correct size hex file from a previous “Write” Action, I am hesitant to flash any hex file created from a “Read” Action since I already had an issue using a hex file that was known to be good from a trusted repository where a flash did not complete successfully and after that it would not accept another flash and the light never worked again.
Am I doing something wrong that is causing me to only backup a portion of the hex file, or is there some explanation as to why the “Write” and “Read” hex file sizes are so different?
The hex file format is just a container. Different addressing, checksums etc can cause a different file size. Also the compiled hex contains more than just the flash section.
2 Thanks
Just adding to the excellent response @SammysHP already gave you: Intel HEX - Wikipedia
To sum it up, there’s a lot of leeway in the HEX format, eg, the exact same binary image could use fewer larger records or more smaller records, different addressing modes, etc – so using its size as a proxy to the binary size is not a good strategy.
Thank you “SammysHP” and “dmenezes” for your replies.
As a test to see what would happen, I was going to flash my “Wurkkos TS11” with that smaller-than-I-had-expected hex file that I had previously created from that same light by using the “Read” Action of the “Zflasher AVR for Android” app, but then I noticed something else about the size of this hex file that was strange.
The “Zflasher AVR for Android” app saves the hex files that I create directly from a light with the “Read” Action into the “Downloads” directory. This directory also contains the hex files that I have downloaded from the repositories of forum member ToyKeeper and gchart.
When I use the native file manager on my Android tablet (Samsung Galaxy Tab A7 Lite) all of the hex files that I created with the Zflasher AVR “Read” Action along with the hex files that were downloaded from other forum member’s repositories have a file size of 21 KB or more.
The “Zflasher AVR for Android” app has a box with rounded corners and three dots in it at the right side of the “HEX file:” field that you click on to select the hex file that you want to use for a “Write” or “Read” Action. When I click on this box it shows all of the hex files that I have in my “Downloads” directory, but only the hex files that I had downloaded from other forum member’s repositories have the correct file size. Any hex file that I created with the Zflasher AVR “Read” Action now shows a file size of 0 KB when viewed from within the “Zflasher AVR for Android” app which does not agree with the file size shown by the native file manager.
Since I do not know what unanticipated consequences could occur from flashing a light with a hex file that the Zflasher AVR app believes is empty, for now I will limit myself to just using hex files from trusted repositories that are known to be good.
Thanks again.
I don’t use ZFlasher but that does seem highly irregular. I’ve seen that with other Android apps but usually the other way around, files that were not created by them could not be read or showed with 0 size.
I commend you for your prudence. I would also recommend that you fix whatever the issue it is with ZFlasher as soon as you can, because if it’s malfunctioning with reading files from the flash, who knows when/what it could start doing the same with the writing. Perhaps someone here can help you further (I would open a new topic) or perhaps the app author?
Sounds like a permission problem. With the Storage Access Framework (SAF) the filesystem isn’t accessed directly, but through an abstraction that manages further permissions. In some cases the old way without SAF works as well, but the resulting files might get permissions that prevent access through other apps. This is a real mess and causes all kind of trouble.
1 Thank
Yeah, in general I’d only trust data I read off a chip on a computer anyway (maybe unless I did a couple of verification passes too to make sure it had read it correctly), had too much flakiness from USB on phones before.
+1 to that. Flashing on a phone/tablet may be convenient but it’s not the safest practice IMHO, too many layers between the app and the USB port hardware means a lot more stuff that can go wrong. And Google certainly doesn’t help by changing Android all the time…
I use only ZFlasher and the app never give me a problem. When the upgrade doesn’t work is always my faulty. Wrong serial, wrong hex, pin are not connected… And I use an old phone.
Is practical, fast and also portable.
I use iOS from 2005 and i see thousand of unreal problem like a missing folder and trust me I don’t trash the folder. Backup save me
We are truly luckiest with flashlight because firmware are rewritable if one thing goes wrong. In other thing (like computer) if you interrupt the firmware process you are doomed.
1 Thank
Have you ever use the ZFlasher “Read Action” and if you have, did the hex file saved to the downloads directory have the issue described below:
I use read one time but nothing happened and I never create an hex file with Avr. I use only to upgrade.
Why you use the “read” function?
I was hoping to use the “Read” Action to back up “as delivered” lights before flashing a new hex file to them when I do not have access to the original hex file in case I want to or need to revert back to the original hex file after the flash.
My “Wurkkos TS11” was delivered with Anduril Version “2022 07 25 0715” and I do not know where to find the original hex file for this light. Also the model number for the TS11 should be “0717” instead of “0715” which is the model number for the “Wurkkos TS25”.
I am guessing Wurkkos may have used hex file “anduril.2022-07-25.wurkkos-ts25.hex” from http://www.ghart.com/blf/firmware/hex_files/sofirn_anduril2/ for the TS11, but I am not sure and cannot compare the hex file size from the ZFlasher “Read” Action to be more sure that this may be the original hex file since this file is not expected to be the same size as the hex file size in the repository used for the “Write” Action based upon the helpful replies I received when I asked about this.
2 Thanks
Only if you use a crappy computer and/or OS 
Seriously, a bad phone would be the same.
And AFAIK, at least with the AT1616 or similar which use UPDI, there’s no possible bricking from a bad flash, just reflash and you’d be OK.
All computers are crappy😂
Not when well wiped
1 Thank
1 Thank
Theoretically, if you disabled the RST pin you could still brick it, or if you set a wrong clock source. I have had an attiny1634 spontaneously disable SPI itself while being flashed (coincidence of a bad byte being written at the wrong moment, I guess) before any that could still happen on the 1616 even if the UPDI 1 wire protocol does seem both faster and less prone to induced error, but another advantage of the t1616 is that it doesn’t need any extra pins for HVP to completely reset the chip like the t1634 does (which are not exposed on the 5 pad flashing pads), it can be done from the three already exposed.
1 Thank
This is weird: AFAIK flashing does nothing but write to memory (flash and/or EEPROM), and neither disabling pins or change clock sources can be done that way (or can they?)
Yeah, that’s one reason I’m avoiding non-at1616 lights as much as I can – finickier, needing special adapters with twice the number of pins, slower, etc – perfect recipe for trouble.
I do hope Hank gets his game together and moves to the AT1616 ASAP – that will be the day I will start buying his lights.