Запрограммировал таймер на отчет временных интервалов:

Период србатывания ~21сек.
В обработчике поставил маркер срабатывания:

При запуске программы почемуто сразу срабатывает прерывание. С какого это оно срабатывает , если событие не наступило?
Как сделать чтобы первое срабатывание было только по совпадению с рег-ом ARR ?

Сначала вопрос, не под отладчиком ли Вы пробуете: если не предпринять мер, а именно запретить счет таймера во время остановки при отладки, то таймер будет бежать дальше.
Регистры ARR и PSC имеют теневые регистры. Команды записи модифицируют теневые регистры, которые перепишутся в рабочие, когда установится флаг обновления:

Это означает, что новые значения регистров, которые Вы записали при инициализации, не действуют, пока не наступит событие переполнения, а оно наступает быстро, т.к. по умолчанию PSC равен нулю.
Действия:
- записать, что надо, прерывание еще не разрешать,
- установить искусственно флаг UG в регистре EGR - это обновит PSC|ARR новыми значениями.
- сбросить установившиеся флаги прерываний
- только теперь разрешить прерывания и запустить таймер.

и это стоит проверить, в том ли регистре идет сброс, и так ли он идет? Обычно делают сбросы через = а не &=(|=), по ряду причин... но это надо проверить. Если регистр не чувствителен к записи 1 или 0 - это явный намек на это

В описании регистра для бита UIF стоит /w0, что означает, что флаг сбрасывается при записи нуля. Так что все правильно. Конечно, можно замутить что-то элегантно и с bitband. Это в EFM32 есть "регистр сброса битов статуса", куда надо писать единицу для сброса бита регистра статуса в ноль. В STM32 такой подход применен только в GPIO.

я к тому что надо писать не
TIM2->SR &= ~(TIM_SR_UIF);

а

TIM2->SR = ~(TIM_SR_UIF);

я не прав? Остальные биты регистра читаемые? Реагируют ли они на 1?

почему = лучше чем &= уже много раз обсуждали....

Оно не лучше, оно для разных случаев.
"&=" или "|=" вместо "=" - типичная ошибка при работе с write-only регистрами.
Но как раз в случае STM так делать нельзя, по причине наличия такого примечания
для незадействованных битов в регистрах: Reserved, must be kept at reset value.
Так что только "&=" и "|=".

Регистр PSC обновляется только при update event.
Если ARPE = 1, то ARR тоже обновляется только при update event (иначе сразу).

Добавьте перед запуском таймера:

нет оно именно лучше.

если в регистре несколько битов - флагов, то
&= |=
срабатывая в 3 такта
забрать значение, изменить, записать обратно
может затереть возникший за эти три такта новый флаг, не говоря уже о чтение битов, которые предназначены только для записи.

Поэтому если в регистре есть биты которые должны оставаться всегда в ресет значениях, значит это должно быть учтено при
REGISTR = SBROS, в величине SBROS, но не как не означает что надо делать &=, |=....

REGISTR = (DEFAULT_VAL & (~INTERRUPT)); - правильно
REGISTR &= (~INTERRUPT) ==== REGISTR = REGISTR & (~INTERRUPT); - не правильно!

Если битов несколько, и есть такая вероятность, то да, может.


Тут уж что-то одно - или write-only, или w0. Но никак не одновременно.

Для обсуждаемого случая "&=" является вполне корректной конструкцией.

Вряд ли. Если в момент "чтение-модификация-запись" произойдет установка какого-нибудь другого флага, то он будет сброшен без обработки.

как я понял автор настаивает на том, что в этом регистре всего один флаг (или используется только он), и потому ничего нельзя затереть. Другое дело что потом понадобиться другой флаг, или будет перенос кода обработчика через ctrl-c, ctrl-v или переход на другой проц с несколькими флагами, но кто у нас об этом думает...

Да мало ли способов накосячить? Это лишь один из многих.

P.S. Специально раскопал свой (целый один) проект с STM32. Таки да, прерывания в нем сбрасываю через = FLAG. Сброс более одного флага в обработчике используется только в модуле USB.

Нет , отлаживаю все в железе по "лампочкам"

Да , действительно , если в свойствах битов регистра "rc_w0" -означает очистка 0 , то корректнее очищать флаг:

Но если используется всего один флаг , то так

тоже правильно

Я надеюсь, что среди всех этих полезных рассуждений о способах сброса флагов вы не пропустили сообщение номер 7, в котором я объясняю причины вашей исходной проблемы и даю способ её решения?