Problems downloading firmware from forum

Continuing the discussion from (Teletype) CHAOS:

something is happening to uploaded .hex files making it hard to flash them after download. for example:

for one, safari is adding .txt extension due to missing MIME-type. but removing it doesn’t help. (here is a link to satck overflow discussing that behavior.)

i’m sorry i don’t have TT hardware to test this and can only look at the file.

it looks like the server (i assume) is converting line breaks to CRLF on upload. that shouldn’t be an issue, intel-hex format allows it, but maybe the TT upload script expects LF only. so maybe try converting the line breaks.

the data still looks like ASCII UTF-8 ( ‘:’ = 0x3a and so on.)

so i don’t know why else the upload script would fail with this file. hopefully someone else can take a look.

What’s odd is that I am able to flash the files without any issue after downloading from Safari, in spite of the renaming and extension adding issues mentioned above. So I’m confused about what the problem might be with regard to flashing the firmware.

then might i humbly suggest that maybe @Leverkusen double-check his USB cables, MMC devices and so on (its happened to me plenty of times)

Might be a good idea to zip the files in order to keep the forum or browser from trying to interpret them as anything else.


My USB cables are fine. I got error messagges on the apple coomand line thingy.

I then installed firefox and it tried to save the files as .txt too but could be prevented to do so and name it .hex.

Flashing worked fine then but definitely did not when using Safari and just rename the file. Comparing the original unpacked .zip file from tt 2…1 and the renamed downloaded one from the chaos thread also showed that the file icons do look different. The new one stays a text file when it is renamed as a .hex file.

Just wanted to chime in that I have experienced similar problems when trying to flash firmware on a different module with files downloaded via Safari.
Using .zip for transferring files solved the problem.
I would suggest this as a practice for sharing .hex files here.
IF possible of course.

1 Like

ok thanks! appreciate it.

so. here’s an interesting thing. querying the file UTI on macos:

downloaded with safari:

> mdls -name kMDItemContentTypeTree test-safari.hex 
kMDItemContentTypeTree = (

downloaded with firefox:

> mdls -name KMDItemContentTypeTree test-firefox.hex 
KMDItemContentTypeTree = (null)

(besides that, i cannot detect any difference in how the OS sees these files.)

so macos has, by some evil magic, created a UTI association between the file downloaded with safari, and a specific file type. (note that this is not a property of the file itself, they are bitwise identical… which is IMO the ‘evil’ part.)

i assume that this “feature” is recently added to macos/safari, or something.
my safari:
Version 11.0 (12604.
my macos:
sierra 10.12.6

the outstanding question is… why the f does the flasher script care about the filetype, as defined by macos UTI? and here i must call a halt to my part in the investigation, having zero experience with that area.

anyways yeah, the workaround is to .zip everything. but its a curious thing that is perhaps worth being aware of. ( perhaps @tehn in particular would like to be aware.)

and maybe i should just say, i guess when i get into “tech mode” maybe it comes off brusquely. and as it happens i have a current professional interest in this (macos item type codes on arbitrary downloaded data files.) i don’t mean to be critical but just trying to cover bases. like you, i spend time on lines for fun and community, and don’t mean to be rude.

Just an FYI for an devs.

If you type make release in the root directory of the Teletype check out, it will spit out a zip file with the firmware, flashing scripts and documentation in it. You do need Latex et al installed though.