Jump to content

    
Sign in to follow this  
jcxz

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

Recommended Posts

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

Share this post


Link to post
Share on other sites
Неужели I2C на STM32F4 такой нежный???

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

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

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

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

 

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
Да и странно это как-то - на LPC1788 всё работало вообще как есть без всяких фильтров и даже просто - всё на соплях болталось на проводах и работало!

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

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

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

 

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

Edited by KnightIgor

Share this post


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

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

Share this post


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

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

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

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

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

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

 

 

 

 

 

 

 

 

 

 

post-127-1491290955_thumb.png

Share this post


Link to post
Share on other sites
…проблема из-за Wi-Fi модуля, у него броски потребления до 40 мА.

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

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

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

Share this post


Link to post
Share on other sites
Правильно ли 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 вроде есть фильтры. И аналоговый и цифровой. И у меня они включены. Получается, что не работают.... :(((

Share this post


Link to post
Share on other sites
Да неужто для работы обычного 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 дефективной платы?

Share this post


Link to post
Share on other sites
мнэ.. вы же понимаете, что без схемы и монтажки давать более предметные советы могут только телепаты со стажем..

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

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

Share this post


Link to post
Share on other sites
Сейчас попробовал воткнуть 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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this