HardFault after EXTI and starting & resetting timer SOLVED

[Lixx]

Hi

I get a hardfault as soon as the HALL sensor (which is connected & set up using CubeMX & EXTI GPI(O)) gets an interrupt.

I have debugged the code to the part where I can safely say that the hard fault only occurs when the " __HAL_TIM_SET_COUNTER(&htim2, 0);" is involved.

EXTI is working properly, that's not my problem, my problem is the hardfault I get when trying to reset the timer / do anything with the timer.

My Question now is, do you spot any mistake in the code below that could cause the Hard Fault?

If no, how could I debug this?

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
	if ((GPIO_Pin == (Hall1_IN_Pin || Hall2_IN_Pin)) && e_ProgramState == Menu)
	{
		HAL_TIM_Base_Start(&htim2);
	}
        if(GPIO_Pin == Hall2_IN_Pin)
        {
                __HAL_TIM_SET_COUNTER(&htim2, 0);
        }
 
}

Best regards

edit

Problem was solved using the Fault Analyzer in CubeIDE where I found out I had a division by Zero which caused the HardFault, nothing to do with the EXTI or Timer

[Bob S]

Probably not the source of your problem, but:

if ((GPIO_Pin == (Hall1_IN_Pin || Hall2_IN_Pin)) && e_ProgramState == Menu)

That probably doesn't do what you THINK (or want) it to do. The "||" is a logical-OR of the two values, each value treated as a boolean (zero or non-zero). So (Hall1_IN_Pin || Hall3_IN_Pin) will always give you "1". If the goal is to see if the EXTI pin is EITHER Hall1 or Hall2 then you need two separate comparisons. Or something like:

if ( (GPIO_Pin&(Hall1_IN_Pin | Hall2_IN_Pin) != 0) && e_ProgramState == Menu)

Did you look at the fault registers? They will tell you the exact instruction address that caused the fault. Then you don't have to guess while line is the issue.CubeIDE even has a fault analyzer built in.

[Tesla DeLorean · Accepted solution]

Look at the code/registers at the fault.

Likely to be something like htim2 not properly initialized, or you precipitating a fault somewhere else due to a TIM IRQ firing and you not being initialized or prepared to handle it.

Be prepared to handle the fault and output actionable data. A while(1) loop is of little help.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

Your tool chain may have an analyzer, learn how to use that, decode what it's telling you about the system and the fault. The app itself reporting is more field ready, and doesn't require an attached debugger or active session.

[Lixx]

That does what I want it to do, I just wanted to start the timer as soon as one of the 2 HALL sensors is triggering, but thank you for noticing 🙂

I'll have a look at it, didn't know it existed, I'm pretty new to more than setting GPIO's :D

thank you!

[Lixx]

Weird thing is, that if I start, get and reset the timer in the while(1) loop, everything works without an error...

It's just when I put it in the EXTI Callback function, that it gets a HardFault error

[Bob S]

NO, that is NOT what that line of code does. In your code, and the 1st example I listed in my response, that "if" statement will only be true if GPIO_Pin == 1. It DOES NOT check if GPIO_Pin equals either Hall1 or Hall2. If your original line of code appears to work it is only because one of your HALL pins has a value of 0x0001 (i.e. PA0, PB0, etc.).

[Bob S]

Could your EXTI trigger before the timer has been configured? For example, the standard MX_GPIO_Init() will enable all EXTI interrupts. If that is called before MX_TIM2_Init(), then the callback will use the htim2 structure before it has been initialized, must assuredly causing a NULL pointer dereference.

[Lixx]

After debugging with the Fault Analyzer of CubeIDE I got the error, it had nothing to do with the interrupt nor the timer, I was just stupid and on the first loop when the variables weren't set to a timer value there was a division by zero which caused the hard fault

Problem is solved, thank you for your answers anyways 🙂