native/platform: fix DFU detach

[tlyu]

DFU detach wasn't lowering the USB pullup. This meant that BMP was rebooting into DFU bootloader mode, but the host wasn't re-enumerating it, because it hadn't detected a detach.

In platform_request_boot, The gpio_set_mode config was for analog instead of floating input. PA8 isn't defined as an analog pin on this chip, so it's arguably undefined behavior.

Also confirmed that using scb_reset_system instead of scb_reset_core to do the DFU reboot would correctly detach and enter the bootloader, if the boot button was held down.

Detailed description

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted)
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

[dragonmux]

LGTM, and as we've talked about this at length on Discord to determine what was wrong and why, we're happy to merge this as-is. Thank you for the contribution!

[tlyu]

For completeness, the DFU product string is Black Magic Probe DFU v1.8.2, but I'm pretty sure that nothing relevant has changed in the DFU firmware since then. (It still doesn't float the USB pullup for a while before driving it high.)

[tlyu]

For the record, BMP native D+ voltages measured with a DMM:

Belkin USB 3.0 SuperSpeed hub with USB A device ports:

• 3.06 runtime idle
• 0.92 pullup set to analog
• -0.03 pullup set to floating input
• 3.04 DFU idle

Directly connected to a USB C port on a M2 MacBook Air:

• 3.05 runtime idle
• 0.94 pullup set to analog
• -0.02 pullup set to floating input
• 3.04 DFU idle

Note that 0.9V is within the forbidden zone for full-speed USB D+/D- voltages. (V_IL (max) is 0.8V for low/full speed, and V_IH (min) is 2.0V.)

This strongly implies that the analog GPIO configuration is invalid for this pin, at least on this particular rev of GD32F103 silicon, and that the D+ pulldown on both the hub and the Mac's host port are reasonably within spec. In analog mode, the voltage did take a while to settle down to around 0.9V, which implies a somewhat moderate impedance or capacitance involved.

The difference between the hub and directly-connected behaviors that I observed pre-patch are almost certainly due to allowed differences in threshold for detecting the disconnect voltage. A hub is required to detect SE0 when D+ and D- are both below V_IL (max), but is allowed to detect SE0 when they're both below V_IH (min).

I might eventually put the analog scope on it, but this is strong enough evidence that the previous code was wrong, and plausibly causing DFU bootloader entry failures that might be inconsistent or difficult to reproduce.

I applied a patch to instrument platform_request_boot to add several seconds of delay between these states. Measurements were made using a custom USB C interposer jig that I made for unrelated power measurement purposes. The small negative voltages are probably meter offset or the result of small leakage currents.

[dragonmux]

Agreed on your analysis there - thank you very much for getting that extra data on the issue, that's extremely useful. Think we'll be backporting this to v1.9 and v1.10 at the very least.