stm32F1 systemClock_Config() causes error in stm32CubeMX in v_4.20 works well in v4.08 with rtos

[Anish Krishna]

Posted on March 27, 2017 at 18:35

Hello All,

I had been using stm32CubeMX v4.08 with w/wo freeRtos on stm32F103CB series mcu successfully , until recently when i upgraded cubeMx to version 4.20. I am totally stuck since then, since i have so got used to using HAL abstraction...

Calling systemClockConfig() in main() .. causes HAL_Timeout - causing function Error_Handler to be called in the following line..

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

  {

    Error_Handler();

  }

on commenting out

/* Configure the system clock */

//  SystemClock_Config();

 ..or..

//Error_Handler();

the cpu runs but presumably on the systemInit()'s reset default HSI clock..

I assume its a bug in hal_rcc drivers...

Can you please suggest some way to get out of this....

Regards

Anish.

[Imen.D]

Posted on March 27, 2017 at 19:28

Hi, 

This bug is confirmed in CubeMx 4.20 and will be fixed soon in the new patch release.

Sorry for the inconvenience it may bring.

Imen

[Anish Krishna]

Posted on April 18, 2017 at 16:23

Just for your information, have tried with CubeMx versions -- 4.15 / 4.17 / 4.18 / 4.20 .. AND recently with -- 4.20.1

in all of them HSE fails to startup...

It is only working in CubeMx version 4.08...

One Common thing i have noted is CubeMX v4.08 uses stm32cube_fw_f1_v100,

while in all the rest i am using  stm32cube_fw_f1_v140...

Highly appreciate any help cause need to get rid of a uart bug fixed in later firmware..

Sincere Regards,

Anish.

[JACK TAN]

Posted on March 27, 2017 at 19:28

http://www.stmcu.org/module/forum/data/attachment/forum/201703/15/162021y5r1y6jc267yd9x7.png

[Sirma Siang]

Posted on April 28, 2017 at 11:21

Hello All,

I confirm that the issue on the clock configuration has been corrected on CubeMX version 4.20.1.

Kind regards

Sirma

[David Kaplan]

Posted on April 30, 2017 at 18:59

I recently updated a project to 4.20.1, and started having the HSE failure.  I'm using a custom F103C8T6 board that was working last week ( I think the version was 4.18.0).  Additionally, I soldered an 8 MHz crystal to a Nucleo F103RB board, and am running into the same error.  

Any advice on troubleshooting?  I've tried creating new projects in Cube from scratch for both boards (custom and Nucleo), and can't get past the HSE startup.  I can't use the internal clock since I'm using the USB peripheral.

Thank you!

[Anish Krishna]

Posted on May 01, 2017 at 10:54

Hi David,

Since I got the problem only in my custom board ( I was using a 12Mhz crystal with 22pf load capacitors ), so i assume the problem is because of one or both of these two things.

I have yet to experiment with the crystal and the load capacitors (try 20 / 18pf)...and check the pulse with a scope....

although the same component pair work perfectly alright with all other ICs (maybe stm's are sensitive in clock stability check..)

Can you also try changing HSE_STARTUP_TIMEOUT values from 100-5000 just to check clock stability (read of similar solution in some thread..)...

Request you to please keep us posted if you find any developments...

Regards,

Anish.

PS-Since i tested the concept on a development board with HSE at 12Mhz (wanted to save power) and found everything alright , that  I got on and designed the custom board and didnt realize that it was actually running on HSI clock (since Cube_4.08 didnt have a HAL_OK check in clock initialization). I only realized it when i upgraded to cube4.20 ..

:(