Garbled Characters Issue in Serial Port 1 with STM32CubeMX 6.13.0 and STM32Cube_FW_H7_V1.12.0

[zhengjianxing]

The serial port 1 code generated by the latest STM32CubeMX 6.13.0 will print garbled characters, and using the serial port routine UART_Printf in STM32Cube_FW_H7_V1.12.0 will also print garbled characters.

It doesn't work when using the serial port routine UART_Printf in STM32Cube_FW_H7_V1.11.2. After comparison, there is a difference here. I can’t understand the function here. I will be careful whether changing it will affect other functions.

*This post has been translated from Chinese to comply with the ST Community guidelines.

[KDJEM.1]

Hello @zhengjianxing,

 

Thank you for bringing this issue to our attention.

 

const uint8_t D1CorePrescTable[16] = {0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 6, 7, 8, 9}; 

 

should be 

 

const uint8_t D1CorePrescTable[16] = {0, 0, 0, 0, 1, 2, 3, 4, 1, 2, 3, 4, 6, 7, 8, 9}

 

I reported this issue internally.

Thank you for your contribution to the community.

Internal ticket number: 197431 (This is an internal tracking number and is not accessible or usable by customers).

Thank you.

Kaouthar

[Andrew Neil]

---

@zhengjianxing wrote:

The serial port 1 code generated by the latest STM32CubeMX 6.13.0 will print garbled characters, and using the serial port routine UART_Printf in STM32Cube_FW_H7_V1.12.0 will also print garbled characters.

---

Which suggests that the baud rate is wrong:

https://learn.sparkfun.com/tutorials/serial-communication/all#:~:text=If%20all%20the%20receiving%20device%20sees%20on%20its%20receive%20line%20is%20garbage%2C%20check%20to%20make%20sure%20the%20baud%20rates%20match%20up

 

[KDJEM.1]

Hello @zhengjianxing,

 

This issue is fixed in STM32Cube_FW_H7_V1.12.1 version.

Could you try to update the STM32CubeH7 and let me know if the issue is solved or not?

You can use STM32CubeMX 6.13.0 to update STM32CubeH7.

 

Thank you.

Kaouthar

 

[siwa]

Hi,

we observed the same problem with the UART baudrate when using APB Peripheral Clock. 

Our setup was:

SYSCLK = 400 MHz, HCLK = 200MHz, APB1-PERCLK / 2 = 100MHz and APB2-PERCLK / 2 = 100MHz.

The configured and expected baudrate was 115200. Instead, we measured 57200 and the communication obviously wasn't working with 115200 baud.
Changing the dividers D2PPRE1 and D2PPRE2 to 1 (instead of 2) led to measured 115200 baud and the communication worked. However, the CubeMX.6.13.0 would not let us do the change as APB-PERCLK would be 200Mhz which is  > 120MHz limit. We made the change directly in the code.
We now wonder whether this 'workaround' creates problems, i.e. noise, inside the STM32H7 - as the changed devider setup now apparently uses 200MHz as APB1/2 PERCLK ?! 

The change to  STM32Cube_FW_H7_V1.12.1 did not help. The problem is still there!

Deriving the UART CLK from PLL2 instead works well.

Have there been any further attempts to find the bug? 

[Stefanos_Sem]

The general issue with UART and PCLK1 looks like it still has issues.

When UART configured to PCLK1:
With Oversampling, ISR register had NF flag enabled.
With single sample it was looking like wrong bitrate.
Signal is crystal clear, generated on same pcb.

When UART configured to PLL2Q :
Runs perfectly fine...