2018-01-18 12:18 AM
Hello,
I've encountered a bug in code generation when using the LL STM32F3 drivers 1.9.0 in Cube 4.23.0.
The device is the
STM32F303CCTx
, although it's probably not device specific.Using the clock configurator and setting an HSE of 16MHz, the code generated in
stm32f3xx_ll_rcc.h
indicates a wrong value for HSE:
&sharpif !defined (HSE_VALUE)
&sharpdefine HSE_VALUE 8000000U /*!< Value of the HSE oscillator in Hz */&sharpendif /* HSE_VALUE */This can cause all sorts of problems if one uses the API to get various peripheral clock speeds, like
LL_RCC_GetUSARTClockFreq
which gave me the wrong value, causing me to set up the wrong baud.The
.ioc
file seems correct since the relevant field is correct:RCC.HSE_VALUE=16000000
#ll-drivers #stm32f3 #cube-mx2018-01-25 12:46 AM
No reply from any rep?
I'm offering debug information for your software, so any response should be expected to say the least.
2018-01-25 07:39 AM
Hello
Pikoulis.George
,Thanks for highlightingthis issue. I raised it to the appropriate team. We will keep you informed about the taken actions if needed.
Best Regards,
Imen
2018-01-30 12:54 AM
Hello George,
Attached the ioc file for F3, RCC, LL configuration,using CubeMX latest 4.24 that solves RCC/LL related issues.Here belowa snapshot of the generated code (found in the CubeMX generated stm32f3xx_hal_conf.h file):
#if !defined (HSE_VALUE)
#define HSE_VALUE ((uint32_t)16000000) /*!< Value of the External oscillator in Hz */ #endif /* HSE_VALUE */Could you please confirm this solves your issue.
Thank you
________________ Attachments : F303_RCC_LL_project.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hxyf&d=%2Fa%2F0X0000000b3m%2FKiUXY0vngpxIL8anqlDPMfwx8c.Dsa2TqkbezzvJpuo&asPdf=false2018-01-30 01:53 AM
Hello,
Thanks for looking into this.
The driver for LL does not generate a
stm32f3xx_hal_conf.h
file. This file is generated in HAL or mixed HAL/LL.On your file, you use mixed HAL/LL.
The relevant file in the LL driver is
stm32f3xx_ll_rcc.h
, which still has wrong code generated. I'm generating for IAR.See attached
.ioc
for an example case.Best regards,
George ________________ Attachments : 2PH_Inverter Test.ioc.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy5a&d=%2Fa%2F0X0000000b3r%2Fdwc292dN2913NR9E5l8KzsffMf0zHnF.30bwmBwtsHU&asPdf=false2018-04-03 03:14 AM
Hello George,
Using your ioc file and CubeMX 4.24, the
stm32f3xx_hal_conf.h
file is properly generated under the Include folder.The
stm32f3xx_ll_rcc.h
driver file is not generated by CubeMX but only copied from the STM32CubeF3 embedded software package.Best regards.
2018-04-04 04:17 AM
Hello
,Thanks for looking further into this.
Please also use the attached
main.c
, I've just added a variable to read theHSE_VALUE
./* Private variables ---------------------------------------------------------*/
volatile uint32_t test; /* USER CODE BEGIN PV */ /* Private variables ---------------------------------------------------------*/.
.
.
int main(void)
{
/* USER CODE BEGIN 1 */
test=HSE_VALUE;
/* USER CODE END 1 */
It seems that due the multiple definitions, inclusion order and
#if !defined (HSE_VALUE)
macro,HSE_VALUE
evaluates to the value set bystm32f3xx_ll_rcc.h
in the end.Best regards,
________________ Attachments : main.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxqV&d=%2Fa%2F0X0000000b1J%2F..Bg0K4ia.uyc2F25BtSlVi8bW8n.PYy95xZ.N4DI9g&asPdf=false2018-05-05 03:09 AM
Hello,
I confirm the same problem that still exists though it was found months ago, it's bad...
I've spent an hour trying to figure out why my just out of the Cube generated USART code based on LL sends wrong data. By debugging the problem's origin was in aforementioned
HSE_VALUE
. The necessary Cube defined value is put only into thestm32f1xx_hal_conf.h
file while it even doesn't get included anywhere in themain.h
since I don't generate HAL code at all preferring LL. After all system just gets the default8000000U
value forHSE_VALUE
and hence calculates the wrong timings.Moreover it seems that all LL
.c
files that includestm32f1xx_ll_rcc.h
still use theHSE_VALUE
defined instm32f1xx_ll_rcc.h
as during every particular.c
compilation they won't touchstm32f1xx_hal_conf.h
in any way. That makes Cube's frequency modification of onlystm32f1xx_hal_conf.h
file meaningless even if it will be properly included formain.c
file.2018-05-06 12:05 PM
The model was to have the project/board specific stuff in the stm32fxxx_hal_conf.h, and this gets pulled via stm32fxxx.h when USE_HAL_DRIVER is defined.
You can also push HSE_VALUE in via the compiler command line if you prefer that approach.
2018-05-06 04:10 PM
IMHO the proper solution for this is to define
HSE_VALUE at the project level in C preprocessor defines. Not in any .h file.
In the library .h files there should be:
&sharpif !defined (HSE_VALUE)
&sharperror HSE_VALUE must be defined in the project settings
&sharpendif /* HSE_VALUE */
--pa