STM32F4Discovery, CubeMX, and default RCC

[Charles Miller]

Posted on March 08, 2018 at 00:01

Creating a project using version 4.24 of CubeMX for the STM32F4Discovery board, I select 'yes' to 'Initialize all peripherals with their default Mode.'

The RCC block selects 'Crystal/Ceramic Resonator' for the LSE.  However, the device (X3) is not populated on the F4Discovery board, and so this entry should be 'disabled'.

The user manual (UM1472) states the part not provided is X1, but the schematic I have (1/9/2012) shows X3--a typo?

An issue, or my interpretation?

Thank you.

#cubemx #stm32f4discovery

[Tesla DeLorean]

Posted on March 08, 2018 at 00:05

Most of the boards with an ST-LINK on-board provide an 8 MHz signal via the MCO pin into the OSC_IN pin of the Target. Frequently solder bridges to support this. The code generator should ideally produce HSE BYPASS code in these situations.

[Charles Miller]

Posted on March 08, 2018 at 00:13

The Nucleo board UMs to describe this.  The STM32F4Discovery UM, however, only describes two options: one for an X3 oscillator, and another for an external signal 'from external oscillator trought the pin 9 of P2 connector.'  That would be pin PC14/RCC-OSC32-IN.  The ST-Link MCO is not connected to this pin, so there's only crickets to LSE.

I would think it should be disabled--even though the bypass 'assumes' an external clock.  But your point is very well taken.

Is there an updated board that supports ST-Link-sourced clock, Clive?

Thank you.

[Tesla DeLorean]

Posted on March 08, 2018 at 00:31

Sorry LSE

Yes, you have to populate X3, populate C16/C27 and R21/R22 (MB997B), done this on a handful of boards.

The secondary issue is that LSE is in low power domain, need power on VBAT when in STANDBY, etc.

[Charles Miller]

Posted on March 12, 2018 at 21:15

I've submitted a ticket to support; they acknowledged the output error and user manual typo, and I assume will fix in a future release.