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

Есть идеи?

[KnightIgor]

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

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

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

[serglg]

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

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

[Allregia]

Когда я после ногодрыга для 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 криминала не вявил - что просили, то туда и записалось.

Результаты:

Код

     MSI_8:   MCO=0.98 MHz,   SCL100 = 38 kHz,    SCL400 = 155 kHz.
     MSI_16:  MCO=0.987 MHz,  SCL100 = 152 kHz,   SCL400 = 550 kHz.
     HSI_16:  MCO=0.982 MHz,  SCL100 = 140 kHz,   SCL400 = 536 kHz.
     HSE_24:  MCO=1.5 MHz,    SCL100 = 113 kHz,   SCL400 = 425 kHz.

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

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



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