2017-06-07 11:18 AM
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
Note: this post was migrated and contained many threaded conversations, some content may be missing.Solved! Go to Solution.
2017-06-08 11:36 AM
It is 1.8.0.
I must add that I had developed the current code using the previous version, then upgraded the CubeMX version and did a ''Generate Code'' on top of the existing project. If that makes any difference...
2017-06-08 04:59 PM
Any clue?
2017-06-08 06:22 PM
I will check it later on dev kit this afternoon.
For the moment you may try to generate the a new cubeMX project,
make no other setting except just rcc external crystallike your above picture.
Then toggle a gpio with a HAL_Delay in between. Check if it's fine.
(If it's not working, guess you really need check registers in the situation.)
2017-06-09 12:51 AM
hi, Ed,
I used a STM32 nucleo board with L476 to make a test.
I got no 2MHz crystal, so I choose a rarely seen 9.8304MHz as the HSE clk source.
Everything works fine for me. I mean uart and systick.
My clk tree
Uart also works.
________________ Attachments : rcc and systick check.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HycK&d=%2Fa%2F0X0000000bA9%2FtSTDe6hlMnrbjxwFjPpk1THE3PV29Jnw0Fz8pmVv724&asPdf=false2017-06-13 01:36 PM
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?!?
2017-06-13 09:06 PM
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.
2017-06-14 12:52 AM
,
,
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.
2017-06-16 10:49 AM
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!
2017-06-16 02:06 PM
On the other hand when they get it 100% right all the time they'll be able to replace you with a robot.
2017-06-17 07:07 AM
Funny you mentioned robot 'cause I often wonder if you are one yourself