STM32 which peripherals dont work reliable with HSI RC as clock?

[MT]

For all the STM devices around which peripherals dont work reliable with HSI RC as clock but requires a crystal?
As there are HSI RC8 and 16 perhaps there was 48 web says they are different designs so im trying to figure if
i can skip the crystal for some of the projects.

[thinkfat]

USB, if you don't want to use one of the "crystalless" chips, will require the HSE.

EDIT: corrected HSE48->HSE

[GromBeestje]

In practice, USB might even work with the internal oscillator, even though it is outside specs. One of the libopencm3 examples actually does this on the STM32F1xx.
Even though it may work, I don't recommend doing this on a commercial project.

So, bascially, the question is, what are your goals? is this to be a commerial project that should meet the USB specs, then look at some models that officially support crystall-less USB operation (from my heart, STM32F0xx, STM32L0xx, STM32L1xx should support it.)  If the project is not required to meet the specs, and should "just work", you may get away with an STM32F1xx without crystal. (As this is officially not supported, CubeMX won't generate code for this mode of operation. However, using libopencm3, see their examples, should work)

[kamtar]

I would like to correct "just work" to "it will work in most cases" until your board is going to heat up little bit coupled with some interference and cheap USB hub and your USB is going to keep resetting and do all sort of stuff. I would recommend keeping all in the specs with a datasheet unless you have a really good reason for it even in case of hobby projects.

[Yansi]

All peripherals will work from HSI reliably. The question asked is being asked in a wrong way I think.

None of the peripherals will fail in any way, being clocked from the HSI.  But the result may be different than intended, as certain timing accuracy standards may not be met and that depends on the applications.

As a general rule:
NEVER clock USB and CAN from any free-running RC oscillator. It is not precise enough.

In some cases, even UART may not work as expected, even though clock is within a small tolerance (large data-bursts with short stop-bits and no inter-frame gaps).

In some cases, even when using a crystal, some things may not work, due to bad crystal absolute frequency accuraccy and (temperature) drift. Typically RF radio communications at UHF and above, when channels are very narrow-band, you may miss the target by a LOT when using a bog standard 50+ppm shit crystal.

Some thing may even become broken when when clocked using a correct crystal, when PLL (with too much output jitter) is used: typically: High speed (480mbps) USB and ETHernet. Avoid clocking any of these from the internal PLL of the STM32. (and think about it as the internal PLL may even use spread-spectrum modulation to lower the EMI, which on large packages(LQFP176, LQFP208,...
 may become unacceptable!)

Some things may even not work when using a correct crystal type, but the oscillator around the crystal is designed incorrectly: Typical problem: Too little oscillator gain margin resulting in unstable oscillation, wrong load capacitance for the crystal... (RTC and low power oscillator circuits most of the time). See AN2867 from ST.

So people, please, don't take oscillators / clock sources for granted. There is much more to them than just "putting a crystal there" and slapping there two 22pF caps.

[thinkfat]

All peripherals will work from HSI reliably. The question asked is being asked in a wrong way I think.

None of the peripherals will fail in any way, being clocked from the HSI.  But the result may be different than intended, as certain timing accuracy standards may not be met and that depends on the applications.

That will depend on the definition of "fail". I think the OPs question is quite clear. "Fail" means "not working reliably", as in "may or may not work, maybe somtimes, depending on the moon phase and the sun activity".

As a general rule:
NEVER clock USB and CAN from any free-running RC oscillator. It is not precise enough.

Actually, STM32F0x2 are doing USB quite nicely clocked from the HSI48, but they have a CRS that takes care of calibrating the clock during the initial USB handshake phase. I guess that doesn't count as "free-running" any more.

So people, please, don't take oscillators / clock sources for granted. There is much more to them than just "putting a crystal there" and slapping there two 22pF caps.

Yup, but that was not quite what the OP wanted to know.

[Yansi]

So it is good to know you know what the OP wanted, with zero added value in your post.

And  btw, HSE48 does not exist.

[SiliconWizard]

Obviously you should state what you mean by not reliably. Any peripheral that relies on accurate timings may cause you issues if the accuracy of the HSI does not fit your requirements. That's pretty much all there is to it. Other than accuracy, the HSI is more than stable enough to guarantee that no peripheral or the core will ever do weird things. So just an accuracy problem.

Even USB can be used with the internal oscillator on some parts I think... (check that though.)

In many cases, it's also adequate for UART communication (but again, check!)

[thinkfat]

So it is good to know you know what the OP wanted, with zero added value in your post.

Seemingly unlike you, I'm by default assuming that someone asking a question generally knows what he's doing and doesn't need a lecture right away.

Also, spelling out the series of STM32 that do USB without an external crystal counts as "added value".

And  btw, HSE48 does not exist.

Thanks, corrected.