Ja, die Frequenz habe ich vergessen (würden aber in der datei twimaster.c stehen), sie liegt bei 400kHz. Aber wie gesagt, das Problem tritt frequenzunabhängig auf.

Leider funktioniert dein Lösungsansatz bei mir nicht. Ich glaube auch zu wissen warum: nach i2c_stop() wird ja trotzdem im Endeffekt i2c_start() (über den Umweg while() und i2c_rep_start() ) direkt aufgerufen und kann deswegen dort hängen. Ich habe es auch mit kurzen delays zwischen jeder i2c-Operation versucht, brachte recht wenig.

Um mal zu sehen, wo genau das Programm stehen bleibt, habe ich jeweils vor den einzelnen Funktionen eine Led angeschalten, am Ende wieder ausgeschalten. Abwechselnd blieb es bei i2c_start() und i2c_readAck() an.
D.h. es kann nur in folgender Schleife hängen: while(!(TWCR & (1<<TWINT))); (je nachdem was ihr für eine lib benützt, ich verwende die von fleury)

Um diese zu verlassen muss TWINT == 1 sein. Deswegen habe ich in der ISR, statt wie oben das TWI zu reseten und die Motoren neu ansteuern einfach TWCR |= (1<<TWINT); eingegeben. Sozusagen die brachiale Lösung dass das Programm weiterläuft. Und es scheint zu funktionieren!

Was es allerdings genau bewirkt und welche Auswirkungen es genau hat kann ich leider nicht sagen, dazu fehlt mir das Wissen (und die Zeit mich dazu ordentlich einzulesen^^)

Zwar eigentlich keine schöne Lösung und es packt das Problem nicht an der Wurzel, aber es läuft... Es sei denn ich hatte in der letzten halben Stunde einfach nur Glück und es lief auch so Sobald ich es mal längere Zeit laufen lassen kann melde ich mich wieder!