2017-05-24 01:49 AM
CubeMX (latest version: 4.21.0) advises NOT to use the 'systick' clock has HAL systick source when FreeRTOS is used (a message box pops up when generating code). So I switched to TIM6.
When doing this the generated code seems buggy: in the main() function a call to HAL_Init() initializes the TIM6 and it queries the HAL for the current PCLK clock to do so. However, since SystemClock_Config() is called only later on in main(), the PCLK clock will change and we end up in a wrong systick frequency. In my case it ended up in 50uS instead of 1mS.
This happened generating code for stm32l476, and it became very evident when using the IWDT: despite it relies on LSI clock, the SW initialization code relies on HAL systick for register write timeouts. It failed and ended up in an error handler.
Using the 'systick' clock as HAL systick seems not affected (BTW why doing this is discouraged by CubeMX?)
#cubemx-bug2017-06-05 04:29 AM
Hi,
Please send your ioc file for more investigation on this issue internally.
Thank
Imen
2017-06-06 06:14 AM
Please find it attached.
Andrea
________________ Attachments : KID.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HycG&d=%2Fa%2F0X0000000bAB%2FJdzLO86EnXF.gpHpFEz9JI6Psy9.650P56g2LAareLI&asPdf=false2017-11-14 08:17 AM
Hi
merello.andrea
Any updates on this issue?
Thanks,
Evgeny
2018-08-23 10:11 PM
Yes, I noticed this on Cube 4.25 recently. It was quite strange. (Release notes summary for version 4.26 did not suggest any fixes.) The default configuration for the STM32f469I-DISCO. The generated code initializes the TIM6 but somehow ends up using SYSTICK interrupt. When the user manually sets the timer to something else, it works fine.
I wish ST would setup a formal issue tracker...