Контроль SDA и SCL на шине I2C

[pifa]

Atmega128 (Master), ATMega8535 (Slave), ATMega8 (Slave) связаны шиной I2C. Иногда возникает ситуация (очень редко), когда шина I2C "зависает" из-за того, что ATMega8535 садит глухо на "0" сигнал SCL. Вся остальная часть схемы на этом процессоре работает нормально. ATMega использует аппаратный I2c и работает по прерыванию. Проверял программу и ошибок, вроде, не нашел. Да и работать оно может неделю-две, а то и больше без проблем. В программе расставлены контрольные точки для Watchdog, в том числе и в программе прерывания I2C. Но они почему-то не срабатывают.
Пока решил контролировать состояние сигналов на шине I2C ("0" или "1") и проводить сброс процессора при зависании. Но как это контролировать? Пока ничего путного в голову не лезет.

[NewWriter]

В описании протоколоа I2C есть такая штука как арбитраж шины. И если возникает конфликт шины, то программа МК должна не забывать его обрабатывать.

[pifa]

сейчас точно не помню, но, кажется, это касается нескольких мастеров на шине. Здесь Master один и с ним проблем нет, а на Slave он никак влиять не может, только через I2C.

[ForcePoint]

сейчас точно не помню, но, кажется, это касается нескольких мастеров на шине. Здесь Master один и с ним проблем нет, а на Slave он никак влиять не может, только через I2C.

Неважно совершенно. Согласно спецификации I2C, ведомый имеет право удерживать SCL в 0, если не успевает обрабатывать данные. Вот, несколько абзацев из фирменной доки.

Описание "TWI Control Register – TWCR. Bit 7 – TWINT: TWI Interrupt Flag":

While the TWINT Flag is set, the SCL low period is stretched.

Разделы "Slave Receiver Mode" и "Slave Transmitter Mode" снабжены одинаковым абзацем:

In all sleep modes other than Idle mode, the clock system to the TWI is turned off. If the TWEA bit is set, the interface can still acknowledge its own slave address or the general call address by using the Two-wire Serial Bus clock as a clock source. The part will then wake up from sleep and the TWI will hold the SCL clock low during the wake up and until the TWINT Flag is cleared (by writing it to one). Further data reception will be carried out as normal, with the AVR clocks running as normal. Observe that if the AVR is set up with a long start-up time, the SCL line may be held low for a long time, blocking other data transmissions.

[pifa]

Неважно совершенно. Согласно спецификации I2C, ведомый имеет право удерживать SCL в 0, если не успевает обрабатывать данные.

Это я знаю. Но ведомый то работает с аппаратным TWI с прерываниями, а не устанавливается мной лично. И TWINTсбрасывается аппаратно
Вот по этому я и хочу отследить эту ситуацию и принудительно произвести RESET.
Возможно, где-то в процессе работы программы и возникает такая ситуация, но пока я её найти не могу. Программу обработки прерываний я привел. После приема одного байта команды процессор выдает 16 байт данных из буфера ADC_N.

[ForcePoint]

Если есть возможность куда-то выдать или где-то сохранить - вставьте проверку, не приходит-ли какое "неразобранное" состояние автомата TWI:

switch (TWSR & 0xF8){
	.....
	.....
	default:
		вот сюда
		break;
}

Скорее всего - именно так и происходит. Ведь в default: нет сброса TWINT.

[pifa]

Скорее всего - именно так и происходит. Ведь в default: нет сброса TWINT.

Вполне возможно. В даной версии все состояния TWI не обрабатываются. Есть уже написаный код с обработкой всех состояний. Но я его даже не компилировал, не говоря уже об отладке.

Что касается проверки на "левое" состояние, то такой возможности нет. На плате с одной стороны аналоговые входы, а с другой - только TWI.
Возможно, сделать так:

switch (TWSR & 0xF8){
	.....
	.....
	default:
		TWCR = (1‹‹TWINT) | (1‹‹TWSTO);   /* переход в безадресный режим */
		break;
}