I2C Slave на STM32F103, нестабильная работа Опции

[Demeny]

Добрый день!
На контроллере STM32F103 реализовано I2C Slave устройство, которое принимает от "внешнего мира" команды, обрабатывает их, и по запросу чтения выдает ответ. Всё это работает на 90% выпущенных плат.
На 10% тех же плат (из той же произведенной серии) наблюдается следующая картина - I2C Slave аппаратно не подтверждает свой адрес, то есть не выдает ACK на первый (адресный) байт со стороны мастера. В качестве мастера для теста используется компьютер с простейшим адаптером на LPT порт, который имитирует программно работу мастера (выдает команды по I2C и получает ответ).
Картина, наблюдаемая логическим анализатором, доподлинно следующая - мастер правильно формирует старт-условие, адресный байт, не получает от I2C Slave ACK, снова формирует старт, адрес и т. д. много-много раз (несколько десятков раз), и вот в какой-то момент адрес подтверждается (ACK), контроллер получает команду, обрабатывает её и готов отдать ответ. Далее та же петрушка начинается с чтением - старт, адрес + бит чтения = NACK до посинения, потом, наконец, STM32 формирует ACK и выдает правильный ответ мастеру.
Примечательный момент - если встать на любую линию SCL или SDA щупом осциллографа, то работа слейва сразу стабилизируется, он начинает работать четко и формирует ACK сразу после первого же запроса.
Что это может быть? В чём ошибка? Почему 90% плат работают, а 10% ведут себя так?

[Golikov A.]

Может 3.3 вольт не хватать компьютеру для 1? У каких то контроллеров они не совсем 3.3?

[Demeny]

Может 3.3 вольт не хватать компьютеру для 1? У каких то контроллеров они не совсем 3.3?

Контроллер не подтверждает свой адрес на шине I2C, который (судя по логу анализатора) формируется правильно, при чём здесь компьютер? Да и на стороне компьютера подтяжка к +5 вольтам, это контроллер "тянет" вниз лог. 0 выходом "open drain"...
Может, в поведении аппаратного контроллера I2C у STM32 есть какая-то особенность, ну скажем, при определённых условиях он не считает шину свободной, или что-то в этом духе...

Осциллограф на шине - это емкость.

Это я понимаю, что ёмкость. Щуп, кстати, неплохой, с полосой 200 МГц, поэтому ёмкость крайне невелика, должно быть около 5-8 пФ.
Ёмкость может не только сглаживать "пички", но и слегка сдвигать фронты сигнала.
Но почему не все контроллеры сбиваются от предположительных "пичков"?

[iosifk]

Это я понимаю, что ёмкость. Щуп, кстати, неплохой, с полосой 200 МГц, поэтому ёмкость крайне невелика, должно быть около 5-8 пФ.
Ёмкость может не только сглаживать "пички", но и слегка сдвигать фронты сигнала.
Но почему не все контроллеры сбиваются от предположительных "пичков"?

Потому что I2C работает на 100 Кгц максимум. А процессор на 20-100 Мгц и для него пологие фронты сигналов I2C - это как "пила". И на фронте этой пилы еще сидят помехи. Так что кто-то их успевает нахватать, а кто-то - нет. Я в ПЛИС для таких сигналов предпочитаю ставить цифровой фильтрик и не иметь головную боль...
А в Вашем случае надо искать откуда лезут помехи. Или поставить в линию 10-30 ом резисторы. Или емкость с линии на землю...

[Demeny]

Потому что I2C работает на 100 Кгц максимум. А процессор на 20-100 Мгц и для него пологие фронты сигналов I2C - это как "пила". И на фронте этой пилы еще сидят помехи. Так что кто-то их успевает нахватать, а кто-то - нет. Я в ПЛИС для таких сигналов предпочитаю ставить цифровой фильтрик и не иметь головную боль...
А в Вашем случае надо искать откуда лезут помехи. Или поставить в линию 10-30 ом резисторы. Или емкость с линии на землю...

В линии стоят последовательные резисторы 100 Ом, я писал об этом выше. Да и ёмкость порядка 200 пФ тоже неявно присутствует в виде ESD-диодов BZA456A. Да и триггеры лейтенанта Шмидта, казалось бы, на входах контроллера должны быть, нет?