[RFC] add DFU runtime

[t-8ch]

Do not merge yet

Everything here currently only handles the Pinecil.

• Please check if the PR fulfills these requirements

• [] The changes have been tested locally
• [] There are no breaking changes

• What kind of change does this PR introduce?

This introduces an USB runtime.
It exposes DFU runtime descriptors that can be used to perform firmware updates as discussed in #817 .

• What is the current behavior?

IronOS does not expose any data over USB.

• What is the new behavior (if this is a feature change)?

IronOS is discoverable over USB.

This does currently not work. The PR is here for review and help.

Without this PR the Pinecil only throws errors in dmesg:

[26047.024977] usb 1-4: new full-speed USB device number 31 using xhci_hcd
[26047.148765] usb 1-4: device descriptor read/64, error -71
[26047.378806] usb 1-4: device descriptor read/64, error -71

With this PR it is detected somewhat but still throws errors:

[26048.711762] usb 1-4: new full-speed USB device number 33 using xhci_hcd
[26048.712020] usb 1-4: Device not responding to setup address.
[26048.919101] usb 1-4: Device not responding to setup address.

I guess something is wrong with the interrupt/timer setups.

Note:
This PR backports a few structures from 1.2.0 of the GD32VF103 firmware library.
(Also the examples there were used as reference)

[alvinhochun]

The first thing that comes into my mind (having read the user manual for a bit), is that, you have to drop the system clock down from 108MHz to 96MHz (or overclock it to 120MHz if you are OK with running it out of spec) for USB to work, because the USB peripheral requires a 48MHz clock and the USB clock prescaler does not support 2.25. I don't know how much heavy-lifting the vendor board files have already done, but this may be something worth checking.

[t-8ch]

@alvinhochun Thanks for the hint!
With the clock set to 96MHz it now boots without the USB but with it it gets stuck inside usbd_init().
As it is different than before I'll call it a success.
For proper debugging I'll have to wait a bit until I am back with my hardware.

[t-8ch]

I am struggling getting the USB interrupts to work, my interrupt handler is not being called at all.
As the DFU bootloader mode works correctly I think that the wiring should work by default (no conflict with the FUSB302).

Maybe somebody with actual hardware knowledge could take a look?

[Ralim]

FUSB only controls the CC lines, so it wont touch the data lines.
Have you any further changes that are unpushed?

I can try and have a look see this weekend if I get time on Sunday (or before should time and sleep schedule allow)

[Ralim]

Ah, having a look quickly; how are you checking your interrupt handler (and therefore usbd_isr) is not being called?

To rule out the function not linking you could try removing the weak on the function declaration in the startup asm file? I think swapping .weak to .global would do this iirc.

Everything looks fairly sane otherwise :/

[t-8ch]

@Ralim thanks a lot!
To test that the ISR is triggered I a) set a breakpoint on the function and b) counted the invocation is a variable that can be shown from the debug screen when not using the debugger/breakout board.
It linked correctly.

[Ralim]

@Ralim thanks a lot!

I'm not ignoring you I promise 😅

To test that the ISR is triggered I a) set a breakpoint on the function and b) counted the invocation is a variable that can be shown from the debug screen when not using the debugger/breakout board.

Welp yep that covers it. I'll try and give this a poke, though I'm not much wiser than you on this platform. All I'll be doing is squinting at the datasheet 😅 . I did have some sucsess with their other peripherals to compare against the stm32f103 datasheet too for where descriptions were missing as this chip seems to use a bunch of peripherals they used in their binary compatible mimic of the stm32f103.

It linked correctly.

Ah bummer, that would have been too simple.

[alvinhochun]

Did you test with QC disabled? If it messes with the D+/D- pins then USB enumeration probably wouldn't work. Though I don't know if this will cause the ISR to not get triggered.

Have you got it to work with a plain USB gadget demo without the IronOS bits?

[t-8ch]

@alvinhochun I tested with the FUSB302 not initialized. Is that enough?

[Ralim]

@alvinhochun I tested with the FUSB302 not initialized. Is that enough?

The FUSB302 only controls CC pins, its entirely separate to all of the QC negotiation over the USB data lines.
You will want to leave the FUSB302 enabled but disable support for QC.

You will need to disable the POW_QC configuration option and edit the gpio setup to ensure all QC io are put into input (high impedance mode) before you are able to do USB.

QC should not kick in for around 2-3 seconds after startup, but a good point is raised that if your not setting all of the IO to input mode you wont get a usb connection.

[discip]

@t-8ch
@Ralim
Is this not realized with IronOS-dfu?

Please correct me if I am wrong, otherwise this can be closed.

[Ralim]

This is separate, this is so that the device shows up on USB during normal use (not bootloader mode)

[discip]

OK.
Thanks for the clarification.