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

[RMatt]

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

[Tesla DeLorean]

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};

[RMatt]

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