STM32G0 support

[HubertD]

Add support for the updated fsdev peripheral in STM32G0 MCUs.

Compared with older fsdev revisions, the STM32G0 variant renamed a lot of registers & fields, some registers were extended from 16 to 32 bits and the USB memory addressing scheme was changed:

• In older versions, USB "PMA" memory had to be accessed using 8 or 16 bit instructions, 32 bit access did not work out.
• In the new version, all PMA accesses have to be 32 bit, 16 bit instructions do not seem to work any more.

Thus, I added a lot of #ifdefs to support both the new and the old peripheral in the same file.
Not sure if that is a good idea, maybe it would be better to factor out the concerned functions to separate header files.

In the previous code, a lot of casting took place to ensure register values are always placed in uint16_t variables.
Maybe I don't get it, but I think that's not necessary. Imho, having the register definitions right (volatile uint16_t*...) should suffice.
So I also changed some function signatures and variables from uint16_t to uint32_t to support the wider registers.
At least with my STM32F072B-DISCO board, the code still works on the old platform.

Using my own custom hardware, the updated driver seems to work on a STM32G0B1CB MCU, though not extensively tested yet.
I might try to get hold of a NUCLEO-G0B1RE board and maybe add a BSP for that.

This is not a final PR, but more of a "Request for Comments".

[HiFiPhile]

Thanks for your work ! I was thinking work on G0 after my vacation :)

it would be better to factor out the concerned functions to separate header files.

It would be nice at a later time to make the code easier to maintain.

[hathach]

thank you for your PR, I just did a quick search to find a G0 board to test with. Though look like all the G0 nucleo does not come with USB connector for user. Can we use an usb breakout to D+/D- to those board to test with. Or do we need to add additional passive (RC) to it. An nucleo BSP is definitely helping, it will make it easier for other maintainers to test with and also add it into ci run as well.

[HubertD]

At the moment, only STM32G0B1 and STM32G0C1 devices have USB peripherals.
The only affordable development board (STM32G0C1VE-EV is too expensive for me) seems to be the NUCLEO-G0B1RE.

And I'm not sure whether the nucleo has a "User USB" connector or not.

The image on the ST web page says no, but looking closely on the chip package, the pictured board has the wrong (STM32G071) MCU, so maybe that image just shows some random nucleo board?

The webpage also states:

    Board connectors:
    USB Type-C® user connector

So I would hope there is a USB-C connector there :)

Anyhow, the MCU has internal USB-Pull-Ups, so soldering a USB cable should suffice, just in case.

[hathach]

I feel you, I don't buy expensive kit myself as well. I have ordered an G0B1 nucleo (waiting for delivery), but look like it only has 1 usb for stlink. I checked that D+/D- is routed out to header, I have a few Adafruit usb breakout cable so hopefully it will work https://www.adafruit.com/product/4448

[HiFiPhile]

FIFO based R/W functions dcd_read_packet_memory_ff() and dcd_write_packet_memory_ff() need to be modified for 32bit alignment.

Both linear & wrapped parts of the circular fifo need to be read/write from/to the packet buffer.

In 16bit case linear part can only be odd or even so it's easy to handle.

Now linear part can remain 0-3 bytes after last 32bit aligned transfer.

[HiFiPhile]

Finally I've got my hands on G0 :)

I'm using a STM32G0B0RET6 soldered on NUCLEO-G071RB and a USB breakout cable.

I've added a NUCLEO-G0B1RE BSP, since B0 and B1 devices are very similar I'm compiling as STM32G0B1RET6, the only deference is B0 doesn't has HSI48 so I'm using HSE PLL clock in the BSP.

cdc_msc example tested ok, there are some remaining works:

• B0 use USB_IRQHandler naming
• Add 32bit FIFO transfer support, tested ok with audio_test_multi_rate and uac2_headset
• Cleanup, I don't think reg16_clear_bits() or clear_istr_bits() has actual meaning.

[hathach]

my G0 board is also arrived, I will test this out as soon as I could.

[hathach]

thank you @HubertD very much for this brilliant port, and @HiFiPhile for improving/enhancing and testing with actual hardware. I have pull and tested this on my https://www.st.com/en/evaluation-tools/nucleo-g0b1re.html . The driver works great, USB enumerates and works as it should be.

However I have to changes the clock setup to use HSI48 (on B1) for USB device to run (existing code doesn't work with B1). @HiFiPhile maybe we should seperate the B0 to its own board, since it seems to lack USB PD and has different clock set up ?

Overally, I think the PR is ready for merge, although I think we could possible refactor the PMA 32 bit access to get an cleaner code (possibly) in dcd driver. But that could wait for the follow up PR ? @HubertD @HiFiPhile Let me know if you are still planning to update this PR more, and prefer to have it pending a little bit more.

[HiFiPhile]

However I have to changes the clock setup to use HSI48 (on B1) for USB device to run (existing code doesn't work with B1).

It must be because of this (I don't even remember when I soldered SB17), since B0 doesn't have CRS HSE must used.

Maybe no need to separate B0 board, just put a word to solder SB17 for B0 user.

Let me know if you are still planning to update this PR more, and prefer to have it pending a little bit more.

It's ok for me atm.

[hathach]

yeah, ST doesnt make nucleo B0 version, you probably the only one that would rework the chip and solder the SB17. That is amazing soldering skill, I struggle enough with only soldering SWD occacsionally :D . I will keep the clock and also added the note for B0, at least that would give you an easy way to modify the code to test with your board. I am trying to add USB PD support, therefore want to get G0/G4 up to date before doing more works to prevent conflict in the future.

[HiFiPhile]

That is amazing soldering skill, I struggle enough with only soldering SWD occacsionally :D

In fact my job title is more like a hardware guy ;) Sometimes I even need to re-plant solder balls of eMMC chip :D

I am trying to add USB PD support

You mean the whole PD stack ? Seems a lot job to do.

[hathach]

In fact my job title is more like a hardware guy ;) Sometimes I even need to re-plant solder balls of eMMC chip :D

That sounds like awesome (awful) job to me 😄

You mean the whole PD stack ? Seems a lot job to do.

yeah, I went through the specs recently, it is lots of works. But i will try to get the PD sink work first, to at least request an vbus = 12v or 20v first with PD controller on G0/G4 then try to bit-bang it with rp2040 (gpio or pio). That is a long way to go.