cancel
Showing results for 
Search instead for 
Did you mean: 

STM32U5xx UCPD RM0456 documentation inconsistency

TDJ
Senior III

I try to figure out what the correct UCPD clock frequency is.
RM0456 in section 74.4.2 UCPD reset and clocks states:
"The receiver is designed to work in the clock frequency range from 6 to 18 MHz. However, the optimum performance is ensured in the range from 9 to 18 MHz"
However, in section 74.8.1 UCPD configuration register 1 (UCPD_CFGR1) it says:
"It is recommended to use the pre-scaler so as to set the ucpd_clk frequency in the range from 6 to 9 MHz."
I found no place where RM0456 clearly states from where UCPD kernel clock is derived.

What is the correct UCPD clock range?

STM32H5xx manual RM0481 has the same above inconsistencies. In section 11.4.12 Kernel clock selection (table 105) it clearly states that UCPD kernel clock is HSI (64MHz) clock divided by 4 but in section "56.4.2 UCPD reset and clocks" it says
"transmitter is clocked with ucpd_clk clock, pre-scaled from the ucpd_ker_ck (HSI16)"
OK, it is still 16 MHz, but STM32H5 has HSI64, not HSI16. This can be confusing.

Speaking of confusion; both RM0481 and RM0456 reference manuals describes UCPD_CFGR1.PSC_USBPDCLK registry.
HAL driver names this registry UCPD_CFG1.PSC_UCPDCLK - which makes more sense.

1 ACCEPTED SOLUTION

Accepted Solutions
KDJEM.1
ST Employee

Hello @TDJ ,

On STM32U5, in order to use UCPD peripheral, you need to clock it with HSI16 (no choice, it is 16Mhz) => ucpd_ker_ck.
It is this value that has to fill the requirement expressed in 74.4.2 : range from 6 to 18 MHz. However, the optimum performance is ensured in the range from 9 to 18 MHz.
This applies to ucpd_ker_ck.

Starting from ucpd_ker_ck, the transmission parts are clocked with ucpd_clk, which could be ucpd_ker_ck or ucpd_ker_ck divided by something (division is selected in CFG1 register in PSC_USBPDCLK[2:0] field).
Statement in 74.8.1 indicates that the ucpd_clk is recommended to be in the range from 6 to 9 MHz.

In the STM32U5 application you can use :

  • ucpd_ker_ck = 16 Mhz (HSI16)
  • PSC_USBPDCLK[2:0] = 1 (DIV2)
    So ucpd_clk = 8MHz

PS : 74.8.1 is a recommendation, as you are also able to work with PSC_USBPDCLK[2:0] = 0 (DIV1), so that ucpd_clk = 16Mhz. But with this case, you experienced more sensitivity to noise on Rx line.

Concerning the RM0481: 
"transmitter is clocked with ucpd_clk clock, pre-scaled from the ucpd_ker_ck (HSI16)"  is wrong and should be "transmitter is clocked with ucpd_clk clock, pre-scaled from the ucpd_ker_ck clock"

Also, I confirm the confusion registers names and I escalate internally.

Thank you for bringing this issue to our attention.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
KDJEM.1
ST Employee

Hello @TDJ ,

First let me thank you for posting.

I will check these issues internally and I will get back to you with more details as soon as possible.

Kaouthar.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

KDJEM.1
ST Employee

Hello @TDJ ,

On STM32U5, in order to use UCPD peripheral, you need to clock it with HSI16 (no choice, it is 16Mhz) => ucpd_ker_ck.
It is this value that has to fill the requirement expressed in 74.4.2 : range from 6 to 18 MHz. However, the optimum performance is ensured in the range from 9 to 18 MHz.
This applies to ucpd_ker_ck.

Starting from ucpd_ker_ck, the transmission parts are clocked with ucpd_clk, which could be ucpd_ker_ck or ucpd_ker_ck divided by something (division is selected in CFG1 register in PSC_USBPDCLK[2:0] field).
Statement in 74.8.1 indicates that the ucpd_clk is recommended to be in the range from 6 to 9 MHz.

In the STM32U5 application you can use :

  • ucpd_ker_ck = 16 Mhz (HSI16)
  • PSC_USBPDCLK[2:0] = 1 (DIV2)
    So ucpd_clk = 8MHz

PS : 74.8.1 is a recommendation, as you are also able to work with PSC_USBPDCLK[2:0] = 0 (DIV1), so that ucpd_clk = 16Mhz. But with this case, you experienced more sensitivity to noise on Rx line.

Concerning the RM0481: 
"transmitter is clocked with ucpd_clk clock, pre-scaled from the ucpd_ker_ck (HSI16)"  is wrong and should be "transmitter is clocked with ucpd_clk clock, pre-scaled from the ucpd_ker_ck clock"

Also, I confirm the confusion registers names and I escalate internally.

Thank you for bringing this issue to our attention.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

TDJ
Senior III

@KDJEM.1 Thank you for the clarification, I think I understand. So the statement
"The receiver is designed to work in the clock frequency range from 6 to 18 MHz. However, the optimum performance is ensured in the range from 9 to 18 MHz"
is perhaps irrelevant, since ucpd_ker_ck frequency is fixed (HSI16), already always ensured and out of control by registry settings.
Consequently, to ensure recommended ucpd_clk value (6-9MHz), the only valid setting for the PSC_USBPDCLK[2:0] field is 1 (div=2 -> 8MHz). Am I correct?

Process-wise I think the main issue is that instead of maintaining a separate RM for each peripheral, usually shared among many MPUs, ST tries to maintain one single document for each MPU and a separate set of HAL drivers. This inevitably leads to versionitis and substantial maintenance overhead which, in turn, adversely impacts the docs quality.

KDJEM.1
ST Employee

Hello @TDJ ,

To minimize the sensitivity to noise on Rx line it is recommended to set the PSC_USBPDCLK[2:0] field to 1.

I have reported the confusion registers names internally to be corrected.

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

Thank you for your contribution in STCommunity.

Kaouthar

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.