Custom STM32F103C8T6

Dallasta
Fri May 20, 2016 7:06 pm
Hey guys!

I recently designed a custom STM32 board for an RS485 aplication. I was using an Atmega 168 before and I was having trouble with speed, so I decided it was time to move.
The board is simply a STM32F103C8T6 with an AS5048A magnetic encoder and a SN65HVD78 transceiver. It reads the encoder via SPI and sends the information to a dynamixel servo network, using the dynamixel protocol. I have the SWD pins to program it.
As I already have the code for the arduino IDE so I was thinking what should I modify on my code to port it. Another question I have is how I set the clock on the microcontroller (on AVR devices you use the memory fuses)? I’m using a 16Mhz crystal to reach the 72Mhz.
If you want, I can send the codes, the libs and the board schematic.
Here is a picture of the boards (I have two different models to fit in different places). I’m now soldering them and waiting for a few components to arrive.
Image
I would apreciate a lot if someone could help me here.
Thanks!


Slammer
Fri May 20, 2016 9:19 pm
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.

Dallasta
Sat May 21, 2016 12:28 pm
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.

martinayotte
Sat May 21, 2016 1:18 pm
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;


RogerClark
Sat May 21, 2016 1:52 pm
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 ;-)


Vassilis
Sat May 21, 2016 2:23 pm
@Dallasta
Open the MXBluePillF103C8.ioc file with STM32CubeMX and see how the 8 MHz clock configuration is set on STM32F103C8 MCU (Clock Configuration tab).

Pito
Sun May 22, 2016 6:15 am
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

Signal32
Sun May 22, 2016 12:43 pm
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

RogerClark
Sun May 22, 2016 1:23 pm
can you post a code snippet when you get it working using the libmaple based core , of what you did to make it work

Dallasta
Sun May 22, 2016 6:38 pm
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?

RogerClark
Mon May 23, 2016 4:36 am
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


stevech
Mon May 23, 2016 10:57 pm
Signal32 wrote:
This is great! Now I can use 3225 16Mhz crystals which are ~5 times cheaper than the 8Mhz ones. Thanks!

Signal32
Mon May 23, 2016 11:55 pm
stevech wrote:Signal32 wrote:
This is great! Now I can use 3225 16Mhz crystals which are ~5 times cheaper than the 8Mhz ones. Thanks!

RogerClark
Tue May 24, 2016 2:33 am
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;
}


GrumpyOldPizza
Wed Jun 01, 2016 12:06 pm
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!

stevech
Wed Jun 01, 2016 5:30 pm
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.


Dallasta
Wed Jun 01, 2016 8:58 pm
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!

RogerClark
Wed Jun 01, 2016 9:23 pm
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


Dallasta
Wed Jun 01, 2016 10:15 pm
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


stevech
Thu Jun 02, 2016 2:01 am
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

RogerClark
Thu Jun 02, 2016 2:06 am
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

stevech
Thu Jun 02, 2016 4:02 am
Ah, I see. I just use ST-Link every day, but to do downloads and SWD. So, I don’t know what I don’t know! :|

Slammer
Thu Jun 02, 2016 7:03 am
STLink of nucleo boards is V2.1, while dongles are V2. USB CDC Serial is supported only in V2.1.

RogerClark
Thu Jun 02, 2016 7:15 am
Slammer wrote:STLink of nucleo boards is V2.1, while dongles are V2. USB CDC Serial is supported only in V2.1.

GrumpyOldPizza
Mon Jun 06, 2016 12:15 pm
RogerClark wrote:Slammer wrote:STLink of nucleo boards is V2.1, while dongles are V2. USB CDC Serial is supported only in V2.1.

Slammer
Mon Jun 06, 2016 12:21 pm
I can use the ST-Link part of my Nucleo-401RE to program the BluePill (103RE) with storage device (copy the binary to storage device) normally.
OK, the name of Volume created by ST-Link is always something with 401RE, but it works. Do you mean that every Nucleo’s stlink V2.1 is working only (as storage device) to specific variants of STM32 family?

GrumpyOldPizza
Mon Jun 06, 2016 12:32 pm
Slammer wrote:I can use the ST-Link part of my Nucleo-401RE to program the BluePill (103RE) with storage device (copy the binary to storage device) normally.
OK, the name of Volume created by ST-Link is always something with 401RE, but it works. Do you mean that every Nucleo’s stlink V2.1 is working only (as storage device) to specific variants of STM32 family?

Slammer
Mon Jun 06, 2016 2:12 pm
GrumpyOldPizza wrote: On the other hand it might be simply marketing, as the ST-Link on the Nucleo boards is fundamentally something different that an standalone ST-Link device.

GrumpyOldPizza
Mon Jun 06, 2016 3:15 pm
Slammer wrote:GrumpyOldPizza wrote: On the other hand it might be simply marketing, as the ST-Link on the Nucleo boards is fundamentally something different that an standalone ST-Link device.

Vassilis
Mon Jun 06, 2016 4:53 pm
I have the feeling that the SB12-SB15 jumpers should be de-soldered in case you don’t want to break the board in two parts,for isolating the ST-Link v2.1 from the main Nucleo MCU.

nucleo-board-bottom-side.jpg
nucleo-board-bottom-side.jpg (253.3 KiB) Viewed 1379 times

Slammer
Mon Jun 06, 2016 8:45 pm
No remove of resistors, no break of board.
Just remove the two jumpers on CN2 (see photo). The only problem I had with Nucleo-STLInk is that RESET pin is required for reseting the target system (or you have to reset manually by button or other way) . Note that VCC cannot power the target board from ST-Link (unlike the cheap ST-Link Dongles), is only for sensing the target voltage, but in Nucleo-STLink is NOT used. Note the TX & RX at CN3, these signals go to USB-CDC.

randybb
Mon Jun 06, 2016 8:48 pm
But these jumpers are for SWD interface only. In case you want to use serial interface as well, then you need to remove mentioned 0 ohm resistors.

Slammer
Mon Jun 06, 2016 8:57 pm
Yes! correct! Serial is available either by removing of SB14/SB15, either by breaking the ST-Link from the board.
The price of the board is so low and I think it is possible for someone to buy it, just for the ST-Link part (and keep the rest as a bonus).

Rick Kimball
Mon Jun 06, 2016 9:14 pm
randybb wrote:But these jumpers are for SWD interface only. In case you want to use serial interface as well, then you need to remove mentioned 0 ohm resistors.

Vassilis
Tue Jun 07, 2016 6:27 am
Rick Kimball wrote:randybb wrote:But these jumpers are for SWD interface only. In case you want to use serial interface as well, then you need to remove mentioned 0 ohm resistors.

Slammer
Tue Jun 07, 2016 1:41 pm
Rick Kimball wrote:I just pull the power jumper to the target chip and it won’t read or write on the serial pins. Oh and I use the power there to power the target off board chip

Rick Kimball
Tue Jun 07, 2016 3:49 pm
I haven’t seen any issues from doing this. However, it doesn’t mean your results will be the same

testato
Mon Sep 26, 2016 12:47 pm
Slammer wrote:No remove of resistors, no break of board.
Just remove the two jumpers on CN2 (see photo). The only problem I had with Nucleo-STLInk is that RESET pin is required for reseting the target system (or you have to reset manually by button or other way) . Note that VCC cannot power the target board from ST-Link (unlike the cheap ST-Link Dongles), is only for sensing the target voltage, but in Nucleo-STLink is NOT used. Note the TX & RX at CN3, these signals go to USB-CDC.

RogerClark
Mon Sep 26, 2016 9:13 pm
The STLink firmware is read protected, but I have seen copies of it in some Russian sites, as someone figured out who to hack the Windows program that does the firmware upgrade, and extracted the unencrypted binary from Windows memory.

Re:Usb mass storage

The STM32F103 does not have any built in USB profiles, ( unlike the F4).
You can write code so that its any form of USB device you want, but you have run code in the MCU to do this.

If you feel like writing a mass storage bootloader, please go ahead, but remember you wont be able to use the HAL or CMSIS etc as the code needs to be ultra small ( less then 0x2000 to be comparable with the existing DFU bootloader)


Slammer
Mon Sep 26, 2016 9:43 pm
The hacked firmware is for STLink/V2 not for V2.1
V2.1 adds some very important features like mass storage upload and USB/Serial passthrough, as I understand nobody has cloned the V2.1 (this is included on all Nucleo boards) as all Chinese clones support V2 operations.
If we compare the code size of BlackMagic (which is also a debuger/serial passtrough device), I dont think that would be possible to include this functionality in the code memory of a typical F103C8 as bootloader (and to have spare memory for a real application)

randybb
Mon Sep 26, 2016 9:47 pm
On Nucleo is STM32F103CB.

RogerClark
Mon Sep 26, 2016 10:54 pm
I suspect the STLink V2.1 would fit in a C8, especially as most C8’s are really CB’s ;-)

But I think the point is that the STLink (even V2) is not intended as a bootloader its a debugger, and would severely limit the amount of available code space left for applications.

The BMP is pretty much the same as the STLink, except without mass storage, and the BMP is quite large as well (i.e it would not be useful as a bootloader)

I think a mass storage bootloader would be great to have, but as using the HAL etc or any other lib e.g. libopencm3 would be impractical due to size, I doubt its practical


octavio
Wed Aug 30, 2017 7:19 pm
Is the external 8Mhz and 32khz crystals required or it could work (arduino bootloader and libs) just with the internal rc?
usb is not used.

Pito
Wed Aug 30, 2017 8:54 pm
usb is not usedIt could work when the RC oscillator’s frequency is known with at least 1-2% precision – because of Serial UART and of course millis() and friends.
STM32duino bootloader is usb based, but you may use ST-LINK/J-LINK, or serial upload.

Leave a Reply

Your email address will not be published. Required fields are marked *