Перейти к содержанию
    

- на контакты питания 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 нормально работает, но.... :((((

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Достаточно ничего не меняя опять вернуть open-drain ножке SCL - сразу начинает сбоить.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Может быть имеет смысл провести отдельным проводником напряжение питания непосредственно от контактов питания контроллера до резисторов подтяжки.

Изменено пользователем AnatolyT

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это конечно неправильно и противоречит спецификации I2C, но ничего не поделаешь - оставлю наверное push-pull для SCL.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

До этого включал и отключал и внутренние и внешние подтяжки в разных комбинациях - не было никакого толку.

 

Может быть имеет смысл провести отдельным проводником напряжение питания непосредственно от контактов питания контроллера до резисторов подтяжки.

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

 

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

Я согласен с Вами, что это хрень. Поэтому и долго не пробовал так сделать.

Но пока вроде всё работает ок до 400кГц со всеми слэйвами.

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

 

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

Кто-ж его знает - используется или нет? Я же не могу влезть в схемотехнику всех своих слэйвов.

Но пока вроде всё работает ок до 400кГц со всеми слэйвами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В свое время делал следующее: в существующий измерительный прибор необходимо было добавить блок памяти, решил использовать i2c, так как только два порта контроллера прибора были доступны и они же использовались для обмена с дисплеем для отображения результатов, и все это в ограниченном объеме. Добавил м\с памяти на платку дисплея. Все это работало в руках на проводах, как собираем все в корпус сбой при обмене. Пришлось экранировать шину i2c, на шлейфе, соединяющим платку дисплея, между шинами scl и sda и с двух сторон оставить заземленные проводники. И после этого все равно были единичные сбои, пришлось организовать обмен с подтверждением и циклическим контролем.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

нужен исключительно для реализации функции Buse
Какой-какой функции?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я бы предположил, что ESP8266 иногда ловит ложное старт-условие с последующим обнаружением своего адреса,

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

Он подключен по UART - коллизий никаких быть не может. На AT-команды отвечает.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если Buse в изделии не используется, нет ни какого смысла конфигурировать SCL в режим открытого коллектора.

Повторю для непонятливых:

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

 

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

Что Вы имеете в виду под подтверждением? Стандартный ACK? Так он и так есть.

И что такое "циклический контроль"?

Свой протокол обмена по I2C я накрутить не могу - у меня связь не между двумя МК.

Сбои идут в виде: NACK на передачу адреса слэйва; arbitration lost, bus error и т.п.

Можно конечно усложнить драйвер I2C - добавить обработку этих ситуаций, в виде повторных транзакций и т.п.

Но неохота это делать, ибо: во 1-х - получается громоздко; во-2-х - считаю принципиально неверным подход придумывания костылей по устранению последствий вместо лечения самой причины (а причина - аппаратная, а не программная).

 

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

Он и работает в режиме мастера всегда. Других мастеров на шине нет.

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

 

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

Спасибо :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Повторю для непонятливых:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...