Add NUCLEO-H7S3L8 BSP

[HiFiPhile]

Describe the PR

Add NUCLEO-H7S3L8 support.

Status:

	FS port	HS port
Device	Unknown	Working
Host	Unknown	*Mostly working

Host issues are generic and not limited to STM32H7RS and will be addressed separately

• Detach is not detected, resulting _usbh_devices overflow.
  Can be fixed by add GINTSTS_DISCINT

• Random assert in edpt_find_opened in hcd_edpt_xfer
  Seems like when there are failed transfers events become mismatched. In the end a transfer is called with addr=1 but in received event addr=0.

• Occasional assert TU_ASSERT(ep_id < CFG_TUH_DWC2_ENDPOINT_MAX); with quickly connection/disconnection.
  A transfer with addr 0 finished after set address, maybe old transfer is not correctly aborted ?

Set Address = 1
[1:0] Set Address: 00 05 01 00 00 00 00 00 
gintsts = 0x20
on EP 00 with 8 bytes: OK
gintsts = 0x2000000
hcint = 0x21
on EP 80 with 8 bytes: OK
gintsts = 0x2000010
hcint = 0x20
gintsts = 0x2000000
hcint = 0x1
gintsts = 0x10
gintsts = 0x2000000
hcint = 0x2

[1:1] Open EP0 with Size = 8
Get Device Descriptor 1
[1:1] Get Descriptor: 80 06 00 01 00 00 12 00 
gintsts = 0x20
on EP 00 with 0 bytes: OK
gintsts = 0x2000000
hcint = 0x21
hcd_edpt_xfer 638: ASSERT FAILED

• Occasional assert tuh_descriptor_get_device(addr0...) when the port is bouncing, can be resolved by put _dev0.enumerating = 1; after debouncing delay, like in ENUM_ADDR0_DEVICE_DESC

[1:] USBH Device Attach
gintsts = 0x20000000
gintsts = 0x1000000
gintsts = 0x20000000
gintsts = 0x1000000
gintsts = 0x20000000
gintsts = 0x1000000
gintsts = 0x20000000
gintsts = 0x1000000
gintsts = 0x1000000
Full Speed
[1:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
process_enumeration 1473: ASSERT FAILED

Additional context
Wasted 2 hours in EXTI as the offset in SVD file is wrong !
Corrected STM32H7S.svd.zip

[hathach]

thanks for your PR, I also have this board. I will try to troubleshoot it later. Just merge master to get ci passed.

[lab313ru]

Is it usable for the board in its current state?

[HiFiPhile]

Is it usable for the board in its current state?

If you use it in device mode yes.

[lab313ru]

Unfortunately I need Host mode:(
ST's usb stub makes me suffer.

[lab313ru]

As I can say, there are problems with the board itself. Even examples code sometimes doesn't work, because of the device's USB controller state. I think it breaks some state inside itself, that's why it happens. Only powering it off for ~10 seconds helps. I don't know why is that, but it's true. I can prove it on my board.

[HiFiPhile]

Since hcd_dwc2 and usbh changes are generic I've excluded them from this PR, will address them separately.

[b4shful]

Been testing this on NUCLEO-H7S3L8 along with some of your DWC2 changes in separate PRs.

I left some review comments on those other PRs, just minor things, but I wanted to also comment on this one and say thank you so much for the great work on H7S3L8 and DWC2.

With a few tweaks for my specific requirements, it's working flawlessly and my basic CDC HS single endpoint setup is already hitting 18MB/s in a super quick benchmark task I wrote, with the only real optimisation I've had to do being changing the 512 byte buffers to 2kb! Excited to make some more tweaks and see how fast I can get it to go.

The project I'm using this for is part of my final year project at university - and I had already wasted a lot of time with ST's USB stack before realising it was fundamentally broken and almost unusable (I think its interaction with the state machine is messed up or something) - so I cannot express my appreciation enough, these PRs have allowed me to escape ST's stack and move to TinyUSB, potentially saving my project 😄

[b4shful]

Out of interest, have you happened to run your benchmarks ("cdc_task2" and such from #920 (comment)) on this board?

I am primarily interested in the throughput I can get sending data from the board as device to the PC as host. I copied over your functions to expose the FIFOs and wrote something like:

static void USB_CDC_Benchmark2(void* params)
{
  (void) params;

  // 1) prepare ramp-data block
# if 0
//  static uint8_t const block[2048] = {
//    #define RAMP(i) (uint8_t)(i)
//    #include "ramp_0_2047.inc"
//  };
#else
  static uint8_t block[2048];
  for (size_t i = 0; i < sizeof(block); ++i) {
      block[i] = (uint8_t)i;
  }
#endif

  // 2) wait until the host opens the port
  while ( !tud_cdc_connected() ) {
    osDelay(1);
  }

  // 3) blast blocks into the TX FIFO as fast as possible
  for (;;) {
    tu_fifo_t* txff = tud_cdc_get_tx_ff();

    // query the linear chunk we can write into
    tu_fifo_buffer_info_t info;
    tu_fifo_get_write_info(txff, &info);

    // calculate number of bytes to copy this round
    size_t want = sizeof(block);
    size_t lin  = tu_min32(want, info.len_lin);

    // copy into the FIFO buffer
    memcpy(info.ptr_lin, block, lin);

    // if we hit a wrap, copy that too
    size_t total = lin;
    if ( lin < want && info.len_wrap ) {
      size_t wrap_copy = tu_min32(want - lin, info.len_wrap);
      memcpy(info.ptr_wrap, block + lin, wrap_copy);
      total += wrap_copy;
    }

    if ( total ) {
      tu_fifo_advance_write_pointer(txff, total);
      tud_cdc_write_flush();
    }
    else {
      taskYIELD();
    }
  }
}

Since I'm just blasting data from the board as fast as possible, my Rx code is a bit different:
https://github.com/b4shful/CDC-Rx-Benchmark

It's C# but knowing the limitations of .NET's SerialPort I used Win32 interop/pinvoke for that part instead.

I managed to hit ~25-26MiB/s on this Benchmark2, still with 2048 byte buffers.

I get a slightly slower 23MB/s when using the following task (Benchmark1):

static void USB_CDC_Benchmark1(void *params)
{
    (void)params;

    /* 1) prepare "ramp" data */
    static uint8_t block[2048];
    for (size_t i = 0; i < sizeof(block); ++i) {
        block[i] = (uint8_t)i;
    }

    /* 2) wait until the host has opened the CDC port */
    while ( !tud_cdc_connected() ) {
        osDelay(1);
    }

    /* 3) blast blocks into the TX ring as fast as it will accept them */
    for (;;) {
        size_t written = tud_cdc_write(block, sizeof(block));
        if ( written == sizeof(block) ) {
            continue;
        }
        taskYIELD();
    }
}

So, I don't know if the approach exposing the FIFOs is inherently faster or if there's other factors (scheduler stuff) actually holding it back moreso than the cdc task implementation - the task priorities are also having a big impact (but I have some other stuff like a basic 1 second blink running also), so that would be another major external factor impacting speed.

I don't really know what I'm doing to be honest and I am new to TinyUSB - I don't know if these numbers sound about right or if I should be able to achieve much higher numbers than this.

Edit: perhaps this isn't the correct place for this discussion - if so, let me know and I can repost this in #920 instead.
Edit2: I realise doing memcpy in Benchmark2 kinda defeats the purpose, not sure if there's a no-copy approach or not - I might be missing something incredibly obvious haha

[HiFiPhile]

Out of interest, have you happened to run your benchmarks ("cdc_task2" and such from #920 (comment)) on this board?

I haven't done it. I think your number is not bad, although maybe there are some chances of optimizations.
You can try to clear this bit:

tinyusb/src/portable/synopsys/dwc2/dcd_dwc2.c

Line 428 in 3024bff

gahbcfg |= GAHBCFG_TX_FIFO_EPMTY_LVL;

[b4shful]

Out of interest, have you happened to run your benchmarks ("cdc_task2" and such from #920 (comment)) on this board?

I haven't done it. I think your number is not bad, although maybe there are some chances of optimizations. You can try to clear this bit:

tinyusb/src/portable/synopsys/dwc2/dcd_dwc2.c

Line 428 in 3024bff

gahbcfg |= GAHBCFG_TX_FIFO_EPMTY_LVL;

WOAH

That speed was achieved using just this simple task:

static void USB_CDC_BenchmarkTask(void *arg)
{
    (void)arg;

    /* 1) prepare one 2 KiB block of “ramp” data */
    static uint8_t block[2048];
    for (size_t i = 0; i < sizeof(block); ++i) {
        block[i] = (uint8_t)i;
    }

    /* 2) wait until the host has opened the CDC port */
    while ( !tud_cdc_connected() ) {
        osDelay(1);
    }

    /* 3) blast blocks into the TX ring as fast as it will accept them */
    for (;;) {
        size_t written = tud_cdc_write(block, sizeof(block));
        if ( written == sizeof(block) ) {
            continue;
        }
        taskYIELD();
    }
}

While I quoted some speeds around 25-26MiB/s before, I think most of that was external factors (like other running tasks, or the configuration of my task that calls tud_task()) - the number I could most accurately quote was 23MiB/s (which occurred using a whole bunch of different implementations of the benchmark task). After clearing that bit via

- gahbcfg |= GAHBCFG_TX_FIFO_EPMTY_LVL;
+ gahbcfg &= ~GAHBCFG_TX_FIFO_EPMTY_LVL;

I immediately saw the throughput hover around 26-27 MiB/s.

Although I noticed that my static uint8_t block[] wasn't sitting in noncacheable_buffer. I tried putting it there with __attribute__((section("noncacheable_buffer"))) and the speed dropped to 20MiB/s. That's probably the data cache in action. Although I'm surprised it can even access the regular cached memory at all, is it first being memcopied into TUSB's FIFO (which is in noncacheable buffer), and then via DMA from that point onwards?

[HiFiPhile]

Although I'm surprised it can even access the regular cached memory at all, is it first being memcopied into TUSB's FIFO (which is in noncacheable buffer), and then via DMA from that point onwards?

Yes cdc driver always copy the data so the source data variable doesn't need to be static. If you need more throughput you can copy the driver (or vendor class driver) and make adjustments then register it as a custom driver.
Here is an example:
https://github.com/kkitayam/akiprobe/blob/c3221be0de3794725e46e427f57ced99826ced12/src/main.c#L53

[hathach]

perfect, hil server probably has some loose connection issue. I am current not at its place to re-connect. We can just merge this for now.