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

Пока нет под рукой. Не думал что для подключения простейшего 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

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

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

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

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

Ну, если Ваши слэйвы клок не придерживают - Вам повезло. Но вообще-то это хрень какая-то... Ваш "прием" по сути означает резкое уменьшение импеданса шины в "единице". Очень похоже на сильную наводку или звон с амплитудой, пробивающей клампы...

Напротив, полагаю, если режим Buse не используется, то всегда лучше иметь SCL в push-pull, это существенно уменьшает возможности для проникновения на шину помех

Прочитайте мой пост внимательнее - я включил push-pull вместо open drain (стандартного для I2C). Подтягивающие резисторы при этом не используются.
До этого включал и отключал и внутренние и внешние подтяжки в разных комбинациях - не было никакого толку.


Вы не понимаете схему включения. Всё описано постами выше.


Я согласен с Вами, что это хрень. Поэтому и долго не пробовал так сделать.
Но пока вроде всё работает ок до 400кГц со всеми слэйвами.
Да и ещё я как-то думал, что в STM32 (мало опыта с ними) характеристики пина определяются включенной альтернативной функцией и думал что невозможно включить push-pull для пинов если для них выбрана функция I2C. В некоторых других МК именно так.


Кто-ж его знает - используется или нет? Я же не могу влезть в схемотехнику всех своих слэйвов.
Но пока вроде всё работает ок до 400кГц со всеми слэйвами.

В свое время делал следующее: в существующий измерительный прибор необходимо было добавить блок памяти, решил использовать i2c, так как только два порта контроллера прибора были доступны и они же использовались для обмена с дисплеем для отображения результатов, и все это в ограниченном объеме. Добавил м\с памяти на платку дисплея. Все это работало в руках на проводах, как собираем все в корпус сбой при обмене. Пришлось экранировать шину i2c, на шлейфе, соединяющим платку дисплея, между шинами scl и sda и с двух сторон оставить заземленные проводники. И после этого все равно были единичные сбои, пришлось организовать обмен с подтверждением и циклическим контролем.
Какие причины возникновения помехи: импульсный ток в цепи питания и по землям от внешнего устройства и радиопомеха на шину i2c. На 32F429IDISCOVERY есть резисторы подтяжки шины, R29 и R30 номиналом 4,7 кОм. Когда включается push pull используется верхний транзистор управления порта, то есть он шунтирует резистор подтяжки и тем самым вероятно устраняет влияние помехи. По всей видимости i2c, организованный на этом порте, может работать в режиме мастера, и все равно это нарушение протокола i2c.

"Открытый сток/коллектор" на шине SCL нужен исключительно для реализации функции Buse, то есть, что бы слейвы имели возможность притормозить обмен. Если Buse в изделии не используется, нет ни какого смысла конфигурировать SCL в режим открытого коллектора.

Какой-какой функции?

Наверное busy. Или clock stretch применительно к I2C.

Я бы предположил, что ESP8266 иногда ловит ложное старт-условие с последующим обнаружением своего адреса, после чего "полноправно" лезет на шину со своими данными. Как отловить такую ситуацию, надеюсь, пояснять не нужно.

Ребята, а давайте читать тему целиком, а не только последнее сообщение?

Повторю для непонятливых:
Не знаю что такое "Buse", но если это "clock stretch", то как определить: "используется в изделии" он или нет?


Что Вы имеете в виду под подтверждением? Стандартный ACK? Так он и так есть.
И что такое "циклический контроль"?
Свой протокол обмена по I2C я накрутить не могу - у меня связь не между двумя МК.
Сбои идут в виде: NACK на передачу адреса слэйва; arbitration lost, bus error и т.п.
Можно конечно усложнить драйвер I2C - добавить обработку этих ситуаций, в виде повторных транзакций и т.п.
Но неохота это делать, ибо: во 1-х - получается громоздко; во-2-х - считаю принципиально неверным подход придумывания костылей по устранению последствий вместо лечения самой причины (а причина - аппаратная, а не программная).


Он и работает в режиме мастера всегда. Других мастеров на шине нет.
Про "clock stretching" знаю. Надеюсь мои слэйвы его не используют.


Спасибо

1) клоки посмотреть. в норме должны стоять ровные посылки по 9 клоков с паузой. если конечно пауза есть. в середине посылки если есть дрожание - это уже намек на стретч.
2) можно врезать резистор в цепь клока. и на нем будет видно - просаживает ли слейв свой конец или нет.

Это слишком трудоёмко + не даёт гарантированного результата. Ибо - задержка клока слэйвом может производиться по его внутренней логике, которую я не знаю.
Не всегда, а только в определённых ситуациях.
Например:
Часы RTC, запись нового значения - теоретически может быть выставлен "clock stretch" если момент записи точно попал в момент обновления внутренних регистров, на время до окончания обновления. Вероятность попадания очень мала и поймать такой случай на осциллографе не получится.
Этот пример просто как предположение, но можно напридумывать кучу других ситуаций. Не зная внутренней схемы устройства слэйва, узнать в каких случаях он использует "clock stretching" невозможно.

PS: Да и вопрос мой был риторический. Просто товарищ не читает ответов ему, а повторяет одно и то же.

Busy. Можно внедрить последовательный резистор в тактовый сигнал, чтобы определить, кто виноват. Но...

Вот именно. А как мы находим аппаратные косяки? Правильно, осциллографом. Пора привлечь, давно пора было, с первого сообщения (ладно, со второго).

См. сообщение выше.

При хардовой реализации слэйвов нет причин закладываться на неиспользование clock stretch...Показали бы осциллограмы, глядишь дурацких неадекватных советов поубавится... а может прибавится... Но точно что-то изменится

Уже посм. но до после того, как написал. НОлитое не обратно же выливать. Осциллограммы когда?
P.S. Не обязательно нести гору (осциллограф) к Магомету. Можно и наоборот.

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

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

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


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

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

на всякий случай полистайте еррату на свое семейство, мало ли какой пункт из 7 по i2c стал вашим случаем..

Всем привет.
Проблема живет не только у STM32, кстати.
Но вот я тоже, помню, сталкивался с подобным: (клик).
Я на плате предусмотрел отключение питания ведомого устройства полевым транзистором, однако датчик I2C-шный настолько мало потреблял, что ему хватало сохранять блокировку шины из-за сквозного тока транзистора, питающего микросхему (судя по даташитам на транзистор и датчик).

Поэтому я воспользовался алгоритмом программного сброса линии - подавал 9 или 10 импульсов на SCL при отпущенном SDA, сбрасывал периферию I2C со стороны STM32 и затем все снова работало.

Вот еще одна статейка по этому поводу (по сути то же самое).

Соедините плату с модулем(ESP8266) кортоким кабелем, а сам модуль - в жестяной(Fe) экран.
Если сбои пропадут полностью - наводка по радиочастоте. И может даже не на I2C, а напр. на частотозадающие
элементы процессора.

Дык... ТС сообщил, что перевод SCL в PUSH-PULL снимает проблемы. Похоже искать надо в цепях I2C. А вообще-то это удача - при переходе с Discovery на штатную плату известно, чего бояться

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

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

Такой у меня есть, только в ловле помех от него нет никакого проку.
Есть и нормальный осцилл, только дома, а дом далеко. :-(


Известно чего - того же
Сбоит в 99% случаев один алэйв - хто подуль с алиэкспресса
И сомневаюсь что и осцилл вряд-ли поможет - помеха почти не действует на другие слэйвы, а значит скорей всего на шине её вряд-ли будет видно.
Не будет тут штатной платы - домашняя поделка это


Вряд-ли на процессор, так как я же писал выше - на шине 3 слэйва, сбоит почти всё время один из них, 2й - очень редко, при особых условиях, 3й - вообще ни одного сбоя не видел на нём. А в тестах нагружал их примерно равномерно, даже 3го - пожалуй больше всех. Если бы проблема была в МК - распределение было бы примерно равномерное.


У меня это делается всегда при старте ПО. Кроме того - я после этого ещё 12 раз стоп-условие на шине формирую. Так как просто импульсы по SCLK не всегда могут помочь.

На всякий случай, Phillips подключает свои м/схемы к шине I2C через низкоомные резисторы от 47 до 100 Ом:
Нажмите для просмотра прикрепленного файла

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

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

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

Последовательные резисторы отражения давят. Особенно эффективны, когда эти отражения есть. Например, при очень большом импедансе на конце линии.

Ну так об об этом и речь. В данном случае это I2C: скорость (как правило) невысока, длина линий (вероятно) небольшая, фронты (должны быть) нерезкие. Т.е. собственно для сигналов I2C реактивная составляющая импеданса несущественна и об отражениях можно не беспокоиться. Если в схеме не используется экзотика типа изоляторов, то активная составляющая импеданса в "0" близка к нулю, в "1" - близка к значению пулл-апов, на что и был намек (исходные предположения сделаны исключительно по субъективным впечатлениям от информации ТС).

Отражения, они всегда есть при несогласованных волновом сопротивлении линии и выходном сопротивлении источника сигнала и сопротивлении нагрузки (приемника). Спасает то, что когда длительность фронта сигнала больше времени распространения сигнала туда и обратно, эти отражения не видны, не успевают проявиться. Завалить фронт и призваны последовательные резисторы.
При больших пулл-апах запросто могут быть отражения. Которые нужно устранить. А вы пишете, "как мертвому припарки".