Глюки с I2C Опции

[Allregia]

Глюк 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мс.

Есть идеи?

[ViKo]

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

[Allregia]

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

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

Насчет "балагана" непонятно. И частоты тоже. SCL характеризуется не частотой, а периодом,

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

тк между фреймами могут быть паузы.
Поэтому смотрите период SCL в ждущем режиме. Оптимально - синхровать осц. (в начале приема или передачи блока) от внешнего сигнала, можно ногодрыгом.

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

Намного более удобно пользоваться лог. анализаторм, где есть разборщик протокола I2C, а не рыться в осцилограмме.

Смотрел конечно. Он вообщето и в самом осциллографе есть, с таким-же точно "разборщиком протоколов", холтя в данном случае мне было удобнее китайским прибамбасом с 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?

[jcxz]

И задается в I2C обычно именно часто клока (100,400, 1000).

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

[Allregia]

"Обычно"? А кроме куба вы что-то ещё знаете?
Обычно - в разных МК по-разному.

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

А ещё - почитайте хоть немного, что такое I2C.

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

И что такое "clock stretching" в нём.
Из-за него получаемая на SCL частота, может быть ниже, чем выставляемая через регистры I2C - это вполне нормально.

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

Может джиттерр "в особо крупных" ?

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

При PLL его наличие и значение будет зависеть от соотношения частот настройки PLL
и опорной частоты. Оптимальній вариант - их кратность.

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

[k155la3]

. . . . Или что частота SCL меняется вдвое при изменении делителя выхода MCO? Это тоже "нормально"? . . .

Захват PLL на (за) границе(ей) , и его прогнозируемый слет. См. док - график частот и допустимых значений коэффициентов.

"Да оно и при переключении источников клока не менялось!"

Я бы отсюда и начал копать. Без I2C.
ps проверить наличие флагов ошибок тактирующей системы.