jcxz 234 11 апреля, 2017 Опубликовано 11 апреля, 2017 · Жалоба 1) клоки посмотреть. в норме должны стоять ровные посылки по 9 клоков с паузой. если конечно пауза есть. в середине посылки если есть дрожание - это уже намек на стретч. Это слишком трудоёмко + не даёт гарантированного результата. Ибо - задержка клока слэйвом может производиться по его внутренней логике, которую я не знаю. Не всегда, а только в определённых ситуациях. Например: Часы RTC, запись нового значения - теоретически может быть выставлен "clock stretch" если момент записи точно попал в момент обновления внутренних регистров, на время до окончания обновления. Вероятность попадания очень мала и поймать такой случай на осциллографе не получится. Этот пример просто как предположение, но можно напридумывать кучу других ситуаций. Не зная внутренней схемы устройства слэйва, узнать в каких случаях он использует "clock stretching" невозможно. PS: Да и вопрос мой был риторический. Просто товарищ не читает ответов ему, а повторяет одно и то же. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 апреля, 2017 Опубликовано 11 апреля, 2017 · Жалоба Повторю для непонятливых: Не знаю что такое "Buse", но если это "clock stretch", то как определить: "используется в изделии" он или нет? Busy. Можно внедрить последовательный резистор в тактовый сигнал, чтобы определить, кто виноват. Но... ...вместо лечения самой причины (а причина - аппаратная, а не программная). Вот именно. А как мы находим аппаратные косяки? Правильно, осциллографом. Пора привлечь, давно пора было, с первого сообщения (ладно, со второго). :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 11 апреля, 2017 Опубликовано 11 апреля, 2017 · Жалоба Busy. Можно внедрить последовательный резистор в тактовый сигнал, чтобы определить, кто виноват. Но... См. сообщение выше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 11 апреля, 2017 Опубликовано 11 апреля, 2017 · Жалоба 1) клоки посмотреть. ... При хардовой реализации слэйвов нет причин закладываться на неиспользование clock stretch...Показали бы осциллограмы, глядишь дурацких неадекватных советов поубавится... а может прибавится... Но точно что-то изменится Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 апреля, 2017 Опубликовано 11 апреля, 2017 · Жалоба См. сообщение выше. Уже посм. но до после того, как написал. НОлитое не обратно же выливать. Осциллограммы когда? P.S. Не обязательно нести гору (осциллограф) к Магомету. Можно и наоборот. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnatolyT 0 11 апреля, 2017 Опубликовано 11 апреля, 2017 (изменено) · Жалоба Осциллограммы посмотреть можно, чтобы убедиться в правильности формирования протокола, хотя несинхронную помеху сложно будет увидеть. Раньше тоже думал, стоит только поставить конденсатор или дроссель в нужное место и все сразу заработает и проблемы исчезнут, не исчезнут, почти всегда приходится изменять топологию или конструкцию. Если вы уверены в протоколе и откуда то все равно идет помеха, попробуйте как-нибудь заэкранировать шину i2c от платы discovery до внешнего устройства, экран землите с одной стороны, чтобы по нему ток не ходил. Если помеха проходит через резисторы подтяжки R29 R30, а это вполне вероятно, тогда можно снять их с платы discovery и для пробы поставить в конец шины i2c на внешнее устройство, тогда потеряем в надежности, если оно отвалится, вся шина не будет работать. Если это поможет, то можно на плате discovery аккуратно отрезать резисторы подтяжки от питания, восстановить шину питания в этом месте, вернуть резисторы назад и подать напряжение на них проводом непосредственно с контактов питания контроллера. Обмен с подтверждением с кодом циклического контроля, КЦК или CRC, в моем случае пишем блок 264 байта в память dataflash, 256 байт данных и 8 байт CRC, затем читаем его и проверяем CRC, при ошибке пишем повторно. Изменено 11 апреля, 2017 пользователем AnatolyT Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным 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 12 апреля, 2017 Опубликовано 12 апреля, 2017 · Жалоба Насчёт осцилла: так как проблема потеряла остроту (пока временное решение с активным SCL устраивает) и есть более важные проблемы (с ПО на всякий случай полистайте еррату на свое семейство, мало ли какой пункт из 7 по i2c стал вашим случаем.. STM32F40x and STM32F41x Errata sheet Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 16 апреля, 2017 Опубликовано 16 апреля, 2017 · Жалоба Всем привет. Проблема живет не только у STM32, кстати. Но вот я тоже, помню, сталкивался с подобным: (клик). Я на плате предусмотрел отключение питания ведомого устройства полевым транзистором, однако датчик I2C-шный настолько мало потреблял, что ему хватало сохранять блокировку шины из-за сквозного тока транзистора, питающего микросхему (судя по даташитам на транзистор и датчик). Поэтому я воспользовался алгоритмом программного сброса линии - подавал 9 или 10 импульсов на SCL при отпущенном SDA, сбрасывал периферию I2C со стороны STM32 и затем все снова работало. Вот еще одна статейка по этому поводу (по сути то же самое). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 16 апреля, 2017 Опубликовано 16 апреля, 2017 · Жалоба . . . 4) при подключении ESP8266 не напрямую в разъём на монтажную плату возле слэйвов короткими проводами, а в этот же разъём через удлинитель порядка 15 см - даёт кратное уменьшение кол-ва сбоев (но всё равно остаются, да и не устраивает такое конструктивно); . . . . Соедините плату с модулем(ESP8266) кортоким кабелем, а сам модуль - в жестяной(Fe) экран. Если сбои пропадут полностью - наводка по радиочастоте. И может даже не на I2C, а напр. на частотозадающие элементы процессора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 16 апреля, 2017 Опубликовано 16 апреля, 2017 · Жалоба ... И может даже не на I2C, а напр. на частотозадающие элементы процессора. Дык... ТС сообщил, что перевод SCL в PUSH-PULL снимает проблемы. Похоже искать надо в цепях I2C. А вообще-то это удача - при переходе с Discovery на штатную плату известно, чего бояться :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nosaer 0 17 апреля, 2017 Опубликовано 17 апреля, 2017 · Жалоба Я бы вам на будущее посоветовал обзавестись вот таким логическим анализатором, благо цена копейки. После того как я его купил, я проблемы с протоколами передачи данных решаю в разы быстрее. Там можно настроить под определенный протокол, и он вам не только временна покажет, но и расшифрует то, что вы передаете. Осциллограф правда полностью не заменит, но большую часть проблем с ним решите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 17 апреля, 2017 Опубликовано 17 апреля, 2017 · Жалоба ...большую часть проблем с ним решите. Не в этом случае, к сожалению... :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Я бы вам на будущее посоветовал обзавестись вот таким Такой у меня есть, только в ловле помех от него нет никакого проку. Есть и нормальный осцилл, только дома, а дом далеко. :-( Дык... ТС сообщил, что перевод 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 25 19 апреля, 2017 Опубликовано 19 апреля, 2017 · Жалоба Насчёт резисторов подтяжки - совет хороший, я тоже думал на этот счёт. Оставил это пока на крайний случай. На всякий случай, Phillips подключает свои м/схемы к шине I2C через низкоомные резисторы от 47 до 100 Ом: PS. Всю тему не читал, может, кто уже советовал.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться