#39

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.

#40

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

1 Like
#41

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?

1 Like
#42

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

#43

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.

2 Likes
#44

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.

1 Like
#45

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.

2 Likes
#46

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.

#47

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

1 Like
#48

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

:slight_smile:

#49

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?

#50

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.

#51

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

#52

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:

#53

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 :stuck_out_tongue:

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.

2 Likes
#54

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

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

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.

7 Likes
(Modern) C Programming Tips and Tricks
#55

valiant effort, thank you!

my intention is to scrap the existing usb disk code, and have an event for usb disk insertion instead, whereupon tt will pause and do the disk op (and write status to screen)

hopefully we avoid delays entirely then

also, i am in mexico with no computer power supply accidentally and typing on my phone is not something i am good at. back to work in a week.

#56

I actually got that to kind of working during my experimentation. But I ran into some issues with the event queue getting blocked and filled up. I’m sure we can get to the bottom of it when you get back.

Have fun in Mexico.

#57

Oops! But also congrats :wink:

#58

As another point of reference, I just did a clean transfer with my old 1GB unbranded drive. So it works for at least 2 of us! :wink:

1 Like