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.

 

[waclawek.jan]

Yes, but that might be a different, unrelated issue.

Are any hints in errata or AN2606?

JW

 

[liampwll]

We use USART on the same pins on the STM32F070F6P6 with the same USB-USART adaptor on a practically identical board, which is what makes me suspect that the bootloader is just broken in general on this specific revision or package.

[waclawek.jan]

This may be the root cause of problems both with USB and UART (with no external oscillator).

The same issue is there for 'F042. That it works may be a coincidence, as exact effect of HSITRIM is process-dependent, (complicated by the fact that HSITRIM is added to the factory-set HSICAL, and their combined effect will be some 5-10% off nominal, I guess) and varies from piece to piece.

There may be no sane solution(*) for the USB case. For UART case, you can try a couple of baudrates around (below) the nominal, if you have such control over the PC-end of software.

Given the 'F0 family is more than 10 years old at this point, unless you present $M++ purchasing power (in which case you are not likely to ask here), I highly doubt ST will ever fix this.

JW

 

(*) Oh, and the insane one would be a contraption with one upstream (device) and one downstream (host) USB port (e.g. an STM32F4 with one USB module as device and other as host), where the downstream (host) would be capable of running the USB at frequencies adequate to the incorrectly detected HSE, e.g. 18MHz instead of 16MHz; attempting to "relay" the DFU protocol. This may be complete impossible due to latencies, and also USB modules/PHYs may not be willing to run at the different baudrate.

I can't explain why would a hub mentioned by @FBL help.

 

[liampwll]

I did see that, but it doesn't explain the USART also not working. (Edit: See next reply)

I suspect the F042 uses clock recovery as it supports USB without an oscillator in the bootloader, but I haven't dumped the ROM to check.

[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