[jcxz 51]

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

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

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

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

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

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

 

[ViKo 2]

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

[Obam 8]

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

 

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

 

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

 

[KnightIgor 2]

Да и странно это как-то - на LPC1788 всё работало вообще как есть без всяких фильтров и даже просто - всё на соплях болталось на проводах и работало!

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

"У меня есть гипотеза" - как говаривал маленький и любознательный динозаврик из "Поезда динозавров". На гипотезу навело меня упоминание об LPC1788, с которым было все хорошо.

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

 

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

Edited April 3, 2017 by KnightIgor

[jcxz 51]

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

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

[KnightIgor 2]

На LPC1788 все было спаяно на соплях - ESP8266 вообще на проводах висел. Здесь же решил сделать получше - спаял на отдельной платке, ещё и блокировочных кондёров понавесил, провода укоротил - и на тебе - ещё хуже получилось :((

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

 

[Шаманъ 0]

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

Дальше на плате навесил разной керамики и 0.1мкФ и 10мкФ прямо возле ног сбоящей I2C-периферии и возле ESP8266.

Потом вообще отделил ESP8266 по питанию и по GND дросселями 22мкГн - кол-во сбоев снизилось в разы, но всё равно неприемлемо много.

[Sanya_kv 0]

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

Проблему на первых парах решали циклическим кодированием и ферритовыми кольцами. В последствии поставили в схеме ёмкости 5.6рF на принимающих проводниках.

[ANT 0]

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

Проблему на первых парах решали циклическим кодированием и ферритовыми кольцами. В последствии поставили в схеме ёмкости 5.6рF на принимающих проводниках.

Вот ещё фильтр, который я успешно применял :)

https://www.google.ru/url?sa=t&rct=j&am...bGg&cad=rja

 

 

 

 

 

 

 

 

 

 

[Obam 8]

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

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

Проблему на первых парах решали…

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

[jcxz 51]

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

Когда изначально писал драйвер I2C, естественно проверил правильность установок SCLK лог.анализатором.

Сейчас пробовал и на 300кГц и на 80кГц - без разницы - сбои одинаковые.

 

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

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

 

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

Проблему на первых парах решали циклическим кодированием и ферритовыми кольцами. В последствии поставили в схеме ёмкости 5.6рF на принимающих проводниках.

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

Ёмкости на каких принимающих ставили? UART-а или I2C? И какая скорость была по этим интерфейсам?

Тоже думал о необходимости малых емкостей.

 

Вот ещё фильтр, который я успешно применял :)

Надо будет попробовать. Хотя там написано "However, programmable devices generally do not have built-in noise filters on their GPIO pins."

А в I2C-контроллере STM32F429 вроде есть фильтры. И аналоговый и цифровой. И у меня они включены. Получается, что не работают.... :(((

[Jury093 1]

Да неужто для работы обычного 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 51]

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

Схемы/монтажки нет. Как я писал выше - это макет.

Т.е.: 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 1]

Сейчас попробовал воткнуть 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