Release 0.2 release bricked TS100 (originally v3.42)

[hugovincent]

Hi, I seem to have bricked my TS100 using release 0.2. I'm not sure what's gone wrong since everything seemed to proceed as in the instructions. I first installed runtime.hex using stock mass storage bootloader. It successfully booted with the IronOS logo and DFU v0.2 shown on screen. I then backed up the stock bootloader:

% sudo dfu-util -d 28e9:0189 -U backup.bin  -s 0x08000000:0x4000

Password:
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
Device ID 28e9:0189
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Upload	[=========================] 100%        16384 bytes
Upload done.

% md5 backup.bin 
MD5 (backup.bin) = cd1038179b3fda32e75d6f300d153cb3

That hash matches that listed for TS100 v3.42 in https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/BackUp.md#checking-your-bootloader-backup-is-valid so it looks good. Then I power cycled, then installed the DFU bootloader:

% dfu-util -D bootloader.dfu
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Match vendor ID from file: 0483
Match product ID from file: df11
Multiple alternate interfaces for DfuSe file
Opening DFU capable USB device...
Device ID 28e9:0189
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
File contains 1 DFU images
Parsing DFU image 1
Target name: ST...
Image for alternate setting 0, (1 elements, total size = 5384)
Setting Alternate Interface #0 ...
Parsing element 1, address = 0x08000000, size = 5376
Erase   	[=========================] 100%         5376 bytes
Erase    done.
Download	[=========================] 100%         5376 bytes
Download done.
Done parsing DfuSe file

Again, seems good (no errors, Download done. seen). At this point I power cycled the iron by unplugging and replugging it in, and it seems to be bricked. Any ideas? (I have an ST-Link and will make up a cable for SWD reflashing... I'm reporting as an issue in case there is a bug or doc improvement that could be made).

Thanks!

[Ralim]

Hmmm I'm not certain how this failed.
If you have the st-link; can you please try and dump your flash before you write the new bootloader.
Would be amazing to get a diff of the two to see what failed to be written to the flash.

[hugovincent]

@Ralim I finally connected up the ST-Link, and found that read-out protection was enabled. I disabled it using OpenOCD, and presumably as a consequence of that, the image read back blank (all 0xff). So, sorry, no clues.

[discip]

@hugovincent
Did you manage to get your TS100 to run again?

@Ralim
As you might recall I had a similar issue from the beginning. (exactly as @hugovincent stated above, except for the device being a TS80P)
And if I remember right, I had problems flashing it even using the ST-Link until I somehow removed some protection, unfortunately I am not sure what exactly it was! 😓
But none the less maybe I will be lucky enough to get the information you need from an TS80, if that is enough.

btw:

HW V1.2
DFU 3.50
APP 1.27

Open On-Chip Debugger
> stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff

Originally posted by @jamesturton in #9 (comment)

[hugovincent]

@hugovincent Did you manage to get your TS100 to run again?

Yes I did, it was fine after reflashing over SWD. (Or, it would have been if I didn't accidentally reassemble the MCU module the wrong way around, burning out diode D1. After replacing that, it works well again).

[discip]

@hugovincent

Great! 😃👍

Then it would be appropriate to close this issue. 😊

Thanks in advance!

[hugovincent]

@discip you're welcome to close it if you want of course; I would rather leave it open as the cause has not been identified or fixed.

[Ralim]

The most likely thing here is that your device had the flash protection level set for the first part of the flash, which means any attempt to write to that area will trigger a device erase. A bit tough to work around really though. Could try re-writing all of this to run from ram but that is a fair bit more effort.

[hugovincent]

Instead of running from RAM, could you add a check for the flash protection and abort the installation if it's set? That way at least it would fail safe.

[Devnol]

I just bricked my TS100 the same way, thankfully the stm daughter board is a 2.51A which from what I understand connects swd to the usb port, so I can probably easily connect to that. Could you please give me some rough instructions on how you went to flash back the bootloader to get the iron working? I don't have an stlink unfortunately but I do have a pi pico I could probably use as an swd debugger, if that's what's needed. Thanks in advance.

[Devnol]

Looks like I managed to get openocd working and connected with gdb, what do I need to do now to flash the bootloader back?

[discip]

@Devnol
I used the ST-Link solution, but I am not sure what exactly I did do to get it running back then.

All I know is that you need to flash the previously backed up bootloader and then repeat what you did before:
Copy the runtime.hex file and then the bootloader.dfu.

Sorry, but that's really all I can remember. 😓

I recommend waiting until @Ralim comes back from vacation. 😊

[Devnol]

Yeah first of all I didn't take a backup of my bootloader because I saw this issue and that I should've done so after the fact 😓 Can't I just flash the ironos dfu directly? I got openocd and gdb up and running, I just don't know what commands I have to run. I guess I can wait for ralim to return lol, but thanks a lot anyway.

[discip]

Does your TS80P run on a ST-chip?
Or is it GD?

[Devnol]

I have a TS100, uses an stm32fsomething.
Also check the ironos repo, I think I fixed the translation (had to open a new pr)

[discip]

Ah, ok?
The only devices I have at hand are a TS80P and a Pinecil_V1.
So you will have to wait than.

[Devnol]

That's fine, I'm not in a hurry to solder anything right now, I just can't believe how I played myself like a fool yesterday by overwriting my bootloader...

[Devnol]

Hey, looks like I managed to get the ironos bootloader on here with a little help from the voidstarlab discord, for future reference, I had to run openocd with the iron attached to my probe (in this case a pi pico) then, inside the folder where the firmware is get an openocd shell with telnet 4444 and run the following:

init
reset halt
srm32f1x unlock 0
reset halt
flash write_image bootloader.hex
flash verify_image bootloader.hex

then optionally repeat the same for the running firmware too.
So now I'm in the ralim dfu, what do I need to run to flash a new ironos image or boot logo?

[discip]

@Devnol
To flash the firmware:

1. Download the latest firmware,
2. unzip the corresponding xxx.dfu
3. and run for example:

   dfu-util -D TS100_EN.dfu   
   

To flash a boot-logo:

1. Download the latest release,
2. unzip the desired xxx.dfu
3. and run for example:

   dfu-util -D IronOS.gif.dfu   
   

[Devnol]

perfect, thanks!

[Devnol]

You should probably make a note on the docs that flashing the ironos dfu bootloader without unlocking the mcu first will cause it to erase itself and be bricked

[discip]

Is your iron up and running again?

[Devnol]

yep, I just wanted to change my fw to greek because I flashed the en one with openocd. In any case, should someone else accidentally brick their iron these should be the steps to fix it after getting to an openocd shell.

[discip]

You should probably make a note on the docs that flashing the ironos dfu bootloader without unlocking the mcu first will cause it to erase itself and be bricked

I'm sorry to disappoint you but since I don't have a deeper understanding of the matter I'll leave that to @Ralim instead of writing a note about things I don't understand thoroughly enough.

[Devnol]

Don't worry, I fixed mine lol. Just saying that you should probably warn people from now on to avoid this bricking again, you don't have to do it now and it doesn't need to be specifically you, just saying that ralim should make a note of that

[discip]

I got that.
Just needed to let him know. 😊

[Ralim]

There already is a warning in the docs that 3.45 onwards has this issue. Will update it to indicate some earlier DFU versions are also affected.

[tdrkDev]

+1 on this issue. I've bricked my TS100 with the same v3.42 DFU after flashing v0.2 bootloader. I've already ordered an ST-Link to repair it :(
The only good thing is that I've backed up stock bootloader according to the warning in docs.
I've not seen any warnings about this issue for old DFU firmwares in docs (https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/Bootloader.md), @Ralim, maybe I've read them careless btw

UPD: I've successfully repaired it after soldering st-link wires to small CPU board and flashing IronOS DFU after unlocking flash.

[kenblu24]

Managed to brick it as well after a seemingly successful bootloader flash, so I had to do it with ST-Link.

Didn't see a pinout for those pads for hooking the daughterboard up to SWD, so here.

Highly recommend probing and doing a continuity check using the image on the right before soldering to those pads. I am obviously not responsible if you break your iron even more.

Pinout on the right taken from GD32F103Tx QFN36 pinout on datasheet

1. Soldered thin solid core wires to the pads and put some female dupont headers on the other ends
2. hooked it up to a crappy ST-Link knockoff to program the IronOS-dfu bootloader.hex file (STM32CubeProgrammer didn't work, so I used the deprecated ST-Link software)
3. desoldered the wires, put the daughterboard back on the iron, connected via the micro-usb and saw it appear in a dfu-util -l
4. flashed the TS100_XX.dfu file using dfu-util
5. ???
6. profit

[Devnol]

Just as a side note for anyone else reading this, the above process is necessary for daughter boards older than v2.51A, as that added swd to the usb port, d+ being swdio and d- being swclk. In that case all you'll need is a usb breakout and a microusb cable, so if you don't have a second soldering iron it's no big deal.