Почему i2c сканер не видит ЖК дисплей с модулем i2c?
Всем привет! Заказал с Китая ЖК дисплей 1602A с модулем для подключения по i2c. Загрузил скетч(ошибок не было), но ничего не выходит. Регулировал контрастность, но ничего. Запустил i2c сканер, но пишет «No I2C devices found». Почему он не видит дисплей? Разъемы подключил правильно.
+ при регулировании контрастности горит только верхняя строчка, нижняя ели ели виден. Это получается неисправен дисплей или что?
P.S Модуль к дисплею припаял сам, замыкании нет.
Нестабильная работа с I2C под STM32
Волею судеб мне пришлось разрабатывать прошивку для одного устройства на основе микроконтроллера STM32F103. Функций у устройства много, в том числе и общение с EEPROM подключенным посредством протокола I 2 C. Кто не знает, микроконтроллеры STM32 во многих своих версиях поддерживают работу по данному протоколу на аппаратном уровне. Это значит, что у микросхемы микроконтроллера присутствуют специальные выводы, которые можно использовать в том числе и для работы по протоколу I 2 C, а все издержки по этому протоколу выполняются «железом» микроконтроллера.
Вообще, I 2 C — штука популярная. Реализуется не так сложно, для его работы требуется всего два сигнальных провода. По одному подаются тактовые импульсы, по второму происходит передача данных, привязанная к тактам первого провода. К шире или выводам I 2 C можно подключить несколько устройств, они не будут мешать друг-другу, т.к. при обращении к конкретному устройству указывается его уникальный адрес.
Шина I 2 C не высокоскоростная и предназначена в первую очередь для обмена данными с различными датчиками, модулями и внешними системами. Через шину прокачать много информации не выйдет, но этого и не требуется. Главное, что она проста, дешева и универсальна. Ну много ли данных передает в секунду датчик температуры или давления? Сущие байты. Этого вполне достаточно.
Как правило в шине I 2 C применяется система с одним ведущим устройством и подключаемыми к нему ведомыми. В качестве ведущего устройства, разумеется, используется микроконтроллер. И он опрашивает подключенные устройства, в надежде получить с них данные. Каким же образом передаются данные по-фактически одному проводу? Конечно, передача данных по одному проводу в I 2 C не является полнодуплексной. Нет возможности в стандарте по одному проводу передавать и принимать данные одновременно. Поэтому, команды на передачу дает ведущее устройство, а все остальные слушают и отвечают, когда это им позволяется.
Простота протокола I 2 C иногда оборачивается и обратной стороной. Отлаживать проблемы, возникающие в коммуникации с внешними устройствами зачастую очень не просто. Ведь в цифровом мире либо устройство работает, либо нет. А еще больше усложняет проблему случай, когда вроде бы работает, а потом, по какой-то причине не совсем работает. Вот именно такая петрушка и произошла в моем случае.
Для реализации микропрограммы был выбран фреймворк STM32Arduino, так как требовалось использовать некоторые библиотеки, которые легче взять готовые, нежели разрабатывать их заново. К чипу же STM32 подключена обычная микросхема EEPROM на несколько килобит. EEPROM используется для частых записей, для чего не предназначена Flash-память на чипе STM32. Все аппаратные подключения проведены в строгом соответствии с документацией как производителя микроконтроллера, так и микросхемы EEPROM. И именно проверка того, как сделаны аппаратные подключения, надежно ли питание, есть ли все необходимые подтяжки и прочее, должна происходить в самую первую очередь, если возникла проблема. Иначе можно потратить годы на то, чтобы найти программную причину ошибки, особенно там, где ее нет.
В моем случае проблема заключалась в выдаче недостоверных результатов с EEPROM и невозможность записи. Точнее запись проходила, но на конечный осмысленный результат они никак не влияла. Причем неполадка появлялась только после аппаратного перезапуска устройства и примерно один раз из десяти. Присутствие какой-либо адекватной реакции от всех программах слоев, на которые опирается STM32Duino ожидать не стоит. I 2 C протокол простой и он либо работает, либо нет. И он работал, выдавал данные, причем даже если данные с EEPROM приходили откровенно левые, то никакие ошибки обращения с библиотекой Wire не возникало. Пришлось начать копать интернет в поисках похожих ошибок и методов их решения.
Как оказалось, проблема при работе с I 2 C на чипах STM32, особенно семейства F103, возникает чуть ли не у каждого второго пользователя чипов. Причем независимо от того, на чем он пишет свой код: HAL, Arduino, Mbed или еще чего. Проблем возникает много, у кого-то ничего не работает сразу, что несколько легче, так как искать ошибку проще, а у других все работает из коробки, но не постоянно. Основные проблемы, на которые натыкаются пользователи кроются в некоторых, назовем их так, особенностях структуры чипов STM32F10x, да ошибках, которые присутствуют в HAL.
Приведу основные причины возникновения неполадок с I 2 C, полученные после изучения «всего интернета»:
- Ненадежное аппаратное подключение, ненадежное неверное питание, несоблюдение рекомендаций по подключению.
- Блокировка шины на стороне микроконтроллера со статусом Busy.
- Перепутанные выходы, перепутанная инициализация при добавлении второго канала I 2 C на многоканальных чипах. Ошибка из серии «Я скопировал оттуда, где работало, а тут не работает».
Кстати, последняя ошибка встречается не столько при простом копировании кода, завязанного на работу через I 2 C, а сколько на его инициализацию. STM32 штука сложная и если невнимательно работать с Cube или писать инициализацию своими руками, то наверняка куда-то может затесаться мизерная ошибочка, которую замыленный глаз уже не в состоянии разглядеть. Вторая же ошибка по большей части связана с неверной (а зачастую с бездумной) инициализацией микроконтроллера, но присутствуют и особенности реализации (читай ошибки) в самом чипе. С ними (обнаруженными и признанными) и объясняется что делать в замечательном документе Errata sheet (ссылка внизу статьи).
В общем наилучшее, что мог создать коллективный разум, это код принудительной переинициализации функции I 2 C через HAL с дополнительными задержками:
/* USER CODE BEGIN SysInit */
HAL_RCC_I2C1_CLK_ENABLE();
HAL_Delay(100); HAL_RCC_I2C1_FORCE_RESET();
HAL_Delay(100);
__HAL_RCC_I2C1_RELEASE_RESET();
HAL_Delay(100);
/* USER CODE END SysInit */
В Arduino на STM32 данный блок так же можно применить, но он не помогает, по крайней мере, в моем случае. Пришлось еще немного пораскинуть мозгами и попытаться докопаться до причины проблемы, а потом попытаться ее решить. В моем случае обмен данными с EEPROM по I 2 C идет без каких-либо проблем. Данные читаются, записываются, никаких ошибок не возникает. Только вот в одном разе из 10 после аппаратной перезагрузки всей системы, EEPROM начинает выдавать совершенно левые данные, при этом никаких ошибок не возникает. С записью тоже в такие моменты не все гладко, проверить-то никак.
Как известно, чипы STM32 многофункциональны и многие из выводов микросхем могут быть использованы под различные функции. У многих микроконтроллеров, не только у STM32, после перезагрузки, некоторые выводы могут переключиться в так называемые неинициализированные состояния. Обычный софтверный разработчик, как правило не задумывается над тем, какой у него уровень на выводах микроконтроллера после его перезагрузки. Высокий? Низкий? Серединный? При использовании фирменного конфигуратора STM32Cube есть возможность настроить инициализацию выводов и некоторых других функций микроконтроллера путем относительно простого конфигурирования. Но данная процедура может быть опущена, а инициализацию можно провести позже, например, при процедуре вызова той или иной функции. Именно последним путем и пошли разработчики STM32Duino. При загрузке микроконтроллера происходит так называемая базовая инициализация функций микроконтроллера, ножки выводов принимают значения по умолчанию. А вот если с данной конкретной ножки требуется другая функция, то ее инициализация происходит при первом вызове соответствующей функции.
В чипах STM32 инициализация происходит очень быстро, ну сами чипы скоростные, это, во-первых, а во-вторых, загрузчик не тормозит загрузку пользовательского кода, так как вызывается при соответствующей аппаратной комбинации. Значит, проблема неинициализированных «ног», когда на них болтается неизвестно что, встает не в полный рост. А вот на других чипах микроконтроллеров, где загрузчик некоторое время ожидает подачу ему сигнала и только потом переходит на пользовательский код, проблема может существенно попортить жизнь. Представьте, что на такой «ноге», которая еще не определилась с уровнем своего сигнала, «висит» управляющий контакт реле. И вот на реле идет жуткая последовательность непонятных сигналов. Что ему делать? Дергаться туда-сюда, пока микроконтроллер не определиться со своим выводом?
Опытный читатель или электронщик, уже догадался, в чем изюминка порылась. Микросхема EEPROM возвращает неверные данные, а библиотека, работающая с I 2 C, говорит, что все нормально, ошибок нет. Суть нестабильного поведения кроется в следующем. На универсальных чипах STM32F103 многие из выводов многофункциональны. При неверной инициализации или отсутствии инициализации, на «ногах», подключенных к микросхеме EEPROM, может появиться произвольный сигнал, который «сведет с ума» саму микросхему EEPROM (команды на обмен данными с EEPROM та еще китайская азбука, куча условностей, задержек и прочего). Да, она будет как-то реагировать на команды, но вот выдавать данные может совсем не те, что должна. Повторная инициализация I 2 C в микроконтроллере ничего не даст, так как ведомое устройство уже не в себе и вывести его из себя можно только аппаратной перезагрузкой микросхемы EEPROM (перезагрузка микроконтроллера тут не помогает, по той же причине, что и переинициализация через HAL).
Именно такая ситуация возникла в моем случае. Проблема возникала случайным образом, но статистически она присутствовала. Если код инициализации Wire поместить ближе к началу программного кода, то вероятность возникновения ошибки уменьшается, если отодвинуть его куда-то подальше, то ошибка будет возникать чаще. И спастись от проблемы можно только аппаратным сбросом всего оборудования (передергиванием питания).
Так как же можно избавиться от проблемы «сумасшествия» ведомой микросхемы EEPROM? Очевидно, что нужно максимально быстро проинициализировать соответствующие терминалы ввода-вывода, дабы успеть в тот момент времени, пока EEPROM не начнет жить по своим собственным законам, повинуясь непонятным сигналам с микроконтроллера. Другими словами, подвинуть код инициализации Wire в самое начало программы. Но… Данный трюк не решает полностью описанное поведение EEPROM. Все еще остается вероятность отказа EEPROM (и опыты это подтверждают). Почему? Потому, что выполнение кода инициализации Wire занимает какое-то время, бесценные микросекунды, которых хватает на то, чтоб EEPROM удалились в мир грез и фантазий. Что в этом случае можно сделать?
pinMode(I2C_SCL, OUTPUT);
pinMode(I2C_SDA, OUTPUT);
Оказалось, что достаточно только проинициализировать порты микроконтроллера, ответственные за I 2 C как выходные цифровые выводы, как можно быстрее. В этом случае цифровое, а скорее аналоговое, шатание отменяется и невменяемость EEPROM тоже. В STM32Duino при инициализации пина как выходящего, он автоматически включается на низкий уровень. Если этого не происходит, например, поменялась идеология разработчиков фреймворка или вышла новая плата, на которой все не так, то дополнительно можно принудительно установить низкий уровень, что должно обеспечить нормальную работоспособность всей связки.
А что же до любителей HAL и особенно STM32Cube? Если работать только на HAL и не прибегать к Cube, как к средству конфигурирования, то проблема будет ровно такой же. Если не применить четкую инициализацию «ног» I 2 C как можно быстрее, то нормально с EEPROM не поработаешь. Впрочем, с Cube тоже не все так гладко как хотелось бы. Да, утилита помогает провести инициализацию микроконтроллера, которая сама по себе не отличается простотой. Но и тут могут быть нюансы. Во-первых, код инициализации I 2 C из Cube может быть выполнен в самую последнюю очередь, когда уже поздно, во-вторых, могут наступить и прочие конфликты, связанные с неверной инициализацией (Cube только выглядит просто, на самом деле без понимания туда лезть не стоит). Более подробно о потенциальных проблемах можно почитать в ссылках ниже.
Почему не определяются устройства на шине i2c
Диагностика последовательных шин I 2 C
I 2 С
Рис. 4. Структура сообщения I 2 C.
Рис. 5. Меню настройки шины I 2 C.
Рис. 6. Пример шины I 2 C.
Рис. 7. Декодирование осциллограммы адресной линии и линии данных I 2 C.
задний план
На самом деле, эта статья уже давно написала решение. После продолжительной практики и углубленного изучения было установлено, что проблема аппаратного тупика I2C находится в официальном руководстве STОшибки Руководство(Ошибка) Решение было предоставлено в течение длительного времени, но я не обращал особого внимания на официальную документацию и искал помощи онлайн.
Несмотря на то, что официальное решение уже существует, все еще есть много людей (включая меня), которые подозревают, что аппаратная ошибка I2C серии STM32. Это также говорит нам о том, что, хотя он-лайн ресурсы богаты, их все равно нужно идентифицировать «золотыми глазами и огненными глазами».
Честно говоря, чтобы решить проблему I2C, я прочитал более N статей, блогов и постов в Интернете, но я не видел, чтобы несколько человек говорили "STM32 аппаратное обеспечение I2C без проблем«Напротив, я видел много похожих на это:«Я слышал, что есть проблема с аппаратным I2C STM32. После попытки я обнаружил, что это действительно проблема. Вместо этого используйте IO имитацию».。
Больше не гудит
Ниже я предоставлю решение проблемы взаимоблокировки I2C серий STM32F207 и STM32F103 (всегда в состоянии BUSY или всегда установлен START). В то же время, в нижней части, мое предыдущее решение (SDA — НИЗКОЕ) все еще сохраняется. Если вы столкнулись с проблемой установки SDA в НИЗКОЕ, вы можете использовать старое решение.
Описание тупика I2C
Проблема взаимоблокировки I2C, описанная в этой статье, выражается следующим образом:Когда связь I2C является ненормальной, SDA и SCL оба имеют высокий уровень (то есть состояние IDLE). При вызове HAL_I2C_Master_Transmit или HAL_I2C_Master_Receive, он всегда возвращает BUSY или TIMEOUT. Проверьте, что шина через логический анализатор всегда ВЫСОКАЯ.
Обычно возникает исключение такого рода:
- После того, как ведомое устройство отключает шину, Master появляется ненормально
- Связь была прервана ненормально, из-за чего Учитель был ненормальным
В STM32F207 вышеуказанные проблемы могут быть решены путем сброса программного обеспечения MCU. Однако сброс программного обеспечения MCU на STM32F103 не полностью решает проблему и часто требует выключения и перезапуска.Конечно, в обычных сценах мы не хотим решать проблему путем сброса программного обеспечения или выключения! Тогда вы должны продолжить чтение.
Отладка позволяет увидеть, что при возникновении исключения значения регистров, связанных с I2C, показаны на следующих двух рисунках.
Рисунок 1: Состояние регистра I2C, когда всегда в состоянии BUSY 
Рисунок 2: Состояние регистра I2C, когда бит START всегда установлен 
Решение STM32F207
По сравнению с STM32F103 решение STM32F207 является относительно простым, нужно толькоСброс периферийного устройства I2C, Может быть, вы скажете, что это за решение! ! ! Пожалуйста, люди не знали, что у него были биты регистра сброса периферийных устройств до
Сначала давайте взглянем на описание руководства по опечаткам. 
Example: Функция для сброса шины
В приведенной выше функции есть строка MX_I2C1_Init() Используется для настройки I2C. Это связано с тем, что значение регистра будет изменено после сброса I2C. Вы можете только настроить его снова.
Раствор STM32F103
Метод STM32F103 более проблематичен. Сначала давайте посмотрим на описание руководства по опечаткам.
Насколько я понимаю руководство по исправлению ошибок: После настройки вывода как обычного выходного вывода уровень инвертируется для достижения отмены взаимоблокировки, а затем восстанавливается в конфигурации I2C.
Example: Код разрешения
SDA для НИЗКОГО решения
Недавно в проекте была разработана вспомогательная программа IIC. Для удобства изображения я взял плату разработки STM32F207 в качестве мастера IIC и создал программу на STM32CUBE.Отправка и получение основных данныхНазываются напрямуюБиблиотека HALФункция.
Через найденный тест логического анализатора,После каждой ошибки хоста IA SDA будет переведен в низкий уровень, что приведет к блокировке всей шины IIC. Последующая передача данных происходит ненормально.Это явление показано на рисунке ниже:
Позже я проверил функцию HAL_I2C_Master_Transmit IIC библиотеки HAL.
найти: Когда происходит TIMEOUT или ERROR, мастер STM32 не генерирует сигнал STOP или не освобождает шину (SDA и SCL установлены на высокий уровень). Это приведет к следующей записи в HAL_I2C_Master_Transmit после TIMEOUT или ERROR. Мастер будет считать шину IIC занятой и откажется от связи, что приведет к блокировке SDA.
Затем я внес некоторые изменения в функцию HAL_I2C_Master_Transmit, как показано в следующей программе.
NOTE: Если это программа, созданная с помощью HAL_I2C_Master_Transmit, вы должны скопировать эту программу и сохранить ее в другом файле при внесении изменений, в противном случае, когда вы используете STM32CUBE для изменения программы, исходные изменения будут перезаписаны.
Ниже приведен модифицированный эффект： 