Upgrading on Linux and Mac

[sgr1ff1n]

Sorry I don't understand how to communicate on GitHub fully and if this is the wrong place for said comment the please advise me on how to move it elsewhere. i just wanted to say that i was able to update the firmware on my ts100 from the stock version to 1.08 found in this repository using my Mac. I simply followed the same steps however through Finder. I have a MacBook Pro (13-inch, Mid 2012) running Sierra 10.12.4 (16E195). Cheers, Shane

[balrog-kun]

Also I've just updated to 1.08 from Linux but it wasn't automatic. Just copying the file to the automounted volume would cause the file to be renamed TS100.NOT and TS100.ERR if I tried it from command line. dfu-tool and dfu-util wouldn't work either.

So I disabled automounting with $ gsettings set org.gnome.desktop.media-handling automount false (or as indicated by googling "disable gnome automount"), unplugged and replugged, then mounted the volume as msdos instead of vfat type using, in my case, # mkdir tmp; mount -t msdos /dev/sdc tmp (as root) and cp /home/balrog/Downloads/ts100.hex tmp/TS100.HEX; sync. I'm not sure which part is the key to making it work really, possibly the msdos FS type. Automounting can be re-eabled once you see 1.08 on the TS-100 display.

[Ralim]

Hi, That's actually really good news to hear. Not sure where the best place would have been to raise this really. However, I have copied these notes over to a page on the wiki and added a link on the homepage to let users know. Sadly I currently do not have access to a Mac to test at the moment. I will test the Linux instructions when I get a chance though.

I'm going to mark this issue as closed, for now, however, if anyone has any further insight to add to this, feel free to re-open the issue.

Also feel free to update the wiki or suggest missing information here as well :)

[doegox]

Hi, sharing my experiences: DFU 3.43 Avoid any USB hub, my TS100 got detected properly only when directly plugged. I tried many things under Linux (Debian with kernel 4.9.0, tried msdos/fat/sync/caps...), no way, always getting .NOT on Ralim fw and .ERR on official fws. What worked:

• Disable automount on Linux
• Plug the device and launch a Win10 in a Virtualbox, share USB device
• Drop file with the Explorer

Now happily running Ralim fw 1.13

[amisoftau]

Just upgraded with Linux no problem from stock shipped 2.12 to stock 2.17.. Linux: Linux Mint 17 DFU: 3.43

Based on balrog-kun's posting; I tried the auto-mount drive, but didn't work as reported. Yes it mounted it as vfat. No need to change automount config.. Just unmount the drive leaving device still plugged in. Get a terminal window and change to super user. mount the drive somewhere as type msdos (-t msdos). Copy the file to the mount point. (device will reboot, then automount will remount again. Should show .RDY) unmount the manually mounted drive.

Hints: When automount first runs, in a terminal window run the df command. Note the last mount drive name. In my case it was /dev/sdi. That's the device you'll want to manually mount.

e.g. (substitute your own username for "username", .hex file name for "APPV217.hex" and correct path to the file, and actual automounted device name for "/dev/sdi") (In a terminal window..) su (supply super user [root] password) mkdir /mnt/tmp mount -t msdos /dev/sdi /mnt/tmp cp /home/username/Desktop/APPV217.hex /mnt/tmp (device will reboot and automount will rerun, showing .RDY) umount /mnt/tmp exit exit

[Ralim]

Thanks, @amisoftau and @doegox for your information. I can confirm I am able to update under Linux by mounting as msdos. I am on the 4.4 kernel though.

[dhottinger]

Didn't work for me until I found out that destination file name needs to be all caps. Now it works.

[Ralim]

That's... Really odd. But good to know to try ! I'm guessing they might be using 8.3 filenames in their code.

[doegox]

I finally could flash it under linux too, no matter the lower case / upper case, but I think it's just quite unstable so sometimes it works sometimes not. My guess as it flashes automatically as soon as the file is there is that there is some racing condition between linux finishing the write and the ts100 initiating the flash procedure. E.g. suppose it watches for some write in the FAT metadata as a trigger, if Windows Explorer updates the metadata after the copy but Linux and probably some other Windows tool may touch first the metadata, this could explain the troubles with anything besides Windows Explorer...

[doegox]

just per curiosity, there is no way from a modified FW to dump the DFU code @Ralim ? or from jtag?

[Ralim]

Yeah it isn't the best reliably bootloader, and I have looked into creating a new one (non virtual flash disk based though).

I'm thinking about making a DFU based one so you can use dfu utility to load the firmware if you don't use a Windows machine.

I'm not sure if it's a race condition of out of order writes that cause the issue.

We can dump the compiled machine code of the unit (already in this repo). But that is a long way removed from the source code, and I don't have access to ida to reverse engineer the assembly. (or patience for radare)

At this point in time, it's basically either take already available dfu bootloader code and adapt it, or fight with Windows to program the iron. There is a nice concept of Web-dfu which I like and plan to create a fork to support the ts100.

[XEJK]

You do know IDA is free for non-commercial use?

[Ralim]

Hi, Last I tested the freeware version It didn't support the arm M core processors, and it was Windows only. I haven't tested it recently, do you know if they have added the cortex M1 (thumb 2 code)?

[XEJK]

That I unfortunately don't know as I've also not used it in a while, but it's always worth a look as it's one of the best tools for this sort of thing.

[Ralim]

Yeah, I've used it before a few times, but the current version does not work with this MCU as far as I can tell.

Honestly, it's not worth reverse engineering the bootloader at this point in time.

[MarSoft]

As a follow-up to this Linux-related coment: I have just successfully installed 1.16 to the fresh new iron. Mine iron has DFU 3.43. When I connect it to my Linux box (latest Arch Linux, with automounting enabled via udiskie), there is a new "flash drive" appears which already has the following files and directories:

• .fseventsd/
• System Volume Information/IndexerVolumeGrid
• .Trashes/
• ._.Trashes

I am not sure why did they put these files into the image, but they are just there. Drive is mounted as vfat by default. When I tried to write firmware hex file, it was renamed to .NOT - not sure what does it mean. Then I power-cycled the device, unmounted it when it was auto-mounted and re-mounted it manually as msdos FS as was advised above. Then I wrote hex file again. As a result (from second try) it was renamed to .RDY, and firmware was upgraded successfully.

So it is not necessary to disable auto-mounting.

[MarSoft]

Actually I am not sure, it took several retries before successful write. Sometimes it was renaming the file to .NOT, sometimes to .ERR.

[awigen]

Could you please try the flasher for Linux merged today and let us know the result and which distro you are using.

[M1k3y-shack]

Just wanted to let you guys know, that the flash script from @awigen works like a charm. I don't know which kind of voodoo he used since I tried the exactly same thing his script does about 10 times and it always failed. But his script just worked on the first try. Anyway, thank you very much for providing it, and if I can help with testing let me know, I have access to about a dozen machines all with different Linux configurations.

[MarSoft]

I can confirm. Just used the flasher script to successfully upgrade from 1.16.3 to 1.17-alpha2. Works like a charm. My setup: Arch Linux, qtile window manager, udiskie-based automount. Important note: flasher script was unable to disable automount, but that didn't prevent it from working. Thanks!

[thanks4opensource]

Just now joined GitHub to post my Ralim/ts100 Linux upgrade experience in case it's of help to others.

First: Thanks, Ralim. Awesome work! I'll probably be offering unnecessary design enhancement suggestions and begging for help as I try to compile and hack on the source code.

On to my Linux firmware flash ...

Bottom line is I had no problems flashing the v1.16.3 ts100.hex file from the releases page. (Well, one due to user error which I'll describe as a question below.) Beyond that, I didn't have any of the difficulties others have described in this thread.

I attribute this to the fact that I run a super plain/simple Linux install: openSUSE Leap 42.1 (don't think that matters) with 4.1.39-53-default kernel. More importantly, I'm running fvwm -- no GNOME or KDE "desktop environments", no file/volume managers, no automounting -- none of that garbage I neither need nor want.

I plugged the TS100 into a USB port (no intervening external hub) and dmesg showed:

[Sat Aug 19 09:47:53 2017] usb 1-1: new full-speed USB device number 11 using uhci_hcd
[Sat Aug 19 09:47:54 2017] usb 1-1: New USB device found, idVendor=0483, idProduct=5720
[Sat Aug 19 09:47:54 2017] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Sat Aug 19 09:47:54 2017] usb 1-1: Product: STM32 Mass Storage
[Sat Aug 19 09:47:54 2017] usb 1-1: Manufacturer: STMicroelectronics
[Sat Aug 19 09:47:54 2017] usb 1-1: SerialNumber: Tÿyr\xffffffc2\xffffff80HP"  g
[Sat Aug 19 09:47:54 2017] usb-storage 1-1:1.0: USB Mass Storage device detected
[Sat Aug 19 09:47:54 2017] scsi host148: usb-storage 1-1:1.0
[Sat Aug 19 09:47:55 2017] scsi 148:0:0:0: Direct-Access     Virtual  DFU Disk              PQ: 0 ANSI: 2
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: Attached scsi generic sg4 type 0
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] 4096 512-byte logical blocks: (2.10 MB/2.00 MiB)
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] Write Protect is off
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] Mode Sense: 03 00 00 00
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] No Caching mode page found
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] Assuming drive cache: write through
[Sat Aug 19 09:47:55 2017]  sdd:
[Sat Aug 19 09:47:55 2017] sd 148:0:0:0: [sdd] Attached SCSI removable disk
[Sat Aug 19 09:52:42 2017] usb 1-1: USB disconnect, device number 11

lsblk showed:

# lsblk -o NAME,FSTYPE,MOUNTPOINT,LABEL,UUID,PARTTYPE,PARTUUID,MODEL,SIZE,STATE,TYPE,VENDOR /dev/sdd
NAME FSTYPE MOUNTPOINT LABEL    UUID                                 PARTTYPE PARTUUID MODEL    SIZE STATE TYPE VENDOR
sdd  vfat              BDC888E8 6CE4-98A2                                              DFU Disk   2M runni disk Virtual 

Because it showed vfat format I ignored all the warnings in this thread about needing to specify msdos instead, and mounted it with auto format detection. Again, note that there was no automount to be unmounted.

The pseudo-disk was immediately accessible as:

$ df -hT /media/sdd
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdd       vfat  2.0M  6.5K  2.0M   1% /media/sdd

containing:

$ ls -alRF /media/sdd/media/sdd:
total 26K
drwxrwxr-x  5 mark users  16K Dec 31  1969 ./
drwxr-xr-x 13 root root  4.0K Jul 23  2016 ../

drwxrwxr-x  2 mark users  512 Nov 25  2014 .Trashes/
-rwxrwxr-x  1 mark users 4.0K Nov 25  2014 ._.Trashes*
drwxrwxr-x  2 mark users  512 Nov 25  2014 .fseventsd/
drwxrwxr-x  2 mark users  512 Oct 29  2014 System Volume Information/

/media/sdd/.Trashes:
total 17K
drwxrwxr-x 2 mark users 512 Nov 25  2014 ./
drwxrwxr-x 5 mark users 16K Dec 31  1969 ../

/media/sdd/.fseventsd:
total 17K
drwxrwxr-x 2 mark users 512 Nov 25  2014 ./
drwxrwxr-x 5 mark users 16K Dec 31  1969 ../

/media/sdd/System Volume Information:
total 17K
drwxrwxr-x 2 mark users 512 Oct 29  2014 ./
drwxrwxr-x 5 mark users 16K Dec 31  1969 ../
-rwxrwxr-x 1 mark users  76 Oct 29  2014 IndexerVolumeGuid*

I copied over the firmware binary (this time heeding the warnings and using uppercase to be safe): $ cp ./ts100.hex /media/sdd/TS100.HEX For about 1-2 minutes the mount showed:

$ ls -a /media/sdd
./   .Trashes/    .fseventsd/                 TS100.HEX*

Then it spontaneously unmounted itself:

$ ls -a /media/sdd
./  ../

I remounted it and, voila:

$ ls -a /media/sdd
./   .Trashes/    .fseventsd/                 TS100.RDY* ../  ._.Trashes*  System Volume Information/
$ df -hT /media/sdd
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdd       vfat  2.0M   59K  2.0M   3% /media/sdd

I did notice the TS100.RDY contents were changed from the original TS100.HEX data. is this normal?

$ cmp -l ts100.hex /media/sdd/TS100.RDY
    1  72  60
    3  62  60
    9  64  60
   11  70  60
   14 106  60
   15  62  60
   16  15  60
   17  12  60
   18  72  60
   19  61  60
   21  64  60
   28  60  63
   29  65 106
   30  60  15
   31  60  12
   32  60  72
   33  62  61
   35 105  70
   36  61  71
   37  67  63
   38  60  70
   42  70  60
...

The sizes (53071 bytes) were the same.

Next there was a small problem after unmounting, unplugging, and repluggiing the USB cable -- without holding down any buttons. On reconnect dmesg had:

[Sat Aug 19 09:45:24 2017] usb 1-1: new full-speed USB device number 7 using uhci_hcd
[Sat Aug 19 09:45:24 2017] usb 1-1: device descriptor read/64, error -71
[Sat Aug 19 09:45:24 2017] usb 1-1: device descriptor read/64, error -71
[Sat Aug 19 09:45:24 2017] usb 1-1: new full-speed USB device number 8 using uhci_hcd
[Sat Aug 19 09:45:24 2017] usb 1-1: device descriptor read/64, error -71
[Sat Aug 19 09:45:25 2017] usb 1-1: device descriptor read/64, error -71
[Sat Aug 19 09:45:25 2017] usb 1-1: new full-speed USB device number 9 using uhci_hcd
[Sat Aug 19 09:45:25 2017] usb 1-1: device not accepting address 9, error -71
[Sat Aug 19 09:45:25 2017] usb 1-1: new full-speed USB device number 10 using uhci_hcd
[Sat Aug 19 09:45:26 2017] usb 1-1: device not accepting address 10, error -71
[Sat Aug 19 09:45:26 2017] usb usb1-port1: unable to enumerate USB device

And the LCD was at the Ralim startup screen. If I had pressed the front/tip/"ON" button at that point would the iron have attempted to heat up under USB power and blown my computer's port?

Not wanting to risk that, I unplugged and replugged, this time holding down the button. Dmesg was normal, and the TS100 mounted correctly, with the TS100.RDY file gone:

$ ls -a /media/sdd
./  ../  .Trashes/  ._.Trashes*  .fseventsd/  System Volume Information/
$ df -hT /media/sdd
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdd       vfat  2.0M  6.5K  2.0M   1% /media/sdd

Again unplugged from USB, and connected the laptop power supply. Got the Ralim ON/SETUP screen, and all working correctly -- settings changes, heat up, soldering, sleep, etc.

Finally, here's the initial problem I had, and a question about the new firmware. Before the Ralim flash, with the stock 2.12 firmware , I connected USB without holding down any buttons and got:

$ mount /media/sdd
$ df -hT /media/sdd
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdd       vfat  8.0K  1.0K  7.0K  13% /media/sdd
$ ls -la /media/sdd
./  ../  CONFIG.TXT

The LCD screen showed "CONFIG" as compared to "DFU:3.43" when correctly holding down the front/tip button on USB connect.

This was my initial user error -- I couldn't copy over the .hex file because the drive wasn't big enough. Totally my fault. But I did hand-edit the CONFIG.TXT file to change settings more to my liking, and the stock 2.12 firmware did run correctly with them.

So ... is this intentional that the Ralim firmware doesn't support mounting the TS100 as a mass storage device except in DFU mode (while holding down the button)? I realize there's no need for the config file because the settings are all changeable directly via the LCD and the buttons, but just wondering.

Thanks again, Ralim, for the great work, and I hope my details can help another Linux only / no Windows user. I'll try to answer any questions directed towards me.

[MarSoft]

@thanks4opensource, according to README the decision to stop using mass storage mode for configuration was made by Ralim to simplify the firmware itself and to free up some space for additional functions. This mode is not needed anymore anyway because now settings can be changed from the soldering iron itself through an interactive menu (which was not possible in the stock firmware).

[Ralim]

Hi @thanks4opensource, Don't panic about pressing buttons when powered off USB, it checks the input voltage before it starts to heat the iron (which is 0V as no input). So there is no risk to your computer :smile:

The TS100.HEX contents do change because of how the DFU works, it actually writes the file to the flash as it is copied from the pc (as ram is much smaller than flash). And so the file when you look at it after re-mounting will be a random flash area I think.

I can confirm as @MarSoft pointed out, this firmware does not implement any USB functionality at the moment. This was removed at the very beginning as it takes up around 36k of the 48k of flash that is left for the code. When using GCC I couldn't even get their existing code to want to compile and fit without issues, so I stripped out the USB support which freed up a stack of code (compiled size went down to around 7k). Since then I have added the menu system and all the screens for the operation that made the USB nearly pointless.

The one thing the USB was nice for, was setting up the bootup screen, however, I have implemented this for now using the custom .HEX file via the bootloader to get around this.

Since implementing the USB required having the USD scsi driver code, dedicated flash section, fat32 driver, decoder for the bmp file as well as their hand coded version of fscanf for scanning the .txt file for all its settings. This removed a lot of code :grin:

Feel free to ask any questions about this though, and offer any ideas you have and I'm more than happy to look into them for future use :)

[thanks4opensource]

Thanks @MarSoft, and (again for all the hard work), @Ralim.

Yes, as I said, I understand why USB mass storage access isn't needed with the Ralim firmware. And I'm also painfully aware of the code size implications of USB. I haven't done mass storage, but I did get the HAL USBD (serial communications over USB) API/driver working on an STM MCU and it was a nightmare.

Very glad to hear about the firmware detecting USB-only power and not turning on the tip heater. Excellent real-world-proof software design (as I've come to expect with your code).

Also thanks for explaining the .HEX to .RDY post-flash byte changes.

I do have some more questions / comments / enhancement requests, but as they're not Linux-flashing specific would you like me to:

1. just continue in this thread / wiki page
2. start a new one (don't know if I have permission access to do that)
3. contact you via your web site email
4. quit bothering you and just enjoy using the firmware as-is ;)

[Ralim]

You're welcome 😄

Generally Opening a new Issue is the best idea for each core idea. So for each group of changes etc you open a new issue to discuss. As this avoids causing emails to be sent to everyone else already in the thread. Anyone who has a Github account can open a new issue for discussion :)

If the ideas are really wacky or are off-topic for the firmware development feel free to email me, and If anything interesting comes up I add it to the wiki or the readme page.

Try and group ideas into issues based on their logic of implementing. So that they can be marked done as they are implemented or resolved.

[novirium]

Just flashed v1.17-alpha6 onto a stock TS100 running 3.43, from Arch Linux. Incrementally tried advice from above, and can confirm that the process worked with the all caps filename ("TS100.HEX"), but did not with lower case (as mentioned, msdos mount was also required).

[LongHairedHacker]

Just for the record: I've flashed mine (DFU 3.43) from Arch Linux. Same behaviour as @novirium describes. Lower case filename didn't work at all. All caps filename works rather consistently.

Might be good a idea to add that to the readme, as it took me file to look over the info in the wiki.

[awigen]

Hi @LongHairedHacker and @novirium,

Please try the flasher script and report any problems.

Cheers, Alex

[LongHairedHacker]

The flasher script won't work for me as I don't have sudo installed. Also my setup uses udisk to automount usb drives, which would likely interferes with the mount in the scripts.

In the end it doesn't matter since I can get it to flash fine without the script. The only problem was that the file name has to be all upper case.

[girst]

for me, the following worked (as root):

• mount -t msdos /dev/sdb /mnt
• cp $FOO/APPV217.hex /mnt/ts100.hex (note the destination filename)
• sync

then monitor dmesg -w for changes. it will likely show up as a different device file.

• umount /mnt
• mount -t msdos /dev/sdc /mnt (note: it changed from sdb to sdc)
• ls /mnt/ts100.rdy
• umount /mnt

[powercycle]

Using the above for me didn't work, Xubuntu 16.04. @awigen script worked without issue.

[radek-senfeld]

Hooray! I was so afraid and in the meanwhile it worked so flawlessly!

DFU 3.43

rush@jarvis:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
rush@jarvis:~$ uname -a
Linux jarvis 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Note that /dev/sde might differ on your system. Use dmesg to find out.

umount /media/<user>/<automount name>
sudo mkdir /mnt/flash
sudo mount -t msdos /dev/sde /mnt/flash
sudo cp /path/to/the/new/firmware.hex /mnt/flash/TS100_EN.HEX
sudo umount /mnt/flash

Voila!

Thank you so much! :-)

[powercycle]

Would anyone be willing to explain why the script is not needed in some cases? I'd love to understand the differences are between Arch Linux and Xubunu, as an example. I realize this is off topic, so might be better discussed somewhere else.

[MartinMajewski]

I just updated from stock firmware (haven't noted the version, unfortunately, but the iron arrived today from banggood) to the latest Ralim firmware (V2.02 - English). This update was done using my MacBook Pro 2017, running macOS High Sierra 10.13.2, as well as a USB-C to USB A, Ethernet and HDMI hub without any issues. Just followed the steps on the repositories' front site.

Thanks for the efforts and the great work. The TS100 is now super easy to configure and did already an excellent soldering job.

[i0y0]

Hi, I just wanted to share that I upgrade my new ts100 (brown) from my phone Lg g4 with otg cable. From stock firmware v2.12 to Ralim firmware v2.02-English with ES file explorer without any problems. Thanks Ralim :)

[grtyvr]

Confirmed that on Ubuntu 16.04 all you need to do is unmount the drive that gets automounted by the UI. Copy over firmware, sync, remount, and the firmware will be .rdy

[grtyvr]

And the script works too @awigen

Thanks!

[jonnieZG]

Adding this info to the Wiki Instructions would be nice.

[grtyvr]

Done.

[kortschak]

I have tried a variety of things on ubuntu 16.04 (4.4 kernel) to no avail. Following the advice above gives me this:

$ sudo umount /media/<user>/<mntpnt> 
$ sudo mkdir mnt
$ sudo mount -t msdos /dev/sdc mnt
$ sudo cp Hexfile/TS100_EN.hex mnt/TS100.HEX
cp: error writing 'mnt/TS100.HEX': No space left on device
$ ls -l mnt
total 5
-rwxr-xr-x 1 root root  218 Feb 14 14:06 config.txt
-rwxr-xr-x 1 root root 4096 Apr 11 16:34 ts100.hex

After this, the CONFIG screen remains and the TS100 does not reboot even after minutes waiting. The ts100.hex file persists over power cycling the iron.

The original firmware version installed on the TS100 is reported as "Ver:2.18" on the boot screen.

Any suggestions?

[Ralim]

If you are seeing "CONFIG" on your screen you're not booted into the bootloader for programming.

You need to hold the button near the tip when plugging it into usb, and the screen should show DFU.

Then try copying the file.

[kortschak]

Just tried the flash_ts100_linux.sh script with great success (mainly because it told me what you just did - thank you).

[lucasmr]

The script worked fine on Gentoo as well. Had to do a few tries on different USB ports, though.

[JayNaire]

Reporting total success with flash_ts100_linux.sh with MINT18/kde. That's a very elegant script especially the exit cleanup. Thanks @awigen ( and obviously thanks to @Ralim but that goes without saying!)

[Miwer]

The script needs modification to work on Mint 17.3/kde - otherwise it will wait forever for plugging the ts100

In line 40 the \\\\x20 needs to be removed, so the line looks like this: to: output=`lsblk -b --raw --output NAME,MODEL | grep 'DFU Disk'`

On my machine this is what is returned by lsblk -b --raw --output NAME,MODEL:

NAME MODEL
sdc DFU Disk        

Other than that - script works fine :)

[gonX]

I think the primary issue stems from Linux asynchronously making the file before it dumps the contents of it. If you see errors like FAT-fs (sdb): Directory bread(block 32) failed, chances are that's what happened.

Mounting the filesystem with -o sync seems to be a way to avoid this, ie.:

# mkdir -p /mnt/usb
# mount -t msdos -o sync /dev/sdb /mnt/usb
# cp TS100_EN.hex /mnt/usb/ts100.hex

[0ddjob]

Hi - another comment about loading this excellent replacement firmware (thanks @Ralim) via a Mac.

I initially tried it on my 2019 MBP (USB-C ports only). The TS100 was connected to a USB cable connected to a Thunderbolt display that was in turn connected to my MBP via a Thunderbolt-to-USB-C converter.

The TS100 showed up as a drive but continually returned an ERR file when dragging the file across.

Suspected the USB-C-to-Thunderbolt-to-USB path was messing it up somehow. I tried doing it via my Win7 VM (VMware Fusion) on the MBP but it didn't show up at all.

So finally just tried on my Mac Pro via a direct USB port ... no issues as reported by @sgr1ff1n

[pjz]

Just got my TS100 today and was able to flash it fine by doing manual mount/copy/unmount under Ubuntu 18.04. I don't have automount on, so looked at dmesg output to see which device it was showing up as. Two tips that I found very helpful, enough that they may need to be stressed more strongly in the docs:

1. Make sure you're plugged in directly to the computer. I first tried going through a USB hub and it didn't even show up as a block storage device at all.
2. Try, try again. It took me something like 4 tries to get it to take. After the first fail, I was worried until I read the docs that said it might take a few tries.

Thanks for the excellent firmware!

[Perlovka]

Hi, tried to flash my TS100 today. File becomes .RDY, but nothing is changed, same stock firmware 2.18. Tried both vfat and msdos. DFU 3.45

[fiechr]

The Linux flashing script doesn't seem to work anymore. I've also tried manually with the "sync" option mentioned above, but always get the .err file instead of .rdy

Any ideas?

System is Manjaro (Arch based) using Linux kernel 5.6.12 and Bash 5.0.16

EDIT: I tried a USB 2.0 port instead of USB 3.0 and it worked at the first try!

[whirm]

It's been a while since I updated my TS100 but the way I got 100% success rate was by doing it like this:

mount /dev/sd? /mnt/1 -t msdos &&  ddrescue -D TS100_EN.hex /mnt/1/ts100.hex ; umount /mnt/1