[SOLVED] STM32F030F4 Internal RC

[BJHenry]

I'm really glad to see this forum back up and running. I'm just starting to play around with the STM32 micros- I've been using the 8bit Arduinos for a couple of years now and want to start using something a bit more powerful.
I've used a Robotdyn STM32F103C8 board for a couple of projects and haven't had any trouble that I couldn't get myself out of, but I'm experimenting with an STM32F030F4 that I'd like to use in a smaller project and I'm having some issues. Namely, although the firmware upload process appears to go ok the micro doesn't actually do anything.
For my setup I have an STM32F030F4 soldered onto a breakout board. This is in turn soldered onto a piece of breadboard which also has a USB-Serial adapter soldered onto it, as well as a 3.3V voltage regulator to power the STM32. The regulator is an uA78M33 and the USB-Serial adapter is this one. This USB-Serial adapter provides 5V to the regulator and has a 100nF capacitor on the line labelled 'RST' so that it can restart the micro at the start of code upload. the BOOT0 pin has a pullup to 3.3V and is broken out a 2pin header so that I can short it to ground when I want.
Here is the schematic:

test.png (41.9 KiB) Viewed 10044 times

There are pullups to 5V on PA9, PA10, PA13 and PA14 because I'd like to use them to interface with a 5V DAC once I've gotten the micro working.
I don't have any resonators/crystals on hand so I'd like to use the internal RC as the system clock.
I believe that this setup is working since the upload process appears to complete without a hitch. Here is the console output once the upload is complete:

Code: Select all

Sketch uses 10796 bytes (65%) of program storage space. Maximum is 16384 bytes.
Global variables use 896 bytes (21%) of dynamic memory, leaving 3200 bytes for local variables. Maximum is 4096 bytes.
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.1.0                  
      -------------------------------------------------------------------

Serial Port COM6 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
Activating device: OK
Chip ID: 0x444 
BootLoader protocol version: 3.1
Device name : STM32F03x
Device type : MCU
Device CPU  : Cortex-M0



Memory Programming ...
Opening and parsing file: Blink.ino.bin
  File          : Blink.ino.bin
  Size          : 11012 Bytes
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 10]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:01.911

RUNNING Program ... 
  Address:      : 0x8000000
Start operation achieved successfully

Since I don't have an external clock source I'm using the 'STM32F030F4 Demo board (internal RC oscillator)' option in Tools>Board Part Number.

Using this simple blink code:

Code: Select all

void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(PA4, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(PA4, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(PA4, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

gives no output on pin PA4 and I'm not sure why. Is there an issue with trying to use the micro while it doesn't have an external clock source? I have some resonators on the way.
VDD and VDDA are both at a steady 3.3V and are each individually decoupled.
My understanding was the STM32s will look for an external clock source, and if there isn't one they'll default to using the internal RC.
If anyone could offer some advice I'd appreciate.

[ag123]

i've not played with an m0, but i'd think even if you don't change the internal rc frequency, it would start up with a fixed HSI frequency like 8mhz?
my guess is that it may help to hook up with an st-link over swd, if nothing works it may point to a hardware problem.
if it traces codes, u'd be able to step the statements/instructions to see what could be the problem.
if the codes tries to switch to HSE it is probably the catch.

i think if you can program the f030 using usb-uart, HSI is already working ok. otherwise, even that should fail

[Just4Fun]

If I remember well, driving BOOT0 to 3.3V will start the internal serial bootloader for ever.
In this way, after every reset you will start the internal bootloader, not your "user" program...

So may be better:

1) disconnect NRST from the serial-usb DTR
2) reset the stm32 (BOOT0 = 3.3V -> Serial bootloader activated)
3) upload the "user" program with arduino (serial bootloader)
4) jumper BOOT0 to GND ( -> execute "user" program from flash)
5) reset.

Now your blink test should work...

[stas2z]

yes, boot0 have to be pulled down for normal operation

[stevestrong]

My understanding was the STM32s will look for an external clock source, and if there isn't one they'll default to using the internal RC.

That is wrong.
The system clock must be selected manually in the clock configuration register RCC_CFGR. The parameter SW (System Clock Switch) is responsible to select HSI (internal 8 MHz clock), HSE (external quartz) or PLL. Have a look into RM0360 chapter 7.

If you don't have any external resonator components, you have to set SW to 00.
This is the default value, but you have to check whether your application or core startup files will change this value or not.

[BJHenry]

If I remember well, driving BOOT0 to 3.3V will start the internal serial bootloader for ever.
In this way, after every reset you will start the internal bootloader, not your "user" program...

So may be better:

1) disconnect NRST from the serial-usb DTR
2) reset the stm32 (BOOT0 = 3.3V -> Serial bootloader activated)
3) upload the "user" program with arduino (serial bootloader)
4) jumper BOOT0 to GND ( -> execute "user" program from flash)
5) reset.

Now your blink test should work...

You were on the money. After the upload has finished I can ground the BOOT0 pin and reset the MCU to make it work.
This behaviour is different to what I've seen on an STM32F103C8 that I've used on another project- with that one it automatically starts the user code after upload is finished.

My understanding was the STM32s will look for an external clock source, and if there isn't one they'll default to using the internal RC.

That is wrong.
The system clock must be selected manually in the clock configuration register RCC_CFGR. The parameter SW (System Clock Switch) is responsible to select HSI (internal 8 MHz clock), HSE (external quartz) or PLL. Have a look into RM0360 chapter 7.

If you don't have any external resonator components, you have to set SW to 00.
This is the default value, but you have to check whether your application or core startup files will change this value or not.

Section 7.2.6 of that RM says the following:

7.2.6 System clock (SYSCLK) selectionVarious clock sources can be used to drive the system clock (SYSCLK):HSI oscillatorHSE oscillatorPLLAfter a system reset, the HSI oscillator is selected as system clock. When a clock source is used directly or through the PLL as a system clock, it is not possible to stop it.A switch from one clock source to another occurs only if the target clock source is ready (clock stable after startup delay or PLL locked). If a clock source which is not yet ready is selected, the switch will occur when the clock source becomes ready.

I took this to mean that it wouldn't change from internal to external oscillator until the external one was up and running satisfactorily.

[ag123]

when the system (stm32) starts, it runs on HSi
there should be codes that switches to HSE
e.g. in RM0091 A3.1 HSE start sequence code example
https://www.st.com/content/ccc/resource ... 031936.pdf

Code: Select all

/**
* Description: This function enables the interrupt on HSE ready,
*
 and start the HSE as external clock.
*/
__INLINE void StartHSE(void)
{
/* Configure NVIC for RCC */
/* (1) Enable Interrupt on RCC */
/* (2) Set priority for RCC */
NVIC_EnableIRQ(RCC_CRS_IRQn); /* (1)*/
NVIC_SetPriority(RCC_CRS_IRQn,0); /* (2) */
/* (1) Enable interrupt on HSE ready */
/* (2) Enable the CSS
Enable the HSE and set HSEBYP to use the external clock
instead of an oscillator
Enable HSE */
/* Note : the clock is switched to HSE in the RCC_CRS_IRQHandler ISR */
RCC->CIR |= RCC_CIR_HSERDYIE; /* (1) */
RCC->CR |= RCC_CR_CSSON | RCC_CR_HSEBYP | RCC_CR_HSEON; /* (2) */
}

^ i think there is probably a need to check that the HSE clock is successfully running before switching to it
i think there may be a endless spinlock which check for HSE to become ready. you may like to look up the codes
and if you find it you may like to change the codes to a time limited spinlock, e.g. after a certain count fall back to HSI.
but normally as crystals are physically wired, i think it is more common to do a endless spinlock

then followed by a sequence to set the pll clock for system clock
RM0091 section 6.2.4 PLL p102
https://www.st.com/content/ccc/resource ... 031936.pdf

1. To modify the PLL configuration, proceed as follows:
2. Disable the PLL by setting PLLON to 0.
3. Wait until PLLRDY is cleared. The PLL is now fully stopped.
4. Change the desired parameter.
5. Enable the PLL again by setting PLLON to 1.
6. Wait until PLLRDY is set.

if you are using codes that can switch to a HSE, you would need to look up in your codes for that section of codes and probably comment codes that call those HSE switching / setting functions.

You were on the money. After the upload has finished I can ground the BOOT0 pin and reset the MCU to make it work.
This behaviour is different to what I've seen on an STM32F103C8 that I've used on another project- with that one it automatically starts the user code after upload is finished.

if you are referring to libmaple core, in particular upload the auto reset after upload over DFU
in libmaple core, there is a [DTR]LEAF reset magic sequence. it is in the usb-serial codes.
this has nothing to do with BOOT0

[Just4Fun]

...I took this to mean that it wouldn't change from internal to external oscillator until the external one was up and running satisfactorily.

I can confirm this behavior. I've done some testing on a STM32F030R8 about it.

Here I've attached a sketch (ST official core) I've used to check which oscillator is active, using both direct registers access and a HAL library.
I've used it on two identical STM32F030R8 boards, one with the crystal not populated.

[stevestrong]

...I took this to mean that it wouldn't change from internal to external oscillator until the external one was up and running satisfactorily.

This is correct, but it is not equivalent to using as fallback the default HSI clock. The MCU will just wait endless for the HSE clock ready, but will not automatically change back to HSI.

[stevestrong]

@ratketyree
That was not my citation, just read what I have responded to that (same as you did)
viewtopic.php?p=1349#p1349