Custom STM32F103C8T6

Normally STM boards using 8MHz XTAL and a programmable PLL creates the 72MHz. There is a complex clock system compared with AVR, that clocks different peripherals. Arduino core makes everything for setting up the clock, but as I said, it is better to use 8MHz crystal.
I suggest to read at least the first chapters of Geoffrey Brown’s book from here: http://www.cs.indiana.edu/~geobrown/book.pdf
It is very important to know something about MCU, everything will be more easy.
As for Arduino compatibility, I can say that most of the libraries not related with hardware directly, will work almost untouchable. Everything is here, Serial, I2C, SPI. Some code with external Interrupts and hardware timers it is possible to need some rework.

Slammer wrote:Normally STM boards using 8MHz XTAL and a programmable PLL creates the 72MHz. There is a complex clock system compared with AVR, that clocks different peripherals. Arduino core makes everything for setting up the clock, but as I said, it is better to use 8MHz crystal.
I suggest to read at least the first chapters of Geoffrey Brown’s book from here: http://www.cs.indiana.edu/~geobrown/book.pdf
It is very important to know something about MCU, everything will be more easy.
As for Arduino compatibility, I can say that most of the libraries not related with hardware directly, will work almost untouchable. Everything is here, Serial, I2C, SPI. Some code with external Interrupts and hardware timers it is possible to need some rework.

In the case of F4xxx, it is quite explicit, the code is located in cores/maples/libmaple/rccF2.c :
/* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N */
#ifdef ARDUINO_STM32F4_NETDUINO2PLUS
int PLL_M = 25; // The NETDUINO has a 25MHz external oscillator
#else
int PLL_M = 8;
#endif
int PLL_N = 336;

/* SYSCLK = PLL_VCO / PLL_P */
int PLL_P = 2;

/* USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ */
int PLL_Q = 7;

Like Martin says..

Its defined for each variant on the F1.

AFIK, no one else uses 16Mhz. Most boards use 8Mhz, though at least 1 STM32 board uses 12Mhz, and the GD32 boards I have use 12Mhz.

Just to get the board working with your existing crystal, just hack the generic f130c board variant file
https://github.com/rogerclarkmelbourne/ … _setup.cpp

However I dont know how you setup a multipler of 16 to give you 72mhz. Youd need mult of 4.5

This may be possible, but I’m not sure

The values are defined in

https://github.com/rogerclarkmelbourne/ … ries/rcc.h

But you’d need to look in the main reference for the F103 (google RM0008) or click here http://www2.st.com/resource/en/referenc … 171190.pdf

And look to see if its supported and if so , how you set it.

But in the long term, get some 8Mhz crystals

@Dallasta
Open the MXBluePillF103C8.ioc file with STM32CubeMX and see how the 8 MHz clock configuration is set on STM32F103C8 MCU (Clock Configuration tab).

There is a prescaler by 2 in front of PLL so you may divide a 16MHz crystal to get 8MHz and use the PLL setting as is. In order to switch the prescaler on:
PLLXTPRE: HSE divider for PLL entry
Set and cleared by software to divide HSE before PLL entry. This bit can be written only
when PLL is disabled.
0: HSE clock not divided
1: HSE clock divided by 2

Pito wrote:There is a prescaler by 2 in front of PLL so you may divide a 16MHz crystal to get 8MHz and use the PLL setting as is. In order to switch the prescaler on:
PLLXTPRE: HSE divider for PLL entry
Set and cleared by software to divide HSE before PLL entry. This bit can be written only
when PLL is disabled.
0: HSE clock not divided
1: HSE clock divided by 2

can you post a code snippet when you get it working using the libmaple based core , of what you did to make it work

Thanks for the help guys!
Now i’m really considering using 8Mhz crystals…
What’s the default configuration for the clock? I really dont want to hack things and hope for them to work. I dont have much time to finish this projetc (Brace yourselves, Robocup is coming!). If I use an 8Mhz crystal, the prescalers are already set to reach 72Mhz?

Yes

Use 8Mhz and you won’t need to change any code.

I suspect to use 16Mhz, the change you would need to make is just 1 bit in one register, but I’d need to read the big manual on the STM32F103 to work out which bit enabled the DIV 2 on the input clock

Signal32 wrote:
This is great! Now I can use 3225 16Mhz crystals which are ~5 times cheaper than the 8Mhz ones. Thanks!

stevech wrote:Signal32 wrote:
This is great! Now I can use 3225 16Mhz crystals which are ~5 times cheaper than the 8Mhz ones. Thanks!

If you want to try to use your 16Mhz crystals

I think you’ll need to modify

STM32F1\cores\maple\libmaple\rcc_f1.c

Specifically

void rcc_configure_pll(rcc_pll_cfg *pll_cfg) {
stm32f1_rcc_pll_data *data = pll_cfg->data;
rcc_pll_multiplier pll_mul = data->pll_mul;
uint32 cfgr;
/* Check that the PLL is disabled. */
ASSERT_FAULT(!rcc_is_clk_on(RCC_CLK_PLL));

cfgr = RCC_BASE->CFGR;
cfgr &= ~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLMUL);
cfgr |= pll_cfg->pllsrc | pll_mul;

RCC_BASE->CFGR = cfgr;
}

Signal32 wrote:stevech wrote:Signal32 wrote:
This is great! Now I can use 3225 16Mhz crystals which are ~5 times cheaper than the 8Mhz ones. Thanks!

Wouldn’t a 16MHz crystal press the PLL stability and noise less than an 8MHz?

And, on the STM32F4 (and others?) the internal clock that runs at power up (HSI) and runs all the C startup code, is 16MHz. Switching to the HSE clock, stays at 16MHz until (or if) the PLL is used. Note that the C startup code at HSI speed has the problem that if you have a lot of BSS to be zero’d and/or a huge number of initialized variables (other than const), that all runs at HSI speed and can slow the startup process – if that’s a factor. It is in one of my projects where the CPU has to get to the first line of code in main.c in < 10mSec.

I have an app on the ‘415 that runs at 16MHz for power up (hardware dictated) then on the PLL at 64MHz for most processing. When it’s time to number-crunch, I switch to 168MHz for a few hundred mSec. Then back. For the switch, I reprogram some of the peripherals (debut UART, SPI) so they will stay at the same line speed no matter the speed switching to 168 then back to 64MHz.

Point being, the 8MHz crystal choice has other factors that may apply to some cases.

Thank you guys for all the help, the 8mhz crystal seems to be working fine.
But I still have some doubts about the programming. Today I tried to make the serial work (uploading thru ST Link and no bootloader) and I was not able to do it. My hardware uses the USART2 and maybe that was the problem. Can someone help me?
Im still very newbie with ARM controllers, i have just dealed with AVR devices.
Also had a problem with the PWM, I dont know why, but it seems to just turn the pin to a normal IO pin, I could not set the frequency for it, hope someone have an idea avout this also.
Thanks!

I think STLink upload has USB serial enabled,

so Serial = USB Serial
Serial1 is Hardware serial 1
Serial2 is Hardware serial 2
etc

If you dont want USB serial, you will need to change boards.txt to remove the inline definitions for the USB serial stuff

or try uploading via Serial, as that upload mode does not have USB serial enabled

RogerClark wrote:I think STLink upload has USB serial enabled,

so Serial = USB Serial
Serial1 is Hardware serial 1
Serial2 is Hardware serial 2
etc

If you dont want USB serial, you will need to change boards.txt to remove the inline definitions for the USB serial stuff

or try uploading via Serial, as that upload mode does not have USB serial enabled

win 7 here. ST-Link shows up in device manager USB list as “Universal Serial Bus Devices \ STMIcroelectronics STLink dongle.”
Not in “Ports” serial ports

stevech wrote:win 7 here. ST-Link shows up in device manager USB list as “Universal Serial Bus Devices \ STMIcroelectronics STLink dongle.”
Not in “Ports” serial ports