Hi all,
I am working with the STM32F7 Disco, trying to use USART6 with CMSIS Drivers and RTOS (v1). With the ARM_USART_Control function, I can control the argument of Baud Rate, such as 9600, 115200... I had already tried on MCB1768 and it was working as expected. With the Disco board, I can send and receive bytes, but the baud rate is not correct. By instance, if I want a baud rate of 115200, the argument has to be about 10700 (this value obtained after some "scaling" tests) instead of 115200.
Do you have an idea where this is coming from?
Thank you, best regards
Xavier
Thank you for your answer, but the idea of a library is to use the associated functions, not really to search into it. The UART library has 3839 lines, that are not easy to understand... at least for me :)
My question was just in case somebody has encountered the same problem, and found the reason of such a difference between the actual UART clock value and the one expected.
Regards,
By far the fastest way for you to solve this problem you have today and MANY of the problems you will encounter in the future will be to step through the code (USART_Control )and find out what is wrong. There is a USART Baudrate section and it is only about 6 lines of code. With those lines of code, the Reference Manual for the processor, your knowledge of how the clocks are configured and the Baud rate value calculated and store in the BRR registers should point very precisely to where the problem is. RCC configured wrong. USART configure wrong. Oscillator constant is wrong.
Here are a few of MANY things you might look for if you are using USART6:
1) The PCLK2 value returned by HAL_RCC_GetPCLKFreq() is not the same as the actual frequency of PCLK2. It look likes the driver code assumes that it is using PCLK2 for the Baud Rate generator for USART6.
2) PCLK2 is not the clock selected to be used for USART6. There are 4 different clocks that you can use for USART6. If it is not using PCLK2 then you MAY need to change something so the calculation is correct.
Xav Cachan said:the idea of a library is to use the associated functions, not really to search into it
Of course, that's true.
But, as Robert McNamara, the quickest way for you to actually fix this and get your system working is most likely for you to step through the code and see what's happening.
Plus, of course, this is an essential skill - and well worth practising!
If you have a Keil licence, perhaps you could contact Keil for direct support (not sure if the Keil support extends to CMSIS?)
Xav Cachan said:The UART library has 3839 lines, that are not easy to understand
That's why we suggest stepping through it - rather than trying to figure it out statically from reading the source!
Xav Cachan said:reason of such a difference between the actual UART clock value and the one expected
The most common reason - in any microcontroller code - is that the clock is not running at the speed you thought it was (and, in chips like the STM32, there is the added complication of having many different clocks to choose from!)
Thank you Robert and Andy for your kind answers. I have verified the clock part, and it seems that the clock used by the UART driver is indeed PCLK2, with a 16 MHz frequency instead of the 216 MHz expected. Moreover, I believe that there is a mistake in the formula used by the init function to calculate the baudate (something with a coefficient 2 that should be included when using oversampling).
Finally, it is just like if the clock has to be adapted with a coefficient 2*16/216 = 1/6.5, and I just have to use as the function argument the baudate I want divided by 6.5 to get the right one.
Best regards
There is no way to make PCLK2 16MHz if your Sysclock is 216MHz.
There are 4 clocks that can be used by USART6
PCLK2, SYSCLK, HSI, LSE
PCLK2 can be a maximum of SYSCLK DIV 2
SYSCLK is Sysclk
HSI is 16MHZ
LSE is externl...
I am pretty sure you have selected the HSI clock for for USART6 but are calculating the baud rate as if the frequency is that of PCKL2.
If the calculation thinks it is using PCLK2 (108MHz) but it is actually using HSI (16MHZ) then Baud rate would need to be adjusted by 16 / 108 ( 1 / 6.75). This is the same number as 2*16 / 216 (also 1 / 6.75)).
Pretty sure:
PCLK2 is 108MHz
Sysclk is 216MHz
The calculation for the baud rate needs to us the the actual frequency for the actual clock selected. If this happens you will no longer need to apply any kind of "fudge factor" to the Baud rate calculation.
I am not sure why it is using the PCLK2 value in the calculation when it is pretty clear the Clock Selected is the HSI clock. The default clock is PCLK2. This would need to be over written to make it different.