Глюк 1:

Мне тут нужно было в одном относительно старом проекте, который делался на 4-м Кейле, поменять некоторые дефолтные настройки. К I2C оно не относится, но глюк я поймал именно с I2C!
Сейчас на компе только 5-й, 4-го нет.
Проц - тот-же F103, к нему по I2C подключена 24LC16.

Запускаю под дебаггером (JLink-Lite подключен, причем настоящий) - ничего не работает, бне входя в деббагер (но с подключенный JLinkом) - все прекрасно работает.

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

WTF?!


Глюк 2:
это коллега тут возится с девайсом на STM32L452 и жалуется. Просил спросить:
Для тактирования используется MSI + PLL.
I2C настроен на 400кгц, тактируется от системного клока.

На одной плате, запускаешь под дебаггером - есть 400кгц. Включаешь ее без дебаггера - там около 40кгц.
Из 5-ти плат, так ведет себя одна, 4 другие в - вообще кто в лес, кто по дрова.
ТЕперь самое интересное - для проверки "на какой- частоте проц работате," вывели махание ножкой в систике - так там четко, 1мс.

Есть идеи?

Каких идей вы хотите?
Если вы не можете пошагово пройти настройку тактовой частоты, то научить вас пользоваться дебаггером?

Например - почему работа одной и той-же прошивки, отличается под дебаггером и не под дебаггером Кейла?



А что, от этого текст программы поменяется?

Например, по причине отсутствия барьеров в нужных местах.

Это для 1-го глюка или второго?

Если второго, то в тестовой программе ничего нет кроме систика, в котором мащется ножкой.
А в основной - просто чтение блока из I2C устройства.
Чтение едет правильно, только частота клока I2C на порядок ниже.
Как такое может быть - он же аппратно формируется. Не мжет же делитель зависеть от того, что проц под дебаггером запустили?

А с первым глком еще не понятнее - устройство не первой свежести, выпущено приличное количество, и никогда небыло никких проблем. А под дебаггером - связь с еепромкой не работает. Ну это ладно, я еще посмотрю, интереснее второй глюк - коллега там уже в ступроре полном.
Ну не ногодрыгом-же I2C делать! Хотя, в том режиме у него больше ничего не делается - проц периодически считывает блок по i2c, небольшая обраткока и отсылает в аурт. Так что, можно и ногодрыгом (на него я надеюсь, дебаггер никаки не повлияет!), в крайнем случае. Но непонятна причина.

Да для обоих подойдет.


Может, если его запись осуществляется некорректно.


Только так и делаю. У меня нет ни времени ни желания искать обходы для 100500 аппаратных
глюков модулей I2C на дюжине используемых платформ. Софтовый же абсолютно надежен
и предсказуем, там не приходится ждать приколов типа "мы не поддерживаем clock stretching
и repeated start". Все вышесказанное, разумеется, относится к режиму master.

Единственный приличный аппаратный контроллер I2C, который я встречал, использовался в
мелких AVR типа ATmega48 и процессорах LPC13xx (автор один). Вот там можно было смело
полагаться на железо.

Забавно. :-)
А я столько лет переживал, что в 8-битнике Z8Encore всегда использовал софтовый I2C. Хотя там уже 15 лет как был аппаратный (начинал я еще в 1995, когда его не было). Я всё никак не мог разобраться там с мудреными регистрами и тупо дергал двумя ножками. Там всё понятно.
И вот достиг наконец в STM32 аппаратного. Рад был до безумия. Всё прекрасно уже 3-й год. И вдруг оказывается там могут быть проблемы. :-(

Кстати, проблем нет у меня ни в STM32L476, ни STM32F446. Ни под дебаггером Кейла 5, ни потом в работе.
Но! В последней версии HAL 1.11 для STM32L476 какой-то глюк - вообще память по I2C не работает.




Если у него HAL и версия STM32Cube_FW_L4_V1.11.1, то может быть что угодно. :-)
А вот STM32Cube_FW_L4_V1.8.1 - всё нормально.
У мня для STM32L476 тактирование как раз MSI + PLL.

Сделал работу i2c для некоего мелкого STM32 (конкретно, сейчас не промню, но проект имеется, естественно) - аппаратно, как положено. Над битами, временными диаграммами пришлось помедитировать и все. Повезло?
P. S. HAL-ами не пользуюсь.

А другие интерфейсы (UART, SPI, ...) на этой дюжине тоже ногодрыгом реализуете?
В чём разница между I2C и каким-то другим последовательным интерфейсом?


мрак.... ногодрыг в наше время на современных МК на вдоль и поперёк изъезженном I2C???... полный мрак...
Писал драйвера I2C на LPC23xx, LPC17xx, OMAP-L137, STM32F4, XMC4500, MSP430 - везде использовал встроенный I2C-контроллер, кое-где - с DMA, кое-где - на шине висела гроздь устройств. Коллеги писали на Tiva TM4C129 - тоже аппаратно.
Ни разу не возникло необходимости или желания заниматься ногодрыгом.

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

Касательно проблемы автора: под дебаггером закройте окошко отладочное с регистрами I2C-модулей, приятно удивитесь.

А их никто и не открывал.
про проблему сброса статусны битов когда дебаггер читает регистры - я в курсе.

К тому-же - в "Глюке #2" все еще чудесатее, т.к. из 4-х плат только в одной без дебаггера частота клока I2C соответствует заданной, а в 4-х платах - нет.
Прошивка, разумеется. одна и та-же. Тутеже дело не в дебаггере.

Ну так выведите значения всех регистров, от коих эта частота зависит, в отладочный UART (или другой удобный интерфейс). И увидите что не так. В чём проблема?
PS: Вопрос вроде не в ветке "Для чайников".....

Так откуда же я знаю что у вас там в программе и процессоре происходит?
Тут один студент несколько дней отлаживал программу в дебаггере - не мог получить правильную частоту в логическом анализаторе Keil. Оказалось дебажил в симуляторе....

Пошагово пройдите настройку процессора, смотрите правильно ли выставлены регистры RCC и I2C и т.д.
Выведите частоту на MCO, посмотрите осциллографом.
А у вас точно I2C? может SMBus?


ТС отказывается учиться работать в дебаггере И ничего полезного не говорит

Нет.


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


Эмоции, вижу, просто зашкаливают

В том-то и дело, что болше ничгео не происходит - сделан был тестовый проект, в котором кроме i2c больше ничего нет.



Коллеге, который с этим возится, скоро 60, совсем не студент
Хотя, я больше чем уверен, что где-то какая-то "детская ошибка" сидит.



Нет.
А для проверки частоты использовалось махание ножкой в систике.



Если Вы не заметили, это вообще не у меня а у коллеги.
У меня - "глюк 1", но я с ним пока больше не возился.

Так я вам и пишу о детских ошибках. Здесь надо тупо и методично проверять всё - от "ту ли прошивку заливаем", до расчетов регистров на бумажке и проверке дебаггером.
А если новым keil компилировали программу, тогда и строки компилятора/линкера сравнить из старого и нового проекта.
На pack переходили в проекте или остались на legacy?

Телепатов здесь нет, чтобы додумывать что уже сделано, что не сделано, что изменилось в проекте, оборудовании и т.д.
А допрашивать лень.....

У F103 абсюлютно вычурно-глючный I2C. Я на эту тему писал неоднократно, делясь опытом своей борьбы в течение, не вру, недель двух. Итог ее: я победил, но ощущение подставы и подвоха не покидает. Поищи тему с моим ником.
Суть выводов:
- при работе по прерываниям страсть как не любит быть прерваным: дай прерыванию от I2C наивысший приоритет или обрабатывай определенные куски при глобально запрещенных прерываниях.
- что будет стабильно работать при максимальных 72MHz такта процессора, напрочь рушится при, скажем, 24MHz, как правило по причине того, что...
- в регистре статуса позможны комбинации битов машины состояния, которые не описаны в доке и не определены во всяких дефайнах! Эти комбинации нужно отслеживать в прерывании в посвященных им ветвям обработчика; при этом для этих комбинаций нельзя просто их проигнорировать, выйти из прерывания и дождаться типа "правильных", а приходится тупо ждать в цикле установки/сброса "лишних" битов.
- необходимо особо обрабатывать случаи трансфера только одного или двух байтов, или когда осталось принять два или один байт.
- шагать под отладчиком в прерывании I2C - это просто квантовые процессы сродни щелевому эксперименту.

Сплошная печаль, короче. Когда мне в руки попался F051, я просто прыгал от восторга, запустив его I2C за часика два (с перерывами на напитки).

Когда я после ногодрыга для I2C на Z8 впервые запустил аппаратный I2C на STM32L476, то вообще ничего не заметил. :-)
Потому что Куб всё сгенерил, я вставил HAL-строки и всё. Память 64К пишется, читается.

Предыдущая верси той платы, с которой колега возится, была тоже на L476, и никаких проблем с ней небыло.
Они начались на новой плате с 452-м.

В общем я решил помочь коллеге, и взял пару платок поиграться.
Сразу скажу - в отличие от его экспериментов, я не заметил никакой разницы между платаи так и в том запускать под дебаггером или не под дебаггером.
Отдал ему результаты. пусть дальше сам возится.

Но(!), кое-какие нестыковки я все-же заметил. Причем из серии "этого не может быть, потому что этого не может быть никогда".

Поясняю - простенькая программка на калохале, ничего кроме i2c в ней нет.
Хал пробовался и 1.8.1 и 1.11.0, разницы в поведении между ними не выявлено.
I2C Fast, 400kHz. и обычный на 100кгц. Константу делителя менял вручную.

Проверено было 4 варианта источника тактовой - MSI_8MHz, MSI_16MHz, HSI_16MHz, HSE_24MHz.
При этом переключался делитель PLLM соответственно 2-4-4-6, т.е. частот на входе PLL была во всех случаях неизменна - 4Мгц.
Для контроля, на MCO выводитась частота с текущего источника деленая на 8 дя 8мгц и на 16 для остальных.

Остальные настойки не менялись вообще. Каждый источник был проверен 2 раза, с разными константами делителя i2c.

В основном цикле, с привязкой к систику (т.е. с периодом 1мс) читался по i2c регистр аккселерометра LSM6DS3.

Сразу скажу - цикл 1мс во всех случаях был правильный, в отличие от не совсем точной частоты на MCO и полного балагана с частотой SCL.
Просомтр в дебаггере регистров i2c криминала не вявил - что просили, то туда и записалось.

Результаты:


Т.е. частота MCO правильная, систика - тоже правильная, а SCK - более-менее правильная только для внешнего кварца.
Напомню еще раз - во всех случаях. на входе PLL частота 4мгц, от которой и шло дальнейшее тактирование всего. Менялся только источник этих 4-х мгц.

P.S. Да, я понмаю, калокуб и всякое тому подобное, но сгенерированый им исходник ведь не менялся.



Тактирование - на вход PLL

Допустимый диапазон частот на входе PLL описан в документации.

Насчет "балагана" непонятно. И частоты тоже. SCL характеризуется не частотой, а периодом, тк между фреймами могут быть паузы.
Поэтому смотрите период SCL в ждущем режиме. Оптимально - синхрнизировать осц. (в начале приема или передачи блока) от внешнего сигнала, можно ногодрыгом.
Намного более удобно пользоваться лог. анализаторм, где есть разборщик протокола I2C, а не рыться в осцилограмме.
С лог. анализатором такие слеты вылввливаются "нараз".
Для отладки рекомендую Вам прописать в 24LC16 12345 слова по всем адресам (data16 == address) и почитать их с автом. контролем.
На запись - в томже стиле.

И что? Там от 4 до 16, 4Мгц в него не попадает?
К тому-же куб бы красным отметил если бы что-то "не то" было.



А меня 40 лет назал еще в школе учили, что частота это 1/период
И задается в I2C обычно именно часто клока (100,400, 1000).




Я даже не в "ждущем" а в стопе смотрю, и не то что скоп померял, а меряю сам курсорами.



Смотрел конечно. Он вообщето и в самом осциллографе есть, с таким-же точно "разборщиком протоколов", холтя в данном случае мне было удобнее китайским прибамбасом с Saleae смотреть.

Все там в порядке. Да и с передачей данных нет пробем, все корректно читается и пишется (я про глюк №2, 1-й меня сейчас не интересует, им я потом займусь).

А дальше все еще чудесатее. Я тут уже как фокусник Следите за руками:

- я в коде, без всяких калокубов меня ДЕЛИТЕЛЬ МСО.

который, согласно всем даташитам НЕ ВЛИЯЕТ НИ НА ЧТО, происходящее внутри процессора,.
И частота SCL меняется в 2 раза, причем в обратную сторону!.

Т.е. при делителе на 8 имеем: MSI_8, DIV=8: MCO=0.98 MHz, SCL100 = 38 kHz, SCL400 = 155 kHz.

после изменения делителя на 16 имеем такое: MSI_8, DIV=16: MCO=0.49 MHz, SCL100 = 76 kHz, SCL400 = 310 kHz.


вот уж точно - WTF?

"Обычно"? А кроме куба вы что-то ещё знаете?
Обычно - в разных МК по-разному.
А ещё - почитайте хоть немного, что такое I2C. И что такое "clock stretching" в нём.
Из-за него получаемая на SCL частота, может быть ниже, чем выставляемая через регистры I2C - это вполне нормально. А чтобы проверить правильность выставления частоты, нужно отключить все слэйвы и перевести SCL в push-pull-режим.

. . . здесь расположены холиврные посты касаемо частоты и периода . . .
Может джиттерр "в особо крупных" ? При PLL его наличие и значение будет зависеть от соотношения частот настройки PLL
и опорной частоты. Оптимальній вариант - их кратность.
В начале main() (до инициализации) поставьте BP, а лучше - ногодрыг. Если код маленький, то Ваши 1 мс могут прокручивться
через ресет, и идет постаянная реинициализация всего.

"обычно" - это в стандартах I2C.




Году в 96-м, переводил я филипсовскую доку по I2C, до сих пор по Сети ходит.....





"Нормально что", что частота 38 килогерц вместо 100? При слейве, умеющим по даташиту работать на 400, и реально прекрасно работающем и на 550?
(на частоту SCL никто бы и не посмотрел бы, если бы незаметили что килобайт даных читается что-то уж больно долго).
Или что частота SCL меняется вдвое при изменении делителя выхода MCO? Это тоже "нормально"?



а в не особо крупных - не вижу.



Так при изменении делителя МСО, все это не менялось.
Да оно и при переключении источников клока не менялось!

Захват PLL на (за) границе(ей) , и его прогнозируемый слет. См. док - график частот и допустимых значений коэффициентов.
Я бы отсюда и начал копать. Без I2C.
ps проверить наличие флагов ошибок тактирующей системы.

Блин, я щас матерится начну, и поверьте - я это умею!

Какой нафиг "слет," какой нафиг "за границей"??????

Вы в курсе что такое МСО? Это выход частоты наружу, через отдельный делитель.
Эта частота нигде внутри процессора не используется (во всяком случае ничего про это нигде не написано), и сответственно - это делитель ни на что не должен влиять.

Сигнал на входе ФАПЧа как был 4мгц, так и остался, как и все его коэффициенты и остальные делители.



"Копать" где? Кроме частоты на SCL оно ни на что другое не воздействует.

Не знаю какие там стандарты в калокубе - не разбираюсь в нём.
Но если открыть даташит на первый попавшийся LPC17xx, то можно прочитать:
15:0 SCLH Count for SCL HIGH time period selection.
15:0 SCLL Count for SCL low time period selection.
Именно период, а не частота.


Что и как там у вас нормально и ненормально - это только вам виднее. И если вы сами не можете отладить свои исходники, то удалённо тут уж точно никто не сможет.
Если Вам пишут, что у других на том же МК получается нормальная частота то искать баги стоит у себя, а не искать виноватых вокруг.

Вас не затруднит привести точную ссылку, где "у других на том же МК получается нормальная частота" ?



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

Во многих микроконтроллерах указывается именно период, а не частота I2C. Даже в том же STM32.
Использовал I2C в STM32F103, STM32F217, STM32F427 и STM32F429, никаких проблем или нареканий не было, все согласно документации. Осциллографом тыкался - Ровно 100кГц получал на последовательных clock-ах. В режиме контроля clock-stretching между отправляемыми байтами цифровой автомат I2C STM32 вставлял "задержки", отсюда общая частота, замеряемая осциллографом по нескольким сотням пачек - была в 1.5-2 раза меньше, чем 100кГц (запись в EEPROM-память 4-10мс). Главным требованием, из-за несоблюдения которого я промучался довольно долго однажды, это правильная выставка полей предделителя частоты для модуля I2C, а также регистров CCR и TRISE. Там есть ограничения, не помню уже какие. Но когда я ручками выставил все что нужно в эти регистры - все заработало как нужно.
Ну а совет сверху очень хороший прозвучал - перевести лапки SCL и SDA в режим push-pull, отключить Slave-устройства от шины и смотреть что на ней.
Вот в одном из моих проектов:

Частота на APB1 45МГц, PLL заведен от внешнего HSE, fHCLK = 180МГц. fPCLK1 = fHCLK/4 = 45МГц. На выходе I2C получаю 100кГц.

Зачем?

Сталкивался один раз с тем, что на Slow-режиме ногодрыг был не таким, каким ожидал. Поэтому всегда ставлю максимум, чтобы хотя бы GPIO отмести из подозреваемых. Для I2C да, возможно, не важно. Выделил для того, чтобы ТС попробовал именно так. Тяжело что-то советовать без целевого авторского железа

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

Но я-то измерял не среднюю по сотням пачек, а по одному биту, курсором.
Впрочем, оно и по длительности работы при передаче пачки можно понять, если частота не "чуть-чуть" а ВТРОЕ отличается.
Ну а когда я дошел до влияния на это МСО, то тут уже просто ступор наступил.
Коллега пока ногодрыгом уже все сделал, так что вопрос остался чисто академический.



Аналогично. Не считая всяких LPC1768, PIC16 и других, в STM32 использовал I2C в F103, F405, F407, F767, L151, L467, и все было ОК.
А в L452 - то что я описал выше.

Я не очень понимаю, причем здесь процессор? Какой-то калокуб вам делает непонятно что, а вы ругаете процессор.
Вы же в курсе, что задавая частоту генерации I2C, программа сама вычисляет коэффициенты делителя I2C, основываясь на какой-то цифре - вот и разберитесь откуда она берется, видимо для разных генераторов она прописана разная.
Извините, недочитал, был неправ.
А без PLL, напрямую от генераторов пробовали тактировать APB1/I2C ?

У меня в проекте на F429. МК не совсем тот, но не думаю что есть существенная разница. Никаких кубов.

Т.е. когда Вы говорили, что "у других на том-же МК получется нормальная частота", Вы как бы это помягче выразится, чтоюы Вас не обидеть - Вы были не совсем точны

А оказывается, у Вас не просто другой проц, но еще и другого семейства.
Так и у меня на L476 - тоже все нормально, как и на всех F4/F7.