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

[Jury093]

Неужели I2C на STM32F4 такой нежный???

во всей эпопее я не увидел подключение осциллографа (если он есть) для анализа происходящего
1. что там с пуллапами? номиналы крутили?
2. сгородить примитивную развязку по i2c пробовали а-ля Филипс?
3. в каком режиме ESP8266? судя по инету оно умеет и мастер и слейв, и тогда коллизии на шине вполне вписываются в картину происходящего..

[jcxz]

во всей эпопее я не увидел подключение осциллографа (если он есть) для анализа происходящего

Пока нет под рукой. Не думал что для подключения простейшего I2C понадобится осцилл....
Если совсем припрёт - придётся притащить.

1. что там с пуллапами? номиналы крутили?

На самой EVB есть резисторы 4.7К, плюс - на внешней плате ещё по 4.7К.

2. сгородить примитивную развязку по i2c пробовали а-ля Филипс?

Да неужто для работы обычного I2C с проводами длиной до 10см необходима ещё и развязка???
Это что-то слишком уже. Питание одно.

3. в каком режиме ESP8266? судя по инету оно умеет и мастер и слейв, и тогда коллизии на шине вполне вписываются в картину происходящего..

Он подключен по UART - коллизий никаких быть не может. На AT-команды отвечает. Источник питания достаточно мощный даже для него:
импульсный DC-DC на LM2596S после которого ещё линейный TLE4275V33 с вых. током 400мА.
ESP8266 в режиме IDLE (нет ничего по эфиру). При этом уже на команду AT+GMR (просто запрос инфы о прошивке) без выхода в эфир - проблемы.

Сама discovery с поганой для рядом находящегося передатчика разводкой (землёй) - возможно?

К этому больше всего и склоняюсь. Ибо даже на её шине питания вместо 3.3V всего лишь 2.95V (оч. слабая схема питания с ещё и диодом с 5V на входе).

SDA, SCL пустить через ферритовые бусины.

Как вариант.

"У меня есть гипотеза" - как говаривал маленький и любознательный динозаврик из "Поезда динозавров". На гипотезу навело меня упоминание об LPC1788, с которым было все хорошо.
Вы будете смеяться, но дело скорее всего не в помехах, а леворезьбовом I2C в STM32F1+. По этой теме было писано-переписано немеряно здесь, мной - по большей части. Краткая суть: I2C в 1xx и 4хх (I2C в 0xx переделан и работает как конфетка) страсть как не любит многозадачность, а хочет исполняться на самом высоком приоритете прерываний, а лучше - вообще при запрещенных. Причина: дурацкое определение бита (N)ACK уже в процессе приема байта и пара других мелочей как-то куча особых случаев при приеме и непредусмотренные битовые комбинации статуса автомата I2C, что вводит в ступор библиотеки. Вангуя, предположу, что обмен AT командами идет с высоким приоритетом, что вторгается во временнЫе характеристики кода для работы с I2C, со всеми вытекающими...

Попробуйте дать I2C высокий приоритет, выше, чем UART для ESP8266. Лучшие советы дать не могу, не зная Вашего кода и OS.

1.Приоритет для I2C и так - максимальный (как и для LPC1788 был), ну правда только делит один уровень вместе с ISR канала захвата таймера IR-приёмника. Можно конечно над IR-приёмником его вынести, но между IR-приёмником и I2C точно никаких проблем нет - во время отладки IR-приёма никаких коллизий с I2C не наблюдалось.
2.Библиотек никаких нету. Работа вся через регистры + частично используется DMA для I2C. Частота CPU 120МГц, можно и больше поставить. На LPC за глаза хватало 78МГц на всё. При том там уже всё работало - все процессы и драйверы.
3."Обмена AT-командами" как такового ещё нет - я постепенно переношу проект с платы LPC1788 на STM32F429. Перенёс почти всё уже - это кучка драйверов для устройств на паре шин SPI, 2-х UART-ах и одной I2C. По SPI идёт периодическое обновление LCD, по I2C периодически опрашивается 3 устройства на шине. Опрос I2C ведётся диспетчером в пределах одной задачи: в задаче - запуск транзакции; в ISR - продолжение транзакции, запуск DMA; завершение транзакции - в задаче. Весь обмен разбит на транзакции, которыми управляет диспетчер в одной задаче ОС.
Запретов прерываний длинных нет - есть контроль - точно все запреты менее 10мкс.
Работа с ESP8266 пока ещё не перенесена. Пока его только подключил и попробовал подавать AT-команды вручную через отладочную консоль - и тут вылезла данная проблема.
Все признаки указывают именно на аппаратную проблему.
На LPC1788 все было спаяно на соплях - ESP8266 вообще на проводах висел. Здесь же решил сделать получше - спаял на отдельной платке, ещё и блокировочных кондёров понавесил, провода укоротил - и на тебе - ещё хуже получилось (

[Jury093]

Да неужто для работы обычного I2C с проводами длиной до 10см необходима ещё и развязка???
Это что-то слишком уже. Питание одно.

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

Он подключен по UART - коллизий никаких быть не может. На AT-команды отвечает. Источник питания достаточно мощный даже для него:
импульсный DC-DC на LM2596S после которого ещё линейный TLE4275V33 с вых. током 400мА.
ESP8266 в режиме IDLE (нет ничего по эфиру). При этом уже на команду AT+GMR (просто запрос инфы о прошивке) без выхода в эфир - проблемы.

мнэ.. вы же понимаете, что без схемы и монтажки давать более предметные советы могут только телепаты со стажем..
попробуйте отключить по питанию esp8266 и хоть через кнопку подключить эквивалент по нагрузке из резисторов.. и пощелкать..
проблемы остались - хилый питальник, хилая земля
проблемы ушли - смотреть пути наводки по эфиру.. не знаю, что такое esp8266, видимо что-то радиосодержащее - возможно есть регистр регулировки мощности передатчика..

К этому больше всего и склоняюсь. Ибо даже на её шине питания вместо 3.3V всего лишь 2.95V (оч. слабая схема питания с ещё и диодом с 5V на входе).

временно напаять заведомо толстый провод..

3."Обмена AT-командами" как такового ещё нет - я постепенно переношу проект с платы LPC1788 на STM32F429.на тебе - ещё хуже получилось (

нельзя ли временно на соплях отцепить stm32 и подключить LPC на i2c дефективной платы?

[jcxz]

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

Схемы/монтажки нет. Как я писал выше - это макет.
Т.е.: EVB вот эта http://www.st.com/en/evaluation-tools/32f429idiscovery.html
к ней проводами длиной до 10см подключена монтажная кросс-плата, к которой припаяны пара платок с I2C-слэйвами (ещё один слэйв на этой-же шине - на самой EVB).
Вот сбоит чаще всего один из слэйвов на монтажке (это FM-тюнер). Ещё иногда сбоит слэйв который на EVB (это touchscreen-контроллер). Второй I2C-слэйв на монтажке (это FM31278/FM31T378) не сбоит никогда.

проблемы ушли - смотреть пути наводки по эфиру.. не знаю, что такое esp8266, видимо что-то радиосодержащее - возможно есть регистр регулировки мощности передатчика..

Это WiFi-чип с подключением по UART. У меня он в виде отдельного модуля.
Эфирные наводки от радиочасти должны быть не при чём вроде. Так как ESP8266 сконфигурирован чтобы после старта не подключаться ни к какой сети и не быть точкой доступа (т.е. - просто ждёт AT-команд).
И для теста даётся команда AT+GMR - это запрос информации о прошивке (версия и т.п.), по этой команде вроде приёмник/передатчик включать не надо. И уже на эту команду происходит сбой.
Мощность передатчика регулируется программно.
ESP8266 при работе по эфиру потребляет прилично - становится горячим на ощупь когда открыт сокет и через него идёт поток данных.

нельзя ли временно на соплях отцепить stm32 и подключить LPC на i2c дефективной платы?

Сейчас вроде появился какой-то прогресс!
Я сделал немного по-другому - постарался максимально возможно повторить конфигурацию проводов как было с платой LPC.
К LPC-ной плате у меня ESP8266 подключался отдельно от монтажной платы, отдельным многожильным кабелем длиной порядка 15 см. При переходе же на STM32 я расположил разъём для ESP8266 на монтажной плате.
Сейчас попробовал воткнуть ESP8266 не напрямую в этот разъём, а через кабель длиной примерно 15см - и о чудо - сбои по I2C почти пропали!!!
За последние 15 минут теста всего один раз сбойнуло. До этого буквально максимум после 10сек после начала теста следовал сбой. (тест - периодическая посылка команды AT+GMR к ESP8266).
Похоже надо во все провода к ESP8266 добавить последовательные резисторы ом на 50.

[Jury093]

Сейчас попробовал воткнуть ESP8266 не напрямую в этот разъём, а через кабель длиной примерно 15см - и о чудо - сбои по I2C почти пропали!!!
За последние 15 минут теста всего один раз сбойнуло. До этого буквально максимум после 10сек после начала теста следовал сбой. (тест - периодическая посылка команды AT+GMR к ESP8266).

хорошо.. еще варианты:
- на контакты питания esp8266 навесить 22-50uF
- для теста закормить плату с esp8266 от отдельного стабилизатора, в идеале только esp8266
- в точке подключения пуллапов i2c к +3в3 временно припаять кондей на 10uF, у вас два комплекта пуллапов, тогда и на второй тоже свой кондей - может удасться этим отсечь возможный путь для помех..

У Вас возможно та же проблема из-за Wi-Fi модуля, у него броски потребления до 40 мА.

насчет бросков не знаю, но в топе потребляет:

Tx802.11b, CCK 11Mbps, P OUT=+17dBm - 170 - mA

[jcxz]

- на контакты питания esp8266 навесить 22-50uF
- для теста закормить плату с esp8266 от отдельного стабилизатора, в идеале только esp8266
- в точке подключения пуллапов i2c к +3в3 временно припаять кондей на 10uF, у вас два комплекта пуллапов, тогда и на второй тоже свой кондей - может удасться этим отсечь возможный путь для помех..

Это всё делалось - ничего не помогло.
Написал тесты плотной работы со всеми слэйвами на шине, запускал эти тесты на несколько часов: если без обмена с 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 нормально работает, но.... (((

[Obam]

Сейчас вдруг решил поменять режим ноги SCL на МК на push-pull вместо open-drain. И все проблемы исчезли! Работает ещё недолго, но уже полчаса прошло - такого ещё не было.
Достаточно ничего не меняя опять вернуть open-drain ножке SCL - сразу начинает сбоить.

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

[jcxz]

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

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