#12

Sounds like the most plausible explanation to me!

#13

Or by disabling the metronome in my case. Also, for reading the faderbank values I tried to trigger the script doing that with a Pamela New workout, I have better results but of course the PNW has to always run.

Once again, I think I’ll use the faderbank for its CV outputs only, even though that will use all the inputs of the 301 :-/ that seems more reasonable

#14

Not sure this applies in my case. If you look at the first of my videos, you see me stop/start the metronome repeatedly without any effect. Or am I misunderstanding?

1 Like
#15

to clarify this in case anybody wants to take a dig at making this change - a simple case IS trivial, but a proper implementation wouldn’t be. simple case: i2c_master_tx actually returns a status (TWI_SUCCESS if successful), which teletype doesn’t currently check. so a simple retry logic could be added here - but it would only deal with one scenario. also, i did some testing when working on polyES, and the problem is that this retry logic doesn’t seem to address the underlying issue - whatever causes it to fail in the first place is not likely to work when you try immediately after. so the retry logic would need to be implemented in a way where it doesn’t retry immediately - which would introduce timing issues…

disabling i2c commands (you can comment them out with alt-/)

that’s part of the problem - when we ran into i2c issues before one of the fixes applied was to give i2c highest priority (it will block timers / screen refresh / keyboard while i2c broadcast is in progress). so if there is anything that causes i2c to get blocked, it will cause tt to freeze. there is one simple fix that seemed to work okay for polyES, we could try it for teletype, i’ll post a test build tonight or tomorrow.

1 Like
#16

I will watch your videos now, sorry maybe our cases are quite different after all, I don’t want to detail the thread. Reading 16 faders at 25ms is definitely the cause of the issue in my case :slight_smile:

#17

That would be awesome, I’ll be delighted to try this out!

I’m pretty sure we’re seeing two sides of the same issue here… So no derailing AFAICC :slight_smile:

1 Like
#18

here is the test build (it will display .3.1 I2C on startup):

teletype.hex (581.4 KB)
teletype.zip (170.6 KB)

make sure to save your presets on USB before you flash, all presets will be erased!!

it has whatever the latest official firmware has plus the i2c fix. to clarify, this will not make i2c more reliable (as a matter of fact it can result in more dropped i2c commands) but it should prevent teletype from freezing if something goes wrong with i2c.

this is a simple protection from infinite loops if the i2c bus becomes locked/corrupted

bonus version (3.1 I2C+):

teletype.hex (581.5 KB)
teletype.zip (170.7 KB)

this version will retry up to 3 times if i2c send fails - i doubt it will do much good based on my previous tests (whatever causes i2c to fail is not likely to get fixed if you try a couple more times immediately after) but give it a try, maybe it’ll improve reliability in your scenario.

1 Like
#19

I can confirm that this patch fixes crashes I was encountering when running Ansible as an I2C leader at really high clock rates (like, tap-tempo as fast as I can -> 16x clock multiplier -> 16x clock multiplier -> Ansible). Now TXo crashes if I run this for a few seconds but if I crank the clock multipliers back down Ansible is still running fine. Teletype with another I2C op in the Metro script also crashed after a little while but the build of Teletype I’m running does not have this libavr32 patch.

1 Like
#20

Thanks a lot, I will try the altered firmware later today!

Would it be possible to either automatically or manually recover from a “corrupted” i2c bus?

#21

recovering from a corrupted bus is not a trivial task, and even if teletype supported some form of it it wouldn’t necessarily work with some followers (depends on how i2c is implemented on the follower side).

#22

Ok, I’ll have to trust you on this one,

Ok, I agree it doesn’t sound too promissing (although I’ll try it out), esp if by freezing you mean “locked up, not responding”, cause this has never happened here…

Thanks anyways so far, no high hopes, but maybe the two alternate firmwares will behave better.

In any case, I might have to adjust my coding practices, and keep an eye on the results in the long run…

#23

i thought you meant by this tt locks up until you reboot it. in any case, it should behave better now since i2c bus getting corrupted (or follower devices responding slowly) should affect tt much less, which is the better option that tt misbehaving.

as @zebra said, poor bus conditions can result in clock stretching which would explain what you were seeing. the experimental beta should prevent this from affecting teletype, so you should just get skipped i2c commands - once you have a chance to confirm it works this way now in your scenario (which i can’t reproduce since there are too many variables in each i2c setup) then try using shorter cables / disconnecting some of the modules from i2c and see if you can get a more reliable setup.

#24

Thanks!

As you can see on the first video I posted TT is still running and reacing to input, but messages are totally all over the place. Never had a lock up!!!

One thing I thought, but forgot to bring up: could it be the pullup resistors that might need to be adjusted in size (I have latest 301 + TT + atm 1xTxo from I believe last batch)?

#25

do you have an i2c backpack?

not sure tt alone provides the proper value for pullups in this setup. and it’s not easy to say whether the pullup value is okay without an oscilloscope.

#26

No backpack. As far as I understand, the new-version TT doesn’t need a backpack

#27

in this case you should be good (to confirm, you have a black PCB TT?) - but again, it comes down to a specific configuration, and the only way to confirm i2c bus is healthy that i know of is by looking at it with an oscilloscope. try connecting only er-301 to TT and keep the cable as short as possible and see if you can still repro the issue.

#28

If it comes this far, could you provide a link to where I can read more about how to perform this inspection? I might be able to visit a friend with an oscilloscope…

#29

http://dsscircuits.com/articles/effects-of-varying-i2c-pull-up-resistors

2 Likes
#30

Thanks, looks great!

#31

Oh yes thank you @scanner_darkly
Try the new firmware this night then tell you if it’s ok