cancel
Showing results for 
Search instead for 
Did you mean: 

Missing device support in CubeMX F0 how to proceed?

vasilevskialeksandar
Associate III

We made software and PCB for our product based on STM32F071V8.

After erratic behavior I narrowed down the problem that in current CUBE MX for STM32F0

there is no support for this chip. It compiles but macros are missing for USART3 and USART4 (peripherals not present in default STM32F071xB).

It is disappointing that CubeMX does not generate any warning during code generation.

But problem is that clock sources are set to unknown state baudrates and timers settings does not use correct values for clock in calckulations ...

What is procedure to get support for this device?

This can cause huge delay in product release.

Is there any fast track?

I can write macros myself based on similarity with other devices but it is time consuming and unprofessional.

8 REPLIES 8
Mike_ST
ST Employee

Hello, what macros are missing ? on what chip ? STM32F071xB or STM32F071V8 ?

I see support for both in cubeMX 5.6.0.

vasilevskialeksandar
Associate III

Support for STM32F071x8 is not good.

One example is that hardware produces baudrate that is half than value set in cubemx IDE.

I tried to debug it and saw that in stm32f0xx_hal_rcc_ex.c part for USART3 is enabled only for STM32F091xc and stm32F098xx .

There USART3 clock source is not set .

Then I tried to set it in my code using macro  __HAL_RCC_USART3_CONFIG(RCC_USART3CLKSOURCE_PCLK1);

which can not be resolved for my chip STM32F071x8.

My chip has 4 UARTS , macros for USART3 and USART4 clock source selection are missing.

This is one example, but there are more, l noticed problems with interrupt for TIM3 ....

Mike_ST
ST Employee

Please have a look there;

https://www.st.com/resource/en/datasheet/stm32f071rb.pdf

Figure 2 / page 16 ClockTree

and according to RM0091 page 132/6.4.13

https://www.st.com/content/ccc/resource/technical/document/reference_manual/c2/f8/8a/f2/18/e6/43/96/DM00031936.pdf/files/DM00031936.pdf/jcr:content/translations/en.DM00031936.pdf

6.4.13 USART3SW[1:0]: USART3 clock source selection (available only on STM32F09x devices)

There is no mention of USART4 clock source selection at all.

vasilevskialeksandar
Associate III

My mistake, I tried to find explanation for wrong baudrate in wrong place.

After your suggestion i rechecked usart settings and value of baudrate registers.

Values are good for 48MHz PCLK. But when I measured SYSCLK and PLLCLK using MCO output with scope

I am seeing value that corresponds to 24MHz pll clock.

Is HSI clock source with /1Prediv and x6 for PLLMul valid combination to get 48MHz SYSCLK?

I have attached screenshot of clock configuration window.

On MCO I measure 1,5Mhz instead of 3MHz as configuration window shows.

Any ideas what I need to check?

Mike_ST
ST Employee

Glad you are going forward,

Your config should be ok.

About 1.5MHz on MCO check that your are not calling  HAL_RCC_MCOConfig(RCC_MCO, RCC_MCO1SOURCE_PLLCLK_DIV2, RCC_MCODIV_16);

or  HAL_RCC_MCOConfig(RCC_MCO, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_32);

instead of  HAL_RCC_MCOConfig(RCC_MCO, RCC_MCO1SOURCE_PLLCLK, RCC_MCODIV_16);

vasilevskialeksandar
Associate III

Problem is that HAL_RCC_OscConfig function returns HAL ERROR.

RCC->CFGR has a value 0x0010000A

RCC->CFGR2 has a value 0.

How it ends in this error I need to investigate.

This sentence from manual (page 111) explains PLLSRC[1:0]

00: HSI/2 selected as PLL input clock (PREDIV forced to divide by 2 on STM32F04x, STM32F07x and STM32F09x devices)

This div by two is not shown in Clock configuration window. Don't know if it is taken into calculation in STM32cubeMX windows software.

Now I will read document details and will try to find explanation for lower PLLCLK than expected.

berendi
Principal

When HAL doesn't work, dont use it.

Neither RCC nor UART is too complicated on the STM32F0 series. Writing a driver should take a lot less time than finding out what HAL doesn't do right, and wait for the next release of HAL for it to be fixed.

Try this as a replacement for SystemClock_Config() if you suspect that HAL did not get your clock setup right.

	FLASH->ACR |= FLASH_ACR_LATENCY; // ensure flash works with the higher clock
	FLASH->ACR |= FLASH_ACR_PRFTBE;
	RCC->CR |= RCC_CR_HSION; // start HSI
	while((RCC->CR & RCC_CR_HSIRDY) == 0) // wait for HSI startup
		;
	RCC->CFGR &= ~RCC_CFGR_SW; // switch system clock to HSI
	while((RCC->CFGR & RCC_CFGR_SWS) != 0) // wait for the switchover to complete
		;
	RCC->CR &= ~(RCC_CR_PLLON | RCC_CR_CSSON | RCC_CR_HSEON); // stop PLL,CSS,HSE
	while((RCC->CR & RCC_CR_PLLRDY) != 0) // wait for PLL to stop
		;
	RCC->CFGR = 0b0100U << RCC_CFGR_PLLMUL_Pos; // 0100: PLL input clock x 6
	RCC->CR |= RCC_CR_PLLON; // turn PLL on
	while((RCC->CR & RCC_CR_PLLRDY) == 0) // wait for PLL startup
		;
	RCC->CFGR |= RCC_CFGR_SW_PLL; // switch system clock to PLL
	while((RCC->CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL) // wait for the switchover to complete
		;

Half of it might be superfluous, I know. If the frequency still does not look right, adjust RCC->CFGR = 0b0100U << RCC_CFGR_PLLMUL_Pos; if necessary.

Then proceed to set up the UARTs as described in the reference manual. For simple RX/TX, this would do

USARTx->CR1 = 0;
USARTx->BRR = 48000000/baudrate;
USARTx->CR1 = USART_CR1_TE | USART_CR1_RXNE | USART_CR1_UE;

Mike_ST
ST Employee

>> This div by two is not shown in Clock configuration window. Don't know if it is taken into calculation in STM32cubeMX windows software.

That's possible. I have entered a ticket.