[ralfdoering]

Summary

MB1136 C-01 boards have no external HSE clock connected in their documented default configuration. The existing NUCLEO-F030R8 option requires an external 8 MHz clock in HSE bypass mode, normally supplied by ST-LINK MCO, so sketches cannot start on these boards.

Add Nucleo F030R8 (HSI, 48 MHz) under Board part number, using the internal 8 MHz HSI oscillator divided by 2 and multiplied by 12.

Both selections share the existing board macro, variant files, pin mapping, linker script, upload methods and debugger configuration. The existing HSE selection and its FQBN remain unchanged.

A separate part-number option follows the existing HSI-selection pattern of the STM32F030F4 demo board. It avoids introducing a clock menu for the entire Nucleo-64 group or an automatic fallback that could conceal an external-clock failure.

The documentation explains the clock selection and HSI accuracy considerations. The generated supported-board list is updated.

Reference: ST UM1724, Rev 17, section 7.9.1, page 25.

Validation

Tested against main at 6a2cddac668cbbaeb4ce1c6fd638f2fe4672fec9 (3.0.1-dev), including its pinned ArduinoCore-API submodule, using Arduino CLI 1.5.1 and GCC 14.2.1-1.1.

Build checks

The checkout was installed as upstreamstm32:stm32 in an isolated test sketchbook. From the repository root, the equivalent build commands are shown below; $ARDUINO_CLI denotes the executable bundled with Arduino IDE:

"$ARDUINO_CLI" --config-file ../arduino-cli.yaml compile --clean \
  --fqbn upstreamstm32:stm32:Nucleo_64:pnum=NUCLEO_F030R8_HSI,upload_method=OpenOCDSTLink,dbg=enable_sym \
  --build-path ../upstream-hsi-build ../Blink

"$ARDUINO_CLI" --config-file ../arduino-cli.yaml compile --clean \
  --fqbn upstreamstm32:stm32:Nucleo_64:pnum=NUCLEO_F030R8,upload_method=OpenOCDSTLink,dbg=enable_sym \
  --build-path ../upstream-hse-build ../Blink

Both builds succeed using the unmodified Arduino Blink example:

• HSI: 9,604 bytes Flash, 880 bytes RAM.
• HSE: 9,608 bytes Flash, 880 bytes RAM.

The existing HSE SystemClock_Config() produces byte-for-byte identical machine code to the unpatched version under the same compiler flags. All existing boards.txt properties remain unchanged; the additional properties belong exclusively to the new HSI selection.

Hardware checks

• The HSI build was uploaded to NUCLEO-F030R8 MB1136 C-01 through OpenOCD/ST-LINK, with successful flash verification.
• SWD inspection confirmed HSI and PLL ready, HSE disabled, HSI/2 × 12, and SystemCoreClock = 48000000.
• The millisecond counter advances and PA5 / LED_BUILTIN toggles.
• The patched checkout was additionally tested directly from Arduino IDE 2.3.10 on Fedora 44 using STM32CubeProgrammer (SWD). Compilation, upload and Blink operation succeeded. That IDE build uses 9,608 bytes Flash and 880 bytes RAM, with no compiler warnings or errors.

Documentation checks

From the repository root, using the local documentation environment:

python3 docs/hooks/supported_boards.py
../docs-venv/bin/mkdocs build --strict
git diff --check

Supported-board generation, the strict documentation build and whitespace checks pass.

Code formatting

AStyle 3.1 passes with no formatting changes. The locally built executable was selected explicitly:

python3 CI/astyle/astyle.py -g -p ../astyle/build/gcc/bin

Test limitations

The existing HSE selection was compiled but has not been hardware-tested on a C-02+ board. Independent oscillator-frequency measurement, UART accuracy testing and the graphical IDE debugger have not been performed.

GitHub CI results will be checked after submission.

Closing issues

Fixes #3104.

[fpistm]

Hi @ralfdoering
Thanks for pointing this, could you test my comment, please.

[fpistm]

I would recommend to test the return value of HAL_RCC_OscConfig and if it is HAL_TIMEOUT then configure the HSI. This would avoid to have 2 entries.
HAL_RCC_OscConfig enable and Wait till HSE is ready if not then return HAL_TIMEOUT

[ralfdoering]

So, we should try HSE first and fallback to HSI is HSE fails during initialization? Sounds reasonable.

[fpistm]

Yes.
Something like that:

@@ -111,21 +111,34 @@ extern "C" {
   */
 WEAK void SystemClock_Config(void)
 {
   RCC_OscInitTypeDef RCC_OscInitStruct = {};
   RCC_ClkInitTypeDef RCC_ClkInitStruct = {};
+  HAL_StatusTypeDef ret = HAL_OK;
   /*
    * Initializes the RCC Oscillators according to the specified parameters
    * in the RCC_OscInitTypeDef structure.
    */
   RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
   RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;
   RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
   RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
   RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6;
   RCC_OscInitStruct.PLL.PREDIV = RCC_PREDIV_DIV1;
-  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) {
+  ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);
+  if (ret == HAL_TIMEOUT) {
+    /* Try HSI when no external clock is connected, e.g. MB1136 C-01. */
+    /* HSI 8 MHz / 2 * 12 = 48 MHz. */
+    RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
+    RCC_OscInitStruct.HSIState = RCC_HSI_ON;
+    RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
+    RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
+    RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
+    RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL12;
+    ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);
+  }
+  if (ret != HAL_OK) {
     Error_Handler();
   }
   /* Initializes the CPU, AHB and APB buses clocks */
   RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK
                                 | RCC_CLOCKTYPE_PCLK1;

[fpistm]

Here the commit replacing your one with the updated clock config: fpistm@86a68db

[ralfdoering]

Can confirm, this correctly falls back to HSI as intended.

[fpistm]

Could you update your PR then I could merge.