STM32F070CBT6 will not enumerate on USB in bootloader mode

[liampwll]

We have a STM32070CBT6 with minimal connections (schematic below) and it appears to be unresponsive to USB enumeration, although it does pull DP low to trigger it. This occurs when hotplugging it or holding reset low for a few seconds. I've checked the input on PF0 and it is getting a clean 16 MHz.

[liampwll]

I did also bump the baud rate up and down a bit and still saw no response, although I don't remember by how much. Surely the USART would be in auto baud rate mode so it wouldn't matter.

I've just replaced all the 070s with 042s at this point but I'd still like to know if the bootloader actually works at all on this revision.

[waclawek.jan]

> Surely the USART would be in auto baud rate mode so it wouldn't matter.

Fair enough (I don't know the exact protocol and though it runs at a fixed predetermined baudrate).

So that should work no matter what's the exact clock, as long as it's far enough from the limits.

JW

[FBL]

@waclawek.jan , a known errata 2.12.1 Possible packet memory overrun/underrun at low APB frequency:

Operating USB controller with low APB frequency could lead to corrupted data. A workaround proposed in such case, to decrease APB clock below 10 - 8MHz. 

About inserting hub, here is a similar issue using STM32F070CB DFU when using win10 or later, suspecting driver DFU.  Solved: Re: DFU mode read out protection - STMicroelectronics Community

[waclawek.jan]

@FBL 

> A workaround proposed in such case, to decrease APB clock below 10 - 8MHz.

Doesn't the erratum call for APB clock *above* 10MHz?

And, isn't the bootloader running the USB stack with setting system clock to 48MHz, presumably APB running without divider at that same frequency? From the STM32F070xB chapter of AN2606:

If HSE is present and has a value of 24, 18, 16, 12, 8, 6, or 4 MHz, the system clock is configured to 48 MHz with HSE as clock source.

> suspecting driver

That's above my paygrade to judge... :)

Thanks,

JW