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% ведут себя так?

[1113]

ваше устройство только с компьютером связано или стоит в связке с чем-то? какие скорости по шине? покажите схему и плату, что с землёй?

[Golikov A.]

и с подтяжками шин...
уровни логические, питание, ничего там не занижено-не завышено? конфликты? Что-то может на грани и потому то туда падает, то суда?

как монтируют? какой контроль? может быть 10% барака?

[Demeny]

ваше устройство только с компьютером связано или стоит в связке с чем-то? какие скорости по шине? покажите схему и плату, что с землёй?

Для тестирования устройство подключается к компьютеру, скорость обмена минимальна, не более 20 кГц по SCL. Программа тестирования 100% рабочая, проверено не на одной тысяче устройств. Да и логическим анализатором записываю обмен...
Схема простая, от внешнего разъёма 2 последовательных резистора по SCL и SDA по 100 Ом, далее подтяжка 4,7 кОм к +3,3 В обе линии, далее ESD-защита на диодах BZA456A обе линии, ну и всё это на контроллер I2C1 STM32F103.
Земля, как земля, полигончик на нижней стороне и на разъём, не думаю, что при таких частотах земля играет какую-то роль.

и с подтяжками шин...
уровни логические, питание, ничего там не занижено-не завышено? конфликты? Что-то может на грани и потому то туда падает, то суда?

как монтируют? какой контроль? может быть 10% барака?

Уровни смотрю осциллографом, что-то около 4,5 вольт, но у контроллера пины 5V Tolerant, насколько мне известно. Прямоугольники чёткие, криминала не видно, но как раз при подключении щупа осциллографа на любую линию, не важно, до резисторов 100 Ом или после, всё работает. Кстати, при подключении лог. анализатора такого эффекта нет, может, потому, что обе линии подключены...
Монтаж автоматический, может и брак, понять бы, в чём он, непропаев нет - всё запаяно нормально.

[1113]

посмотрите осциллографом на землю компьютера относительно земли процессора (или наоборот, как удобнее) - может тут что-нибудь увидите

[Demeny]

посмотрите осциллографом на землю компьютера относительно земли процессора (или наоборот, как удобнее) - может тут что-нибудь увидите

Вообще, земля компьютера, процессора и минус лабораторного блока питания соединены, как и земли осциллографа и лог. анализатора, которыми подключаюсь. Но посмотрю, на всякий случай.
Я бы искал системную ошибку, если бы все платы вели себя так. Но абсолютное большинство плат работает нормально. Значит, что 10% плат из той же производственной серии, без видимых дефектов монтажа, чем-то отличаются от остальных. Главный вопрос -чем? Битый контроллер, перегрев при монтаже, или всё же софтовая/схемная ошибка?

[Golikov A.]

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

[iosifk]

Примечательный момент - если встать на любую линию SCL или SDA щупом осциллографа, то работа слейва сразу стабилизируется, он начинает работать четко и формирует ACK сразу после первого же запроса.
Что это может быть? В чём ошибка? Почему 90% плат работают, а 10% ведут себя так?

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

[Demeny]

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

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

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

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

[Timmy]

Согласен с iosifk, это могут быть короткие пички на шине. Попробуйте для начала притянуть SCK к земле конденсатором 1-10nF.

[iosifk]

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

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

[Demeny]

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

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

[scifi]

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

Вообще-то правильный блок I2C умеет всё это фильтровать. Осталось только понять, насколько он правильный у STM.

[Golikov A.]

В линии стоят последовательные резисторы 100 Ом,

а если их закоротить? Чтобы фронты по резче были...

[iosifk]

Вообще-то правильный блок I2C умеет всё это фильтровать. Осталось только понять, насколько он правильный у STM.

Ну так и я об этом же.
Есть "правильное" изделие и есть "неправильное". Надо перенести из одного в другое "питание", "микроконтроллер", "задатчик шины" и т.д. И на каком-то этапе обнаружатся сбои... Хотя тут дело может быть и не так однозначно.
Но в любом случае, имеет смысл сравнивать сигналы. Вплоть до глазковой диаграммы по генераторам.. Возможно что осцилл имеет связь корпуса и питания, что действует как фильтр для источника...
"Бороться и искать, найти и не сдаваться!"

[Demeny]

Вести с полей.
Не веря ни в какие "пички", решил поискать более материальную причину происходящего. Если контроллер не отвечает на свой адрес - возможно, он находит какую-то ошибку в происходящем на шине.
Сказано - сделано, подключил обработчик прерывания ошибок на шине I2C, разрешил прерывания ITERREN=1, и в обработчике прерывания дергаю внешним отладочным пином, чтобы видеть происходящие ошибки.
И сразу увидел, что в момент, когда при передаче адресного байта обе линии SCL и SDA одновременно падают в ноль (после переданного бита 1) - возникает ошибка Bus Error.
Согласно даташита, это как раз ситуация, когда посреди передачи байта возникает "старт" или "стоп" условие на шине.
Казалось бы, вот и ответ - программа бросает обе линии в ноль одновременно, но из-за различных емкостных характеристик линий SCL,SDA, неидеальности резисторов и ESD-диодов линия SDA с точки зрения контроллера падает в ноль первой, и возникает минимое "старт"-условие, которое и сбивает контроллер с толку.
Включив лог. анализатор на максимальную скорость 400 MS/s, вижу, что SCL 1=>0 всё же опережает SDA 1=>0 буквально на 7-8 нс, то есть "старт"-условия нету, а ошибка шины есть!
Замыкая проходные резисторы 100 Ом, могу подвигать фронтами, и вижу, что фронты двигаются друг относительно друга примерно на 10-15 нс, и ошибка пропадает при этом.
НО!
Я ещё понимаю, когда ошибка пропадает при отодвигании SDA 1=>0 позже по времени от SCL 1=>0.
Фантастика заключается в том, что ошибка пропадает и при отодвигании спада SCL в другую сторону, то есть фактически, когда "старт"-условие в реальности выполняется (SDA 1=>0 при SCL=1)!
Итого - ошибка шины возникает тогда и только тогда, когда разбежка между фронтами спада меньше 7-8 нс.
Если разбег фронтов (в любую сторону) больше - ошибки нет, что мы и видим при любом прикосновении к любой линии (пинцетом, щупом осциллографа и т. п.).
Что это - метастабильность триггера, защёлкивающего "старт" условие, из-за невыполнения setup-hold ??
Почему он его не защелкивает, когда "старт"-условие фактически выполняется (при подвижке спада на 10-15 нс в нужную сторону)??
И ещё. На такой же плате, у которой нет проблем с обменом (таких 90%) - также точно линии SCL и SDA падают в ноль с минимальным разбегом (<2.5 нс), но ошибки нет...

[Golikov A.]

а вы уверены что дело в том что вы сдвинули фронты, а не в том, что вы их сделали круче убрав резисторы?

[scifi]

По спецификации I2C Fast Mode для Start Condition между фронтами SDA и SCL должно быть как минимум 600 нс. Вот не надо нарушать.

[Demeny]

а вы уверены что дело в том что вы сдвинули фронты, а не в том, что вы их сделали круче убрав резисторы?

Как изменяет фронт прикосновение пинцетом или щупом осцилла? Разве что затягивает из-за доп. емкости...
Посмотрел осциллографом - спад идёт 75 нс. По даташиту на контроллер I2C в STM32 до 300 нс максимум.
Кстати, да, если закоротить оба резистора 100 Ом проблема тоже уходит...
Но в том же даташите на I2C в STM32 (Fig. 48) как раз нарисованы эти резисторы 100 Ом и подтяжка 4,7 кОм, прямо как у меня.
Ничего не понимаю...

По спецификации I2C Fast Mode для Start Condition между фронтами SDA и SCL должно быть как минимум 600 нс. Вот не надо нарушать.

У меня слейв, который как раз ловит "неправильный" Start Condition, поэтому я ничего не нарушаю.

[scifi]

У меня слейв, который как раз ловит "неправильный" Start Condition, поэтому я ничего не нарушаю.

Если Start Condition неправильный, то имеете все основания предъявить претензии его аффтару.
Или затяните один из фронтов в правильную сторону. Но это некий танец с бубном.