[CUBE OTG] Incorrectly set HFIR.FRIVL

waclawek.jan · ‎2018-11-12

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

Amel NASRI · ‎2018-11-13

Hi Jan,

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

Thanks.

-Amel

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.

waclawek.jan · ‎2018-11-13

Thanks, Amel.

Jan

Amel NASRI · ‎2021-02-25

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

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.

waclawek.jan · ‎2021-02-25

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

waclawek.jan · ‎2021-02-25

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

waclawek.jan · ‎2021-02-25

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

Amel NASRI · ‎2021-02-25

Hi @Community member ,

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

Sorry for making you sad.

-Amel

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.

waclawek.jan · ‎2021-02-25

Hi Amel,

Thanks a lot for taking care.

Jan

@Amel NASRI

Piranha · ‎2021-02-27

I'll use a chance and remind of this topic:

https://community.st.com/s/question/0D50X0000B2AG7FSQW/ethernet-send-complete-interrupt-not-triggered-in-stm32f7

Those issues are also related to errors in the same IP provider's documentation. So maybe those issues can be communicated and solved all at once. :)