Fix USB Host issues

[AndrewCapon]

Code to fix the issues currently with the USB Host code.

Enable with ARC_USB_FULL_SIZE=1

Use the HAL to handle the entire transfer.

Stop the NAKs flooding the cpu.

Stop the CHHs flooding the cpu.

Only retry if no data has already been received for transfer.

[github-actions[bot]]

Memory usage change @ 88edfeddc6a79d62308df8f1bea4986ae3d58e02

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6576 - +6640	+0.33 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6568 - +6640	+0.33 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6632|0.34|0|0.0|6576|0.33|0|0.0|6632|0.34|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_opta:opta`|6632|0.34|0|0.0|6568|0.33|0|0.0|6640|0.34|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6632,0.34,0,0.0,6576,0.33,0,0.0,6632,0.34,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_opta:opta,6632,0.34,0,0.0,6568,0.33,0,0.0,6640,0.34,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[github-actions[bot]]

Memory usage change @ 864f722b1cc34c1f5ba06e1b3e07786a35ceece7

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6640 - +6648	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6640 - +6704	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6640|0.34|0|0.0|6648|0.34|0|0.0|6640|0.34|0|0.0|6648|0.34|0|0.0|6640|0.34|0|0.0 `arduino:mbed_opta:opta`|6704|0.34|0|0.0|6640|0.34|0|0.0|6648|0.34|0|0.0|6648|0.34|0|0.0|6704|0.34|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6640,0.34,0,0.0,6648,0.34,0,0.0,6640,0.34,0,0.0,6648,0.34,0,0.0,6640,0.34,0,0.0 arduino:mbed_opta:opta,6704,0.34,0,0.0,6640,0.34,0,0.0,6648,0.34,0,0.0,6648,0.34,0,0.0,6704,0.34,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[github-actions[bot]]

Memory usage change @ 1a82f9171012a5802a4f019014187ec3c981f7fb

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6640 - +6648	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6640 - +6704	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6640|0.34|0|0.0|6648|0.34|0|0.0|6640|0.34|0|0.0|6648|0.34|0|0.0|6640|0.34|0|0.0 `arduino:mbed_opta:opta`|6704|0.34|0|0.0|6640|0.34|0|0.0|6648|0.34|0|0.0|6648|0.34|0|0.0|6704|0.34|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6640,0.34,0,0.0,6648,0.34,0,0.0,6640,0.34,0,0.0,6648,0.34,0,0.0,6640,0.34,0,0.0 arduino:mbed_opta:opta,6704,0.34,0,0.0,6640,0.34,0,0.0,6648,0.34,0,0.0,6648,0.34,0,0.0,6704,0.34,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[facchinm]

Looks good to me but I'd love if @alrvid could take a look too

[AndrewCapon]

I guess the GIGA define should be used instead of ARC_USB_FULL_SIZE, I have no idea how this may effect other boards it is only tested with the GIGA.

[github-actions[bot]]

Memory usage change @ 2d7534eabb2e8e5748729ed54270d4bf4d181385

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6568 - +6640	+0.33 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6632 - +6640	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6632|0.34|0|0.0|6640|0.34|0|0.0|6568|0.33|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_opta:opta`|6632|0.34|0|0.0|6632|0.34|0|0.0|6640|0.34|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6632,0.34,0,0.0,6640,0.34,0,0.0,6568,0.33,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_opta:opta,6632,0.34,0,0.0,6632,0.34,0,0.0,6640,0.34,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[github-actions[bot]]

Memory usage change @ 61ccb56125a395d76fb2830cf79794f4f06d8008

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6568 - +6640	+0.33 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6632 - +6640	+0.34 - +0.34	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6632|0.34|0|0.0|6640|0.34|0|0.0|6568|0.33|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_opta:opta`|6632|0.34|0|0.0|6632|0.34|0|0.0|6640|0.34|0|0.0|6640|0.34|0|0.0|6632|0.34|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6632,0.34,0,0.0,6640,0.34,0,0.0,6568,0.33,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_opta:opta,6632,0.34,0,0.0,6632,0.34,0,0.0,6640,0.34,0,0.0,6640,0.34,0,0.0,6632,0.34,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[github-actions[bot]]

Memory usage change @ dba021ead84237d43a38c857b95ed9491c0cf9f8

Board	flash	%	RAM for global variables	%
arduino:mbed_giga:giga	:small_red_triangle: +6896 - +6904	+0.35 - +0.35	0 - 0	0.0 - 0.0
arduino:mbed_opta:opta	:small_red_triangle: +6896 - +6904	+0.35 - +0.35	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A

Click for full report table

Board|`examples/DirList`
flash|%|`examples/DirList`
RAM for global variables|%|`examples/FileRead`
flash|%|`examples/FileRead`
RAM for global variables|%|`examples/FileWrite`
flash|%|`examples/FileWrite`
RAM for global variables|%|`examples/OptaDirList`
flash|%|`examples/OptaDirList`
RAM for global variables|%|`examples/PortentaOTA`
flash|%|`examples/PortentaOTA`
RAM for global variables|% -|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- `arduino:mbed_giga:giga`|6896|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0 `arduino:mbed_opta:opta`|6896|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0|6904|0.35|0|0.0 `arduino:mbed_portenta:envie_m7`|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A|N/A

Click for full report CSV

``` Board,examples/DirList
flash,%,examples/DirList
RAM for global variables,%,examples/FileRead
flash,%,examples/FileRead
RAM for global variables,%,examples/FileWrite
flash,%,examples/FileWrite
RAM for global variables,%,examples/OptaDirList
flash,%,examples/OptaDirList
RAM for global variables,%,examples/PortentaOTA
flash,%,examples/PortentaOTA
RAM for global variables,% arduino:mbed_giga:giga,6896,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0 arduino:mbed_opta:opta,6896,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0,6904,0.35,0,0.0 arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A ```

[facchinm]

Manually merged, thank you so much! Everything works wonderfully from my tests!

[AndrewCapon]

Nice one.

I'm at the moment trying to track down an issue with hubs.

If you have a bulk device and an interrupt device connected, if you request async data from the bulk device (after data received) and the interrupt device within a ms of each of each other there is a chance that the interrupt device data will never be received, so rxhandler not called, next request not made so dead from that point.

Hopefully I can find the issue, it seems to be deep down, either in the STM code or maybe the TransferDescriptor stuff. It is illusive at the moment. When I find it I will put in another PR...

[KurtE]

@facchinm @AndrewCapon - I also have a partial fix that works for USB LS devices that are connected directly. So far I don't have the low speed devices working with HUBs, but that may be related to the issues that Andrew mentioned.

So for example I have extended Keyboard and Mouse classes that are working (as well as some tablets and likewise @mjs513 also has some game controllers working as well.

[AndrewCapon]

@facchinm @AndrewCapon - I also have a partial fix that works for USB LS devices that are connected directly. So far I don't have the low speed devices working with HUBs, but that may be related to the issues that Andrew mentioned.

So for example I have extended Keyboard and Mouse classes that are working (as well as some tablets and likewise @mjs513 also has some game controllers working as well.

Where would I find the LS stuff?

[KurtE]

I just rebased my branch up to the current stuff... https://github.com/KurtE/Arduino_USBHostMbed5/tree/usb_host_fixes_lowspeed

I am about to test it out again:

The different USB devices that @mjs513 and myself have been playing with is up at: https://github.com/KurtE/GIGA_USBHostMBed5_devices

Note: several of these examples and classes may be currently using some other classes and the like, that I have up on github:

Not sure how much you might want to play. For example there is a keyboard view sketch which is setup to use an ILI9341 SPI driven display using the library: https://github.com/KurtE/ILI9341_GIGA_n

I have a quick and dirty version of digitalWriteFast/digitalToggleFast https://github.com/KurtE/UNOR4-stuff/tree/main/libraries/GIGA_digitalWriteFast I really should move that somewhere else. Maybe in the GIGA_USBHostMBed5_devices or on it's own.

I am also using a MemoryHexdump function, located up at: https://github.com/KurtE/MemoryHexDump

If desired I can update some of these test sketches and classes to not use some of these libraries by default

Edit: Looks like I can still talk to the low speed device. At some point I still have more keyboard stuff to debug. Like my sending data back to the keyboard to change the LED states is not fully working. But that is beyond what is implemented on other libraries.

[mjs513]

@facchinm - @KurtE - @AndrewCapon - @wwatson Thought you should know that there may be an issue with setting arc_usb = 1. When @wwatson and I were playing with the usb_file_write example it would crash the GIGA I get and error on doing a fclose of the file (https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/8). This was using @KurtE's branch that had most of the fixes + the LS fixed Kurt mentioned.

@wwatson did some investigating and found that #define ARC_USB_FULL_SIZE 1 seemed to be causing the issue: https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/22

Briefly quoting him:

If this is defined the USB keyboard and mouse work but then we get the fclose error for a file write. If I comment out the define then the USB mouse and keyboard are not recognized and file writing works.

[IOSAudio]

I just rebased my branch up to the current stuff... https://github.com/KurtE/Arduino_USBHostMbed5/tree/usb_host_fixes_lowspeed

Thanks

@facchinm - @KurtE - @AndrewCapon - @wwatson Thought you should know that there may be an issue with setting arc_usb = 1. When @wwatson and I were playing with the usb_file_write example it would crash the GIGA I get and error on doing a fclose of the file (https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/8). This was using @KurtE's branch that had most of the fixes + the LS fixed Kurt mentioned.

@wwatson did some investigating and found that #define ARC_USB_FULL_SIZE 1 seemed to be causing the issue: https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/22

Briefly quoting him:

If this is defined the USB keyboard and mouse work but then we get the fclose error for a file write. If I comment out the define then the USB mouse and keyboard are not recognized and file writing works.

I will have a test today...

[AndrewCapon]

Whoops, posted that last message from wrong account!

[AndrewCapon]

@facchinm - @KurtE - @AndrewCapon - @wwatson Thought you should know that there may be an issue with setting arc_usb = 1. When @wwatson and I were playing with the usb_file_write example it would crash the GIGA I get and error on doing a fclose of the file (https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/8). This was using @KurtE's branch that had most of the fixes + the LS fixed Kurt mentioned.

@wwatson did some investigating and found that #define ARC_USB_FULL_SIZE 1 seemed to be causing the issue: https://forum.arduino.cc/t/usbhostmbed5-fileread-ino-fails-with-crash/1189658/22

Briefly quoting him:

If this is defined the USB keyboard and mouse work but then we get the fclose error for a file write. If I comment out the define then the USB mouse and keyboard are not recognized and file writing works.

So I have had a look into this.

At a guess it is something to do with the fact the underlying STM code does not update the xfer_count of the endpoint when writing unless DMA is used, this may well be confusing issues or may have nothing to do with it, who knows.

Nothing is written in that example until the fclose (the fflush(stdout) does nothing).

Writes < 65 bytes are all working.

So I'm not sure if the write is working with > 64, what is happening is the data read after the write is timing out. So I'm guessing the write is not working even though all the return values are fine.

I have spent a few hours on it and have had enough, I will look again in a while...

When I wondered why the original code was handling the packet splitting rather than using the STM stuff before, maybe this is the smoking gun,

[KurtE]

@facchinm @AndrewCapon - and all.

At a guess it is something to do with the fact the underlying STM code does not update the xfer_count of the endpoint when writing unless DMA is used, this may well be confusing issues or may have nothing to do with it, who knows.

Wondering, is DMA implemented anywhere within the STM32... HAL/mbed-os code base? I have noticed that both USBHost libraries have: hhcd->Init.dma_enable = 0; // for now failed with dma

Is there code to support DMA and it is failing? Or not implemented? My search through the mbed-os github project did not find much under the targets\TARGETS_STM

[AndrewCapon]

If you turn that DMA on then nothing works at all. I did try it, first I disabled both caches entirely as I thought that would be the problem, this did not fix anything so the idea of trying to work out what wasn't working was not one I wanted! :)

The ST recommendation is to use DMA, all the underlying ST code supports it.

I'm beginning to wonder if the best bet is to throw away this stuff and get the host side of TinyUsb ported, the device side should work...

[mjs513]

I'm beginning to wonder if the best bet is to throw away this stuff and get the host side of TinyUsb ported, the device side should work... Maybe its for the best. I think I read on the mBedOs forum that USBHostMbed5 would not work with MBedOS6 (which they are currently at). So if Arduino ever upgrades to Mbedos6 might be a problem!

[KurtE]

Not sure if better to continue on new issue/pr or forum...

I believe that very likely DMA is not used anywhere within the GIGA code base...

I have a quick and dirty DMA dumping sketch, that I extracted the parts from my ILI9341 GIGA port, that as I mentioned can use DMA...

dump_dma_information-231205a.zip

The main setup() code is:

void setup() {
  while (!Serial)
    ;
  Serial.begin(115200);

  Serial.println("\n********** DMA Information **********");
    if (RCC->AHB1ENR & RCC_AHB1ENR_DMA1EN) Serial.println("DMA1 RCC Enabled");
  else Serial.println("DMA1 RCC *NOT* Enabled");
    if (RCC->AHB1ENR & RCC_AHB1ENR_DMA2EN) Serial.println("DMA2 RCC Enabled");
  else Serial.println("DMA2 RCC *NOT* Enabled");

  dump_dmamux(DMAMUX1_Channel0);
    dump_dmamux(DMAMUX1_Channel1);
    dump_dmamux(DMAMUX1_Channel2);
    dump_dmamux(DMAMUX1_Channel3);
    dump_dmamux(DMAMUX1_Channel4);
    dump_dmamux(DMAMUX1_Channel5);
    dump_dmamux(DMAMUX1_Channel6);
    dump_dmamux(DMAMUX1_Channel7);
    dump_dmamux(DMAMUX2_Channel0);
    dump_dmamux(DMAMUX2_Channel1);
    dump_dmamux(DMAMUX2_Channel2);
    dump_dmamux(DMAMUX2_Channel3);
    dump_dmamux(DMAMUX2_Channel4);
    dump_dmamux(DMAMUX2_Channel5);
    dump_dmamux(DMAMUX2_Channel6);
    dump_dmamux(DMAMUX2_Channel7);
  // Lets first print out the DMAMux information.
}

And the output:

********** DMA Information **********
DMA1 RCC *NOT* Enabled
DMA2 RCC *NOT* Enabled

** DMAMUX1_Channel0 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel1 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel2 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel3 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel4 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel5 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel6 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX1_Channel7 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel0 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel1 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel2 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel3 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel4 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel5 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel6 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

** DMAMUX2_Channel7 **
  CCR: 0 NBREQ(0) Sync(0) REQ ID: (unused)

So it looks like neither DMA is enabled and all of the DMAMux channels are showing nothing...

EDIT: Quick note: I get the same output on Portenta H7 board as well

[AndrewCapon]

I have managed to blunder my way through getting TinyUSB host running on a STMh747 even though it is not supported on ST, its all very hacky at the moment but it may be the way to go:

USBH init on controller 1
sizeof(usbh_device_t) = 184
sizeof(hcd_event_t) = 12
sizeof(_ctrl_xfer) = 24
sizeof(tuh_xfer_t) = 24
sizeof(tu_fifo_t) = 12
sizeof(tu_edpt_stream_t) = 24
HUB init
Init
[0:] USBH DEVICE ATTACH
Full Speed
[0:0] Open EP0 with Size = 8
Opened pipe for devaddr:0 epaddr:00 in slot 6
Opened pipe for devaddr:0 epaddr:80 in slot 6
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00 
hcd_setup_send on pipe for devaddr:0 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 00 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:0 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 8
Transfer SUCCESS devaddr 00 ep:80 8 bytes, channel 6
on EP 80 with 8 bytes: OK
[0:0] Control data:
  0000:  12 01 00 02 00 00 00 40                          |.......@|
hcd_edpt_xfer on pipe for devaddr:0 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 00 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Set Address = 1
[0:0] Set Address: 00 05 01 00 00 00 00 00 
hcd_setup_send on pipe for devaddr:0 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 00 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:0 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 0
Transfer SUCCESS devaddr 00 ep:80 0 bytes, channel 6
on EP 80 with 0 bytes: OK

Closing pipe 0 on dev 00
Closing pipe 1 on dev 00
[0:1] Open EP0 with Size = 64
Opened pipe for devaddr:1 epaddr:00 in slot 6
Opened pipe for devaddr:1 epaddr:80 in slot 6
Get Device Descriptor
[0:1] Get Descriptor: 80 06 00 01 00 00 12 00 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 18
Transfer SUCCESS devaddr 01 ep:80 18 bytes, channel 6
on EP 80 with 18 bytes: OK
[0:1] Control data:
  0000:  12 01 00 02 00 00 00 40 AC 05 67 02 51 08 01 02  |.......@..g.Q...|
  0010:  03 01                                            |..|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Get Configuration[0] Descriptor (9 bytes)
[0:1] Get Descriptor: 80 06 00 02 00 00 09 00 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 9
Transfer SUCCESS devaddr 01 ep:80 9 bytes, channel 6
on EP 80 with 9 bytes: OK
[0:1] Control data:
  0000:  09 02 54 00 03 01 04 A0 FA                       |..T......|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Get Configuration[0] Descriptor
[0:1] Get Descriptor: 80 06 00 02 00 00 54 00 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 84
Transfer SUCCESS devaddr 01 ep:80 84 bytes, channel 6
on EP 80 with 84 bytes: OK
[0:1] Control data:
  0000:  09 02 54 00 03 01 04 A0 FA 09 04 00 00 01 03 00  |..T.............|
  0010:  00 05 09 21 10 01 00 01 22 53 00 07 05 81 03 10  |...!...."S......|
  0020:  00 08 09 04 01 00 01 03 01 01 06 09 21 10 01 0D  |............!...|
  0030:  01 22 B6 00 07 05 82 03 10 00 08 09 04 02 00 01  |."..............|
  0040:  03 00 00 07 09 21 10 01 00 01 22 1B 00 07 05 85  |.....!....".....|
  0050:  03 40 00 02                                      |.@..|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Parsing Configuration descriptor (wTotalLength = 84)
[0:1] Interface 0: class = 3 subclass = 0 protocol = 0 is not supported
[0:1] Interface 1: class = 3 subclass = 1 protocol = 1 is not supported
[0:1] Interface 2: class = 3 subclass = 0 protocol = 0 is not supported
Set Configuration = 1
[0:1] Set Configuration: 00 09 01 00 00 00 00 00 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 0
Transfer SUCCESS devaddr 01 ep:80 0 bytes, channel 6
on EP 80 with 0 bytes: OK

Device configured
Device attached, address = 1
[0:1] Get Descriptor: 80 06 00 01 00 00 12 00 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 18
Transfer SUCCESS devaddr 01 ep:80 18 bytes, channel 6
on EP 80 with 18 bytes: OK
[0:1] Control data:
  0000:  12 01 00 02 00 00 00 40 AC 05 67 02 51 08 01 02  |.......@..g.Q...|
  0010:  03 01                                            |..|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Device 1: ID 05ac:0267
Device Descriptor:
  bLength             18
  bDescriptorType     1
  bcdUSB              0200
  bDeviceClass        0
  bDeviceSubClass     0
  bDeviceProtocol     0
  bMaxPacketSize0     64
  idVendor            0x05ac
  idProduct           0x0267
  bcdDevice           0851
  iManufacturer       1     [0:1] Get Descriptor: 80 06 01 03 09 04 00 01 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 256
Transfer SUCCESS devaddr 01 ep:80 22 bytes, channel 6
on EP 80 with 22 bytes: OK
[0:1] Control data:
  0000:  16 03 41 00 70 00 70 00 6C 00 65 00 20 00 49 00  |..A.p.p.l.e. .I.|
  0010:  6E 00 63 00 2E 00                                |n.c...|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Apple Inc.
  iProduct            2     [0:1] Get Descriptor: 80 06 02 03 09 04 00 01 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 256
Transfer SUCCESS devaddr 01 ep:80 30 bytes, channel 6
on EP 80 with 30 bytes: OK
[0:1] Control data:
  0000:  1E 03 4D 00 61 00 67 00 69 00 63 00 20 00 4B 00  |..M.a.g.i.c. .K.|
  0010:  65 00 79 00 62 00 6F 00 61 00 72 00 64 00        |e.y.b.o.a.r.d.|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

Magic Keyboard
  iSerialNumber       3     [0:1] Get Descriptor: 80 06 03 03 09 04 00 01 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 256
Transfer SUCCESS devaddr 01 ep:80 66 bytes, channel 6
on EP 80 with 66 bytes: OK
[0:1] Control data:
  0000:  24 03 46 00 4E 00 50 00 31 00 33 00 37 00 35 00  |$.F.N.P.1.3.7.5.|
  0010:  30 00 30 00 35 00 33 00 4A 00 31 00 59 00 35 00  |0.0.5.3.J.1.Y.5.|
  0020:  41 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00  |A.0.............|
  0030:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
  0040:  00 00                                            |..|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

FNP13750053J1Y5A0
  bNumConfigurations  1
[0:1] Get Descriptor: 80 06 00 02 00 00 00 01 
hcd_setup_send on pipe for devaddr:1 in slot 6, ep_type 0, len 8
Transfer SUCCESS devaddr 01 ep:00 8 bytes, channel 6
on EP 00 with 8 bytes: OK
hcd_edpt_xfer on pipe for devaddr:1 epaddr:80 in slot 6, ep_type 0, ep_dir 1, len 256
Transfer SUCCESS devaddr 01 ep:80 84 bytes, channel 6
on EP 80 with 84 bytes: OK
[0:1] Control data:
  0000:  09 02 54 00 03 01 04 A0 FA 09 04 00 00 01 03 00  |..T.............|
  0010:  00 05 09 21 10 01 00 01 22 53 00 07 05 81 03 10  |...!...."S......|
  0020:  00 08 09 04 01 00 01 03 01 01 06 09 21 10 01 0D  |............!...|
  0030:  01 22 B6 00 07 05 82 03 10 00 08 09 04 02 00 01  |."..............|
  0040:  03 00 00 07 09 21 10 01 00 01 22 1B 00 07 05 85  |.....!....".....|
  0050:  03 40 00 02                                      |.@..|
hcd_edpt_xfer on pipe for devaddr:1 epaddr:00 in slot 6, ep_type 0, ep_dir 0, len 0
Transfer SUCCESS devaddr 01 ep:00 0 bytes, channel 6
on EP 00 with 0 bytes: OK

  Open EP 81 with Size = 16
Opened pipe for devaddr:1 epaddr:81 in slot 0
[1] Claimed EP 0x81
  Queue EP 81 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:81 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Listen to [dev 1: ep 81]
  Open EP 82 with Size = 16
Opened pipe for devaddr:1 epaddr:82 in slot 0
[1] Claimed EP 0x82
  Queue EP 82 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:82 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Listen to [dev 1: ep 82]
  Open EP 85 with Size = 64
Opened pipe for devaddr:1 epaddr:85 in slot 0
[1] Claimed EP 0x85
  Queue EP 85 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:85 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Listen to [dev 1: ep 85]
Transfer SUCCESS devaddr 01 ep:81 3 bytes, channel 0
on EP 81 with 3 bytes: OK
[dev 1: ep 81] HID Report:
  90 03 04 
[1] Claimed EP 0x81
  Queue EP 81 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:81 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Transfer SUCCESS devaddr 01 ep:82 10 bytes, channel 0
on EP 82 with 10 bytes: OK
[dev 1: ep 82] HID Report:
  01 00 00 11 00 00 00 00 00 00 
[1] Claimed EP 0x82
  Queue EP 82 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:82 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Transfer SUCCESS devaddr 01 ep:82 10 bytes, channel 0
on EP 82 with 10 bytes: OK
[dev 1: ep 82] HID Report:
  01 00 00 00 00 00 00 00 00 00 
[1] Claimed EP 0x82
  Queue EP 82 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:82 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Transfer SUCCESS devaddr 01 ep:82 10 bytes, channel 0
on EP 82 with 10 bytes: OK
[dev 1: ep 82] HID Report:
  01 00 00 11 00 00 00 00 00 00 
[1] Claimed EP 0x82
  Queue EP 82 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:82 in slot 0, ep_type 3, ep_dir 1, len 64
OK
Transfer SUCCESS devaddr 01 ep:82 10 bytes, channel 0
on EP 82 with 10 bytes: OK
[dev 1: ep 82] HID Report:
  01 00 00 00 00 00 00 00 00 00 
[1] Claimed EP 0x82
  Queue EP 82 with 64 bytes ... 
hcd_edpt_xfer on pipe for devaddr:1 epaddr:82 in slot 0, ep_type 3, ep_dir 1, len 64
OK

[mjs513]

@AndrewCapon - nice job on getting TinyUSB working.

[KurtE]

@AndrewCapon - Sounds like you are making progress. Will be interesting to see where the TinyUSB goes. I have not played enough with it to know, how easy it is to add different things...

[AndrewCapon]

For the device side it is very easy to add devices, basically define the descriptors, call tud_task() in loop or from interrupt/rtos code. Then implement the callbacks you are interested in, there are quite a few examples here: https://github.com/hathach/tinyusb/tree/master/examples/device

The Host side is not that well developed though, not many boards are supported so not many examples to look at: https://github.com/hathach/tinyusb/tree/master/examples/host

We do have HID and MSC examples though but they are minimal.

I did help out a little a while ago with looking into hubs and multiple midi devices on the host side, this is now working for the PI Pico and finally made it into: https://github.com/rppicomidi/usb_midi_host

Getting this going on the GIGA properly though is a long term thing, I think the advantage of going this way is that there are a lot of people that know how TinyUSB works and not many that know how Arduino_USBHostMbed5 works! Also I think we have ISO support for hosts which is something I want, proper interrupt handling based on the interval, and I have really had enough banging my head against the wall with the Arduino_USBHostMbed5 code!

I am using a stm32h747 dev board and so far have got Audio and Midi devices going, the code to support TinyUSB host side on the stm32h747 (very basic, needs work), and an example simple host that basically just enumerates connected devices. I can see data coming in on this for a keyboard attached so the interrupt stuff is working but not any bulk data from midi devices so something wrong there. All this is very hacked together though.

So current plan is:

1. Get a clean STMCubeIDE project for testing with the code mentioned above. (working on now)
2. Get usb drive host support to test bulk.
3. See if this project runs on the GIGA and what needs changing.
4. Integrate it properly with the existing Arduino/MBED framework
5. Put the top level multi device/multi driver stuff I have been working on running on top of all of this.

[AndrewCapon]

So I have hit the same issue with the URB_NOTREADY/NAK madness using tinyusb as well.

It is more difficult to work around this with the TinyUSB host code as the resending is more difficult, and as we are seeing the same problem my same fix would probably also not work with all devices.

I'm going to give it all a rest for a while!

[KurtE]

@AndrewCapon @facchinm and all...

So I have hit the same issue with the URB_NOTREADY/NAK madness using tinyusb as well. ... I'm going to give it all a rest for a while!

Thanks for the update. Darn... I can totally understand the need to give it a rest.

Sorry, sometimes I get completely confused on some of this. That is like where the problem actually is.

For example, with the NAK madness. The thing I have run into with for example the Keyboard code sending a standard control msg back to the keyboard to update the LEDS. I have seen with the Teensy code, where the Keyboard maybe NAKs this several times, like in some cases10 to15, before it accepts it and returns an ACK. I believe that most/all of this is handled directly by the hardware. Also, the time between when the SETUP message is sent, and the data is sent is much quicker... In this code base with the STM32H7... there is a gap of time between when the SETUP and data are sent, and most of the time the data gets sent once, receives the NAK and then returns error code... Is this a configuration issue? Hardware Issue? Are there other implementations of the USB code for this hardware that works better? DMA?

I am also tempted to give this a break as well. May try a few more things with the GIGA and Portenta H7 before I find another diversion.

[AndrewCapon]

I think the problem is somewhere in the HAL implementation for the stm32h7.

I can understand the need to retry sends of data to devices (which I have for TinyUSB), if you look at the STM examples for example the mass media one then they retry on sends, the device wasn't ready so send again.

I can not understand having to retry receives from devices though, the STM examples so not do this. But what I am seeing is requests for data just constantly getting URB_NOTREADY and the data never arriving.

The issues I am seeing are on BULK, INTERRUPT and CONTROL seem to be working fine.

I'm going to take a fine tooth comb to the mass media example for sum with works fine and see exactly what they are doing...

[AndrewCapon]

One thing I have found out is that in the STM32 Cube code generator, if you set the USB up as OTG Host/Device it doesn't generate any code at all. It is just not supported!

[AndrewCapon]

So I have some more info after looking at the mass media STM example.

When waiting for data (URB_STATE != USBH_URB_DONE) ping messages are sent:

So for example when getting the product name:

HAL_HCD_HC_SubmitRequest ch_num = 0, direction = 0, type = 0, token = 0, length = 8, do_ping = 0
HAL_HCD_HC_SubmitRequest ch_num = 1, direction = 1, type = 0, token = 1, length = 255, do_ping = 0

HAL_HCD_HC_SubmitRequest ch_num = 0, direction = 0, type = 0, token = 1, length = 0, do_ping = 1
HAL_HCD_HC_SubmitRequest ch_num = 0, direction = 0, type = 0, token = 1, length = 0, do_ping = 1
HAL_HCD_HC_SubmitRequest ch_num = 0, direction = 0, type = 0, token = 1, length = 0, do_ping = 1
Product :  SanDisk 3.2Gen1

This as far as I can see in the non existent documentation is only for high speed devices and CONTROL and BULK endpoints.

Neither the Arduino_USBHostMbed5 or my TinyUSB code is doing this.

STM actually have a host system (above the HAL) that on first look didn't seem too bad, maybe we could use this I thought.

You can have multiple classes/drivers registered, it uses multiple state machines for all the various parts of the transfers, which in the end handle these pings.

It all looks great till you realise it doesn't support hubs, it is only single device :(

So my next thing to play with is to get this ping behaviour into the Arduino_USBHostMbed5 code.

So we will retry sends on CONTROL and BULK like we currently do. For receives we will use the ping.

Who knows maybe it will work...

[mjs513]

Wondering maybe thats why they went that way with USBhost_Giga?

[AndrewCapon]

Yep, not much use really :)

The ping stuff didn't make any difference.

Interestingly as well the ST mass media example splits the packets itself when dealing with BULK endpoints, so they do not use the underlying HAL large transfers, I guess there is a reason for this!

I took some time yesterday to make a little breakout board for the USB so now I can actually look at the packets on my analyser.

The issue with the TinyUSB stuff I have done is that the second time I try to read from the BULK EP it fails with the mad NAK nightmare.

So as an example using SCSI Test Unit Ready the first time:

write:

Then read:

All very nice, but the second time the write is the same, but the read looks like this:

This continues forever.

Banging my head against the wall trying to work out why!

[AndrewCapon]

Some good news.

With a lot of help from a guy on the ST forum I managed to get the mass storage going in TinyUSB.

There is an issue if the HAL USB system is inited as FS and you use a HS device, the packet splitting at the lower HAL level causes problems. Basically it seems the same as we were seeing with the Arduino_USBHostMbed5 mass storage with my changes in this PR.

This is an issue he has seen as well and he days it is with transfers > 256 bytes: so output BULK >256 bytes then read BULK > 256 bytes and it goes into NAK nightmare. So as the minimum sector size is 512 bytes for FAT it goes bang. The ST example code splits the transfers to multiple transfers based on the actual packet sizes so does not have this issue, I guess we know why now.

So tomorrow I will have a look at the way Arduino_USBHostMbed5 is initing the USB, maybe it is running it at FS which will be why the PR isn't working for mass storage, we will see!

[AndrewCapon]

Aha:

#elif defined(TARGET_GIGA) || defined(GIGA_PINS)
    hhcd->Instance = USB_OTG_HS;
    hhcd->Init.speed =  HCD_SPEED_FULL;
    hhcd->Init.phy_itface = USB_OTG_EMBEDDED_PHY;

[AndrewCapon]

So you want the bad news, or the bad news?

The embedded PHY on the stm32h7 is only FS, you need an external PHY for HS.

I cannot see that the GIGA has an external PHY.

[mjs513]

The embedded PHY on the stm32h7 is only FS, you need an external PHY for HS.

Saw this on the schematic and seems to indicate USB1 is HS.

[AndrewCapon]

It is HS capable but needs an external PHY.

The STM32H7 microcontroller embeds two instances of a USB HS peripheral (OTG_HS1 and OTG_HS2). Both support Full-Speed communication and OTG mode but only the OTG_HS1 peripheral supports High-Speed communication through an external HS PHY thanks to its ULPI interface.

[mjs513]

Thanks - not the little ligthbulb comes on and yeah - didn't see an external PHY on the schematic

[AndrewCapon]

Maybe there is one there somewhere, the documentation is woefull.

I tried enabling it when initing the HAL USB stuff and nothing works at all!

[KurtE]

The STM32H7 microcontroller embeds two instances of a USB HS peripheral (OTG_HS1 and OTG_HS2). Both support Full-Speed communication and OTG mode but only the OTG_HS1 peripheral supports High-Speed communication through an external HS PHY thanks to its ULPI interface.

Some of this gets confusing as some of the documentation shows like USB0 and USB1 and others 1 and 2... Also wondering if there are any differences in the Portenta hardware or not... Back to playing

[facchinm]

On Portenta, the USB on the USB-C connector is using the ULPI interface (via an external PHY) to reach real High Speed. The other USB (on high density connectors) is only FS.

On Giga, both port are Full Speed, with the one on USB-C being FS (to allow bootloader reflash via ROM loader DFU) and the other being FS-over-HS (in ST lingo, so it's just an FS at the end of the day)

[AndrewCapon]

Thanks @facchinm

[AndrewCapon]

So a bit more success here with tinyUSB.

There is definitely an issue with bulk out endpoint transfers > the packet size in the underlying HAL code, looking at the USB data it all looks good but the next time you do a bulk in endpoint transfer it starts to do the NAK nonsense.

As a test I split up the bulk out transfers to multiple calls to HAL_HCD_HC_SubmitRequest() and then we do not get the NAKS when we read from the in endpoint. The in endpoint is fine with transfers > packet size.

Interestingly the code I now have has no issues with needing to retry transfers for Bulk or Control, but if I also split the in EP transfers though then we get the failures we were originally seeing before this PR was put in with data going missing.

So it seems the way to get it working for everything in the HAL is:

For out endpoints always send data as <= packet size, repeating as needed. For in endpoints always read the full size of data.

This way everything works.

it seems to be to do with FS-over-HS, if using HS-over-HS then everything just works with full transfer sizes in both direction. I guess this is why we don't see the issue on the Portenta.

[KurtE]

Keeping fingers crossed that you find a workable solution. Then may experiment with some of the stuff we were playing with for the MBed... library

[AndrewCapon]

I have updated all my Arduino mbed stuff to the latest versions and am going to hopefully get a working solution for Arduino_USBHostMbed5 today, hopefully!

[AndrewCapon]

Ok, new code running.

The mass storage example fails:

Starting USB Dir List example...
Mounting USB device... done.
Open /usb/numbers2.txt
Writing numbers (0/10)
Writing numbers (1/10)
Writing numbers (2/10)
Writing numbers (3/10)
Writing numbers (4/10)
Writing numbers (5/10)
Writing numbers (6/10)
Writing numbers (7/10)
Writing numbers (8/10)
Writing numbers (9/10)
File closing
fclose error:I/O error (-5)Opening the root directory... Done
done.
Root directory:
0 files found!
Closing the root directory... OK

But is you flush the file before the close it works:

Starting USB Dir List example...
Mounting USB device... done.
Open /usb/numbers.txt
Writing numbers (0/10)
Writing numbers (1/10)
Writing numbers (2/10)
Writing numbers (3/10)
Writing numbers (4/10)
Writing numbers (5/10)
Writing numbers (6/10)
Writing numbers (7/10)
Writing numbers (8/10)
Writing numbers (9/10)
File flushing
File closing
File closed
Opening the root directory... Done
done.
Root directory:
    SanDiskSecureAccessV3.1_win.exe
    SanDiskSecureAccess
    Back Up Your Files to the Cloud.pdf
    crap.txt
    development
    scripts
    test1.img
    net.sh
    k3-j721e-beagleboneai64.dtb
    .Spotlight-V100
    USBHOST.TXT
    net2.sh
    moddwarf
    USBHostLi
    applicat.ion
    .fseventsd
    ._net.sh
    crap1.txt
    numbers2.txt
    numbers.txt
20 files found!
Closing the root directory... OK

Very strange!

I'm going to test some other devices...

[mjs513]

Indeed very strange but doesn;t surprise me. But at an rate sounds like you made real progress !!!!! Congrats.

[AndrewCapon]

Yep very strange, both cases seem to be sending the same USB stuff, maybe a timing issue.

I did also test the mass storage with the old code and the flush and it fails, so something at least is better!

I tested MIDI devices and they are working, whoopee. no more of that retry code needed :)

Interrupt devices are not working though, so I have broken something there.

Will look later...

[AndrewCapon]

Ok, I have a branch that looks pretty good I think: https://github.com/AndrewCapon/Arduino_USBHostMbed5/tree/fs_over_hs

Maybe you guys could give it a go and try to break it.

I will have a look at the fflush()/fclose() tomorrow, in the meantime if you do a fflush() before fclose() then the mass storage stuff should all work.

[mjs513]

Morning Andrew Downloaded your updated branch last and seems to be working at least for the joysticks I tried it with: DS4 and the XBOX360(wireless) ones.

Tried using a hub with 2 joysticks attached but always loose the first one before it starts to send data but think thats a hub issue.

I also tried the serial GPS one (serial-serial) and that seemed to work for me.

So at least it break the joystick stuff. :)