NUCLEO_073RZ support

Mon Jun 04, 2018 3:44 pm
I am Trying to crate a new variant for the NUCLEO_073RZ and I am following this guide … 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.

Mon Jun 04, 2018 7:40 pm
Hi Zoomx,

void SystemClock_Config(void)

RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;

/**Configure the main internal regulator output voltage

/**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;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
_Error_Handler(__FILE__, __LINE__);

/**Initializes the CPU, AHB and APB busses clocks
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

/**Configure the Systick

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

Mon Jun 04, 2018 7:54 pm
Thank you very much! Merci beaucoup!
I will give a try to cubeMX anyway!

Mon Jun 04, 2018 8:01 pm
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)

Tue Jun 05, 2018 9:13 am
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 … 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 L073RZ

Tue Jun 05, 2018 11:15 am
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 :lol: ) account? If yes then I can set you as author of this variant.

Tue Jun 05, 2018 12:48 pm
I read that the NUCLEO_L073RZ is in the 64 NUCLEO en.DM00105918.pdf but the MCU seems a 32bit
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!

Tue Jun 05, 2018 1:04 pm
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: … ins.c#L145

Rick Kimball
Tue Jun 05, 2018 1:07 pm
[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 ;)

Tue Jun 05, 2018 2:51 pm
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 :oops:

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.

Fri Sep 28, 2018 9:12 am
Pull Request done!

Leave a Reply

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