NUCLEO_073RZ support

I am Trying to crate a new variant for the NUCLEO_073RZ and I am following this guide
https://github.com/stm32duino/wiki/wiki … 28board%29
I arrived at point 5 – System Clock configuration where is written
In variant.cpp, void SystemClock_Config(void) need to be defined.
It could be generated thanks STM32CubeMX or
copied from a STM32CubeYY project examples (where ‘YY’ could be F0, F1, F2, F3, F4, F7, L0, L1, L4)
Since there are 3 L0 boards that are already supported I am wandering if I can copy the necessary remaining configuration from one of the L0 boards.
The other way is to use CubeMX that I already have but I am not sure if I am able to use it but I can learn if necessary.

Hi Zoomx,

void SystemClock_Config(void)
{

RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;

/**Configure the main internal regulator output voltage
*/
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

/**Initializes the CPU, AHB and APB busses clocks
*/
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.HSICalibrationValue = 16;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
RCC_OscInitStruct.PLL.PLLMUL = RCC_PLLMUL_4;
RCC_OscInitStruct.PLL.PLLDIV = RCC_PLLDIV_2;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
_Error_Handler(__FILE__, __LINE__);
}

/**Initializes the CPU, AHB and APB busses clocks
*/
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;

if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1) != HAL_OK)
{
_Error_Handler(__FILE__, __LINE__);
}

/**Configure the Systick interrupt time
*/
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);

/**Configure the Systick
*/
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

/* SysTick_IRQn interrupt configuration */
HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
}

Thank you very much! Merci beaucoup!
I will give a try to cubeMX anyway!

Welcome.
A nice feature is the graphical clock configuration with automatic configuration (you can lock freq you desired then it search for the best configuration with source configured)

Done! Got NUCLEO_L073RZ blinking!

I removed my old CubeMX manually because it was in C:\Program Files folder instead the new one goes in C:\Program Files(x86) folder.
Thei I got an error about java, CubeMX was unable to find it. This was due to Oracle that instead of using only one folder for java uses as many folders as version you have but in register not all paths are updated. So I manually updated paths in registry and also in path environment variable.

Started CubeMX I created a new project started to put the mcu name STM32L0 and found that there is a NUCLEO_L073RZ option to click. So I clicked it.
I got some warning about some input ADC pins and USART2. I Ignored them since I am not as smart to resolve them.

After made all the modification started the IDE and got the infamous versioning problem described here
Board Nucleo_32 (platform stm32, package STM32) is unknown
https://github.com/stm32duino/wiki/wiki … ing-change
so I manually deleted the january core version and leaved the 1.2.0 version.

I chosed to use TIM3 for tone and servo but I am not sure that it’s the right choice.

Attached there is the folder with all definition and this was what I added in boards.txt Nucleo32 Nucleo64 section

# NUCLEO_L073RZ board
# NUCLEO_L073RZ board
Nucleo_64.menu.pnum.NUCLEO_L073RZ=Nucleo L073RZ
Nucleo_64.menu.pnum.NUCLEO_L073RZ.node=NODE_L073RZ
Nucleo_64.menu.pnum.NUCLEO_L073RZ.upload.maximum_size=196608
Nucleo_64.menu.pnum.NUCLEO_L073RZ.upload.maximum_data_size=20480
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.mcu=cortex-m0plus
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.board=NUCLEO_L073RZ
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.series=STM32L0xx
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.product_line=STM32L073xx
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.variant=NUCLEO_L073RZ
Nucleo_64.menu.pnum.NUCLEO_L073RZ.build.cmsis_lib_gcc=arm_cortexM0l_math

Warning is just to inform that pins is allocated to one function so an other is not possible at the same time.
TIM should be different btw tone and servo if you want use both at the same time.
In boards.txt, it should be in Nucleo64 as the Nucleo L073RZ is a Nucleo 64 but this is only to sort properly the board per package format.
This do not change the build process only the menu.
You can do a PR if you want integrate this variant in the core (most easiest way) or I can use your zip file.
HAve you a github (Microsoft ) account? If yes then I can set you as author of this variant.

I read that the NUCLEO_L073RZ is in the 64 NUCLEO en.DM00105918.pdf but the MCU seems a 32bit
http://www.st.com/en/microcontrollers/stm32l073rz.html
I assumed that all NUCLEO64 boards have a 64bit MCU but maybe I am wrong.

I have a github account but I prefer to test it in some way, I was able to compile one sketch using serial port but I see nothing in virtual serial ST-Link port, I am not sure thet USART2 is connected to ST-LINK and I have not around a serial adapter.

I planned some investigations!

Thank you very much!

Oh nucleo 64 is not for 64 bits it’s just a form factor
Nucleo 144 is not 144 bits .
STM32 are 32bits and STM8 are 8 bits.

STLink are connected on PA3/PA2 (Rx/Tx).
PeripheralPins.c show those pins can used 2 U(S)ART:
https://github.com/stm32duino/Arduino_T … ins.c#L145
PinMap_UART_TX:
{PA_2, LPUART1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_LPUART1)},
{PA_2, USART2, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_USART2)},

[zoomx – Tue Jun 05, 2018 12:48 pm] –
I assumed that all NUCLEO64 boards have a 64bit MCU but maybe I am wrong.

You made me laugh … I’m going to go order one of those 328 bit atmegas now

Modification made, it works, now usart2 is linked on the usb virtual com port.

zip updated

never noticed that there are nucleo144 otherwise the suspect that the number refers to pins instead of achitecture should be arised

At this point a little analogical data acquisition project works but more tests to do then PR on github.
Maybe adding the other pins that are not labelled on the board.

Pull Request done!