stm32f4 hardfault

[jhasa.2]

hi

I use stm32f4 micro but an external interrupt pin

when i increase frequency of the external signal connected to interrupt pin, the micro jump to hardfault

why? how I can detect the solution?

 

[SRedd.5]

At what frequency of the external signal it goes to hardware fault? Below this frequency which function you are calling when interrupt happens?

[jhasa.2]

the interrupt routine is free and i commented all the code in it.

the frequency above 3khz will be Hard Fault.

how i can see the problem detail in hard fault?

 

[SRedd.5]

The sequence is step1: HAL_GPIO_EXTI_IRQHandler function is called and after that some issue happened and the hardfault handler is called. Can you show your code? In the interrupt handler can you toggle a port based on the external input signal, so both shall match for debugging purpose.

[Tesla DeLorean]

>>why?

These things don't need to be guessing games. Go identify what's actually faulting and work backward from there.

If you don't service interrupts in handlers, they'll keep entering.

Have a Hard Fault Handler that does something more useful that while(1), I've posted examples on multiple occasions on.

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

[jhasa.2]

this data is displayed on stm32cubeide

what i should with this data?

 

[SRedd.5]

What data? 

[FBL]

Hello @jhasa.2 

 

In general, you can use the fault analyzer to dump registers content during the exception. 

 

[Tesla DeLorean]

You're trying to understand what the MCU is objecting too based on instructions and context it is executing in.

Memory issues, alignment, stack corruption, etc. Is it consistently faulting in the same places or after certain events.

The MCU provides a bunch of data, you can use that to find the cause in your code, or significantly narrow the search to specific functions, pointers or structures.

[jhasa.2]

most of the time my code faults in EXT Interrupt

but i can not check which section trig this section.

?

 

this is the fault analyzer.

 

[SRedd.5]

Frankly your code is not organized properly, you have written everything in one main.c file which is not recommended, you can split into multiple files and enable one feature after other. I can see SPI communication, DAC etc. I recommend you disable all features and use verify only external interrupt code and proceed. Once you fix external interrupt you can add the modules step by step.

[Pavel A.]

In the stack trace 20011540 is a RAM address. How you've got there? This looks like stack corruption (overwrite).

 

[jhasa.2]

why the stack is corrupted?

is it related to fake micro-controller?

[Pavel A.]

> why the stack is corrupted?

As @Piranha wrote - because someone overwrites an object on stack!

[jhasa.2]

how i can found it?

[Shirley.Ye]

you can check the disassembly file or use fromelf tool to analyze the stack data 0x20011540, what data is stored there?

[Piranha]

char received_string_data[4];


strncpy(received_string_data , RxData,12);

for (int i = 5; i < (5+2); i++) {if(received_string_data[i]!='\0') k = 10 * k + (received_string_data[i]-48);}

for (int i = 8; i < (8+4); i++) {if(received_string_data[i]!=0) k = 10 * k + (received_string_data[i]-48);}
//	else k = 10 * k + (received_string_data[i]);

The array size...

[jhasa.2]

i remove an 60000 byte array

why compiler does not warn or error when we use huge array in local functions?

[Tesla DeLorean]

Neither the compiler or linker track call-stacks and stack usage, most of this occurs dynamically as the code runs, not a static allocation which the linker must fulfill.

You should not have more local/auto variables that exceed the available RAM under the stack pointer.

[jhasa.2]

the full project has been attached