Cube says STM32F411 clock configuration is invalid, but processor still runs correctly

[Eqqman]

Hello-

Working with the STM32F411 on the ST F411 Discovery board, we have set the speed to 72MHz using the HSI as the PLL source.  The register values are as follows:

RCC->CR = 0x03005C83

RCC->PLLCFGR = 0x23001208

According to Cube, this configuration is invalid:

In fact, there seems to be NO clock speed we can find that won't flag the configuration as invalid if HSI is the PLL source.  Although the code appears to run correctly and there haven't been any timing issues experienced we want to check if there is some additional clock setting someplace that needs to be used to stop Cube from flagging this as an error.  Current version of cube is:

STM32CubeIDE

Version: 1.15.0

Build: 20695_20240315_1429 (UTC)

But this issue is not new, it has happened on older versions as well.

[SofLit]

Hello,

Could you please share the error/warning message CubeMx is showing for that configuration?

[Eqqman]

As you can see in the original attached image, there is a red box around the HSI selection at the PLL Source Mux input.  This box is there any time HSI is chosen as the input no matter what /M /N /P settings we pick.  The tool-tip that pops up when you hover over merely says "PLL Mux should have HSE as input".

EDIT : The STM32 Discovery board does have an external oscillator attached to the HSE inputs, so theoretically the chip could be ignoring our RCC settings and using the external crystal, but in such a case, all our timings would be off since we'd be basing them on the wrong cpu speed.  There is also nothing I can find in the F411 documentation that gives any case where the HSI clock is not allowed as a PLL source.

[SofLit · Accepted solution]

Hello,

I reproduced the behavior.

Are you enabling USB in your project? if not disable it from here:

If you need USB function, you need to use HSE with an external crystal.

[Eqqman]

Yes, that seems to be the issue.  The curious thing though is that USB functionality appears to be correct regardless, so we will need to check this again.  Our USB stack is a 3rd-party project from github and their clock configuration code is as follows:

/* modify bitfield */
#define _BMD(reg, msk, val)     (reg) = (((reg) & ~(msk)) | (val))
/* set bitfield */
#define _BST(reg, bits)         (reg) = ((reg) | (bits))
/* clear bitfield */
#define _BCL(reg, bits)         (reg) = ((reg) & ~(bits))
/* wait until bitfield set */
#define _WBS(reg, bits)         while(((reg) & (bits)) == 0)
/* wait until bitfield clear */
#define _WBC(reg, bits)         while(((reg) & (bits)) != 0)
/* wait for bitfield value */
#define _WVL(reg, msk, val)     while(((reg) & (msk)) != (val))
/* bit value */
#define _BV(bit)                (0x01 << (bit))

    /* set flash latency 2WS */
    _BMD(FLASH->ACR, FLASH_ACR_LATENCY, FLASH_ACR_LATENCY_2WS);

    _BMD(RCC->PLLCFGR,
        RCC_PLLCFGR_PLLM | RCC_PLLCFGR_PLLN | RCC_PLLCFGR_PLLSRC | RCC_PLLCFGR_PLLQ | RCC_PLLCFGR_PLLP,
        _VAL2FLD(RCC_PLLCFGR_PLLM, 😎 | _VAL2FLD(RCC_PLLCFGR_PLLN, 72) | _VAL2FLD(RCC_PLLCFGR_PLLQ, 3));

    RCC->CFGR &= ~((uint32_t)(0x07 << 0x0A));
    RCC->CFGR |=  ((uint32_t)(0x04 << 0x0A));
    /* enabling PLL */
    _BST(RCC->CR, RCC_CR_PLLON);
    _WBS(RCC->CR, RCC_CR_PLLRDY);
    /* switching to PLL */
    _BMD(RCC->CFGR, RCC_CFGR_SW, RCC_CFGR_SW_PLL);
    _WVL(RCC->CFGR, RCC_CFGR_SWS, RCC_CFGR_SWS_PLL);

    /* enabling GPIOA and setting PA11 and PA12 to AF10 (USB_FS) */
    _BST(RCC->AHB1ENR, RCC_AHB1ENR_GPIOAEN);
    _BST(GPIOA->AFR[1], (0x0A << 12) | (0x0A << 16));
    _BMD(GPIOA->MODER, (0x03 << 22) | (0x03 << 24), (0x02 << 22) | (0x02 << 24));

As mentioned the Discovery board does have the external crystal attached, so possibly the USB peripheral is still being clocked by this despite enabling HSI as the input source?  We may need to double-check this on a Discovery board with the crystal removed or somehow disabled.

[SofLit]

I’m not expert of usb but as I said previously you need to use HSE for usb either in crystal or in bypass mode. 

[Bob S]

Yeah - the HSI is not stable enough over temperature and voltage for the USB spec.  It may work at room temperature in your particular setup, but that is no guarantee it will work elsewhere under different conditions.

[Eqqman]

We'll have to see how it goes.  In our particular application the USB stack is running as a device and two internal components are using USB to communicate with each other, so this may not be a huge issue.  Especially if it passes the hair dryer test...

[Bob S]

Really???  I sure wouldn't want my name or company's name attached to that kind of design.

[Andrew Neil]

Instead of just saying it's invalid, it would be helpful if CubeMX would say what the problem(s) is/are .