Get blinky running again and update xpcc.

[strongly-typed]

DFU method was removed but it will be added to xpcc. See roboterclubaachen/xpcc#285.

[salkinium]

So… not sure how you feel about the ST USB stack, but it may be interesting to look at kevinmehall/usb for a OSS USB implementation. ST recently released a lower-level HAL than STCube, maybe that could be of use to port this. To be clear, I've used neither of these, so can make no call on the quality or ease-of-use, so feel free to ignore me (but please report back your experiences ;-)

[ekiwi]

Just FYI, as far as I know, the 48MHz clock is the only one that can be calibrated via the USB clock.

[strongly-typed]

@ekiwi Thanks for pointing out that detail. So I will try to care about the HSI48MHz clock and update the PR.

At the moment the device does not start after flashing with DFU in one of about ten tries. I witnessed that the device stopped blinking after five or ten seconds (blinky example). That is very strange. My feeling was that it was much more reliable and stable when running from HSI8MHz.

This is hard to reproduce and hard to debug. Any suggestions?

[strongly-typed]

Ok, found it. Kevin's version did not set the flash latency at all. So running at 48 MHz with zero wait states is out of spec and pure luck. It is important to set the wait states before switching the clock.

I was not able to figure out why the reset after DFU programming does not work reliably. Pressing reset or just unplugging the device is a workaround.

You you please review? I will take care about CAN and USB in later PRs (and feature branches of course).

@salkinium Thanks for pointing at the USB stack. I probably won't try it now because someone Daniel knows has a running binary for the hardware. Will look into what is more convenient.