Super User

Question

[CUBE OTG] Incorrectly set HFIR.FRIVL

Forum|Forum|7 years ago
November 12, 2018
8 replies
1781 views

In CubeF4 v1.21, OTG_HFIR is set in USB_InitFSLSPClkSel() to either

USBx_HOST->HFIR = 48000U;

or

USBx_HOST->HFIR = 6000U;

which according to the RMs is incorrect, as they should be set to value one less.

This has been already noted by @tsuneo here https://community.st.com/s/question/0D50X00009Xkf8MSAR/stm32f415-and-frame-timinig-jitter-on-usb-host-problem

JW

This topic has been closed for replies.

A

Amel NASRI

Technical Moderator

Hi Jan,

I'll take care to report this to development team.

Thanks.

-Amel

W

waclawek.janAuthor

Super User

Thanks, Amel.

Jan

A

Amel NASRI

Technical Moderator

Hi @Community member ,

Yes, I'm coming back after 2 YEARS to let you know that there is a confirmed a typo error in IP provider Documentation. This is impacting the reference manuals which will be updated in order to remove the non required "-1".

Even if it is very late to provide the answer, I think that it is worth to share it for other users who may review this question.

-Amel

W

waclawek.janAuthor

Super User

Hi Amel,

Thanks for the info.

Except that I doubt it's correct, given in the thread I linked above, two users independently confirmed experimentally, that the -1 is needed.

I don't remember exactly the circumstances how did I arrive to writing the opening post, but I suspect it was also after having confirmed this fact by experiment.

Jan

@Amel NASRI

W

waclawek.janAuthor

Super User

To exclude bias given my cheap LA is surely not extremely precise, when it comes to timing: In a 'F427 running from HSE at 168MHz (with the USB fed from Q-tap of the same PLL, at 48MHz), I set up TIM1_CH4 on PA11 (which is also OTG_FS_DM, so I lazily did not need to move the probes) as follows:

(gdb) p /x *TIM1
$53 = {CR1 = 0x0, CR2 = 0x0, SMCR = 0x0, DIER = 0x0, SR = 0x0, EGR = 0x0, CCMR1 = 0x0, CCMR2 = 0x6800,
 CCER = 0x1000, CNT = 0x0, PSC = 0xa7, ARR = 0x3e7, RCR = 0x0, CCR1 = 0x0, CCR2 = 0x0, CCR3 = 0x0,
 CCR4 = 0x1, BDTR = 0x8000, DCR = 0x0, DMAR = 0x0, OR = 0x0}

LA measured period as 999'993.0ns, averaged from 100 periods, LA samples at 100MHz nominally.

Then I measured period of OTG's SOF, when

(gdb) p usb_fs->c->u->host.HFIR

$56 = 47999

and it resulted in 999'992.9ns (measured in the same way).

I then tried HFIR set to 48000 and 48001; it resulted in SOFs period of 1'000'013.7ns and 1'000'034.9ns respectively. The increase well corresponds to the theoretical 20.8ns difference.

So, IMO, at least in 'F427, the -1 is needed.

I am not surprised, just sad. This is a simple experiment for ST to try.

Jan

W

waclawek.janAuthor

Super User

I of course tried also LS, where the divider ought to be 6000-1 (as clock is internally changes to 6MHz, through a not described mechanism).

Using the same methodology, I arrived at the same results: HFIR=5999 resulted in 999'992.9ns, HFIR=6000 in 1'000'159.5ns (the expected difference is 166.6ns).

But it gets even more interesting. As this difference is large enough to be seen at the "raw" resolution of my LA which is 10ns, I tried to measure period of individual frames - and I discovered, that the OTG module actually *dithers* the required timing: when HFIR=6000, out of 4 consecutive frames, duration of 3 was 1'000'000ns, whereas duration of the 4th frame was 1'000'660ns. (Setting HFIR=6001 resulted in 2 frames out of 4 to be longer; HFIR=6002 caused 3 out of 4 frames to be longer, exactly as expected. The reason is probably some internal subcounter to have 4 phases to move things around internally.)

This may explain, why the problem with not applying -1 may be easy to overlook: when doing this sort of measurement on individual frames, there's a 75% chance one measures the shorter frame which is nominal, as expected.

JW

A

Amel NASRI

Technical Moderator

Hi @Community member ,

I totally understand your disappointment and I'll share your last feedback internally.

Sorry for making you sad.

-Amel