Closed et11haan closed 5 years ago
should I try deleting the files inside the virtual drive, to create space?
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?
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
So i got mine working by changing from USB 3 to a USB 2 connector. cant figure out why that matters but oh well
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
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:
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
😎
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).
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
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?
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.
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!