CubeMX clock code generation bug (stm32f103c8t6)

[Glen Cook]

Posted on March 22, 2017 at 22:46

Hi,

I'd like to report a potential bug in the code generation / clock initialisation code for the STM32F103c8t6.

Cube version 4.2

STM32CubeF1 Release 1.4.0

Keil uVision 5.22

I have attached the very simple project and cube file. The line that fails is 339 in stm32f1xx_hal_rcc.c

I am not using HSI as a system clock.

Any help most appreciated.

[Tilen MAJERLE]

Posted on March 23, 2017 at 10:33

Hello Glen,

this is a bug I found it yesterday too. Go to your main.c file and removeRCC_OSCILLATORTYPE_HSI on line 133.

This happens if you have setup HSI clock first, export project and later setup HSE clock as source.

Why it fails?

Because configuration for HSIState and HSICalibrationValue are missing now (removed from CubeMX generation tool) and have unknown value and assert_param goes to assert_failed function. When you removeRCC_OSCILLATORTYPE_HSI from first line, configuration won't try to init HSI clock.

How to reproduce the bug:

1. Create new empty project (In my case I used STM32F746) in CubeMX
2. In RCC IP add HSIexternal crystal mode
3. Go to clock control and select HSIas PLL source and configure PLL
4. Export project, open in IDE, compile and run.
5. Project will work with HSI (High Speed Internal) clock.
6. Go back to CubeMX and in the same project configure HSE value as PLL source
7. Export and look at main.c where clock configuration is setup.
8. You will still seeRCC_OSCILLATORTYPE_HSI for OscillatorType.
   1. It means that we still want to init HSI clock
   2. But there is no HSIState and HSICalibrationValue parameters in initialization structure
9. FunctionHAL_RCC_OscConfig will try to init HSE and HSI and it will fail at HSI setup because of missing HSI important parameters.

First code export

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON; //HSI State is here
RCC_OscInitStruct.HSICalibrationValue = 0; //HSI calibration value is here
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
RCC_OscInitStruct.PLL.PLLM = 16;
RCC_OscInitStruct.PLL.PLLN = 432;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 2;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
 Error_Handler();
}�?�?�?�?�?�?�?�?�?�?�?�?�?

Second code export

//HSI is still here for oscillator type, but there are missing important HSI parameters
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI|RCC_OSCILLATORTYPE_HSE;
//missing here
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 25;
RCC_OscInitStruct.PLL.PLLN = 432;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 2;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
 Error_Handler();
}
//First line should be
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[Glen Cook_2]

Posted on March 23, 2017 at 12:11

Fantastic, thanks for the comprehensive reply.

Cheers

Glen.

[Amel NASRI]

Posted on March 23, 2017 at 11:44

Hello,

Please note that this is a confirmed CubeMX bug which will be fixed in a patch to be delivered soon.

Sorry for such inconvenience.

-Amel

[Glen Cook_2]

Posted on March 23, 2017 at 12:48

Hi Amel,

Is the list of known issues with CubeMX available to view?

Cheers

Glen.

[Amel NASRI]

Posted on March 23, 2017 at 13:23

Hi Glen,

Unfortunately, no list currently available.

I raise this request -again- internally.

-Amel

[Amel NASRI]

Posted on April 20, 2017 at 11:51

Hello

glenc

‌,

If you aren't already aware, this regression bug is fixed and a patch is delivered end of March (CubeMX v4.1).

-Amel