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 такой нежный???

[AnatolyT]

Осциллограммы посмотреть можно, чтобы убедиться в правильности формирования протокола, хотя несинхронную помеху сложно будет увидеть. Раньше тоже думал, стоит только поставить конденсатор или дроссель в нужное место и все сразу заработает и проблемы исчезнут, не исчезнут, почти всегда приходится изменять топологию или конструкцию.
Если вы уверены в протоколе и откуда то все равно идет помеха, попробуйте как-нибудь заэкранировать шину i2c от платы discovery до внешнего устройства, экран землите с одной стороны, чтобы по нему ток не ходил. Если помеха проходит через резисторы подтяжки R29 R30, а это вполне вероятно, тогда можно снять их с платы discovery и для пробы поставить в конец шины i2c на внешнее устройство, тогда потеряем в надежности, если оно отвалится, вся шина не будет работать. Если это поможет, то можно на плате discovery аккуратно отрезать резисторы подтяжки от питания, восстановить шину питания в этом месте, вернуть резисторы назад и подать напряжение на них проводом непосредственно с контактов питания контроллера.
Обмен с подтверждением с кодом циклического контроля, КЦК или CRC, в моем случае пишем блок 264 байта в память dataflash, 256 байт данных и 8 байт CRC, затем читаем его и проверяем CRC, при ошибке пишем повторно.

Сообщение отредактировал AnatolyT - Apr 11 2017, 22:41

[jcxz]

Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным SCL устраивает) и есть более важные проблемы (с ПО) - отложу это пока в сторону, тем более что доставить осцилл к устройству или устройству к осциллу пока затруднительно по географическим причинам (был бы я дома - не вопрос - через неск. минут снял-бы их).
Но по мере возможности осциллограммы сниму и выложу сюда.
В протоколе уверен почти на 100%, ибо:
1) с остановленным обменом с ESP8266 всё работает часами в разных режимах обмена со слэйвами, при старте же обмена с ESP8266 падает через неск. секунд после старта;
2) обмен с ESP8266 в данном случае простейший (тестовый) и опять-же выполняется через драйвер UART, через данный драйвер ещё два других UART-канала работают с гораздо более сложным траффиком (т.е. - драйвер можно считать отлаженным);
3) все сбои по I2C носят ярко выраженный характер помех на линии (все исключительные ситуации в ПО, типа фаултов, выходов за границы регионов памяти и т.п.) у меня максимально возможно отслеживаются;
4) при подключении ESP8266 не напрямую в разъём на монтажную плату возле слэйвов короткими проводами, а в этот же разъём через удлинитель порядка 15 см - даёт кратное уменьшение кол-ва сбоев (но всё равно остаются, да и не устраивает такое конструктивно);
5) ... многие другие причины, в том числе и субъективные

Насчёт резисторов подтяжки - совет хороший, я тоже думал на этот счёт. Оставил это пока на крайний случай.

Обмен с подтверждением с кодом циклического контроля, КЦК или CRC, в моем случае пишем блок 264 байта в память dataflash, 256 байт данных и 8 байт CRC, затем читаем его и проверяем CRC, при ошибке пишем повторно.

У Вас вероятно SPI. С I2C это никак не поможет, ибо типы сбоев, которые у меня происходят - я описывал выше. Они приводят к обрыву транзакции, а не к разрушению данных (хотя может и последнее тоже есть).
И самое интересное - из всех слэйвов висящих на шине, как раз I2C-FRAM память и не сбоит вообще!
Сбоят как раз другие слэйвы, которые не память и для которых такой контроль не подходит.

PS: Кстати - в Вашем случае, раз уж хотите контролировать правильность записи в DATAFLASH, имхо оптимальнее контролировать по-другому: загружать во внутренний ОЗУ-буфер в чипе, потом оттуда считывать полностью, сравнивать, а потом уже давать команду записи буфер->flash. Ну или считывать и сверять буфер после записи во flash.

[blackfin]

Насчёт резисторов подтяжки - совет хороший, я тоже думал на этот счёт. Оставил это пока на крайний случай.

На всякий случай, Phillips подключает свои м/схемы к шине I2C через низкоомные резисторы от 47 до 100 Ом:
[attachment=106748:EEPROM.jpg]

PS. Всю тему не читал, может, кто уже советовал..

[jcxz]

подключает свои м/схемы к шине I2C через низкоомные резисторы от 47 до 100 Ом:
PS. Всю тему не читал, может, кто уже советовал..

Да, стоит попробовать. Советовали уже.

[Axel]

Да, стоит попробовать...

Если pull-up резисторы >= 1к - как мертвому припарки (ИМХО). Более перспективно уменьшить пулл-апы Ом до 300 (если все абоненты держат 10mA и тока не жалко).