STM32 startup fails at HAL_RCC_ClockConfig

[Faizan75]

Hi,

I have designed the custom board for STM32L073 series.

Initially i have tested the code/firmware in Nucleo board of same part number, and we have designed the board keeping nucleo board schematic as reference.

The code works fine in Nucleo board, but in the custom board it takes multiple reset to start the same code.

For example if i take simple GPIO toggle program in the custom board, i found in the debug session it hangs/stops at

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK)  ,  but it works fine in Nucleo board.

In some cases when i start debug session it directly goes to HARD FAULT.

Currently i am using HSI clock source.

Kindly help me with this issue

[Faizan75]

The basic requirement of my application is that the firmware should run as soon i connect the battery/power supply, which is not happening as i have to reset the controller after i connect the power source.  

[Tesla DeLorean]

Make sure BOOT0 is pulled Low

[Andrew Neil]

---

@Faizan75 wrote:

For example if i take simple GPIO toggle program in the custom board, i found in the debug session it hangs/stops at

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK)  ,  but it works fine in Nucleo board.

---

Are you sure it is actually hanging in the HAL_RCC_ClockConfig() call, or is that code  really:

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK) 
{
   Error_Handler();
}

and it is actually going to the Error_Handler() - which is typically just an infinite loop?

• If it is actually hanging in the HAL_RCC_ClockConfig() call, then step into that function and see where, exactly, it is hanging.
• If it's going to the  Error_Handler(), then check what value HAL_RCC_ClockConfig() is returning.

But, either way, failing in HAL_RCC_ClockConfig() suggests that your oscillator is not working - so check that.

Post the schematics of your board.

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228 

[Andrew Neil]

---

@Faizan75 wrote:

The basic requirement of my application is that the firmware should run as soon i connect the battery/power supply, 

---

Of course - that is a basic requirement of any firmware!

---

@Faizan75 wrote:

which is not happening

Then how can you say:

---

@Faizan75 wrote:

it hangs/stops at

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK)  , 

---

That is in your firmware - so, it it's hanging at that point, then it is running your firmware!

[Faizan75]

Thank you for the reply,

Are you sure it is actually hanging in the HAL_RCC_ClockConfig() call, or is that code  really:

 Yes i am pit sure its hanging in this line because I am using step by step debug, and it is not going in 

Error_Handler();

as when i pause the debug it doesnt go to error handler,

In some cases when i start debug session it directly goes to HARD FAULT.

Currently i am using HSI clock source.

[Andrew Neil]

---

@Faizan75 wrote:

 Yes i am pit sure its hanging in this line because I am using step by step debug, and it is not going in 

---

So step into that function - see where, exactly, it is hanging.

---

@Faizan75 wrote:

In some cases when i start debug session it directly goes to HARD FAULT.

---

Could also be due to a clocking issue.

[TDK]

VDDA should have 1 uF + 0.1 uF decoupling caps. BOOT0 should be pulled low. Otherwise schematic looks okay.

I would guess the lack of VDDA caps isn't good. Shorting the ferrite bead would be a quick hack to fix this.

What is the cause of the hard fault? Use the hard fault analyzer.

[Andrew Neil]

---

@TDK wrote:

Use the hard fault analyzer.

---

@Mahmoud Ben Romdhane said that's been removed:

https://community.st.com/t5/stm32cubeide-mcus/fault-analyzer-no-hard-fault-info-no-toolbar-ide-v1-13-0/m-p/698742/highlight/true#M29108

:thinking_face:

@Faizan75 but plenty of resources on how to debug Cortex-M Hard Faults; eg,

https://community.arm.com/support-forums/f/embedded-forum/3257/debugging-a-cortex-m0-hard-fault