[SOLVED via WinPE] TS101 DFU v1.06 rejecting all firmwares (ERR/NOT) and custom BMP logos – New hardware batch

[deadofgamers1999]

Device Details

• Device: Miniware TS101
• Factory Firmware: v2.11
• Bootloader Version: DFU v1.06 (Brand new unit)

---

Problem Description

I recently purchased a brand new TS101 for fine mobile phone repair work. The device came with the new DFU v1.06 bootloader, and it refuses every firmware update attempt and custom BMP logo customization.

Since I work in smartphone repair, software flashing and firmware operations are routine for me. However, this new bootloader revision completely blocks USB flashing across multiple platforms and tools.

---

What I Have Already Tried (Detailed Troubleshooting)

1. Firmware Update (Official v2.20 & IronOS):

   • .HEX files: Copying standard .hex files (attempting to update from factory v2.11 to official v2.20, as well as IronOS) results in an immediate renaming to TS101A~1.ERR (or FW.ERR).
   • .BIN files: Copying .bin files produces a .NOT file on the drive dismount. Upon rebooting, the device completely ignores the flash and boots right back into factory v2.11.

2. Cross-Platform / Method Testing:

   • Windows: Normal File Explorer drag-and-drop, Command Prompt (CMD), and PowerShell.
   • Linux: Flashing via Zorin OS (to eliminate modern OS hidden metadata/indexing issues).
   • Result: Failed on all systems with the exact same error behavior.

3. Custom Boot Logo (.BMP):

   • Created standard 1-bit monochrome .BMP files in both 96x16 and 128x32 resolutions (e.g., LOGO.BMP / LOGOM.BMP).
   • Attempted placing the files into the root directory during normal USB boot mode AS WELL AS in DFU mode.
   • Result: The iron completely ignores the files upon startup; the boot logo remains untouched.

---

Additional Context & Hardware Situation

• Goal: My main objective is to customize the display interface and flash IronOS with the Hungarian language interface.
• ST-Link Availability: I do have an ST-Link V2 on hand and could technically wire up to the SWD pads (fine soldering is part of my daily job). However, since this is a brand new unit, I strictly do NOT want to open the casing or solder to the PCB right now to avoid voiding the warranty.

Is there any known header change, checksum requirement, or vector table offset update specifically for DFU v1.06 that would allow USB flashing without hard-bricking or opening the iron?

When can a new IronOS release be expected that will include a fix or support for these DFU v1.06 issues?

I must admit I'm a bit disappointed, as I've been eyeing this iron ever since it was released and kept postponing the purchase. Now that I finally bought it, my very first idea was to completely customize it :D Well, that didn't go as planned :/ On the other hand, it really is a beast of a little machine and heats up insanely fast! :D

Thanks in advance to Ralim and the team for your hard work on IronOS!

[deadofgamers1999]

[Ralim]

Hello, im sorry to hear you have had this issue. Unfortunately im not going to help much here as we don't have much information on their dfu system.

The best thing you can do is contact miniware especially as you can't even update the official firmware. They seem to downplay issues with their bootloader setup which makes this a frustrating endeavor sadly. While in a potential return window I would do what you can to get it replaced. If that doesn't work and your "stuck" then we can talk about potential ways to dump/replace the bootloader. Dont connect an st-link until last as they set the memory protection bits now so a lot of tools will do a full erase by default.

I can't think of anything that you haven't tried at this point off the top of my head. It does seem that miniware keep using different stm32 clones each batch and some are worse than others. (Or maybe their DFU has more bugs, not sure).

I did notice in the past their dfu was very fussy about the order and location in the virtual fat filesystem that the file gets written. At one point in the very past I spent a while testing around with this and had some success with older windows versions instead of newer ones. Though these past ~6 years I no longer have a windows machine to test as the while fleet is Linux of some form. For all the Linux machines I always need to copy the file 2-3 times onto the device before ejecting and that has "worked".

[deadofgamers1999]

Flash Success via WinPE + Display Issue on TS101 PCB V1.51 (DFU v1.06)

Hi @Ralim and team,

I wanted to share a major breakthrough regarding the flashing process for the new TS101 PCB V1.51 running Bootloader DFU v1.06, as well as a hardware display compatibility finding.

---

1. How to bypass the FW.ERR / .NOT issue during flashing:

Standard OS environments (Windows 10/11, macOS, and Linux distros like Zorin OS) fail to flash IronOS on DFU v1.06, generating FW.ERR or .NOT files. This is due to background OS indexing and metadata files created on the virtual USB drive.

Solution:
Booting into a clean WinPE environment (specifically Hiren's BootCD PE / Live USB) completely solved the flashing lockout!
Because WinPE does not write hidden background metadata/indexing files, copying the IronOS binary in this clean environment was 100% successful and accepted by DFU v1.06 without any error files.

---

2. Post-Flash Issue: Garbled Screen (Display Driver Mismatch)

While the firmware boots up and the iron functions in the background, the OLED screen output is completely garbled / scrambled (glitched pixels across the display).

• PCB Revision: TS101_V1.51
• Bootloader: DFU v1.06
• Behavior: IronOS is running, but the display controller/initialization sequence on this new V1.51 PCB seems to differ from earlier TS101 revisions (likely a new OLED driver chip or modified I2C address).

If needed, I can provide high-resolution photos of the V1.51 PCB components or assist in testing a fix/beta build for this display driver issue!

Thanks for all your hard work on IronOS!

[deadofgamers1999]

I confirmed both methods failed:

IronOS (img2logo.py merge): Merging a proper 128x32 1-bit monochrome logo into TS101_FullOLED.hex results in a scrambled/corrupted screen upon boot. Flashing the clean TS101_FullOLED.hex back immediately fixes the display. It seems img2logo.py overwrites the display driver init required for the V1.51 OLED.

Stock Firmware: On stock firmware (v2.20), copying LOGAIN.BMP / LOGOM.BMP (tested all upper/lowercase variations) to the root directory and booting with the A button held is completely ignored by the bootloader.

Hopefully a fix can be found for merging custom logos without breaking the V1.51 OLED driver!

[arlenko]

@deadofgamers1999 I had the exact same display issue and got it fixed. The thing is that I use IronOS on my custom soldering iron controller for JBC tips. If you could assist me with testing the firmware on your TS101 we could attempt to find a fix for it.

UPD: Actually, check the #2063 discussions. There's a link to IronOS fork which seems to have it fixed.

[deadofgamers1999]

Just yesterday I finally managed to get it working with the Full OLED version from another repo:
https://github.com/vtolvr/IronOS-TS101-FullOLED
I also replaced the boot animation logo (which was quite a struggle 😅). Honestly, when I decided to buy a programmable soldering iron, I didn’t expect it to be this much of a pain 🤣
I had to recompile the entire source code...
For the boot logo editing, I had to modify the /Core/Drivers/BootLogo.cpp file.
I used the Image2CPP website, where I uploaded a 128x32 pixel 1-bit image and converted it into code with these settings:
Code output format: Arduino code
Draw mode: Vertical – 1 bit per pixel
Then I asked ChatGPT to help me generate the complete bootlogo.cpp file (since I’m not really into coding 🤣).
After that, I compiled everything — and now it works perfectly 👌
In the end, it was totally worth it — I even managed to install my own custom language 👌
Also, after a lot of testing, I found out that the firmware wouldn’t flash properly on Linux or even on Windows 11.
So I had no choice but to run Windows 7 — and there it updated instantly without any issues.

[deadofgamers1999]

[0Karakurt0]

@deadofgamers1999 can you post lsusb -v of the iron? Maybe there is something to differentiate it...

Also,

This is due to background OS indexing and metadata files created on the virtual USB drive.

that is not valid on Linux in general case. Although some file managers do similar stuff, you can easly avoid it by manually mounting the drive.
Have you tried flashing with scripts/flash_ts10X_linux.sh?