Skip to main content
Dave Nadler
Dave Nadler
Senior III
October 4, 2019
Question

BUG: CubeMX-generated code fails to properly initialize PLLI2S, MCO2, etc.

  • October 4, 2019
  • 9 replies
  • 3320 views

Latest CubeMXIDE, code for F437. IOC to reproduce bugs attached. Here's the clock configuration:

0690X000009k4U3QAI.png

MCO2 required is 50MHz (for LAN8742A).

Clock diagram shows PLLI2S is used to generate 50MHz from external 12MHz crystal /8,

using *100 / 3, then PLLI2SCLK is fed to MCO.

Bug #1

The generated SystemClock_Config routine contains the following:

PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_PLLI2S;
 PeriphClkInitStruct.PLLI2S.PLLI2SN = 100;
 PeriphClkInitStruct.PLLI2S.PLLI2SR = 3;
 if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK)

Unfortunately, with these inputs,

the HAL_RCCEx_PeriphCLKConfig routine does absolutely nothing!

PLLI2S is neither set up nor enabled.

The idiotic function just happily returns HAL_OK after doing nothing.

Bug #2:

The CubeMX graphic does not show the output frequency of PLLI2S or PLLCLK

Bug #3:

Updating the PLL2IS x value to 200 fails to update the derived values.

@Markus GIRDLAND​ - Can you please confirm you can reproduce all 3 bugs and corresponding tickets are opened?

Is there a HAL or LL call that will actually set up PLL2IS properly ???

Or should I just give up on HAL/LL stuff???

For now I've just patched up the STM code to get things working (patched file attached).

Thanks!

Best Regards, Dave

This topic has been closed for replies.

9 replies

waclawek.jan
waclawek.jan
Super User
October 5, 2019

Maybe this time Cube/CubeMX is innocent.

https://community.st.com/s/question/0D50X0000BOvbShSQJ/nucleof429zi-mco2-is-not-working

But you said that

> For now I've just patched up the STM code to get things working.

So you got the I2S PLL working and outputting to MCO2?

What the patch is?

Please read out and post content of the relevant RCC and GPIO registers, before and after the patch.

JW

PS LAN8274 - there's no such

Note that PLL output may have more jitter than RMII allows.

Dave Nadler
Dave NadlerAuthor
Senior III
October 5, 2019

@Community member​ - CubeMX is absolutely guilty this time, again...

After RubeMX-generated SystemClock_Config(), PLLI2SCFG is at reset value and PLLI2S is not enabled.

Visual inspection or tracing through the function HAL_RCCEx_PeriphCLKConfig shows it does nothing for PeriphClockSelection = RCC_PERIPHCLK_PLLI2S.

Temporary patch is to fix routine to setup and enable PLLI2S for RCC_PERIPHCLK_PLLI2S.

LAN8742A, typo fixed above, thanks, also I attached patched HAL routine.

Board is now working on my network but I'll recheck the jitter requirements, thanks!

@Markus GIRDLAND​ - Is this all clear?

Thanks,

Best Regards, Dave

Markus GIRDLAND
Markus GIRDLAND
ST Employee
October 10, 2019

Sorry... busy week, haven't had much forum time to spare.

Looks like Amel is looking into it, though.

waclawek.jan
waclawek.jan
Super User
October 5, 2019

Okay, so it's technically CubeF4 and not CubeMX which is guilty... :)

Thanks for spotting this and sharing the solution.

So, there are 6 incarnations of HAL_RCCEx_PerphCLKConfig() in given file, and only the 'F4x7/'F4x9 incarnation appears to have this bug.

@Amel NASRI​  , can you please have a look at this? Btw. where did the Cube/HAL tag disappear?

JW

PS. Dave, I wonder, by this time, you still sticking to the whole Cube shebang?

Dave Nadler
Dave NadlerAuthor
Senior III
October 5, 2019

@Amel NASRI​ , @Community member​ Summary:

Maybe bug: Perhaps CubeMX is generating the wrong value for PeriphClockSelection.

Absolutely a bug: The HAL function should never return HAL_OK when it did absolutely nothing.

Absolutely a bug: Combination of CubeMX-generated code and HAL don't properly set up PLL2IS.

Hope that helps,

Best Regards, Dave

Amel NASRI
Amel NASRI
ST Technical Moderator
October 10, 2019

Hello @Dave Nadler​ ,

I reviewed the suggested patch and assume that there is an issue when RCC_PERIPHCLK_PLLI2S is selected.

I'll share this with our development team for deeper analysis.

Could you please provide more details about the 2 other "bugs" related to CubeMX: I don't understand BUG#2 and I cannot reproduce BUG#3.

Thanks,

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
Dave Nadler
Dave NadlerAuthor
Senior III
October 23, 2019

@Amel NASRI​ Further info:

Bug #2: The CubeMX graphic does not show the output frequency of PLLI2S or PLLCLK.

For all PLL, the graphic display should show the internal PLL frequency and the output frequency,

even if those frequencies are not currently selected.

Otherwise, for example, it is not possible to see if a PLL is in the allowed range, or if one s getting the desired output.

Bug #3: Load the example IOC, and try to change the *N value of the PLLI2S, for example to 150.

You will see the GUI screw up and not take the intended selection, pause a while and change the selection, and otherwise behave badly.

Hope that is clear!

Please confirm this is understood and tickets created,

Thanks,

Best Regards, Dave

Terms & ConditionsAccessibility statement