stm32H7 - USB application - HSE or HSI+CRS

[jmf1]

Hello,

I'm a hobbyist and I'm working on a USB to 4xI2S (8 channels using the SAIs) using a stm32H7 MCU. I have a proof of concept working on a stm32F7 discovery board. I'm starting to look at the dedicated board.

I understand that the USB peripheral needs a precise clock, which can't be achieved alone by the internal HSI oscillator, as it is not precise enough. The stm32H7 has a clock recovery system, CRS, to calibrate the HSI with the SOF signal.

Would you have experience with using the HSI+CRS?

Are there tricks in the implementation if the Return of Experience was positive?

Safer to go with a 8Mhz HSE?

Best regards,

JMF

[AScha.3 · Accepted solution]

Hi,

yes, always better to use HSE / crystal or oscillator .

And for audio...anyway: want best, low jitter clock source. (Never an internal RC-osc.)

[jmf1]

Thanks for the confirmation.

For the audio part, my intention is to feed the SAI with dedicated crystals fit to 48k and 44.1k frequencies.

Best regards,

JMF

[AScha.3]

Right,

or other way round : i use an ES9038 DAC, as SAI master with its own low jitter clock ( AS318-B ), and it can be set to the desired sampling rate . So no clock switching needed . (CPU has its standard crystal, 8M or 24MHz .)

And for USB usually a crystal is recommended for stable connection anyway .

[jmf1]

I wanted to confirm the above understanding by looking at the examples developped by ST team for Nucleo and Discovery Boards, and to the "standard" configuration of the Nucleo H723 board. Failed.

The "standard" .ioc for the Nucleo H723 board is using for the USB_HS the 48MHz HSI with disabled CRS.

The Ux_Device_CDC_ECM example for the H735 Discovery board is also using for the USB_HS the 48MHz HSI with disabled CRS.

The Ux_Device_HID for the the Nucleo H723 board is also using for the USB_HS the 48MHz HSI, but with enabled CRS sync on the USB_HS, which looks correct.

It seems that ST is not so picky on the quality of the clock for the USB_HS peripheral, relying on the HSI, and without CRS in several cases.

In my application, the SAI clocks will be clocked by dedicated crystals. Remaining time sensitive part is only USB (rest will be I2C, serial at low bitrate, GPIO...). So it is appealing to simplify when possible and rely on the HSI if sufficient... if it does not generates issues down the road.

JMF

[AScha.3]

The examples show just, whats possible - not whats best.

I also have a (cheap) USB-4x-HUB here, no crystal - nothing, just a small so16 chip. (Internal clever PLL for clock..)

Works fine, most time; sometimes just dont work, need re-plug , then working.

So: to do it as good as possible, with a crystal, or get it cheaper, maybe 40 ct, is this the problem you think about, when building some hi-end (I assume, its not cheap junk.) audio with expensive DACs and opamps ?

Then try without crystal, if there is explicit "crystal-less solution" in datasheet. (Some chips can do this, but its always a "how can i do it as super-cheap-solution" , not "how to make it 100% reliable".)

[jmf1]

Thanks Asha to have made it so clear. I will follow your advice.

I have to find the balance between two quotes I like a lot:

- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away (Antoine Saint Exupery)

- Everything Should Be Made as Simple as Possible, But Not Simpler (Einstein).

I don't target "whatever the cost/snake oil" design, but something can look at saying it is good engineering.

Best regards,

JMF

[jmf1]

Hello,

Looking at some ST documentation for the STM32H7, a 25MHz crystal indicated as a good value for both Ethernet and USB.

Using Cube MX, with such crystal, and the fracn feature of the H7, I can get a 48.000336 MHz for the USB peripheral.And for  the ULPI, export a 24.000168MHz clock to MCO1.

Is this precise enough for the USB HS peripheral and to drive the ULPI?

(It would be better t use a 24MHz, but 1) the 25MHz one allows some savings, 2) I'm curious of the ST indicaction).

Best regards,

JMF