STM32F4: Помехи по I2C. Опции

[jcxz]

Есть небольшой проектик на STM32F429 (на отладке discovery). На этой EVB на I2C3 сидит пара чипов + я подключил к ней внешнюю плату, на которой на этой шине ещё 2 устройства.
Кроме того - в проекте есть модуль на ESP8266.
Пока ESP8266 находится в RESET-е - всё прекрасно работает - обмен со всеми используемыми (3-мя) устройствами на I2C идёт без проблем.
Но как только снимаешь RESET с ESP8266 и начинаешь ей давать какие-то AT-команды, начинаются чудеса на I2C: возникают различные ошибки обмена на шине (и "bus error" и " Arbitration lost" и просто NACK в произвольный момент транзакции).
Всё работает конечно параллельно-многозадачно и нельзя остановить ESP8266, поюзать I2C и продолжить работу с ESP8266.
Такое ощущение что мощные помехи прут из ESP8266 и влияют в основном на I2C.
Но ранее этот проект работал на EVB с LPC1788 и там проблем с I2C не было вообще! Там ESP8266 работал часами параллельно с обменом по I2C, разве что устройств на I2C было на 1 меньше.

Перепробовал уже всё что можно для борьбы с помехами - в регистрах I2C периферии включил все фильтры на максимум, перепробовал все опции для отдельных пинов I2C, менял скорости - никакого толку.
Дальше на плате навесил разной керамики и 0.1мкФ и 10мкФ прямо возле ног сбоящей I2C-периферии и возле ESP8266.
Потом вообще отделил ESP8266 по питанию и по GND дросселями 22мкГн - кол-во сбоев снизилось в разы, но всё равно неприемлемо много.
Пробовал вообще отдельный источник питания (DC-DC от розетки 220V) для ESP8266, соединив его GND с остальной платой через дроссель - стало даже хуже.
Сейчас запитано так: EVB питается штатно от USB, внешняя плата запитана +5V от отдельного DC-DC, на ней стоит ещё LDO, от которого запитано всё по 3.3V и от него же через дросселя по +3.3V и GND запитана ESP8266. Пока RESET на ESP8266 - всё ок. Как только снимаем RESET и начинаем подавать AT-команды, то максимум на 10-й команде AT+GMR (печать инфы о прошивке и т.п.) получаю сбой по I2C. Если давать команды перезагрузки ESP8266 или команду скан эфира - ещё быстрее сбой происходит.

Попробую ещё навешать последовательных резисторов по всем сигнальным линиям ESP8266, но что-то сомнительно. И больше уже не знаю что ещё сделать.
Да и странно это как-то - на LPC1788 всё работало вообще как есть без всяких фильтров и даже просто - всё на соплях болталось на проводах и работало!
Неужели I2C на STM32F4 такой нежный???

[vladec]

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

[jcxz]

Если Buse в изделии не используется, нет ни какого смысла конфигурировать SCL в режим открытого коллектора.

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

И после этого все равно были единичные сбои, пришлось организовать обмен с подтверждением и циклическим контролем.

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

По всей видимости i2c, организованный на этом порте, может работать в режиме мастера, и все равно это нарушение протокола i2c.

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

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

Спасибо

[AlexRayne]

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

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

[jcxz]

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

Это слишком трудоёмко + не даёт гарантированного результата. Ибо - задержка клока слэйвом может производиться по его внутренней логике, которую я не знаю.
Не всегда, а только в определённых ситуациях.
Например:
Часы RTC, запись нового значения - теоретически может быть выставлен "clock stretch" если момент записи точно попал в момент обновления внутренних регистров, на время до окончания обновления. Вероятность попадания очень мала и поймать такой случай на осциллографе не получится.
Этот пример просто как предположение, но можно напридумывать кучу других ситуаций. Не зная внутренней схемы устройства слэйва, узнать в каких случаях он использует "clock stretching" невозможно.

PS: Да и вопрос мой был риторический. Просто товарищ не читает ответов ему, а повторяет одно и то же.