RCC stuck!

[Ala]

hey there

I have a customized board with STM32F030K6T6 on it and a 11.0592MHz crystal for HSE. the thing is my code does not run through and when I try to debug it, I can see it sticks in SystemClock_Config(), more specifically, in HAL_RCC_OscConfig() and when I trace it even more I get to __HAL_RCC_HSE_CONFIG() which seems like is responsible for bit setting and stuff...

any ways I have no Idea why this happens and though I think crystal is just fine(the reason is that I have tested my code in other boards and it was OK! therefore I dont think the problem is my code, it should be hardware somehow but I dont know what it could be?)

HELP!

[Ala]

I guess that crystal is not properly soldered to the board, as I push it to the board, my code runs, and as soon as I leave it, it stops

[Peter BENSCH]

Yes, that could well be a problem.

There are, however, ways to catch the issue, because it could also occur during operation (e.g. broken internal bond wires of the crystal): the CSS (Clock Security System) is designed to switch over to the HSI in the event of a failure of the HSE and also to report it via NMI. Details can be found in RM0360, section 7.2.7.

Regards

/Peter

[Ala]

thanks @Peter BENSCH​ 

is there a way to enable CSS in CubeMX? I mean I have enable it in Clock configuration panel, but I dont think this helped... it still has problem sticking in RCC... should I do something in void NMI_Handler(void) interrupt?

regards

[Peter BENSCH]

Well, if you don't change NMI_Handler() accordingly, the function gets stuck in while(1).

The description for HAL_RCC_EnableCSS(), inserted in SystemClock_Config(), says:

If a failure is detected on the HSE oscillator clock, this oscillator is automatically disabled and an interrupt is generated to inform the software about the failure (Clock Security System Interrupt, CSSI), allowing the MCU to perform rescue operations. The CSSI is linked to the Cortex-M0 NMI (Non-Maskable Interrupt) exception vector.

So you'll get a top priority information that HSE has failed, but of course only you know what to do then.

Regards

/Peter

[Ala]

"Well, if you don't change NMI_Handler() accordingly, the function gets stuck in while(1)."

I dont see any while(1) here is the generated code

void NMI_Handler(void)
{
  /* USER CODE BEGIN NonMaskableInt_IRQn 0 */
 
  /* USER CODE END NonMaskableInt_IRQn 0 */
  HAL_RCC_NMI_IRQHandler();
  /* USER CODE BEGIN NonMaskableInt_IRQn 1 */
 
  /* USER CODE END NonMaskableInt_IRQn 1 */
}

let me ask my question in a different way:

1-if I enable CSS in CubeMX, even if HSE fails, I have the security of switching to HSI, right? nothing to do further?

2-of curse if HSE fails, it will inform me through NMI_Handler()(above code), where I can insert my customized code. assuming HSE has failed and MCU has switched to HSI. and now for example I want to inform this using USART. does UART work now? we all know that UART needs a very accurate clock. are you saying switching to HSI, manages UART?

thanks for you helpful and informative replies:folded_hands:

Regards

[Peter BENSCH · Accepted solution]

The current version of STM32CubeMX generates a while trap in USER CODE NonMaskableInt_IRQn 1:

void NMI_Handler(void)
{
  /* USER CODE BEGIN NonMaskableInt_IRQn 0 */
 
  /* USER CODE END NonMaskableInt_IRQn 0 */
  HAL_RCC_NMI_IRQHandler();
  /* USER CODE BEGIN NonMaskableInt_IRQn 1 */
  while (1)
  {
  }
  /* USER CODE END NonMaskableInt_IRQn 1 */
}

1. The changeover to HSI is automatic, as the RM0360 says: If the HSE oscillator is used [...] as the system clock [...], a detected failure causes a switch of the system clock to the HSI oscillator and the disabling of the HSE oscillator.
2. Everything after switching to HSI must of course be done by the user. The custom code should be inserted either before or after the call to NMIHandler, depending on the requirement. In your case, it seems to make sense to insert it instead of the while trap, because the RCC CSS pending bit has already been cleared. For UART, about 3% accuracy of the clock is sufficient because of oversampling. HSI, however, typically has 5%, but can also reach the required accuracy with user calibration (HSITRIM).

Good luck!

Regards

/Peter

[Ala]

thanks @Peter BENSCH​ ! you saved the day! many thanks again:folded_hands: :folded_hands: :folded_hands:

[JustSomeGuy]

I had the same problem and this solved it. It was hard to narrow down the source, since as soon as it went into that while trap, the debug would just show the controller looping through a chunk of ROM. Thanks, Peter!