Clock setup in cdc_init_rcc() for STM32F411 is incorrect

[Eqqm4n]

Hello- The STM32F411 cannot have the APB1 clock running at 50MHz or higher, but the clock setup function cdc_init_rcc() in cdc_startup.c does not account for this. On our import of this project we added the following to correct it:

    RCC->CFGR &= ~((uint32_t)(0x07 << 0x0A));
    RCC->CFGR |=  ((uint32_t)(0x04 << 0x0A));

The clock setup code is in this block:

#elif defined(STM32F429xx) || defined(STM32F405xx) \
    || defined(STM32F401xC) || defined(STM32F401xE)  || defined(STM32F411xE)

These other chips may or may not have the same issue, it could easily be confirmed by using the clock configuration tool of ST's STM32CubeMX IDE.

It should also be mentioned that this clock configuration code is set to use the internal oscillator. While it does work, it should be noted that according to ST you "can't" use HSI to run the USB peripheral (what they really mean is "shouldn't") and in fact STM32CubeMX IDE will flag this as a clock error if you enable both HSI and USB. The HSI oscillator does not meet the timing requirements for USB, so be aware that anybody using this setting won't be able to claim their project is USB compliant. Under testing we noted a 3-6% packet loss that varied by the temperature of the F411 (which makes sense, as the RC clock circuit would be affected by it). This issue is beyond the scope of this code but should be mentioned in case somebody using it notices these PHY layer errors.

[dmitrystu]

I know that the HSI clock is unstable, but I think it is acceptable for the demo purpose. Also, packet loss is critical for the ISO endpoint, but not for other types. No AHB1 peripherals used for demo, but AHB1 clocks will be corrected anyway to avoid side effects. PS. Need to add don't copypaste setup code to readme