Skip to main content
RMatt
Associate
November 28, 2018
Question

Assert fail due to PLLR not being configured in code generated by CubeMX

  • November 28, 2018
  • 2 replies
  • 870 views

Hello,

I'm generating code for a project targeting the stm32767zi Nucleo. When I run the generated code, I encounter an assert_failed due to the PLLR not being configure to the correct value. If I look at the generated SystemClock_Config() function in main.c, there is no code generated to configure the PLLR, but there is code to configure other aspects of the PLL such as PLLM,Q, etc. So I believe that this is the cause of the failure.

I'm using the default clock configuration, and using the latest version of CubeMX and the HAL.

Is there a reason that the PLLR is not being configured? Is this a bug, or is there a setting somewhere I need to change?

Thanks

This topic has been closed for replies.

2 replies

Tesla DeLorean
Guru
November 28, 2018

Poorly tested and validated

As a rule of habit I initialize auto/local variables where I suspect there is opportunity for undefined operation.

 RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};

 RCC_OscInitTypeDef RCC_OscInitStruct = {0};

Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
RMatt
RMattAuthor
Associate
November 29, 2018

In the latest version of Cube, the initialization structs are now initialized to zero, which is good. Unfortunately for this application the PLLR has a valid range of values between 2-7, so setting it to 0 still causes an assertion failure. In my application I think I can ignore this assertion failure, since I'm not using the DSI hardware which receives the output of the PLLR clock, but it would be nice if the generated code could be fixed so this assertion failure doesn't occur