2019-12-29 10:23 PM
I am using TIM1&TIM8 for PWM generation and using TIM15 for PWM input capture mode, individually if I check in IAR TIM1&TIM8 WORK properly for PWM generation, and TIM15 properly in input capture mode, but if I use them all together after the first iteration of PWM input capture of TIM15, as soon as I initialize TIM1 or TIM8 processor goes to hard fault
In the same code if I comment TIM1 and TIM8, TIM15 works properly in input capture mode
And if I comment TIM15 other two work properly
2019-12-30 01:43 AM
Increase the stack size maybe?
I assume that all interrupt service routine can coexist, clear the pending interrupt and have been put on same priority level and they don't use HAL_Delay() within them
All these for sanity check
2019-12-30 01:52 AM
You mean HAL_Delay(); in interrupt handler?
2019-12-30 07:44 AM
Interrupt handler should be as brief as possible and only manage what is critical, so so printf, no delays.
The embedded MCU art is to well understand all the interrupt max latency and duration and make sure there is no weak race condition which could occur once overnight. Usually there is no tool for this kind of profiling and this is what is the trickiest to manage.
Anyway, I really feel you should check what is the stack size used in the project.
2019-12-30 08:31 AM
Pretty sure the HW works correctly. More probable you have some blocking or deadlocking issue on the SW side.
2019-12-30 10:22 AM
Debug the hardfault, track back from the stack content and the fault registers, where did the fault happen.
The technique to do this has been discussed here many times, search perhaps for "hardfault handler" in Clive's posts.
JW
2019-12-31 12:43 AM
Hardfault indicates a software problem, most likely uninitialized, corrupted or otherwise improperly used pointers, maybe stack overflow.
You have the code, we don't. How could we guess?