Есть небольшой проектик на 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 такой нежный???

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

А осциллограммы I2C шины будут продемонстрированы? О, предыдущий оратор опередил.

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

Дросселя "по земле" могут ухудшать результат.

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

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

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

Сообщение отредактировал KnightIgor - Apr 3 2017, 12:40

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


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


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


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


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


Как вариант.


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 вообще на проводах висел. Здесь же решил сделать получше - спаял на отдельной платке, ещё и блокировочных кондёров понавесил, провода укоротил - и на тебе - ещё хуже получилось (

Правильно ли I2C проинициализирован? Может слишком шустро?

jcxz, тактируете это дело я так понимаю от HSE? Если да, то попробуте от HSI запустить и расскажите нам, изменилось ли что...есть одна мысль, на которую наводит эта фраза:

Сталкивался с подобной проблемой, импульсными наводками на 20 см кабель UARTа от модуляций тока в соседнем кабеле. У Вас возможно та же проблема из-за Wi-Fi модуля, у него броски потребления до 40 мА.
Проблему на первых парах решали циклическим кодированием и ферритовыми кольцами. В последствии поставили в схеме ёмкости 5.6рF на принимающих проводниках.

Вот ещё фильтр, который я успешно применял
https://www.google.ru/url?sa=t&rct=j&am...bGg&cad=rja

Это броски? Может до 400мА?

Да, пары пропускать "не комильфо" - черевато отработкой (;

Когда изначально писал драйвер I2C, естественно проверил правильность установок SCLK лог.анализатором.
Сейчас пробовал и на 300кГц и на 80кГц - без разницы - сбои одинаковые.


Попробовал - ничего не изменилось. Попробовал ещё понизить частоту МК до 48 (частота APB1 стала = 24МГц) - тоже без разницы, что на внешнем кварце, что на внутреннем RC.


Кодированием решать невозможно, ибо протокол обмена задан жёстко. Да и неправильно это - решать аппаратные проблемы программными затычками.
Ёмкости на каких принимающих ставили? UART-а или I2C? И какая скорость была по этим интерфейсам?
Тоже думал о необходимости малых емкостей.


Надо будет попробовать. Хотя там написано "However, programmable devices generally do not have built-in noise filters on their GPIO pins."
А в I2C-контроллере STM32F429 вроде есть фильтры. И аналоговый и цифровой. И у меня они включены. Получается, что не работают.... ((

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


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


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


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

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


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


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

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


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

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