[jcxz 213]

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

Это слишком трудоёмко + не даёт гарантированного результата. Ибо - задержка клока слэйвом может производиться по его внутренней логике, которую я не знаю.

Не всегда, а только в определённых ситуациях.

Например:

Часы RTC, запись нового значения - теоретически может быть выставлен "clock stretch" если момент записи точно попал в момент обновления внутренних регистров, на время до окончания обновления. Вероятность попадания очень мала и поймать такой случай на осциллографе не получится.

Этот пример просто как предположение, но можно напридумывать кучу других ситуаций. Не зная внутренней схемы устройства слэйва, узнать в каких случаях он использует "clock stretching" невозможно.

 

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

[ViKo 1]

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

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

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

...вместо лечения самой причины (а причина - аппаратная, а не программная).

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

[jcxz 213]

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

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

[Axel 1]

1) клоки посмотреть. ...

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

[ViKo 1]

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

Уже посм. но до после того, как написал. НОлитое не обратно же выливать. Осциллограммы когда?

P.S. Не обязательно нести гору (осциллограф) к Магомету. Можно и наоборот.

[AnatolyT 0]

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

Если вы уверены в протоколе и откуда то все равно идет помеха, попробуйте как-нибудь заэкранировать шину i2c от платы discovery до внешнего устройства, экран землите с одной стороны, чтобы по нему ток не ходил. Если помеха проходит через резисторы подтяжки R29 R30, а это вполне вероятно, тогда можно снять их с платы discovery и для пробы поставить в конец шины i2c на внешнее устройство, тогда потеряем в надежности, если оно отвалится, вся шина не будет работать. Если это поможет, то можно на плате discovery аккуратно отрезать резисторы подтяжки от питания, восстановить шину питания в этом месте, вернуть резисторы назад и подать напряжение на них проводом непосредственно с контактов питания контроллера.

Обмен с подтверждением с кодом циклического контроля, КЦК или CRC, в моем случае пишем блок 264 байта в память dataflash, 256 байт данных и 8 байт CRC, затем читаем его и проверяем CRC, при ошибке пишем повторно.

Изменено 11 апреля, 2017 пользователем AnatolyT

[jcxz 213]

Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным SCL устраивает) и есть более важные проблемы (с ПО) - отложу это пока в сторону, тем более что доставить осцилл к устройству или устройству к осциллу пока затруднительно по географическим причинам (был бы я дома - не вопрос - через неск. минут снял-бы их).

Но по мере возможности осциллограммы сниму и выложу сюда.

В протоколе уверен почти на 100%, ибо:

1) с остановленным обменом с ESP8266 всё работает часами в разных режимах обмена со слэйвами, при старте же обмена с ESP8266 падает через неск. секунд после старта;

2) обмен с ESP8266 в данном случае простейший (тестовый) и опять-же выполняется через драйвер UART, через данный драйвер ещё два других UART-канала работают с гораздо более сложным траффиком (т.е. - драйвер можно считать отлаженным);

3) все сбои по I2C носят ярко выраженный характер помех на линии (все исключительные ситуации в ПО, типа фаултов, выходов за границы регионов памяти и т.п.) у меня максимально возможно отслеживаются;

4) при подключении ESP8266 не напрямую в разъём на монтажную плату возле слэйвов короткими проводами, а в этот же разъём через удлинитель порядка 15 см - даёт кратное уменьшение кол-ва сбоев (но всё равно остаются, да и не устраивает такое конструктивно);

5) ... многие другие причины, в том числе и субъективные :laughing:

 

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

 

Обмен с подтверждением с кодом циклического контроля, КЦК или CRC, в моем случае пишем блок 264 байта в память dataflash, 256 байт данных и 8 байт CRC, затем читаем его и проверяем CRC, при ошибке пишем повторно.

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

И самое интересное - из всех слэйвов висящих на шине, как раз I2C-FRAM память и не сбоит вообще! :laughing:

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

 

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

[Jury093 2]

Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным SCL устраивает) и есть более важные проблемы (с ПО

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

STM32F40x and STM32F41x Errata sheet

[Arlleex 160]

Всем привет.

Проблема живет не только у STM32, кстати.

Но вот я тоже, помню, сталкивался с подобным: (клик).

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

 

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

 

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

 

[k155la3 26]

. . .

4) при подключении ESP8266 не напрямую в разъём на монтажную плату возле слэйвов короткими проводами, а в этот же разъём через удлинитель порядка 15 см - даёт кратное уменьшение кол-ва сбоев (но всё равно остаются, да и не устраивает такое конструктивно);

. . . .

Соедините плату с модулем(ESP8266) кортоким кабелем, а сам модуль - в жестяной(Fe) экран.

Если сбои пропадут полностью - наводка по радиочастоте. И может даже не на I2C, а напр. на частотозадающие

элементы процессора.

 

 

[Axel 1]

... И может даже не на I2C, а напр. на частотозадающие

элементы процессора.

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

 

 

[Nosaer 0]

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

[Axel 1]

...большую часть проблем с ним решите.

 

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

[jcxz 213]

Я бы вам на будущее посоветовал обзавестись вот таким

Такой у меня есть, только в ловле помех от него нет никакого проку.

Есть и нормальный осцилл, только дома, а дом далеко. :-(

 

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

Известно чего - того же ;)

Сбоит в 99% случаев один алэйв - хто подуль с алиэкспресса :laughing:

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

Не будет тут штатной платы - домашняя поделка это :laughing:

 

Соедините плату с модулем(ESP8266) кортоким кабелем, а сам модуль - в жестяной(Fe) экран.

Если сбои пропадут полностью - наводка по радиочастоте. И может даже не на I2C, а напр. на частотозадающие

элементы процессора.

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

 

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

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

[blackfin 23]

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

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

 

 

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