Ralim
Ts101 unable to load firmware
Describe the bug I am unable to upload the firmware on a ts101 with usbc. I keep getting the ERR files after it reboots. This is with the EN version of the file. I tried the ES versions and it worked fine. Tried both builds and 2 different cables and computers
I have the same problem, only none of the languages work for me :( I have Windows 11
Under which operating system do you have the problem?
It was on windows 10
I confirm, I encountered the same problem. Neither stable nor dev are flashed. Windows 11 24H2.
I can flash the TS101_ES firmware, but the EN firmware always gives ERR.
Same. I can flash the TS101_ES firmware, but the EN firmware always gives ERR.
Windows 11 24H2
I think I found a solution (that worked for me at least): I'm using Windows 11 24H2 btw.
- Launch an Ubuntu 24.04 Virtual Machine (I use VMWare Workstation)
- If you have USB 3. X ports, change the USB controller of the VM to USB 3.1
- Connect the TS101 in DFU Mode
- Copy the hex firmware (you can use any language)
- If it gives ERR just try again, for me, it always worked the second time.
I use the stable version (2.22), most dev versions over that puts the TS101 on reboot loop (even the 2.23 RC1).
Thanks.
If anyone still have this problem, please, could you read & try advises and recommendations from these two links:
- general set of hints how to flash "more properly";
- confirmation that all files you have on DFU drive must be deleted before copying HEX firmware.
If nothing will help, there is not so much we can do. :(
On Thu, Jan 30, 2025 at 03:19:30AM -0800, Ivan Zorin wrote:
If anyone still have this problem, please, could you read & try advises and recommendations from these two links:
• [1]general set of hints how to flash "more properly"; • [2]confirmation that all files you have on DFU drive must be deleted before copying HEX firmware.
If nothing will help, there is not so much we can do. :(
One can always connect SWD (without a debug adapter it can be bitbanged with a raspberrypi or other SBC) and flash a sane bootloader (implementing real standard DFU class), right?
This constant wrestling with broken mass storage emulation tricks feels like a rather unnatural and joyless way to spend time.
One can always connect SWD (without a debug adapter it can be bitbanged with a raspberrypi or other SBC) and flash a sane bootloader (implementing real standard DFU class)
This is out of IronOS scope. But since we're here - do you know any 3rd party DFU bootloader with TS101 support?
right?
Not quite. Not when users just want to have an iron with IronOS without a need in learning how to use hardware debugging protocols to flash their irons. IronOS users may have very different backgrounds and interests, so getting a separate equipment and figuring out the wiring to connect to an iron to flash bootloader may be by far not ones of them.
This constant wrestling with broken mass storage emulation tricks feels like a rather unnatural and joyless way to spend time.
Not when a user at least tries to follow the recommendations. :/
On Thu, Jan 30, 2025 at 09:44:23AM -0800, Ivan Zorin wrote:
One can always connect SWD (without a debug adapter it can be bitbanged with a raspberrypi or other SBC) and flash a sane bootloader (implementing real standard DFU class)
This is out of IronOS scope. But since we're here - do you know any 3rd party DFU bootloader with TS101 support?
Judging by https://github.com/Ralim/IronOS-dfu/commit/c157229e1e8fb465a8abebd13ad7c7489885f7c9 I would expect it to be nearly trivial to add support for TS101 as well. Or am I missing some important detail here?
right?
Not quite. Not when users just want to have an iron with IronOS without a need in learning how to use hardware debugging protocols to flash their irons. IronOS users may have very different backgrounds and interests, so getting a separate equipment and figuring out the wiring to connect to an iron to flash bootloader may be by far not ones of them.
So probably what would be in scope for the project is developing a userspace libusb-based UMS+FAT implementation to reliably flash even when the extremely buggy Miniware bootloader has to be used? But even with that windows users will complain because nothing is easy there...
IDK, I think it's great when users get educated about things, connecting 4 wires and running a pre-made script shouldn't be that much of a burden, we're not talking about any exotic hardware or actual required knowledge here.
This constant wrestling with broken mass storage emulation tricks feels like a rather unnatural and joyless way to spend time.
Not when a user at least tries to follow the recommendations. :/
Over the time there were many conflicting recommendations (mount as "msdos", mount as "vfat" copy with this command, copy with that command, use Nautilus, use windows xp, use another port etc etc), none were really working reliably and there's no decent way to troubleshoot because it involves many layers of different kernels (different versions too) and userspace and that proprietary bootloader without any additional feedback.
I'd say the recommendation should be: if you try it and it works to flash IronOS-dfu "Runtime", great, lucky you, proceed to flashing everything proper. If it doesn't don't waste too much time, just connect SWD.
Judging by Ralim/IronOS-dfu@c157229 I would expect it to be nearly trivial to add support for TS101 as well. Or am I missing some important detail here?
Your link to the patch is about S99. TS101 support is on the way for a long time, but apparently as it turned out there are not so many TS101 owners who would like to help with testing & debugging, especially if something will go wrong.
developing a userspace libusb-based UMS+FAT implementation to reliably flash even when the extremely buggy Miniware bootloader has to be used?
This is one of those cases when effort < result.
IDK, I think it's great when users get educated about things, connecting 4 wires and running a pre-made script shouldn't be that much of a burden
Do you understand that your set of skills & interests is not a set of skills & interests of a user who just want to use a soldering iron with Iron OS, right? The world doesn't begin nor end in IT world, while soldering can be used in very different ways & areas.
I say this calmly and politely, because this is observable fact related to any project: in fact, modern users don't even check bug trackers for already opened & existed similar bug reports anymore at all, while some of the reports are looks like nothing more than "feature X doesn't work, please, fix it!" (literally). And you're talking about using hardware debug interfaces. The era when kids could make their own radio or calculator just by reading local magazines & books about electronics & hardware are over. For the record: I'm not complaining, just sharing observation from my perspective.
Over the time there were many conflicting recommendations [...]
I just provided what works for me & for other users (like that great discovery about deleting all the existed files first).
Anyway, it starts to look more like a general discussion on usenet :) Ironically, I understand that I'm part of the problem. So I'm posting this so you could read my reply, but in a little bit I will have to mark the replies from both of us as hidden here, since they do not have any relation to this #2014 issue at all. Thank you for understanding.
Same happened to me from Windows 11 24H2 (build 26100.4946), worked from latest macOS.
Didn't try _ES, only _EN.
Can confirm, I can't flash anything on my TS101 from Windows 1124H2, on two different computers. Or a Raspbery Pi 3b+ running Debian 12.
But I could flash just fine from WIndows 10.
This is insane. 😓
