NUCLEO-F030R8 support for Arduino_Core_STM32

I took a first pass at adding a new variant with the new combined core. The board I’m using is the NUCLEO-F030R8, it has a smaller cortex-m0 chip, that only has 64k of flash and 8k of ram.

You can find the code here:
https://github.com/RickKimball/Arduino_Core_STM32

If you follow the steps I outlined in this post http://www.stm32duino.com/viewtopic.php … 172#p29377 ( sorry for hijacking the end of your thread @joelcrouch ), you can see how I created the files in the variant/NUCLEO_F030R8 directory.

To get this to compile, I had to hack up stm32/analog.c to avoid all the DAC functions. This could probably be nicer. I just wanted to throw this out here so others might try it.

One change I made because this chip has such a small amount of ram, I limited the variant to one Serial port. You can conditionally include the Serial1 if you add a define to the board.txt file (-DENABLE_SERIAL1). This change cuts down on the ram usage by not adding the usart buffer used by the second Serial1 port. You probably won’t use that most of the time anyhow. Serial is connected to the Nucleo board’s VCP and connected to cortex-m0 on USART2 (PA2/PA3). See UM1724 for the pin mapping.

I decided to make the default Oscillator the High Speed Internal one clocked at 48MHz using the PLL. I played around with the value of the internal Oscillator trim value and measured it with a scope. A value of 15 yields the most accurate 48MHz clock for me. You might have to adjust this if your clock speed isn’t right.

https://github.com/RickKimball/Arduino_ … t.cpp#L152

You can measure you clock speed by adding this line below to your setup() function. Then measure PA8 with a scope to find out your actual SYSCLK frequency.
HAL_RCC_MCOConfig(RCC_MCO, RCC_MCO1SOURCE_SYSCLK, RCC_MCODIV_1);

Hi Rick,

Thanks for your feedback.
I’ve done a pull request to fix when DAC is not available:
https://github.com/stm32duino/Arduino_C … 32/pull/28

I’ve also create the variant for the Nucleo F030R8:
https://github.com/stm32duino/Arduino_C … 32/pull/29

One strange things, the mount point of my board is named “NODE_F030R8”.

About your variant, in PeripheralPins.c, it is best to keep only one pin definition for the same feature (by commenting):
{PA7, TIM14, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM14, 1, 0)}, // TIM14_CH1
{PA7, TIM17, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_TIM17, 1, 0)}, // TIM17_CH1
{PA7, TIM1, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM1, 1, 1)}, // TIM1_CH1N
{PA7, TIM3, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM3, 2, 0)}, // TIM3_CH2

fpiSTM wrote:…
One strange things, the mount point of my board is named “NODE_F030R8”.

Rick Kimball wrote:
Maybe we should change the massStorageCopy application to try the NODE_XXXX first and if it isn’t found then look for NUCLEO?

fpiSTM wrote:Rick Kimball wrote:
Maybe we should change the massStorageCopy application to try the NODE_XXXX first and if it isn’t found then look for NUCLEO?

fpiSTM wrote:
Rick Kimball wrote:
How do you go about picking the proper timer? It seems fairly arbitrary. I noticed in your version of PeripheralPins.c in the case above you picked the last PA7 entry using TIM3_CH2 and commented out all the others.

Same for lsub:
$ lsusb -d 0483: -v | head -40

Bus 004 Device 014: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x374b ST-LINK/V2.1 (Nucleo-F103RB)
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 STLink
iSerial 3 0672FF485550755187054539
bNumConfigurations 1

For this case I think it is a user/developer choice. It make sense to follow the UM.
It provide a pins mapping configuration but nothing stops user to use one other timer.

fpiSTM wrote:
For the label I have well “NODE_F030R8” that’s why I have it as mount point name. As you have “NUCLEO” it uses “NUCLEO”. That is normal what I try to understand is why you have this label.

fpiSTM wrote:For this case I think it is a user/developer choice. It make sense to follow the UM.
It provide a pins mapping configuration but nothing stops user to use one other timer.

Yes same as mbed. For your version (without comment) the first one in the array is get.
Genpinmap extract all possible pin values for a mcu. Not linked to the boards.
It could not choose which one use instead of one other. User has to choose his configurations.

About the Node, you find the cause.
I have:
od -t x1 -c -A x </dev/sdb | head -100
000000 eb 3c 90 4d 53 44 30 53 34 2e 31 00 02 08 01 00
353 < 220 M S D 0 S 4 . 1 \0 002 \b 001 \0
000010 02 20 00 c8 00 f8 03 00 01 00 01 00 00 00 00 00
002 \0 310 \0 370 003 \0 001 \0 001 \0 \0 \0 \0 \0
000020 00 00 00 00 00 00 29 74 19 02 27 4e 4f 44 45 5f
\0 \0 \0 \0 \0 \0 ) t 031 002 ' N O D E _
000030 46 30 33 30 52 38 46 41 54 31 32 20 20 20 00 00
F 0 3 0 R 8 F A T 1 2 \0 \0
000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

I would have thought running the same firmware we would have had the same boot sector. I guess there must be bits on the newer board revisions that let the stlink side of the board know which NUCLEO it is supposed to be. I’ve had this board a long time. It is probably one of the first ones.

I moved the issue to the Arduino_Tools repo.
https://github.com/stm32duino/Arduino_Tools/issues/6

From UM1724 wrote:
“The board marking MB1136 C-01 corresponds to a board, configured as HSE not used.
The board marking MB1136 C-02 (or higher) corresponds to a board, configured to use
ST-LINK MCO as clock input.”

No Rick.
It should be a nice improvement.

Hi, Rick,

I have update the massStorageScript:
https://github.com/stm32duino/Arduino_Tools/pull/8

Still need to build the binary for MacOsx but it is ok for Linux32/64 and Windows.

Thanks @fpiSTM works great!