Device doesn't enumerate with STM32H7xx

[wolfmanjm]

Has anyone made this work on an STM32H743? (Devebox) I have ported it as required using this very simple CDC example.
My linux PC sees a new device but is unable to enumerate it.

[346066.977184] usb 1-9.1: new full-speed USB device number 76 using xhci_hcd
[346077.503187] usb 1-9.1: device descriptor read/all, error -110
[346077.701240] usb 1-9.1: new full-speed USB device number 77 using xhci_hcd
[346088.213259] usb 1-9.1: Device not responding to setup address.
[346088.421332] usb 1-9.1: Device not responding to setup address.
[346088.629204] usb 1-9.1: device not accepting address 77, error -71

Stepping through the code I am getting the request and appear to be sending the reply but the send is either incorrect or not happening at all.
I have checked the clocks, I am using the USB_OTG_FS device.
I do have the HAL version working ok for the CDC, but I'd like to have a composite device so that is why I am trying to get this to work. Thanks for any help or pointers.

[benedekkupper]

I haven't tried to run it on a STM32H7 device yet. I do know that there's an issue with STM32F723 which I have reproduced already, but haven't gotten to analyzing it further. What you're seeing seems very similar to that, so I'll treat them as the same until I have a fix for that. I'll let you know here when that happens, but unfortunately I have very little spare time to investigate this.

[wolfmanjm]

Thank you. I am continuing to work on this by comoparing the setuop with the STM32H7 HAL. I think this maybe a Fifo setup issue, as the H7 has a lot more fifo space and looking at the way the two are setup there are significant differences in the sizes used. I'll update here if I make any progress.

[wolfmanjm]

Ok so I got it to work with an ugly hack :)

The STM32H7 HAL does this

    HAL_PCDEx_SetRxFiFo(&g_hpcd, 0x80);
    HAL_PCDEx_SetTxFiFo(&g_hpcd, 0, 0x40);
    HAL_PCDEx_SetTxFiFo(&g_hpcd, 1, 0x80);

so I basically hacked the USB_vAllocateEPs() function (you made it __weak for a reason right ;)
to set the fifos to the same values as the HAL did, and it worked.

[360180.258383] usb 1-9.1: new full-speed USB device number 115 using xhci_hcd
[360180.480021] usb 1-9.1: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 1.00
[360180.480027] usb 1-9.1: New USB device strings: Mfr=16, Product=32, SerialNumber=0
[360180.480030] usb 1-9.1: Product: STM32 Virtual ComPort
[360180.480033] usb 1-9.1: Manufacturer: STMicroelectronics
[360180.490261] cdc_acm 1-9.1:1.0: ttyACM0: USB ACM device

    for (ucEpNum = 1; ucEpNum < ucEpCount; ucEpNum++)
    {
        /* Increase offset with the FIFO size */
        ulFifoOffset += ulFifoSize;

        /* FIFO sizes are in words */
        ulFifoSize = (pxUSB->EP.IN[ucEpNum].MaxPacketSize + 3) >> 2;
        if (ulFifoSize < 0x80)
        {   ulFifoSize = 0x80; } // JM++

        /* EPx TX FIFOs */
        pxUSB->Inst->DIEPTXF[ucEpNum - 1].w =
                (ulFifoSize   << USB_OTG_DIEPTXF_INEPTXFD_Pos) |
                (ulFifoOffset << USB_OTG_DIEPTXF_INEPTXSA_Pos);
    }

As the H7 has 4K of FIFO this seems to be ok.

This is probably not a good general fix, I suspect a few more configuration #defines for the H7 maybe in order.

Thanks
(Now onto trying to make a CDC and DFU composite device).

[benedekkupper]

Wow, thanks for the quick fix :) I'll be sure to check if this also applies to my situation. And yes, the endpoints allocation can get tricky with different configurations, that's why it can be overridden.

Just out of curiosity, are you using the DFU interface for the bootloader implementation, or the reboot only version (to use the ROM bootloader)?

[wolfmanjm]

FYI the H7 docs say...

Device RxFIFO =
(5 * number of control endpoints + 8) + ((largest USB packet used / 4) + 1 for status
information) + (2 * number of OUT endpoints) + 1 for Global NAK

So I did increase the RxFIFO size as well.

Re DFU...
I plan on using two versions of the DFU, a composite one in my Firmware that just does a jump to a flashloader on DFU_DETACH. (Basically is shuts everything down and jumps to a flashloader I have in QSPI flash).
The flashloader in QSPI memory already has a full DFU using the STM HAL as it is not a composite device, but once I get the composite device working I'll change that to use your stuff so I only need to deal with one USB stack.
We don't have a bootloader per se as our firmware has an ability to upgrade itself, The dfu is mainly for developers to easily do a edit/compile/flash cycle from an editor easily. In case of an end user bricking the firmware we will have instructions on how to use the STM builtin ROM DFU to repair it. (there is a BOOT0 button in the board).

Thank you for this code BTW it is the only workable solution OI have found to do a composite USB device on STM32xxx the new STM HAL USB stack is atrocious.

[benedekkupper]

The RX FIFO config is already matching the H7 docs:

    /* Global RX FIFO according to trial and error, thanks to defective documentation */
    ulFifoOffset = 11           /* to receive SETUP packets on the control endpoint */
            + (ulFifoSize + 1)  /* each packet gets status info as well */
            + (ucEpCount * 2)   /* transfer complete status is also stored with the last packet */
            + 1;                /* for Global OUT NAK */

Do you mean that you need to increase it to work, or you increased it just for safety?

[wolfmanjm]

I think the 11 needed to be 13, but I just set it to 0x80 (128) which is what the STM HAL sets it to.

BTW I made a number of other minor changes, which may or may not be necessary.

The main one that needed upstream changes is that I changed alignment to 4 as it appeared that H7 needed that and the default was setting it to 1 (it may be a good idea to make this a #define in the usbd_config.h.

[wolfmanjm]

Oh I also had to explicity do #undef USB_OTG_HS in the config, because for some reason the STM Hal include files set it regardless if you are using FS or HS (it sets both) they are labeled as 'legacy defines'.

[benedekkupper]

I think the 11 needed to be 13, but I just set it to 0x80 (128) which is what the STM HAL sets it to.

You're right, I've overlooked it.

The main one that needed upstream changes is that I changed alignment to 4 as it appeared that H7 needed that and the default was setting it to 1 (it may be a good idea to make this a #define in the usbd_config.h.

Oh I also had to explicity do #undef USB_OTG_HS in the config, because for some reason the STM Hal include files set it regardless if you are using FS or HS (it sets both) they are labeled as 'legacy defines'.

You shouldn't need to undefine the USB_OTG_HS if that peripheral is present in the system. Moreover, if you keep it, then the USBD_DATA_ALIGNMENT will also be set to 4.

[wolfmanjm]

The problem is I do not use that device, on the H7 there are two USB controllers one is HS and needs an external PHY and one is FS and uses the internal PHY. It selects the wrong device on H7 if USB_OTG_HS is defined and many other settings and registers end up being incorrect too. Also the USB2 (the USB_OTG_FS in the Hal) cannot use DMA explicitly, and if USB_OTG_HS is defined it enables the DMA which would also be a problem with the caches.
I am not sure but I think the H7 maybe using DMA under the hood to access the 4k of dedicated RAM, but you do not setup DMA explicitly. I may be wrong though.

[benedekkupper]

The OTG_HS also has an internal PHY, which is FS-only, so it can be preferred as the primary USB device as it has more FIFO RAM and endpoints iirc. Having it doesn't enable the DMA by itself, only after you configure the DMA field in the USBD_ConfigurationType config, and it's only possible for the HS peripheral anyway. You can fire a ticket here with the conflicts this creates.