dmitrystu / sboot_stm32

Secure USB DFU1.1 bootloader for STM32
Apache License 2.0
313 stars 67 forks source link

Use HSI48+CRS on L0 #43

Closed dzarda closed 1 year ago

dzarda commented 3 years ago

It is rather a happy accident (not guaranteed by spec) that the L0 USB works off of the HSI16 like we use it. On the L0 the crystal-less USB should use the HSI48 with the Clock Recovery System. I may get around to doing it soon but as a documentation note, this would be the presumed init sequence:

  1. Enable HSI48 voltage reference thing SYSCFG->CFGR3 |= SYSCFG_CFGR3_ENREF_HSI48;
  2. Enable HSI48
  3. Enable CRS clock RCC->APB1ENR |= RCC_APB1ENR_CRSEN;
  4. Enable CRS with default parameters CRS->CR |= CRS_CR_AUTOTRIMEN | CRS_CR_CEN;

Don't know if some other family is also affected (L1 ??)

dmitrystu commented 3 years ago

Agreed with this point. It's better to use auto-trimmed HSI48 rather than HSI16 if available. L1 has no similar clock system. L4 can still use MSI for the USB as described in article 6.2.3. Need to check other series.

dmitrystu commented 3 years ago

G4 also can use a dedicated HSI48.

Sfinx commented 3 years ago

Seems like having the similar problem with L1 device (checked with Nucleo R152RE) - stock STM ROM DFU bootloader works, but sboot prints:

[Nov16 02:34] usb 3-1: device descriptor read/8, error -62
[  +0.258000] usb 3-1: new full-speed USB device number 114 using exynos-ohci
[  +0.018000] usb 3-1: device descriptor read/8, error -62
[  +0.117000] usb 3-1: device descriptor read/8, error -62
[  +0.101000] usb usb3-port1: unable to enumerate USB device
dmitrystu commented 3 years ago

@Sfinx I think, there is another cause. See issue https://github.com/dmitrystu/libusb_stm32/issues/103 and fix https://github.com/dmitrystu/libusb_stm32/commit/c3bcfc9456ebd9b5fc6db8010a431fe8a94814cc

Sfinx commented 3 years ago

@Sfinx I think, there is another cause. See issue dmitrystu/libusb_stm32#103 and fix dmitrystu/libusb_stm32@c3bcfc9

Wow, works ! Thanks ! ;)