It's impossible to say with so little info.
The HAL is great as long as everything just works out, but when it doesn't, you don't have visibility, or knowledge how the timers work internally. The two first things I'd do here:
1) Read the relevant timer sections of the reference manual, so that you have an idea about they are supposed to work internally, including the status register,
2) Then I'd look up these HAL functions and bring their code - even with just copypasting - to your own program. Even though you could use a debugger to see what happens in the HAL functions, it's easier to have it in your own code base, so you can make any modifications to test things out.
When you do that, you are exposed to the status registers of the timers, can look at them in debugger on print them out any way you wish. This gives you a starting point how to investigate such issues.
If your "program hangs", there tends to be two possibilities,
1) you have an ISR which reruns infinitely because the relevant flag is not cleared, not a single cycle is available to your main program. With a debugger, just stop and see where you are. Without a debugger, turn on an LED at the beginning of the interrupt handler and turn it off at the end. You instantly see the CPU time spent in the interrupt from the LED brightness (and can look it up with a scope for precise timing).
2) some of those HAL_ functions have a while() loop which does something (polls for a status), and if never satisfied, locks the system up. IMHO, a timer start function shouldn't need such a while() loop at all, but the HAL is quite crap...ish so it's well possible.
Do you have hardfault, busfault, usagefault etc. handlers?