Intermittent failure to enable the usb bus

[dgoodlad]

Developing on an STM32F446 device, I've been seeing a 50/50 chance of the bus enable() function hanging waiting for the core soft reset to complete. It sits stuck in the loop in bus.rs:437. This happens at least 50% of the time, and it doesn't matter if the code being flashed is the same or not.

There are a number of folks complaining about similar issues around the internet, with varying causes noted:

• https://electronics.stackexchange.com/questions/224174/stm32-usb-host-will-not-return-from-reset-request
• https://sourceforge.net/p/libopencm3/mailman/libopencm3-devel/thread/50240594.6050003%40gmx.de/#msg29656354
• https://community.st.com/t5/embedded-software-mcus/otg-usb-delay-needed-between-selecting-phy-and-softreset/m-p/211903

... and more.

I have confirmed that the HSE is stable and configured correctly. I am using the f446 nucleo board, which has an on-board 8MHz external oscillator signal passed through from the st-link. My clocks are configured using the stm32f4xx-hal package's code like so:

let clocks = rcc
    .constrain().cfgr
    .use_hse(8.MHz())
    .bypass_hse_oscillator()
    .sysclk(168.MHz())
    .require_pll48clk()
    .pclk1(42.MHz())
    .pclk2(84.MHz())
    .sai1_clk(49_142_857.Hz())
    .freeze();

One consistent message in a few others' experience is that the otg core seems to need to have interrupts unmasked internally to function correctly, and that needs to happen early. This aligns with the programming model in RM0390, section 31.16.1:

I've given this a hacky go by doing the following before any other USB initialisation code:

// GAHBCFG.GINT = 1
cx.device.OTG_HS_GLOBAL.gahbcfg.modify(|_,w| w.gint().set_bit());
// GINTMSK.OTGINT = 1; GINTMSK.MMISM = 1;
cx.device.OTG_HS_GLOBAL.gintmsk.modify(|_,w| w.otgint().set_bit().mmism().set_bit());

I can't 100% confirm this works, but I have yet to see another stall waiting for the core soft reset to clear.