2020-10-12 05:46 PM
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
2020-10-13 06:52 AM
No changes to TIM are listed in the release notes:
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.
2020-10-13 09:15 AM
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:
... 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.