Это всё делалось - ничего не помогло.
Написал тесты плотной работы со всеми слэйвами на шине, запускал эти тесты на несколько часов: если без обмена с ESP8266 - работало пару суток без единого сбоя, за это время на I2C-FRAM-ку записалось несколько гигабайт (запись-чтение-проверка) и с другими I2C-слэйвами было много операций.
Как только включаешь обмен с ESP8266 - не позднее чем через минуту следует сбой, а обычно - уже через несколько секунд.
Перепробовал разные подтяжки, скорости по I2C, конденсаторов кучу навесил, резисторы 50 Ом последовательно на все сигналы ESP8266, пробовал отдельно запитывать ESP, дросселя на питание (и на GND) - ничего не помогало. (((((
Сейчас вдруг решил поменять режим ноги SCL на МК на push-pull вместо open-drain. И все проблемы исчезли! Работает ещё недолго, но уже полчаса прошло - такого ещё не было.
Достаточно ничего не меняя опять вернуть open-drain ножке SCL - сразу начинает сбоить.

Это конечно неправильно и противоречит спецификации I2C, но ничего не поделаешь - оставлю наверное push-pull для SCL.
Без ESP8266 и с open drain нормально работает, но.... (((

Как честный человек, вы просто обязаны предоставить сообществу осциллограммы обоих случаев (;

Я бы предоставил. Но лень осциллограф тащить сюда

Если проблема исчезла когда переключили резисторы подтяжки шины с внешних на внутренние, то вероятно помеха наводится по питанию на участке цепи между контроллером и этими резисторами.
Может быть имеет смысл провести отдельным проводником напряжение питания непосредственно от контактов питания контроллера до резисторов подтяжки.

Сообщение отредактировал AnatolyT - Apr 9 2017, 17:29

Ну, если Ваши слэйвы клок не придерживают - Вам повезло. Но вообще-то это хрень какая-то... Ваш "прием" по сути означает резкое уменьшение импеданса шины в "единице". Очень похоже на сильную наводку или звон с амплитудой, пробивающей клампы...

Напротив, полагаю, если режим Buse не используется, то всегда лучше иметь SCL в push-pull, это существенно уменьшает возможности для проникновения на шину помех

Прочитайте мой пост внимательнее - я включил push-pull вместо open drain (стандартного для I2C). Подтягивающие резисторы при этом не используются.
До этого включал и отключал и внутренние и внешние подтяжки в разных комбинациях - не было никакого толку.


Вы не понимаете схему включения. Всё описано постами выше.


Я согласен с Вами, что это хрень. Поэтому и долго не пробовал так сделать.
Но пока вроде всё работает ок до 400кГц со всеми слэйвами.
Да и ещё я как-то думал, что в STM32 (мало опыта с ними) характеристики пина определяются включенной альтернативной функцией и думал что невозможно включить push-pull для пинов если для них выбрана функция I2C. В некоторых других МК именно так.


Кто-ж его знает - используется или нет? Я же не могу влезть в схемотехнику всех своих слэйвов.
Но пока вроде всё работает ок до 400кГц со всеми слэйвами.

В свое время делал следующее: в существующий измерительный прибор необходимо было добавить блок памяти, решил использовать i2c, так как только два порта контроллера прибора были доступны и они же использовались для обмена с дисплеем для отображения результатов, и все это в ограниченном объеме. Добавил м\с памяти на платку дисплея. Все это работало в руках на проводах, как собираем все в корпус сбой при обмене. Пришлось экранировать шину i2c, на шлейфе, соединяющим платку дисплея, между шинами scl и sda и с двух сторон оставить заземленные проводники. И после этого все равно были единичные сбои, пришлось организовать обмен с подтверждением и циклическим контролем.
Какие причины возникновения помехи: импульсный ток в цепи питания и по землям от внешнего устройства и радиопомеха на шину i2c. На 32F429IDISCOVERY есть резисторы подтяжки шины, R29 и R30 номиналом 4,7 кОм. Когда включается push pull используется верхний транзистор управления порта, то есть он шунтирует резистор подтяжки и тем самым вероятно устраняет влияние помехи. По всей видимости i2c, организованный на этом порте, может работать в режиме мастера, и все равно это нарушение протокола i2c.

"Открытый сток/коллектор" на шине SCL нужен исключительно для реализации функции Buse, то есть, что бы слейвы имели возможность притормозить обмен. Если Buse в изделии не используется, нет ни какого смысла конфигурировать SCL в режим открытого коллектора.

Какой-какой функции?

Наверное busy. Или clock stretch применительно к I2C.

Я бы предположил, что ESP8266 иногда ловит ложное старт-условие с последующим обнаружением своего адреса, после чего "полноправно" лезет на шину со своими данными. Как отловить такую ситуацию, надеюсь, пояснять не нужно.

Ребята, а давайте читать тему целиком, а не только последнее сообщение?

Повторю для непонятливых:
Не знаю что такое "Buse", но если это "clock stretch", то как определить: "используется в изделии" он или нет?


Что Вы имеете в виду под подтверждением? Стандартный ACK? Так он и так есть.
И что такое "циклический контроль"?
Свой протокол обмена по I2C я накрутить не могу - у меня связь не между двумя МК.
Сбои идут в виде: NACK на передачу адреса слэйва; arbitration lost, bus error и т.п.
Можно конечно усложнить драйвер I2C - добавить обработку этих ситуаций, в виде повторных транзакций и т.п.
Но неохота это делать, ибо: во 1-х - получается громоздко; во-2-х - считаю принципиально неверным подход придумывания костылей по устранению последствий вместо лечения самой причины (а причина - аппаратная, а не программная).


Он и работает в режиме мастера всегда. Других мастеров на шине нет.
Про "clock stretching" знаю. Надеюсь мои слэйвы его не используют.


Спасибо

1) клоки посмотреть. в норме должны стоять ровные посылки по 9 клоков с паузой. если конечно пауза есть. в середине посылки если есть дрожание - это уже намек на стретч.
2) можно врезать резистор в цепь клока. и на нем будет видно - просаживает ли слейв свой конец или нет.