Это слишком трудоёмко + не даёт гарантированного результата. Ибо - задержка клока слэйвом может производиться по его внутренней логике, которую я не знаю.
Не всегда, а только в определённых ситуациях.
Например:
Часы 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, при ошибке пишем повторно.

Сообщение отредактировал AnatolyT - Apr 11 2017, 22:41

Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным 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 Ом:
[attachment=106748:EEPROM.jpg]

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