2020-03-06 02:21 AM
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.
2020-03-06 03:01 AM
Hello, what macros are missing ? on what chip ? STM32F071xB or STM32F071V8 ?
I see support for both in cubeMX 5.6.0.
2020-03-06 03:15 AM
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 ....
2020-03-06 04:45 AM
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
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.
2020-03-06 06:00 AM
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?
2020-03-06 06:27 AM
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);
2020-03-06 07:05 AM
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.
2020-03-06 08:13 AM
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;
2020-03-06 08:15 AM
>> 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.