MTP Responder Contribution

[KurtE]

@... - Hopefully not stepping on any toes here,

But thinking of trying to rework the USB2 library for T4... To be more like the newer version of RAWHID stuff.

In particular the current code only has one RX and one TX transfer object where as the RAWHID has 4, and I know from some of the previous work I did with USBHost stuff, that we ran into issues like hangs or the like when we would receive something and not have another buffer active when more data is coming in...

So will try to implement that and see if it changes the issue on larger files.

[mjs513]

@... - Hopefully not stepping on any toes here,

But thinking of trying to rework the USB2 library for T4... To be more like the newer version of RAWHID stuff.

In particular the current code only has one RX and one TX transfer object where as the RAWHID has 4, and I know from some of the previous work I did with USBHost stuff, that we ran into issues like hangs or the like when we would receive something and not have another buffer active when more data is coming in...

So will try to implement that and see if it changes the issue on larger files.

Are you talking about USB1_mtp.c or USB2_mtp.c. Never thought of looking there to be honest - you made me look

Anyway USB1 I see TX_NUM = 1 and RX_NUM = 1, while is USB2 looks like its TX_Num = 4, and I think only 1 rx buffer of 512 bytes. Might have to do some rework on both if you go down that path which knowing you...

[KurtE]

USB1 is the one I think right now that is used for IMXRT so that is the rabbit hole I am trying right now.

Assuming that it works and helps, may have to go down the other Rabbit hole

What I remember from earlier with RAWHID was that it would hang at times if you did a receive and while the receive was busy it received something else like the continuation of the data and you had no pending receive transfers it would hang... Turns out I was the one who changed it in Rawhid to match what Paul did with Seremu.... Back in March... Also moved buffers to DMAMEM and ...

So will try to make same changes here.

[WMXZ]

Are you talking about USB1_mtp.c or USB2_mtp.c. Never thought of looking there to be honest - you made me look

Anyway USB1 I see TX_NUM = 1 and RX_NUM = 1, while is USB2 looks like its TX_Num = 4, and I think only 1 rx buffer of 512 bytes. Might have to do some rework on both if you go down that path which knowing you...

It is USB1 for T4.1 main USB.
The USB2 is for USBHS on T3.6 (Yes, I did use 2nd USB on T3.6 as a USB device and not only as USB Host)
The TX/RM numbers were the result of long testing, i,e. I could not get the buffered USB working, so I went back to single buffer mode, but is should be easy to paly with multiple buffers

[WMXZ]

So will try to make same changes here.

You have definitely more knowledge on USB than I have. Feel free to rewrite the code.

[WMXZ]

Got moving directories working (both within a disk and cross disks)
Github updated

[Frank B]

Wmxz, great!

[Frank B]

    writestring(MTP_VERS);      // version
    char buf[16];
    #if defined(__IMXRT1062__)
      uint32_t num = (HW_OCOTP_MAC0 & 0xFFFFFF);
      ultoa(num, buf, 10);
    #else
      uint32_t num=1234567;
      ultoa(num, buf, 10);
    #endif

Any reason why you did it this way, and not just re-use the already existing sernum?

[WMXZ]

Any reason why you did it this way, and not just re-use the already existing sernum?

because I did not see your PR yet

Anyhow, gives this Warning

C:\Users\zimmer\Documents\Arduino\libraries/MTP_t4/src/MTP.cpp: In member function 'void MTPD::WriteDescriptor()':
C:\Users\zimmer\Documents\Arduino\libraries/MTP_t4/src/MTP.cpp:239:76: warning: array subscript is above array bounds [-Warray-bounds]
     for (size_t i=0; i<10; i++) buf[i] = usb_string_serial_number.wString[i];

[mjs513]

Got moving directories working (both within a disk and cross disks)
Github updated

That's really great news now to do some testing. See below

Move directories and structure between storage areas: Works but doens't work. Tested moving directory between SPIFlash and QSPI.
a. move directory from QPSI to SPIFlash: Directory moved but when you open the directory on SPIFlash shows empty folder. If I recycle power and open the directory, file was moved and if I open the file the contents is correct.
b. If i move the directory on QSPI to the Builtin SD card it works. Directory created along with contents and file contents correct.
c. If I try to move the directory from the SD card to SPIFlash I get the infamous window dong. If i reset the chip the directory will move with the same results as identified in (a). This time I did the disable/enable in Device Manager(and it worked) to refresh the Teensy

[KurtE]

Morning all, @WMXZ - great will have to test.

I am still playing around with the underlying USB1 stuff and have the multiple RX implemented, but it still is not helping with the copying long files to propshield and at times my QSPI.

It appears like if the file transfer takes over some period of time somewhere around half second, and windows brings up progress window and is not done then, it will error out. Not sure if there is some other IO IOCTL like thing that windows will send asking about progress or if it just knows when the target has transferred each USB packet or???

Will update with LA output showing it. On Propshield and QSPI it appear like the write operations are running real slow. I will instrument that one as well.

One question to myself (maybe not completely the right thread), is should LittleFS be updated some to speed up operations like the program block... Should any of these operations be setup to use DMA?

[mjs513]

Morning @KurtE
In my latest iteration of my test sketch I changed the clock on QSPI to 132 Mhz and haven't seen any issues with copying files. Maybe give it a try with the higher speed clock

As for the propshield, I ordered some W25Q64FV chips so I could put one on a breakout board. Why, just had to be sure its not something with my propshield. Won't get them until tonight so will probably test that tomorrow. Why did I do this, I ran a quick test with SerialFlash yesterday and the CopyfromSDcard sketch failed to copy files to the propshield flash.

Tried changing the SPI clock to see if it would help the propshield but that didn't help either.

[KurtE]

Morning again all,

For the fun of it, I have been playing around with some more instrumented version of the MTP code... And for example with a hook up such as MTP test minus the extra WinBond:

I copied a 167KB file to several of the different logical drives under Teensy to get an idea of timin:
For example To RAM1: LittleFS

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 98: 3 ffffffff f
100d 12 1 99: 5 dc04 c7e6eb2c
100d 171232 2 99: e0ffd8ff 464a1000 1004649
a 170720 500 0 12 500 0
a 170208 1012 0 0 512 0
a 169696 1524 0 0 512 0
a 169184 2036 0 0 512 0
a 168672 2548 0 0 512 0
a 168160 3060 0 0 512 0
a 167648 3572 0 0 512 0
a 167136 4084 0 0 512 0
a 167124 4096 500 0 12 0
  SW: 4096!
b 166624 500 500 0 12 1
a 166112 1012 0 0 512 0
a 165600 1524 0 0 512 0
a 165088 2036 0 0 512 0
a 164576 2548 0 0 512 0
a 164064 3060 0 0 512 0
a 163552 3572 0 0 512 0
a 163040 4084 0 0 512 0
a 163028 4096 500 0 12 0
  SW: 4096!
b 162528 500 500 0 12 1
a 162016 1012 0 0 512 0
a 161504 1524 0 0 512 0
a 160992 2036 0 0 512 0
a 160480 2548 0 0 512 0
a 159968 3060 0 0 512 0
a 159456 3572 0 0 512 0
a 158944 4084 0 0 512 0
a 158932 4096 500 0 12 0
  SW: 4096!
b 158432 500 500 0 12 1
  SW: 4096!
b 154336 500 500 0 12 1
  SW: 4096!
b 150240 500 500 0 12 0
  SW: 4096!
b 146144 500 500 0 12 0
  SW: 4096!
b 142048 500 500 0 12 1
  SW: 4096!
...
a 7392 4084 0 0 512 0
a 7380 4096 500 0 12 0
  SW: 4096!
b 6880 500 500 0 12 1
a 6368 1012 0 0 512 0
a 5856 1524 0 0 512 0
a 5344 2036 0 0 512 0
a 4832 2548 0 0 512 0
a 4320 3060 0 0 512 0
a 3808 3572 0 0 512 0
a 3296 4084 0 0 512 0
a 3284 4096 500 0 12 0
  SW: 4096!
b 2784 500 500 0 12 1
a 2272 1012 0 0 512 0
a 1760 1524 0 0 512 0
a 1248 2036 0 0 512 0
a 736 2548 0 0 512 0
a 224 3060 0 0 512 0
a 0 3284 0 0 224 0
len 3284
  SW: 3284!
SCL - startSCL - complete
2001 12 3 99: 5 5d019a0a a4fce3a4

Sorry for the length I believe the printf lines for a and b lines code is in the current sources but commented out. I added delta time in millis as the last bit of data on each of these lines and you can see all of the a) are typically 0 and b) 1....

I did again for the QSPI on this board: LittleFS
The timings are a lot slower:

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 262: 5 ffffffff 22
100d 12 1 263: 10 dc04 b620239a
100d 171232 2 263: e0ffd8ff 464a1000 1004649
b 166624 500 500 0 12 58
b 162528 500 500 0 12 96
b 158432 500 500 0 12 49
b 154336 500 500 0 12 53
b 150240 500 500 0 12 53
b 146144 500 500 0 12 49
b 142048 500 500 0 12 51
b 137952 500 500 0 12 52
b 133856 500 500 0 12 51
b 129760 500 500 0 12 49
b 125664 500 500 0 12 49
b 121568 500 500 0 12 53
b 117472 500 500 0 12 49
b 113376 500 500 0 12 51
b 109280 500 500 0 12 52
b 105184 500 500 0 12 49
b 101088 500 500 0 12 53
b 96992 500 500 0 12 52
b 92896 500 500 0 12 51
b 88800 500 500 0 12 50
b 84704 500 500 0 12 49
b 80608 500 500 0 12 51
b 76512 500 500 0 12 50
b 72416 500 500 0 12 49
b 68320 500 500 0 12 50
b 64224 500 500 0 12 51
b 60128 500 500 0 12 52
b 56032 500 500 0 12 51
b 51936 500 500 0 12 52
b 47840 500 500 0 12 51
b 43744 500 500 0 12 53
b 39648 500 500 0 12 51
b 35552 500 500 0 12 50
b 31456 500 500 0 12 49
b 27360 500 500 0 12 49
b 23264 500 500 0 12 49
b 19168 500 500 0 12 50
b 15072 500 500 0 12 51
b 10976 500 500 0 12 52
b 6880 500 500 0 12 51
b 2784 500 500 0 12 52
len 3284
SCL - startSCL - complete

I believe the next one I went to was SPI0 which is faster then the QSPI? SDFAT

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 412: 2 ffffffff 34
100d 12 1 413: 2e dc04 57371595
100d 171232 2 413: e0ffd8ff 464a1000 1004649
b 166624 500 500 0 12 3
b 162528 500 500 0 12 4
b 158432 500 500 0 12 5
b 154336 500 500 0 12 4
b 150240 500 500 0 12 4
b 146144 500 500 0 12 5
b 142048 500 500 0 12 4
b 137952 500 500 0 12 5
b 133856 500 500 0 12 5
b 129760 500 500 0 12 5
b 125664 500 500 0 12 5
b 121568 500 500 0 12 6
b 117472 500 500 0 12 5
b 113376 500 500 0 12 5
b 109280 500 500 0 12 6
b 105184 500 500 0 12 6
b 101088 500 500 0 12 6
b 96992 500 500 0 12 3
b 92896 500 500 0 12 4
b 88800 500 500 0 12 4
b 84704 500 500 0 12 3
b 80608 500 500 0 12 4
b 76512 500 500 0 12 4
b 72416 500 500 0 12 4
b 68320 500 500 0 12 4
b 64224 500 500 0 12 4
b 60128 500 500 0 12 4
b 56032 500 500 0 12 4
b 51936 500 500 0 12 4
b 47840 500 500 0 12 5
b 43744 500 500 0 12 4
b 39648 500 500 0 12 5
b 35552 500 500 0 12 5
b 31456 500 500 0 12 5
b 27360 500 500 0 12 5
b 23264 500 500 0 12 6
b 19168 500 500 0 12 5
b 15072 500 500 0 12 6
b 10976 500 500 0 12 6
b 6880 500 500 0 12 6
b 2784 500 500 0 12 5
len 3284

Then I tried the SDIO which is sort of interesting in that a lot of them were faster and every so many it took longer time... But still faster....
SDFAT

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 777: 1 ffffffff 61
100d 12 1 778: 35 dc04 24060592
100d 171232 2 778: e0ffd8ff 464a1000 1004649
b 166624 500 500 0 12 1
b 162528 500 500 0 12 0
b 158432 500 500 0 12 1
b 154336 500 500 0 12 0
b 150240 500 500 0 12 1
b 146144 500 500 0 12 0
b 142048 500 500 0 12 0
b 137952 500 500 0 12 10
b 133856 500 500 0 12 0
b 129760 500 500 0 12 1
b 125664 500 500 0 12 0
b 121568 500 500 0 12 1
b 117472 500 500 0 12 0
b 113376 500 500 0 12 0
b 109280 500 500 0 12 0
b 105184 500 500 0 12 1
b 101088 500 500 0 12 0
b 96992 500 500 0 12 0
b 92896 500 500 0 12 0
b 88800 500 500 0 12 0
b 84704 500 500 0 12 0
b 80608 500 500 0 12 0
b 76512 500 500 0 12 1
b 72416 500 500 0 12 11
b 68320 500 500 0 12 0
b 64224 500 500 0 12 0
b 60128 500 500 0 12 1
b 56032 500 500 0 12 0
b 51936 500 500 0 12 1
b 47840 500 500 0 12 0
b 43744 500 500 0 12 0
b 39648 500 500 0 12 0
b 35552 500 500 0 12 0
b 31456 500 500 0 12 0
b 27360 500 500 0 12 0
b 23264 500 500 0 12 1
b 19168 500 500 0 12 0
b 15072 500 500 0 12 0
b 10976 500 500 0 12 0
b 6880 500 500 0 12 12
b 2784 500 500 0 12 0
len 3284
SCL - startSCL - complete

And then went to propshield which in this case is just slightly slower than my QSPI flash. LittleFS

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 789: 4 ffffffff 62
100d 12 1 790: 61 dc41 b620239a
100d 171232 2 790: e0ffd8ff 464a1000 1004649
b 166624 500 500 0 12 66
b 162528 500 500 0 12 104
b 158432 500 500 0 12 57
b 154336 500 500 0 12 57
b 150240 500 500 0 12 57
b 146144 500 500 0 12 57
b 142048 500 500 0 12 57
b 137952 500 500 0 12 57
b 133856 500 500 0 12 57
b 129760 500 500 0 12 57
b 125664 500 500 0 12 57
b 121568 500 500 0 12 57
b 117472 500 500 0 12 57
b 113376 500 500 0 12 57
b 109280 500 500 0 12 56
b 105184 500 500 0 12 56
b 101088 500 500 0 12 56
b 96992 500 500 0 12 55
b 92896 500 500 0 12 54
b 88800 500 500 0 12 56
b 84704 500 500 0 12 55
b 80608 500 500 0 12 56
b 76512 500 500 0 12 56
b 72416 500 500 0 12 56
b 68320 500 500 0 12 56
b 64224 500 500 0 12 60
b 60128 500 500 0 12 56
b 56032 500 500 0 12 56
b 51936 500 500 0 12 56
b 47840 500 500 0 12 57
b 43744 500 500 0 12 56
b 39648 500 500 0 12 57
b 35552 500 500 0 12 56
b 31456 500 500 0 12 57
b 27360 500 500 0 12 56
b 23264 500 500 0 12 57
b 19168 500 500 0 12 56
b 15072 500 500 0 12 56
b 10976 500 500 0 12 56
b 6880 500 500 0 12 57
b 2784 500 500 0 12 56
len 3284
SCL - startSCL - complete

Next up I will swap in the beta board that should have similar PSRAM/FLASH...

[KurtE]

For what it is worth I removed the T4.1 from breadboard and put in the original Beta version which should have the same FLASH chip...

reran the same program... And the QSPI is faster...

SCR: Teensy-TTL-Level_converters.jpg
2001 24 3 154: 5 ffffffff 2f
100d 12 1 155: 28 dc03 ffffffff
100d 171232 2 155: e0ffd8ff 464a1000 1004649
b 166624 500 500 0 12 35
b 162528 500 500 0 12 61
b 158432 500 500 0 12 31
b 154336 500 500 0 12 33
b 150240 500 500 0 12 32
b 146144 500 500 0 12 32
b 142048 500 500 0 12 32
b 137952 500 500 0 12 31
b 133856 500 500 0 12 31
b 129760 500 500 0 12 33
b 125664 500 500 0 12 32
b 121568 500 500 0 12 31
b 117472 500 500 0 12 34
b 113376 500 500 0 12 33
b 109280 500 500 0 12 35
b 105184 500 500 0 12 34
b 101088 500 500 0 12 33
b 96992 500 500 0 12 34
b 92896 500 500 0 12 32
b 88800 500 500 0 12 31
b 84704 500 500 0 12 32
b 80608 500 500 0 12 31
b 76512 500 500 0 12 32
b 72416 500 500 0 12 34
b 68320 500 500 0 12 34
b 64224 500 500 0 12 33
b 60128 500 500 0 12 31
b 56032 500 500 0 12 34
b 51936 500 500 0 12 33
b 47840 500 500 0 12 31
b 43744 500 500 0 12 31
b 39648 500 500 0 12 31
b 35552 500 500 0 12 32
b 31456 500 500 0 12 33
b 27360 500 500 0 12 32
b 23264 500 500 0 12 34
b 19168 500 500 0 12 32
b 15072 500 500 0 12 31
b 10976 500 500 0 12 33
b 6880 500 500 0 12 34
b 2784 500 500 0 12 32
len 3284

The newer one averages maybe 55-60ms and this one maybe 32?

Wonder if I need to do a third one? I do have another T4.1 and Paul included a few of the Flash which look the same and have the same part number marked on them?

EDIT: I should have mentioned right now I am trying it with 4K instead of 8K per write. No difference other than half the time in write...
And if you are curious I also instrumented some of the lower level stuff in the USB1 file to see when things are called
digitalWriteFast digitalToggleFast...

Note the top line when high is when the code is within the file write to the propshield... the next lines down are when it is receiving data. from the USB.
easier to see in the closeup image below. Next line is actually when the RX callback is called and the next line is when we call read to get the data. Again in this test I have multiple RX transfers and so you can see they are all being filled up ...


Yet another edit:
I changed my startup.c timing:

	CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_FLEXSPI2_PODF_MASK | CCM_CBCMR_FLEXSPI2_CLK_SEL_MASK))
		| CCM_CBCMR_FLEXSPI2_PODF(4) | CCM_CBCMR_FLEXSPI2_CLK_SEL(3); // 88 MHz

b 166624 500 500 0 12 31
b 162528 500 500 0 12 53
b 158432 500 500 0 12 30
b 154336 500 500 0 12 32
b 150240 500 500 0 12 30
b 146144 500 500 0 12 30
b 142048 500 500 0 12 30
b 137952 500 500 0 12 29
b 133856 500 500 0 12 30
b 129760 500 500 0 12 30
b 125664 500 500 0 12 29
b 121568 500 500 0 12 31
b 117472 500 500 0 12 30
b 113376 500 500 0 12 30
b 109280 500 500 0 12 32
b 105184 500 500 0 12 29
b 101088 500 500 0 12 29
b 96992 500 500 0 12 30
b 92896 500 500 0 12 29
b 88800 500 500 0 12 31
b 84704 500 500 0 12 30
b 80608 500 500 0 12 30
b 76512 500 500 0 12 31
b 72416 500 500 0 12 30
b 68320 500 500 0 12 29
b 64224 500 500 0 12 29
b 60128 500 500 0 12 29
b 56032 500 500 0 12 31
b 51936 500 500 0 12 30
b 47840 500 500 0 12 30
b 43744 500 500 0 12 30
b 39648 500 500 0 12 29
b 35552 500 500 0 12 31
b 31456 500 500 0 12 30
b 27360 500 500 0 12 30
b 23264 500 500 0 12 33
b 19168 500 500 0 12 30
b 15072 500 500 0 12 30
b 10976 500 500 0 12 29
b 6880 500 500 0 12 29
b 2784 500 500 0 12 29

Timing on the original slightly faster. I believe @mjs513 you went to a 3... I have done that before and sometimes the PSRAM was not found...
Also with the order I had the FLASH says: IC FLASH 1G SPI 104MHZ 8WSON

OOPS put the wrong one up here: IC FLASH 128M SPI 133MHZ 8SOIC

Back to playing

[mjs513]

Morning again
Well just soldered up another T4.1 with Flash and PSRAM. Ran MTP responder and all seems well especially after I put some files on the chips on the flash. Don't have your mods for timing to check though to compare with yours.

For laughs I did solder up a W25N01G flash to a breakout board and was able to read the JedecID from the chip at a SPI Clock of 75Mhz. Maybe will play some more with is as a serial chip at some point

[KurtE]

My changes are pretty simple for the timings:

    void MTPD::SendObject() 
    { 
      pull_packet(rx_data_buffer);
      printContainer(); 

      read(0,0);
      uint32_t len = ReadMTPHeader();
      uint32_t index = sizeof(MTPHeader);
      disk_pos=0;
      
      while((int)len>0)
      { 
        uint32_t start_time = millis();
        uint32_t bytes = MTP_RX_SIZE - index;                     // how many data in usb-packet
        bytes = min(bytes,len);                                   // loimit at end
        uint32_t to_copy=min(bytes, DISK_BUFFER_SIZE-disk_pos);   // how many data to copy to disk buffer
        memcpy(disk_buffer+disk_pos, rx_data_buffer + index,to_copy);
        disk_pos += to_copy;
        bytes -= to_copy;
        len -= to_copy;
        printf("a %d %d %d %d %d %u\n", len,disk_pos,bytes,index,to_copy,  millis()-start_time);
        //
        if(disk_pos==DISK_BUFFER_SIZE)
        {
          storage_->write((const char *)disk_buffer, DISK_BUFFER_SIZE);
          disk_pos =0;

          if(bytes) // we have still data in transfer buffer, copy to initial disk_buffer
          {
            memcpy(disk_buffer,rx_data_buffer+index+to_copy,bytes);
            disk_pos += bytes;
            len -= bytes;
          }
          printf("b %d %d %d %d %d %u\n", len,disk_pos,bytes,index,to_copy, millis()-start_time);
        }
        if(len>0)  // we have still data to be transfered
        { pull_packet(rx_data_buffer);
          index=0;
        }
      }
      printf("len %d\n",disk_pos);
      if(disk_pos)
      {
        storage_->write((const char *)disk_buffer, disk_pos);
      }
      storage_->close();
    }

Most of these were simply uncommenting existing lines. I then just added the millis() stuff to get some timings.
Note: I changed the writes to 4kb instead of 8kb in my previous timings. I have since then removed that change.

[WMXZ]

Got copy functionality working, but is all but useful.
While copying if files and directories work, they show up on Windows file explorer only after disable/enable sequence.
Github updated

If we only would be able to implement events then responder could signal PC that storage is invalidated and rescan.
When implementing USB2 I spent some time for events, but PC never responded, so I gave up.

[Frank B]

There is a MTP Compliencetest in the Windows Hardware Lab Kit
https://docs.microsoft.com/de-de/win...e-5b6ccab11f0f
Maybe it is useful and can give some insights(?)

[defragster]

There is a MTP Compliencetest in the Windows Hardware Lab Kit
https://docs.microsoft.com/de-de/win...e-5b6ccab11f0f
Maybe it is useful and can give some insights(?)

Nice, and the English non translated version :: docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/bbfe7dc4-8ccf-4d8d-b68e-5b6ccab11f0f

[mjs513]

Got copy functionality working, but is all but useful.
While copying if files and directories work, they show up on Windows file explorer only after disable/enable sequence.
Github updated

If we only would be able to implement events then responder could signal PC that storage is invalidated and rescan.
When implementing USB2 I spent some time for events, but PC never responded, so I gave up.

Same thing happens when you do a move directory as I mentioned. Guess events is on the todo list

[WMXZ]

Nice, and the English non translated version :: docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/bbfe7dc4-8ccf-4d8d-b68e-5b6ccab11f0f

And how does it work?
Downloaded SW and now?
Have difficulties to follow the WorldWideLinks os MS documentations.

[KurtE]

Same thing happens when you do a move directory as I mentioned. Guess events is on the todo list

I was wondering working with USB1 stuff if there was some form of event mechanism. I see there is some form of it in the USB2 stuff, so I am playing with it.

UP till now I was just playing with the code and not looking too much at documentation. But finally downloaded a USB Document on some of this:
I think I retrieved it from: https://www.usb.org/sites/default/files/MTPv1_1.zip

I was also browsing through some other documents on line, which were about specific implementations. Like:
https://hcc-embedded.com/uploads/201...de%20v1_40.pdf

But so far I know nothing... But will try playing around

[Frank B]

And how does it work?

Don't know.

[KurtE]

@WMXZ and @Paul (and all) - Looking at the USB2 events stuff and trying to figure out how events should work... What I am wondering and need probably to reread some sections of documents. is how the Events stuff should work? with MTP. Some of the current configuration sort of confuses me.

Sorry if this message reflects my confusion.

For my own rambling, I think I need to talk about it in two parts:

a) How the Host sends EVENTS to the Teensy (MTP).
b) How the Teensy sends Events to the HOST.

And how and which endpoints are involved with these two cases. Again remember I know just enough to be dangerous.

But when I look in usb2_desc.c I see the MTP interface defined as:

#ifdef USB2_MTP_INTERFACE
        // interface descriptor, USB spec 9.6.5, page 267-269, Table 9-12
        9,                                      // bLength
        4,                                      // bDescriptorType
        USB2_MTP_INTERFACE,                          // bInterfaceNumber
        0,                                      // bAlternateSetting
        3,                                      // bNumEndpoints
        0x06,                                   // bInterfaceClass (0x06 = still image)
        0x01,                                   // bInterfaceSubClass
        0x01,                                   // bInterfaceProtocol
        4,                                      // iInterface
        // endpoint descriptor, USB spec 9.6.6, page 269-271, Table 9-13
        7,                                      // bLength
        5,                                      // bDescriptorType
        USB2_MTP_TX_ENDPOINT | 0x80,                 // bEndpointAddress
        0x02,                                   // bmAttributes (0x02=bulk)
        LSB(USB2_MTP_TX_SIZE_480),MSB(USB2_MTP_TX_SIZE_480),   // wMaxPacketSize
        0,                                      // bInterval
        // endpoint descriptor, USB spec 9.6.6, page 269-271, Table 9-13
        7,                                      // bLength
        5,                                      // bDescriptorType
        USB2_MTP_RX_ENDPOINT,                        // bEndpointAddress
        0x02,                                   // bmAttributes (0x02=bulk)
        LSB(USB2_MTP_RX_SIZE_480),MSB(USB2_MTP_RX_SIZE_480),   // wMaxPacketSize
        0,                                      // bInterval
        // endpoint descriptor, USB spec 9.6.6, page 269-271, Table 9-13
        7,                                      // bLength
        5,                                      // bDescriptorType
        USB2_MTP_EVENT_ENDPOINT | 0x80,              // bEndpointAddress
        0x03,                                   // bmAttributes (0x03=intr)
        USB2_MTP_EVENT_SIZE, 0,                      // wMaxPacketSize
        USB2_MTP_EVENT_INTERVAL,                     // bInterval
#endif // MTP_INTERFACE

It has an Event endpoint defined, which I show in RED:

When I read this, I take it that as the 0x80 bit is set end point, that it is a TX end point, and likewise I believe that Interrupt end points are unidirectional. Again could be wrong, but I also get that impression from documents like: https://www.beyondlogic.org/usbnutshell/usb4.shtml

So I am not sure if the usb2_mtp_configure that tries to setup that end point for two different types of transfers:

	usb2_config_rx(MTP_EVENT_ENDPOINT, MTP_EVENT_SIZE, 0, rx_event_event);
	usb2_config_tx(MTP_EVENT_ENDPOINT, MTP_EVENT_SIZE, 0, tx_event_event);

Again I could be completely wrong here. But assuming that this is a TX end point, not sure if the RX has a different end point? Or does it receive data over the control end point?
May be interesting to look at another device that does MTP... And see how it is defined...

Now back to experimenting.

EDIT: I plugged in an older Kindle Fire I have into an RPI4, and looked at how it was configured.

ubuntu@ubuntu:~$ lsusb -v -d 1949:000c

Bus 001 Device 005: ID 1949:000c Lab126, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x1949 Lab126, Inc.
  idProduct          0x000c
  bcdDevice            2.32
  iManufacturer           1 Android
  iProduct                2 Android
  iSerial                 3 D0FCA0A0342600M6
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol      0
      iInterface              4 MTP
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x001c  1x 28 bytes
        bInterval               6
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000002
      HIRD Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000f
      Device can operate at Low Speed (1Mbps)
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat           1 micro seconds
    bU2DevExitLat         500 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

And it shows the third Endpoint as IN as well.

EDIT2: I tried same with an IPAD, but it does not show it supports MTP, it does support PTP

[WMXZ]

@KurtE
IIRC USB2 is for Teensy 3.6 2nd USB (your USB-host becoming USB-device)
Maybe you are using MTP over USBHS ?
for T4 it is USB1