search

Ralim / IronOS

Open Source Soldering Iron firmware
https://ralim.github.io/IronOS/
GNU General Public License v3.0
7.24k stars 718 forks source link

ts100 seemingly bricked #482

Closed et11haan closed 5 years ago

et11haan commented 5 years ago

I am having some troubles with my ts100. I wanted to see how updating it works, and tried dragging the bootup icon's .hex file over to the drive (in DFU mode) and it failed. I tried doing this a few more times, and then tried updating the firmware. It said file too large, and now fails to boot. When plugged in to the included DC power adapter, it fails to do anything. When plugged in to a computer, it fails to enter config mode. It does appear as a drive when holding the button close to the tip, and reads DFU: 3:45. It is recognized as a drive, but I cannot get any files on to it. I tried putting the stock firmware on, but it failed. Help!

et11haan commented 5 years ago

should I try deleting the files inside the virtual drive, to create space?

et11haan commented 5 years ago

sorry to be so quick to as, i got it to work just by trying it again. Strangely, it was my 3rd or 4th time trying. However, I still cant get custom firmware on it, as it says its too large. Solution?

Ralim commented 5 years ago

If it is saying that the file is too large, most likely you are not booted into DFU. There has been lots of discussion of this on different issues. Almost always it boils down to either software on your computer changing window's behaviour from default OR not being in the right mode OR bad usb cable OR bad usb hub

ThineTroll commented 5 years ago

So i got mine working by changing from USB 3 to a USB 2 connector. cant figure out why that matters but oh well

zanmoskotevc commented 5 years ago

Just had the same issue and I also resolved it by switching to a usb port in the back that was 3.0 Maybe add that to the README

dzalf commented 5 years ago

Guys. I just want to confirm that the USB cable is REALLY important.

Symptom: The TS100 bricked after several intents for copying the file. Unit bricked after that. Dead.

Here's how my case developed with the faulty cable:

  1. I entered into DFU (3.45) pressing button A. Windows 10 recognised it as a 1.95 MB disc drive
  2. I dragged and dropped the hex file into it. Here's where the issue happened:

The TS100 disconnected itself from Windows before the file transfer completed.

I tried different ports (USB 2.0 and USB 3.0 back and front) without success.

Strangely this USB cable is my favourite one. I do Arduino/Teensy/PIC programming on a daily basis and the cable has ALWAYS worked like a charm.

SOLUTION:

I used another crappy cable that I found on a drawer. I connected the TS100 to a back USB 3.0 port and voila. The file was successfully transferred and the unit came back to life. Happiness.

I must point out that the cable that made the trick was shorter (about 15 cm) vs the other faulty cable that is ~1 m. I insist: the first cable is my daily driver for programming Microcontrollers and it still works. i just tested it with a fast serial communication with no problems.

Moral of the story: never trust your trusted cables.

Thank you @Ralim for this amazing firmware!

I'm inviting you a :beer: for sure ;) (for real. I'll go right away to the donation page)

dzalf

😎

Ralim commented 5 years ago

A big component as to why these units are so picky is a small cost saving that Miniware did.

They are running the STM32 off the internal 8MHz oscillator, which does not meet the tolerance requirements of USB. ST's tools wont let you generate code for the USB port while you have it to set to the internal oscillator as its known to be out of spec. Newer microcontrollers support a feature where the STM will align its internally oscillator to the USB port messages, but the F1 series does not support this at all.

some USB hubs are ok at dealing with the TS100 when its out of tolerance and will clock match and be fine (typically Intel ones). However, some others will just drop the USB connection entirely.

Using shorter cables most likely increases the tolerance on the timing / propagation of the data (I'm guessing).

dzalf commented 5 years ago

A big component as to why these units are so picky is a small cost saving that Miniware did.

They are running the STM32 off the internal 8MHz oscillator, which does not meet the tolerance requirements of USB. ST's tools wont let you generate code for the USB port while you have it to set to the internal oscillator as its known to be out of spec. Newer microcontrollers support a feature where the STM will align its internally oscillator to the USB port messages, but the F1 series does not support this at all.

some USB hubs are ok at dealing with the TS100 when its out of tolerance and will clock match and be fine (typically Intel ones). However, some others will just drop the USB connection entirely.

Using shorter cables most likely increases the tolerance on the timing / propagation of the data (I'm guessing).

Dear Ralim

I believe that your (highly) educated guess is very plausible. Timings on serial communications are crucial and long transmission lines absolutely have an impact on the communication.

Fortunately we're narrowing down the causes of failure. 😉

Kudos for your work

Cheers 🍺

dzalf

dickysoe commented 2 years ago

A big component as to why these units are so picky is a small cost saving that Miniware did.

They are running the STM32 off the internal 8MHz oscillator, which does not meet the tolerance requirements of USB. ST's tools wont let you generate code for the USB port while you have it to set to the internal oscillator as its known to be out of spec. Newer microcontrollers support a feature where the STM will align its internally oscillator to the USB port messages, but the F1 series does not support this at all.

some USB hubs are ok at dealing with the TS100 when its out of tolerance and will clock match and be fine (typically Intel ones). However, some others will just drop the USB connection entirely.

Using shorter cables most likely increases the tolerance on the timing / propagation of the data (I'm guessing).

Hi Ralim. I also experiencing the same issue with my sq001. Is there anyway around it? Does opening up the device and use stlink work?

Ralim commented 2 years ago

Yes you can use the SWD programming pins if you wish. You can just load the hex file as per normal and that should work.

You will need to leave the bootloader intact at the beginning of the flag so make sure you don't erase it

If you are going to the effort of getting out a programmer you might want to try the DFU alternative bootloader.