Проблема I2C на процессоре STM32F303, что происходит с SDA?

Я пытаюсь добавить дисплей I2C к своему дрону с дистанционным управлением. Не могу заставить работать дисплей. Я взял тот же код и скопировал его на ядро ​​​​stm32f303k8, и дисплей заработал. Я перенес код обратно на дрон и протестировал его на процессоре STM32F303cc. Это не работает. Приведенные ниже сигналы формируют одну и ту же строку кода, проходящую через I2c на обоих чипах. Ну и конечно перекомпилировал в фреймворке cubemx для разных чипов. Желтая линия — scl. Синяя линия часы. Желтая линия с закорючками — это неработающий дрон. Остальные 2 из рабочего ядра. Что не так с сигналом на дроне, чип stm32f303cc? Почему он действительно волнистый. Оба имеют тяговые резисторы 2,2к и 4,7к. В частности, почему желтая линия внизу, на верхнем изображении, разделить 50/50 между высоким и низким на то, что выглядит как бит подтверждения? Спасибо

плохое общение

хорошая связь на ядре stm32f303k8

Что еще более важно: почему линия SDA не тянется до земли?
Если бы я знал. Первоначально на обоих чипах я использовал в общей сложности 4 резистора по 4,7 кОм, чтобы поднять напряжение на 2 линиях на 2 чипах. Затем я заменил резистор на 2,2 кОм на линии sda на верхнем графике. Никаких изменений во внешнем виде графика с проблемного дрона. Даже когда я установил шину на 10 кГц, график дрона выглядел так же. На Nucleo I2C находится на I2C1. На дроне он на I2C2. Существуют также различные скорости шины и настройки часов. Я не думаю, что это должно иметь значение. Это похоже на перетягивание каната между высоким и низким на ack
«Желтая линия — scl. Синяя линия — часы». Но «scl» — это часы, так что я не думаю, что вы имеете в виду это :-) Я думаю, вы имеете в виду, что желтая линия — это SDA, а синяя линия — это SCL (часы) — да?
да, желтая линия - sda/non clock

Ответы (1)

разделить 50/50 между высоким и низким на то, что выглядит как бит подтверждения
[...]
Это похоже на перетягивание каната между высоким и низким на подтверждении

Верно, и это означает, что ведущий I 2 C на самом деле не освободил линию SDA, чтобы ведомый I 2 C мог выполнить Ack.

В свою очередь, это означает, что контакты GPIO, используемые для шины I 2 C на I 2 C Master (вероятно, оба контакта, но определенно SDA), были неправильно сконфигурированы и оставлены по умолчанию «двухтактными», а не переключены на "открытый сток", как требуется для работы I 2 C.

Вот что вызывает «перетягивание каната», как вы его описали, или, как сказал glen_geek : «почему линия SDA не тянется до земли?» Ответ заключается в том, что SDA (и, возможно, SCL тоже, но большинство ведомых устройств не пытаются управлять им) все еще управляется ( выводом GPIO, все еще сконфигурированным как «двухтактный»), а не освобождается (только с пассивным подтягиванием). ) как контакт с открытым стоком.

Если вы полагаетесь на STM32CubeMX для написания кода инициализации, то вы либо только что обнаружили ошибку в используемой вами версии (ищите обновления и опечатки), либо неправильно настроили ее (я не использую ее, поэтому могу' не скажу вам, какая настройка может быть неправильной).

На Nucleo I2C находится на I2C1. На дроне он на I2C2.

Таким образом, порты I 2 C различаются в рабочей и нерабочей конфигурациях. Это может легко объяснить, почему ваша проблема проявляется только в одной конфигурации, если инфраструктура STM32CubeMX неправильно инициализирует I2C2 (и были ошибки инициализации портов, которые затрагивают только некоторые порты).

Вау, это чрезвычайно проницательно. Спасибо. Я купил прицел, чтобы увидеть это. Я копался в этом в течение нескольких недель, изучая все виды изящных вещей. Когда код был создан STM32CubeMX, это был в основном проект по умолчанию для nucleo. Проект по умолчанию от cubemx для платы STM32F303cc имел i2c2 на выводах pf0 и pf1. Мне пришлось переключить их на PA9 и Pa10, чтобы работать с дорожками к этим контактам. это на дроне между дисплеем и процессором.
Я еще раз посмотрю на код, я помню, что он был в основном таким же. .. Помечен как открытый сток в обоих. Я посмотрю на это больше и посмотрю, что отличается. Я должен признать, что один находится на i2c1, а другой на i2c2. Если я заставлю это работать, исходный код дрона использовал периферийную библиотеку, а не hal. В конечном итоге мне придется выяснить, как это было неправильно настроено/узнать больше о настройках конфигурации gpio.
@Джеффри - я рад, что объяснение помогло. :-) Получить такой прицел было хорошей идеей! Re: «Помечен как открытый сток в обоих». Таким образом, везде, где вы это видели, похоже, понимается, что он должен использовать открытый сток, но трассировка области действия подтверждает, что SDA на самом деле не был настроен на открытый сток. Вся цель I2C с использованием драйверов с открытым стоком состоит в том, чтобы позволить любому устройству I2C полностью перевести любой сигнал в низкий логический уровень, а ваш ведомый не может этого сделать, чтобы подтвердить. Поскольку у вас есть пример «хорошей» трассировки I2C, вы будете знать, когда «проблемная» конфигурация будет исправлена, поскольку она будет соответствовать «хорошей» трассе (подтверждение полностью низкое).
Проблема I2C на процессоре STM32F303, что происходит с SDA?
СпросиСетьПолитика конфиденциальности1y, 1v