Есть проект, в котором TIM3 используется для генерации периодических прерываний по update. Соответствующий handler вызывается.
Попытка просто переехать на TIM2 (для получения более точных - соответствующих желаемым - интервалов за счёт использования его 32-х разрядности) - прерывания (TIM2_IRQHandler) не происходят.
Программирование (используемая разрядность) не менялась.
Работа без SPL, всё "ручками". Про включение соответствующей периферии не забыл.
Что в этих таймерах такого особенного?

Файл: http://188.134.5.254/browser/hfreceiver/trunk/hardware.c

Разобрался.
В программе было разнесено два действия - инициализация таймера и загрузка предельного значения ARR (которое меняется в процессе работы). Дабы избежать чересчур быстрых прерываний от таймера (документация говорит об значении 0 в ARR после включения), прерывания разрешались после загрузки рассчитанного значения периода. Но это сейчас не имеет значения.
Как оказалось, после RESET значение в ARR 0x0000FFFF для 16-битного таймера и 0xFFFFFFFF для 32-х битного (TIM2). После разрешения таймера (в инициализации) таймер начинает считать. Загруженное новое значение в ARR будет использовано только тогда, когда таймер досчитает до 0xFFFFFFFF. Я не дождался ни разу...
Раскопано отладочной печатью в компорт на живом железе.

Или, если лень ждать, то можно сделать вот так

При нормальной работе требуется "мягкое" переключение с одного набора параметров (prescaler+ARR) на другой. Так что
TIM3->EGR = TIM_EGR_UG не совсемм устраивает. Получившийся вариант - счётчик начинает работать когда образовался набор параметров.