Can't flash the newest 2.15 EN firmware

[cleveHEX]

Describe the bug Can't flash the 2.15 TS80_EN.hex, any tried other language and they work (CS, DE).

Details on your device:

• Device: TS80
• Release: 2.15

TS80_EN.ERR.txt

[ricktendo]

Try flashing in Windows 7, or use the script to flash in Linux

https://github.com/Ralim/IronOS/tree/master/Flashing

./flash_ts100_linux.sh <hexfile>.hex

[Ralim]

Hia,

The most likely cause here is Miniwares DFU code not wanting to play along. Best advise is to flash under windows (with no mitm antivirus) or to use the double copy method on other OS's.

Given the firmware file works fine locally here and for other users the most likely culprit is your computer's interaction with their bootloader sadly.

[cleveHEX]

I have tried on both Linux and Windows, my DFU is 3.45, is there any newer? Will try on another computer too.

[Devnol]

Similar issue in macOS, it flashes but only like 10% of the time.

[Ralim]

There isn't a whole lot that we can really do. If you are technically minded and know what USB-DFU is, you can try loading the alternative bootloader that is over here. But if you dont know what your doing that may be more annoying as that will require you to use dfu-util for all flashing.

Otherwise only thing you can do is try and get the manufacturer to care enough to either fix or open source their bootloader.

Not really in the scope of this firmware sadly, and writing a re-implementation of their bootloader feels like a nightmare

[Devnol]

Yeah I see, I was just wondering if there is any known solution to this or whether you know exactly what is causing it to fail and how to mitigate it. All I see reading the Linux shell script is that you're manually mounting and unmounting the drive and using cp to copy the file, nothing I would consider special.

[Ralim]

The main thing as far as I know (still a guess) is that the OS must write every sector in order. any reshuffling of the data write order appears to break it.

So a lot of the "magic" that works for people is often using older and dumber drivers to mount with.

I do suspect some careful dd might work well but untested

[Devnol]

Hmm, but the weird thing is that flashing works sometimes and it fails others

[Devnol]

disk destroyer sounds like a good idea, I'll report back in a little

[Ralim]

I believe that is down to the host OS; most likely depending on how things are being buffered. This is really all guess work; but given older OS's work better than newer it feels like they built it around a lot of assumptions as to how the virtual disk was accessed

[Devnol]

dd'ing with a bs of 1b and no other special flags also yielded in an error so it appears it's something very low level

[Ralim]

I'm not really sure tbqh.

I could try capturing some logs of the bus but i dont have the time to really dig into that anytime soon :(

[Devnol]

Alright, thanks for your time anyway, if I do find anything interesting I'll report back. One last thing is do you remember the syntax needed for dfu-util to flash to the iron?

[discip]

@cewbdex Is this issue solved for you using the latest commit? If so please closing it. 😊

@Devnol There is a custom built DFU-Bootloader by @Ralim, which you might want to test.

[Devnol]

Oh, sorry this was left stale, iirc I got it working a little later by flashing the miniware fw and then ironos, which somehow fixed it.

[cleveHEX]

Flashing 2.17 EN works, so the can't fix can be removed too.

[Ralim]

Can't fix is because the root cause of this issue is not something I can really fix