Teletype v1.1 Issue with USB flash drive scene read/write

tehn · 2017-03-05T18:06:27.925Z

it’s more of a code structure issue-- it was easy to hack in a startup routine to detect for a usb disk. having a persistent detection and a modal switch isn’t difficult, it’s just a bigger job than a task that can be wedged between other rapid tasks.

i’ll make sure this gets taken care of soon, but “soon” is unfortunately weighed against all of the other feature requests and needs, ah.

jasonw22 · 2017-03-05T18:09:53.781Z

tehn:

weighed against all of the other feature requests and needs, ah

I don’t know how you juggle it all.

wolfgangschaltung · 2017-03-05T19:01:13.057Z

Thanks much for the answer, good luck with all the task…and thanks so much for doing all this!

Leverkusen · 2017-03-05T19:20:21.458Z

Oh, does that mean it is not possible to save/load before updating teletype at the moment?

barksten:

I did an update to 1.21 tonight and I can’t load the default 1.0 presets.When I power with the USB (FAT-32 formatted and the default tt??.txt files) nothing special happens. It just starts as normal.No files ending with ‘s’ get written to it either.

trickyflemming:

I’m having trouble with this again. I can’t seem to get 1.4.0/1.4.1 to read/write.

trickyflemming:

From what I can tell, it seems that Teletype is booting faster than it did when using the “delay” firmwares which worked for me. Am I imagining things? Is it possible that it’s failing now that I have more i2c devices connected somehow?

tehn:

this is possible, yes.

the usb import/export needs to be rewritten in general, to do the operation whenever a usb disk is detected, hence avoid this whole startup wait thing. let me see if this might be something i can flip quickly

JohnWynberg · 2017-03-05T19:40:55.003Z

I just realised there have been some updates since 1.1, but I’m too afraid to mess up things with my TT. For me, it’s not a big deal for now, since Ansible doesn’t seem to be available in Europe. I would like to try Just Type, though, but if that means I would be back to no being able to export/import scripts, I prefer to stay on 1.1.

tehn · 2017-03-05T19:43:07.847Z

1.1 can export scripts. you may need to try a few different flash drives.

also just type is pretty unstable presently, but @Galapagoose will soon have a v1.0 ready soon

JohnWynberg · 2017-03-05T20:15:29.159Z

Yes, I know. With the delays you introduced, it works for me, with some flash drives. That’s why I’m not updating TT anymore.
How difficult is it to add the same reading and writing delays to the new updates (1.2 to 1.4)? Can’t those lines just be copied and pasted? Or perhaps you could point out where and how we can add them ourselves in the code, so we could try different delays until we find the best ones that work for us?

wolfgangschaltung · 2017-03-05T20:58:51.141Z

It’d be awesome If adding the delays back into the code would do the trick!

sam · 2017-03-12T17:26:37.910Z

This has stopped working for me too.

I’m trying to figure out why… I’m wondering if we can try and narrow down which versions the USB read / write is definitely working.

There is a funky trick using the git source control tool that can help you figure when a particular bug was introduced. But in order to use it I need to know the most recent known working version.

trickyflemming · 2017-03-12T18:38:44.983Z

This is a pretty serious issue for me. Right now, I have a blank Teletype as I updated the firmware to work with the Telex modules. I don’t want to write any new scenes if there’s not a stable way to backup my progress.

My two options at the moment are to downgrade the firmware and not use the expanders or wait until this gets figured out, neither of which are pleasant options.

scanner_darkly · 2017-03-12T19:05:07.332Z

fwiw - just tried it again, no issues here using the latest TT version and an old Kingston 8gb stick, so sounds like it didn’t just stop working, but got less reliable.

sam · 2017-03-12T19:08:47.578Z

1.4 or 1.4.1?

Grrrrr. I think I’m just resigned to having to yank my Teletype from my main case and bring it over to the computer for a serious debugging session.

scanner_darkly · 2017-03-12T19:11:27.108Z

1.4.1+ (the latest official 1.4.1 plus the 2 remote commands i added that have been merged to master)

Leverkusen · 2017-03-12T19:18:23.427Z

Ah, that’s good to know - so there is hope and we just have to quest for the magick stick…

sam · 2017-03-12T19:28:15.826Z

I’ve tried both my USB sticks. At least one of them definitely used to work.

Others on this thread, is that your experience too? Sticks that used to work have stopped working?

trickyflemming · 2017-03-12T19:31:42.238Z

Yep. During the first go-round, I tried 5 different sticks that I already owned, none of them worked. Purchased one recommended by @tehn, still didn’t work. None of them worked until the test firmware with the load delay. Now I’m back to all of them failing again.

sam · 2017-03-12T19:45:07.861Z

Just out of interest, did they all start working with the delay?

scanner_darkly · 2017-03-12T19:45:33.964Z

the latest firmware should have the delay fix included. perhaps we could try increasing it and see if that makes a difference. @sam - do you want to give it a try?

this is the commit that introduced the delay and retries:

github.com/monome/teletype

cleanup

by tehn on 01:20PM - 29 Mar 16 UTC

changed 3 files with 15 additions and 39 deletions.

sam · 2017-03-12T19:52:52.338Z

I think I’m going to try a git bisect, I’ve never actually used it anger before, so it’ll be a learning experience

My USB stick didn’t work at first, then started working with the delay fix, and has now stopped. I’d like to get to the bottom of it. Looking at the code, I have a suspicion the issue may be a change in libavr32, but hopefully I’ll be able to nail down an exact commit with bisect.

sam · 2017-03-13T09:38:00.563Z

9:36am
First bit of good news… v.1.21 works, v1.3.0 does not. Let’s bisect!

9:45am
The results are in!

dfc5827cf6bd90824eab3279b1507852d5305c5e is the first bad commit
commit dfc5827cf6bd90824eab3279b1507852d5305c5e
Author: brian crabtree <tehn@monome.org>
Date:   Thu Dec 8 17:12:07 2016 -0500

    new ii ansible ops

:160000 160000 93241edf5eeb40b839ddf162c76d1aebce9f602c e189811766ad4e8d7b2721b232117a7be3940943 M	libavr32
:040000 040000 add2c6c5adab9a0e2667d211305be95c0fa8ee31 34839d4f174f735c97142791fff4d8e401eb0524 M	module
:040000 040000 e2e134bb6a329a3dbef2fe552e7dac15da82e117 41c9a97c07c8514920abfadad0a895d63e2ecb43 M	simulator
:040000 040000 cac5d6827f5d8f7ae3df47610c66750afbbf9a14 d6acf1f429d9db75564ff7b441faac6590b74afc M	src

github.com/monome/teletype

new ii ansible ops

by tehn on 10:12PM - 08 Dec 16 UTC

changed 9 files with 593 additions and 35 deletions.

As suspected, I think the issue is within libavr32. I’m going to try and bisect in there…

10.04am
Getting kinda of weird…

1f20226ed81ecb40e5bbaa46b2ba5b8109f3c557 is the first bad commit
commit 1f20226ed81ecb40e5bbaa46b2ba5b8109f3c557
Author: brian crabtree <tehn@monome.org>
Date:   Fri Dec 2 10:00:55 2016 -0500

    disable uhi_midi debug prints

:040000 040000 06d4f5bf4646b1252e4ba6c0ed93ac94a44a9726 a87d7b1b214bc0ad91b47cd0b6b74ad46eaaefb9 M	src

github.com/monome/libavr32

disable uhi_midi debug prints

by tehn on 03:00PM - 02 Dec 16 UTC

changed 1 files with 1 additions and 1 deletions.

10.07am
So… if I make the following change in libavr32, the master branch reads and writes USB sticks properly:

diff --git a/src/usb/midi/uhi_midi.c b/src/usb/midi/uhi_midi.c
index 25278b6..8a7f552 100644
--- a/src/usb/midi/uhi_midi.c
+++ b/src/usb/midi/uhi_midi.c
@@ -21,7 +21,7 @@
 #include "usb_protocol_midi.h"
 #include "uhi_midi.h"

-#define UHI_MIDI_PRINT_DBG 0
+#define UHI_MIDI_PRINT_DBG 1
 #define UHI_MIDI_TIMEOUT 20000

 // looks like we need to get class-specific endpoint descriptors,

Looking through the code, there is no reason why it should make any such difference. My suspicion, is that all the extra debug printing is in effect an increase to the delayed start up. Time for a break, then I’ll test my theory.

10.33am
Aaarrrgggghhhhh. Delays seem to make no difference, even adding a 5s predelay. Nothing. But when I re-enable UHI_MIDI_PRINT_DBG. Everything works.

Paging @ngwese, any ideas?

I’m going to fiddle with uhi_midi.c and see if I can figure out what’s going on in there…

10.52am
My descent into insanity continues… removing all the midi code from the Teletype does not fix the problem.

12:37pm
I think I’ve got to the bottom of it. Basically the logic in tele_usb_disk is a bit wonky. Enabling the midi debugging code, fiddles with the timing somehow and makes it work. I’m trying to tweak it to get it working. But my Teletype is on the floor next to my desk and bending over constantly to change USB cables is getting tiring… time for a lunch break.

12:58pm
Last entry. Fed up of bodging code. I’m going to park this for a few days and then do it properly. I’ll start posting some 2.0 beta hexes in the next few days and I’ll make sure that I use the UHI_MIDI_PRINT_DBG hack to get flash drives working.