Не, @xDriver , не забыл про галки. На них и надеялся. Разобрался уже когда в регистры вникать начал и понял что надоть ручками “разрешить работу” и “разрешить прерывание”.
Вобщем светодиод адекватно мигает в прерываниях в RTC,TIM2 и SysTick. Но! При отладке через st-link ставил брейкпоинт, смотрел счётчик DWT и…он показывал гадость, будто прерывание срабатывает через 1, 35, 7, 450 мс. Дичь какая-то. Хотя при запуске светодиод моргает нормуль. Отладка не всесильна, видимо. Или я что-то не то сделал.
P.s.: пока голову ломал на форуме 11 новых тем для срача появилось!
Это только если ты тот самый «срач» устроить хочешь…
20+ лет назад мы писали на PHP как раз в эклипсе. Может просто «мышечная память» ? 
я, стыду своему, познакомился с ним очень поздно и именно на стм, а потом увидел его и в ESP и WCH MounRiver Studio и еще где то, очень удобно когда знакомая среда везде…
1 лайк
Обработчик прерывания от таймера должен сбросить бит TIM_SR_UIF регистра TIMx->SR путём записи в бит 0. …вручную… не забыли ?
Проверил, сбрасывается. На обработчике SysTick всё чётко по 1 мс. Таймер и RTC нет. Ща покопаюсь ещё. Там же обработчик один на все события? Видимо ещё что-то флаги ставит, отсюда и неравномерность.
Уточню … Вы сами должны ручками сбросить…Обработчик прерывания Вы пишите…
TIMх->SR &= ~ TIM_SR_UIF;
Именно так. В дебаге этот бит сбрасывается, ошибки нет. Никаких других прерываний таймера не разрешено.
Специально выписал знченияDWT_CYCCNT/72000( в мс сразу) при каждом заходе в IRQ: 0, 152, 285,461, 684, 695, 766. Думал закономерность найти. Причём при очередном перезапуске дебага цифры другие.
Но стоит запустить на F5, так нормально отрабатывает как и должен 0.5с (CLOK 72МГц, PSC 35999, ARR 999)
У некоторых камней там счетчик 24 битный !!!
Намёк на переполнение? Другие прерывания он показывает же)
Вдруг раз в секунду захочется …
1 лайк
Трудно так понять … вообще по хорошему если время критично правильнее осцилом…
не совсем понятно , что имеете ввиду… много событий на один обработчик , но обработчиков тоже несколько
.word TIM1_BRK_IRQHandler
.word TIM1_UP_IRQHandler
.word TIM1_TRG_COM_IRQHandler
.word TIM1_CC_IRQHandler
1 лайк
Ща отключу всё лишнее, один таймер только. Попробую TIM1.
похоже все таки что-то в дебагере не так настроенно .
1 лайк
Цифры в дебагере могут отличаться ±2000 циклов. Разгон на 72 мгц происходит не всегда одинаково и может проскочить несколько кругов ожидания стабильности кварцевого гегератора … пробуйте на встроенном с родной частотой …
Это идея.
Вобщем убрал вообще всё, вместо TIM2 запустил TIM1…и такая же херня)))
Где-то слышал что там не так всё просто. Какие-то клоки могут работать даже если дебаг на паузе.
Попробую идею командира, нет так нет, главное что в железе работает. В конце концов длинные промежутки можно и SysTick`ом проверять.
Слушайте…а флаг-то не сбрасывается. Либо отладка не видит. После сброса программно попробую проверить. Его точно сбрасывать нулём? Может 1 туда писать?
В библиотеках действуют методом
TIMx->SR = (uint16_t)~TIM_IT;
С внутреннего генератора 8 МГц делил ещё на 8. 1МГц. Не помогло. Надо на st.com поинтересоваться, почему китайский st-link криво дебаггирует Blue Pill с алиэкспресса😆
Да я уж все методы испробовал) Это глюк дебага. В железе-то работает с нужным периодом, как и должно.
Встряну тут со всем нужным каментом. Дебаг не юзаю даавно, вместо этого делаю вывод на диспл или как щас в порт. Полезен мне дебаг был когда отлаживал всякие хитро-ж вычисления и логику, где время было некритично в момент отладки. Там да, идёшь неспеша по шагам и смотришь в окнах результаты, сравниваешь их с Экселькой контрольной.
А быстрые дела как-то не удавалось даже логику прицепить, ибо там сам объект обычно требовал скорости и дебажить смысла мало.
Рекомендую вместо дебажения просто делать в коде всяческие проверки и вывод на диспл или светодиодики и тп. Ну, я так делаю обычно. Всегда знаешь что должно быть вот и суешь проверку в коде, на ходу.
сбросте прект у меня где-то 103 валялся