STM32F401 USB without HSE

[gw_it]

Posted on March 05, 2014 at 12:59

I'm looking at making a device with the STM32F401, and I'm wondering if USB on it can function without a HSE crystal?

The clock diagrams seem to imply that PLL48 can work off of HSI, but the reference implies that USB needs HSE to work.

I'm planning on adding a LSE for the RTC, so I could probably automatically calibrate the HSI relatively easily.

#stm32f401-usb

[chen]

Posted on March 05, 2014 at 14:01

Hi

It has been pointed on on many posts that the internal oscillator variance (10% from memory) is too great to guarantee correct USB operation.

Yes, you can use the internal OSC (HSI) but there is no guarantee that it will work on every part 

[gw_it]

Posted on March 05, 2014 at 14:16

Thanks - so if the HSI was actually the correct speed, USB would work. There's no other reason that it wouldn't?

The STM32F401 reference+datasheet says that HSI is laser-trimmed to 1% at 25 degrees C. You're saying it might actually be as much as 10% out though? Even so, I plan to have a LSE so I could probably do a pretty good job of auto-calibrating using the HSITRIM register.

[Tesla DeLorean]

Posted on March 05, 2014 at 16:35

You can certainly generate 48 MHz via the PLL VCO from the HSI, it's more of a stability issue.

The behaviour of the HSI is likely to be impacted by both temperature and voltage, the trimming handles a single point of a much larger graph that represents the entire operational space, I don't think I'd represent it as a thorough, or effective, characterization of the part.

You can certainly use TIM5 to stand HSI(PLL) against LSE, I'd have to fix up a 401-DISCO, but in prior tests I don't recall the HSI/LSI being particularly stable even in static conditions.

[tsuneo]

Posted on March 05, 2014 at 19:35

 > so I could probably automatically calibrate the HSI relatively easily

Unfortunately, your plan doesn't result in enough accuracy, required for a USB full-speed device.

The trimming step of HSI clock (HSITRIM) is around 0.5% per bit **1), **2)

Whereas the required accuracy of full-speed USB clock is +/-0.25%

The trimming step is too rough to get this accuracy.

**1) RM0008 STM32F1xx  Reference manual

7.3.1 Clock control register (RCC_CR)

Bits 7:3 HSITRIM[4:0]: Internal high-speed clock trimming

The default value is 16, which, when added to the HSICAL value, should trim the HSI to 8 MHz +/- 1%. The trimming step (Fhsitrim) is around 40 kHz between two consecutive HSICAL steps.

40 kHz / 8 MHz = 5/1000 = 0.5%

**2) RM0033 STM32F2xx Reference manual

5.3.1 RCC clock control register (RCC_CR)

Bits 7:3 HSITRIM[4:0]: Internal high-speed clock trimming

The default value is 16, which, when added to the HSICAL value, should trim the HSI to 16 MHz +/- 1%. The typical trimming step (FHSITRIM) between two consecutive HSICAL steps is around 80 kHz.

80 kHz / 16 MHz = 5/1000 = 0.5%

Tsuneo

[zzdz2]

Posted on March 07, 2014 at 11:28

As I'm on USB device development right now I decided to test it.

It looks like the usb is quite tolerant of clock deviation (of course the USB host clock should be as stable as possible, clocking host with HSI would be insane).

Anyway, the device seems to be usable with HSITRIM ranging from 0 to 28, not bad.

I would say it roughly matches the theory, there should be at least one data transition in every 7 bits, so the max clock skew: 8e6/7 ~ 1.1Mhz -> about 28 * 40kHz steps.

Nevertheless I'm going to use HSE for USB.