When i set PA2 as output, Program go into HardFault.

[Jpark.1]

�? original source code : B-L475E-IOT01A.(STM32L475V)

�? IDE Tool : uVision

�? Symptom : When i set PA2 as output, Program go into HardFault_Handler()

it can't reach while(1);

Other ports are no problem. only PA2 has this problem.

�? source code

int main(void) {

 HAL_Init();

 SystemClock_Config();

  __HAL_RCC_GPIOA_CLK_ENABLE();

 GPIO_InitTypeDef gpio_init_structure;

 gpio_init_structure.Pin  = GPIO_PIN_2;

//gpio_init_structure.Mode =GPIO_MODE_OUTPUT_OD;

//gpio_init_structure.Mode =GPIO_MODE_AF_OD;

 gpio_init_structure.Mode = GPIO_MODE_OUTPUT_PP  ;

 gpio_init_structure.Pull = GPIO_NOPULL;

 gpio_init_structure.Speed = GPIO_SPEED_FREQ_HIGH;

​  HAL_GPIO_Init(GPIOA, &gpio_init_structure);

while(1);

[Tesla DeLorean]

Ok, so you're going to have to inspect the fault registers, and look at the processor registers and assembler code at and before the faulting instruction.

Check you have a sufficiently large stack, the flash wait states are correct, and whether PA2 is used for anything else, look at the schematic.

[Jpark.1]

Strange thing is that this problem not happened when i run step by step execution in uVision.

only when i run none stopping, this problem occured.

1) stack problem.

I think it has nothing to do with stack problem.

I programmed test code in main. and i checked also stack.

2) schematic problem.

humm...

There is little possibility to be ralated to this problem.

please refer to register file when it goes into hardfault.

I can't break before the faulting insruction.

[Tesla DeLorean]

You're going to need to unpack the registers and look at the faulting instruction. Looking at the while() loop in the Handler won't help.

Look at myriad of posted examples for a Hard Fault Handler that outputs actionable data.

[turboscrew]

A good way would be enabling the usagefault, busfault and memfault exceptions and put a breakpoint at those handlers as well as in the hardfault handler.

That way you can find out what actually happens. If the other faults are allowed to escalate to hard fault, information about the problem is lost.

[waclawek.jan · Accepted solution]

So, setting this pin switches on the WIFI module? Can't this cause a sudden voltage drop, potentially leading to a glitch in the mcu's power supply? Try to remove R80 - problem persists?

JW

[Jpark.1]

yes. you're right. I detached R80 and tested it and then the problem of hardfault was disappeared. thank you so much.