cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L433 goes to hardfault after certen time lapse

rahulgate
Associate II

Hello everyone,

I am using STM32L433 with external crystal 12MHz. SYSCLK is 72MHz. i am using three usarts (1,2and 3).

but after certain time period of execution lapse. STM32L433 goes to hardfault handler and executiion stucks,

After debug found that it stucks at HAL_Delay() function

 

7 REPLIES 7
Karl Yamashita
Lead III

Show your relevant code so we can pin point your issue. 

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.
KnarfB
Principal III

Check the STM32CubeIE Fault Analyzer output.

i have checked Fault Analyzer output i have attached fault analyzer log. Every time code is getting stuck in HAL_Delay() function.

That is why i asked you to post your code. I bet you are calling HAL_Delay() from inside an interrupt.

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.
rahulgate
Associate II

Hi Karl,

Please find attached my code. 

I see you commented out the HAL_Delay in this delay function. Is it still hard faulting?

void delay(int dly)
{
//	for(int d =0;d<dly;d++)
//	{
//		HAL_Delay(1);
//	}
	start_cnt = 1;
	cnt = 0;
	while(cnt < (dly / 8))
	{

	}
}

 

You've mentioned after certain time period of execution lapse so it can't be the other HAL_Delay before the main while loop. I assume you're getting your LED's to toggle?

So the "delay" function is the only place that calls HAL_Delay unless there is more somewhere else? You haven't shown all your functions so i don't know.

 

 

 

If smoke escapes your device, put the smoke back in. It'll still work as a conversation piece. If you find my answers useful, click the Accept as Solution button so that way others can see the solution.

pc == 0 should not happen. Look for undefined (NULL) interrupt handlers or function pointers or stack overwrites. The lr register tells you the return address of  a function call, inpect that code and try setting a breakpoint shortly before taht address.

hth

KnarfB