Did timer behavior change between STM32H7 firmware versions 1.7.0 and 1.8.0?

[E P]

I've got a project that uses TIM1 in OC mode to toggle some pins. It's been working fine for months but I made some changes that sent me back to Cube to make changes. While there, it wanted me to migrate the project:

Cube version 5.6.1 -> 6.0.1

STM32H7 firmware version 1.7.0 -> 1.8.0

"Why not" I said because surely it's harmless? Well ... after the update everything seems grand EXCEPT that TIM1 does not activate (by "does not activate" I mean "the pins don't do what they used to do, or anything at all"). Even if I make no changes other than the version migration, TIM1 works just fine before migration, and doesn't operate after. I hunted around here and didn't see any other posts about it, apologies if I missed something, but ... anyone know what gives here? Are there new steps for setting up the timer? I poked around the examples that came with the firmware update package and didn't see any notable differences though I do see that there were various changes to *tim*.* files (that didn't seem relevant, but I guess they are). I did note the migration included a bug where a line is added to ethernetif.c that prevents compiling, but by commenting out the offending line the build goes fine and Ethernet still works.

If Ethernet is working but I can't twiddle pins with a timer I feel like I've probably just overlooked some detail but I can't see what I'm missing here. Any hints would be appreciated!

Thanks

[TDK]

No changes to TIM are listed in the release notes:

https://htmlpreview.github.io/?https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Release_Notes.html

The TIM peripheral is simple enough that you should be able to debug it and see what the issue is. Check that pins are initialized, check that the timer has the correct prescaler, period, settings, check the PWM setting is correct.

[E P]

Per the HAL release notes at https://htmlpreview.github.io/?https://raw.githubusercontent.com/STMicroelectronics/STM32CubeH7/master/Drivers/STM32H7xx_HAL_Driver/Release_Notes.html there were a handful of changes to HAL/LL TIM:

• stm32h7xx_hal_tim.h:
• Update to handle channel state and DMA burst state independently allowing to use multiple DMA request with different channels of same timer:
  • Add HAL_TIM_ChannelStateTypeDef and HAL_TIM_DMABurstStateTypeDef enumerations
    • Add APIs: HAL_TIM_GetActiveChannel, HAL_TIM_GetChannelState and HAL_TIM_DMABurstState and remove TIM_DMADelayPulseCplt callback
  • Add ChannelState, ChannelNState and DMABurstState private parameters to the TIM_HandleTypeDef structure
  • Update __HAL_TIM_RESET_HANDLE_STATE to consider ChannelState, ChannelNState and DMABurstState.
  • Add private macros: TIM_CHANNEL_STATE_GET, TIM_CHANNEL_STATE_SET, TIM_CHANNEL_STATE_SET_ALL, TIM_CHANNEL_N_STATE_GET, TIM_CHANNEL_N_STATE_SET and TIM_CHANNEL_N_STATE_SET_ALL
• stm32h7xx_hal_tim_ex.h:
  • Add HAL_TIMEx_GetChannelNState API allowing to retrieve a channel state
• stm32h7xx_hal_tim.c and stm32h7xx_hal_tim_ex.c:
  • Remove private function “TIM_DMADelayPulseCplt�?
  • Update to handle channel state and DMA burst state independently allowing to use multiple DMA request with different channels of same timer
• stm32h7xx_ll_tim.h
  • Fix values of defines LL_TIM_COUNTERMODE_CENTER_UP and LL_TIM_COUNTERMODE_CENTER_DOWN (values was inverted)
  • Remove “register�? “C�? keyword: The register storage class specifier was deprecated in C++11 and removed in C++17

... but as far as I can tell, they shouldn't have any impact on this.

The thing is that the configuration should be correct already - this is code that works with HAL v1.7.0, and the basic configuration (minus clocks and pins) is one that I've been re-using for years (from the original ST CubeMX, on STM32F4 chips). There are zero changes to my code when I let cube do its thing - so if code works with one version of HAL and not with another, my question is: is my code relying on an existing (mis)behavior that was changed/fixed, or did something break in the new version? I use another timer to run the program loop and that one is working fine. My settings in tim.c (pins, prescalers, settings, modes, etc) that work with HAL v1.7.0 are intact; none of them change with the upgrade to v1.8.0.

Since HAL_TIM_GetChannelState() was added, I went ahead and looked at it; the value seems to always be 2 (HAL_TIM_CHANNEL_STATE_BUSY) but I haven't yet looked into what that means.