Так я вам и пишу о детских ошибках. Здесь надо тупо и методично проверять всё - от "ту ли прошивку заливаем", до расчетов регистров на бумажке и проверке дебаггером.
А если новым 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кГц.

Сообщение отредактировал Arlleex - May 1 2018, 13:42