Ironos: ts100 seemingly bricked

[et11haan]

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]

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

[et11haan]

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]

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]

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]

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]

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]

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]

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