Cannot see custom logo on TS101

[johncohn]

Describe the bug Can't load custom logo on TS101

To Reproduce Steps to reproduce the behavior:

1. Successfully installed IronOS on TS101.. by following directions here ie, pushing button closest to tip, plugging in to Mac using USB-C and copying English version of ST101 into the mouted TS101 device. verified it was function.

2. Following directions here to generate logo

3. Downloaded stuff from repo IronOS-Meta

4. cd to Bootup Logos

5. created 96x16 BW png file of logo

6. Tried 'python3 img2logo.py -P test.png smurphysiron.png out -m ts101' and validated that my image test.png looked ok

7. Tried 'python3 img2logo.py smurphysiron.png out -m ts101' which created the following files which did not match the expected outcome of creating hex files in subdirectory out

-rw-r--r--   1 johncohn  staff  11550 Jun 13 09:07 outsmurphysiron_L.png.hex
-rw-r--r--   1 johncohn  staff   1333 Jun 13 09:07 outsmurphysiron_L.png.dfu
-rw-r--r--   1 johncohn  staff  11550 Jun 13 09:07 outsmurphysiron.png.hex
-rw-r--r--   1 johncohn  staff   1333 Jun 13 09:07 outsmurphysiron.png.dfu

8. copyied "outsmurphysiron_L.png.hex" onto mounted TS101, un plugged and replugged TS101 into a dc usbc charger. IronOs came up fine, but no sign of my logo
9. tried the same with "outsmurphysiron.png.hex" . again no logo

Expected behavior I expected to see my custom log , but did not.

Details of your device:

• Device: [TS101]
• Release: [eg TS101_2.01.hex]
• Power adapter being used: Apple USB-C charger
• If this is an accelerometer related issue, please include its model number here:

Additional context Trying to get this done for a gift tomorrow :-) Thanks for all you've done here ! Note also posted on discussions here

[johncohnvt]

Any ideas on this?… I have successfully created logos using the python code in the IronOS meta-repo… But when I load them, I only get .ERR

Any help would be much appreciated -jc

[StevenSeifried]

Any ideas on this?… I have successfully created logos using the python code in the iOS meta-repo… But when I load them, I only get .ERR

Any help would be much appreciated -jc

Are you uploading under Windows or Linux? If Linux, try Windows

[johncohn]

Thanks Steven - I'm using Windows 11... (though I haveve both Mac and Ubuntu as well)

[Arbut-himself]

Can confirm same exact issue on V2.22E.C308FE8C.

[Ralim]

Eugh, getting .ERR means the TS101 bootloader is being a pain. What DFU version does it say when you put the device into bootloader?

[Arbut-himself]

1.05 DFU version. Just to be clear it's flashing correctly and showing .RDY not .ERR after flashing. Not sure if related, but the default Miniware logo that shows up is not affected by boot logo duration setting and always shows up for <1s even if set to Off.

[reversr]

Eugh, getting .ERR means the TS101 bootloader is being a pain. What DFU version does it say when you put the device into bootloader?

I have the same issue. DFU is 1.05, I've downloaded the latest version of IronOS from Github. I tried different commands which lead to the same result - the firmware is being created and it works - everything except the image: python img2logo.py -M TS101_RU.hex 1.bmp TS101_Merged.hex -m ts101 or python img2logo.py 1.bmp i -m ts101 --merge TS101_RU.hex

I tried different languages, and seem to try almost everything I could only think of. Every command creates 2 files with .hex extension and 2 files with .dfu extension. I tried copy each file to the TS101 while pressing A button before connecting the cable. The result is the same it remounts the drive with .RDY file. IronOS works perfectly - but no image. This is a present, and I would really appreciate if someone can help or point what am I doing wrong, please? Thank you in advance!

[ia]

Here is the very important thing to understand - first of all, technically this is not IronOS bug: obviously, there is some problem in built-in dfu loader made by Miniware, flashed on a factory by Miniware (or their subcontractors) for a soldering iron produced by Miniware (or what's their another name for today). There is no any way we could even possibly fix it.

Second, I have older model myself - TS80P - and I heard a lot of flashing problems there too, but I did not have not a single one myself (crossing fingers), whether it's gif or png. Why? Because when you flash, you should do everything by the book. Or at least, please, report detailed report. But some of these reports do not contain even the name of the operating system (I'm talking in general, not even about this particular issue). Which OS do you use? If it's *nix/mac-based, what is mount output when dfu storage is mounted (yes, that's important to), how do you copy - drag'n'drop or cp image.hex /mount/point, I even noticed that in some comments here hex/dfu files are mentioned in plural...

Anyway, here is the rules which I follow and do not have problems with flashing logos:

• DO NOT COPY MORE THAN ONE FILE;
• DO NOT COPY RANDOM FILE ONLY BECAUSE PREVIOUS DOESN'T WORK;
• after you generated files, pick only one which you really need (let's use the names from the original report): outsmurphysiron_L.png.hex or outsmurphysiron.png.hex, let it be the latter;
• RENAME IT TO HAVE THE SHORTEST NAME POSSIBLE WITH .HEX EXTENTION, ALL CAPS: cp outsmurphysiron.png.hex FW.HEX
• if you're on gnulinux:
  • disable any automount - in gnome or mate it's only these two commands: $ gsettings set org.gnome.desktop.media-handling automount false; gsettings set org.mate.media-handling automount false;
  • plug-in iron holding the button for dfu mode;
  • detect attached block device using dmesg;
  • mount the dfu storage USING msdos file system module, not vfat: $ sudo mkdir -p /mnt/dfu && sudo mount -t msdos /dev/sdXN /mnt/dfu;
  • copy hex file to the directory: $ cp -f FW.HEX /mnt/dfu/
  • flush the cache, wait for a couple of seconds, unmount disk: $ sudo sync && sleep 3 && sudo umount /mnt/dfu
  • DO NOT UNPLUG NOR TOUCH ANYTHING, now iron tries to flash itself & reboot, wait for ~5 seconds;
  • verify the flashing: find block device in dmesg again, mount it again, and check /mnt/dfu for FW.RDY file (if ok) or for FW.ERR (if not ok).

I flash in gnulinux environment, works for me. Flashed in Windows 8 once, it went good either. Sorry, but we can't help with the detailed instruction for every OS or environment... not a sarcasm, I really wish to help but not sure how. I guess the main takeaways:

• do not copy more than one file at a time;
• you need hex file, nothing else;
• rename file before uploading to two-three letters name + .HEX, ALL CAPS LOCK;
• try to use legacy msdos file system module in your system if possible;
• do not trust automount/autoplay mechanics - they mess with dfu FAT storage badly (for example, macOS just loves to create .DS_Store meta file on every single attached & discovered storage and volume... where is the chance that it's not messing with DFU? Sorry, but we don't have so much time to debug all these 3rd party madness nuances.

Oh, and of course, do not forget to turn the logo feature on in the settings. ;)

[ia]

Dear @johncohn, @Arbut-himself, and @reversr. Please, try to follow the advises & recommendations from the previous comment, and read it very carefully.

If it will be helpful - good, if not - it's really hard and nearly impossible to tell what else you should try, sorry.

[johncohnvt]

Ok thanks ! I will try this method

-jc

[resistancelion]

• where is the chance that it's not messing with DFU? Sorry, but we don't have so much time to debug all these 3rd party madness nuances

Android's one loves to mess to, while i was succesfull to flash TS101(DFU 3.50, IronOS 1.05) from my phone, i cannot longer do it, and now it have folders : .fseventsd, .Trashes and a 4kb file ._.Trashes. & I can no longer flash or open it from phone for whatever reason. Flashing under Windows 11 (x64, usb 3.2 controller) works no problem, same with TS100(DFU 3.45)

[ia]

Android's one loves to mess to now it have folders : .fseventsd, .Trashes and a 4kb file ._.Trashes

I'm not sure about all of them, and this is quite off-topic, but .fseventsd is leftover from MacOS FSEvent API daemon (background service) fseventsd, so it's not from Android.