Skip to main content
e d
e d
Associate III
June 7, 2017
Solved

CubeMX timing

  • June 7, 2017
  • 20 replies
  • 3448 views
Posted on June 07, 2017 at 20:18

Hi guys,

I am running into some timing issue using CubeMX, probably after upgrading to the latest version. A couple of weeks ago I noticed my SysTick running roughly twice as fast as expected (half of 1ms) so I changed my 1ms systick to Timer2 which worked fine. Today I turned on my USART3 for the first time at 9600 BAUD and could not get the HyperTerm to receive correctly (all garbage). Then I took a closer look at the signal through the scope and noticed the BAUD was actually at about 23KBAUD, which was weird because I set it in the code as:

huart3.Init.BaudRate = 9600;

After mucking around I got the HyperTerm to work normally by changing the BAUD setting to:

huart3.Init.BaudRate = 4000; // This is actually 9600 BAUD (verified with scope)

I have a hunch the BAUD rate issue is related to the SysTick issue.Anyone has this issue or is familiar with CubeMX to give me a clue here?

Thanks,

ED

0690X00000607G5QAI.png

Note: this post was migrated and contained many threaded conversations, some content may be missing.
    This topic has been closed for replies.
    Best answer by Zt Liu

    Posted on June 14, 2017 at 06:06

     

     

     

    I think I found why this would happen.....

     

    using HAL library, here my Crystal is 9.8304MHz

     

    in file stm32l4xx_hal_conf.h , you can find this macro

     

    #if !defined (HSE_VALUE)

     

     

    #define HSE_VALUE ((uint32_t)

     

    9830400U

    ) /*!< Value of the External oscillator in Hz */

     

     

    #endif /* HSE_VALUE */

     

    Once you choose LL drivers, the project includesstm32l4xx_ll_rcc.h

     

    Unfortunately, the macros in stm32l4xx_ll_rcc.his still as followed:

     

    #if !defined (HSE_VALUE)

     

     

    #define HSE_VALUE 8000000U /*!< Value of the HSE oscillator in Hz */

     

     

    #endif /* HSE_VALUE */

     

    If you manually modify this value to your crystal's frequency,

     

    If you define the HSE_VALUE in the project setting (thanks

     

    meyer.frank

    ‌ for reminding this!)

     

    for example, in keil,

     

     

    Everything would work as you expected!

     

    :)

     

    Guess we need ST guys to fixed up the library.

     

     

    20 replies

    Andrei Chichak
    Andrei Chichak
    Lead
    June 7, 2017
    Posted on June 07, 2017 at 21:07

    Let's start at the start, are you really running a 19.5MHz external crystal?

    Andrei

    e d
    e dAuthor
    Associate III
    June 7, 2017
    Posted on June 07, 2017 at 21:54

    19.2MHz to be exact. As I stated, I programmed the timer2 to run at 1ms interval with no problem so the timing for APB1 at 38.4MHz based on the 19.2MHz external crystal should be correct.

    htim2.Instance = TIM2;

    htim2.Init.Prescaler = 383;

    htim2.Init.CounterMode = TIM_COUNTERMODE_UP;

    htim2.Init.Period = 99;

    Besides, SysTick should run at 1ms no matter what, am I right?

    e d
    e dAuthor
    Associate III
    June 8, 2017
    Posted on June 08, 2017 at 14:39

    Anyone else want to chime in for this? I need the answer asap. Thanks!

    Zt Liu
    Zt Liu
    Senior III
    June 8, 2017
    Posted on June 08, 2017 at 16:51

    Hi, Ed!

    Can you please tell me which mcu you are using? at least which series?

    e d
    e dAuthor
    Associate III
    June 13, 2017
    Posted on June 13, 2017 at 22:36

    I can confirm that generating the SPI2 code using HAL instead of LL fixes the issue of SysTick timing and UART BAUD rate anomalies. This is quite disturbing as a programmer so can anyone let me know if this is an intended behavior?!?

    Zt Liu
    Zt LiuBest answer
    Senior III
    June 14, 2017

    Posted on June 14, 2017 at 06:06

     

     

     

    I think I found why this would happen.....

     

    using HAL library, here my Crystal is 9.8304MHz

     

    in file stm32l4xx_hal_conf.h , you can find this macro

     

    #if !defined (HSE_VALUE)

     

     

    #define HSE_VALUE ((uint32_t)

     

    9830400U

    ) /*!< Value of the External oscillator in Hz */

     

     

    #endif /* HSE_VALUE */

     

    Once you choose LL drivers, the project includesstm32l4xx_ll_rcc.h

     

    Unfortunately, the macros in stm32l4xx_ll_rcc.his still as followed:

     

    #if !defined (HSE_VALUE)

     

     

    #define HSE_VALUE 8000000U /*!< Value of the HSE oscillator in Hz */

     

     

    #endif /* HSE_VALUE */

     

    If you manually modify this value to your crystal's frequency,

     

    If you define the HSE_VALUE in the project setting (thanks

     

    meyer.frank

    ‌ for reminding this!)

     

    for example, in keil,

     

     

    Everything would work as you expected!

     

    :)

     

    Guess we need ST guys to fixed up the library.

     

     

    AvaTar
    AvaTar
    Senior III
    June 14, 2017
    Posted on June 14, 2017 at 07:52

     ,

     ,

    Guess we need ST guys to fixed up the library.

    I would not bet on that - this issue was already present in the 'old' Standard Peripheral Libs.

    Instead of throwing an error (' ♯ error 'define a HSE_VALUE !'), these guys presumed to define a default.

    This threw many users off the track initially ...

    The best place to define HSE_VALUE would be your project settings (or a make file).

    Editing the header file is not a good option.

    e d
    e dAuthor
    Associate III
    June 16, 2017
    Posted on June 16, 2017 at 17:49

    Why are these ST guys so neglectful of a long standing issue? They could have saved us our precious development time and undue stress with a simple change in the library. This is my first time using ST products and I don't have a good first impression.

    Thanks all for your help!

    Guru Vel
    Guru Vel
    Visitor II
    August 1, 2017
    Posted on August 01, 2017 at 09:46

    Short answer: Make sure the USE_HAL_DRIVER is defined as part of your build system (CFLAGS += -DUSE_HAL_DRIVER).

    Detailed Answer: When you generate the code using CubeMx the HSE_VALUE goes into the file stm32l4xx_hal_conf.h under STM32CubMX_generated_files/Inc/

    stm32l4xx_hal_conf.h

     file. This file should be included in all HAL_DRIVER based project and will be included by the stm32l4xx.h (

    stm32l4xx.h -> 

    stm32l4xx_hal.h -> stm32l4xx_hal_conf.h) only when the USE_HAL_DRIVER is defined.
    Terms & ConditionsAccessibility statement