В "AN10216-01 I2C Manual" не сказано: "безудержно дергать......". Там довольно определенная последовательность действий.

Вот же к фразе прицепились... Я так ОБРАЗНО обозвал цитату из рекомендации "I2C bus recovery" по ссылочке, подчеркивая, что уже не сама I2C периферия процессора формирует сигналы, а это надо делать "вручную".


Если автоматы EEPROM разных производителей есть плод Вашей разработки, то нам несказанно повезло иметь возможность наконец распросить Вас, как же там все на самом деле работает! До сих пор понимание глубинных процессов автомата было недоступно, приходилось судить лишь по поведению этого черного ящика по внешним проявлениям и набивать шишки. Я приготовился внимать!

Такое простое дело сложно сделать зачем то по разному. Так что можете верить, или не верить, но они у всех одинаковы и одинаково отрабатывают процесс recovery.

Да, должны вроде. Но вот тут у меня FM31T378 почему-то никак не хочет прислушаться к доводам zltigo разума
В процессе отладки, после обрыва одной из сессий на полдороге, вдруг перестал отвечать ACK на свой адрес и больше никак не приходит в себя.
И пока даже не понятно, что и делать - даже сброс отключением питания не помогает... ((
Хотя вроде и не должны микросхемы дохнуть просто от обрыва I2C-транзакции на полдороги. Но уже кажется, что бывают исключения....

Я писал про логику автомата и выводе его в начальное состояние. То, что что то уже за автоматом I2C сдохло намертво, и совсем не обязательно, что от обмена (если однократный случай)это уже другое дело.
Я использую их-же FM24V10 в тяжелых условиях, посему мучал не только прерыванием транзакций и закорачиванием всего и вся в процессе, но и статикой. Завешивал таким образом многократно. И развешивал.

Мои 5: когда я работал с I2C на AVR то на коротком кабеле обмен работал без повисаний сколь угодно долго, на длинном же периодически, при скачках напряжения на самой схеме (не внешние помехи), датчик вешал шину и контроллер. Там я решил таймаутом и реинициализацией I2C и всё продолжало работать. Когда работал с Microblaze с его I2C-мастером и уже другим датчиком - тоже повисало и никакие реиниты уже не помогали. С тех пор я решил что шина I2C противная. Тем не менее, мои софтовые реализации (bit-bang) мастера протокола I2C работали без сбоя, равно как и I2C порты на всяких ARM-платах с ОС Linux (через драйвер производителя).
Всю тему не читал, но пробовал ли автор темы просто для эксперимента программно сделать I2C?

Это у Вас несколько иное, просто FRAM. А FM31T37x - это Companion-чип - там внутре два слэйва FRAM + RTC с разными адресами на одной шине. Перестали отвечать оба сразу.
Есть кое-какое подозрение что что-то защёлкнулось и запомнилось в каких-то внутренних регистрах возможно внутри есть какой-то кондёр раз это RTC. Пусть полежит неск. дней без питания - может разрядится и оживёт.
С просто FRAM мы тоже много лет работает (только по SPI - FM25) - не было проблем.

Естественно,что я посмотрел что это перед ответом. Под "их-же" я имел виду того-же производителя а не такой-же чип. Представить, что в таком сдвоенном чипе могли что то налажать я в общем могу. Но вот выход из строя от неправильного цикла обращения, уже нет. По поводу - полежали и заработали - не помню уже за давностью лет подробности, но такое встречал с Flash. Три чипа 512 килобайтных были вставлены в панельки индустриальной PC наоборот и сдохли. Спустя некоторое время случайно были вставлены нормально и ожили. Поскольку такое в условиях сервисного центра случалось несколько раз, то эффект был стабильный и оживали они через месяц-другой.