#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

#32

Hey!
I did not have time to test the new firmware
someone has tested it?

#33

Just posted a handy tip over on the Orthogonal forum and figured it would share it here to. Basically, if you are driving your i2c bus super-hard trying to read and pass along values from the 16n, you are most likely stressing the heck out of the i2c bus. You are bound to have weird issues over time. (As clearly noted above.)

What has worked for me is reducing the 16n “sampling rate” (number of times I read from FB n ) and implementing slew on the output it is piped to. This reduces the stress on the bus and still gives a smooth-feeling response on the output.

2 Likes
#34

I need to try that. What sampling rate and slew rate would you recommend ? More than 100ms ?

#35

It really depends on the feel you are looking for (how responsive you want it to be) and how much other stuff you are doing. If you make the slew and your read/update rate the same, you should get good results. 100ms is a good place to start. :slight_smile:

2 Likes
#36

Thanks, I will try that :slight_smile: