Teensyduino File System Integration, including MTP and MSC

Observations, about differences between running MTP on Windows versus Ubuntu:

In this case running on T4.1 with MTP_Teensy -> Simple example, I have prop shield simple plugged in to it (sort of... 3 rails)
Note the 32gb SD Card I plugged in, has a copy of MTP_Teensy github on it... (that is I copied the github project to it) so I could try out some files on Ubuntu...

So, when I plugged this into Ubuntu (actually programmed it here), and the program launches I noticed the debug output showing a lot of stuff... If I do the '1' command you see:
Code:
Dump Storage list(4)
store:0 storage:10001 name:RAM fs:20005684
store:1 storage:20001 name:SD_Card fs:20004f24
store:2 storage:30001 name:Program fs:200055b8
store:3 storage:40001 name:SPI Flash fs:200054d4

Dump Index List
0: 0 1 1 -1 0 20 0 0 /
1: 1 1 1 -1 0 23 0 0 /
2: 2 1 1 -1 0 0 0 0 /
3: 3 1 1 -1 0 25 0 0 /
20: 0 0 0 0 0 0 1637390360 1637390360 mtpindex.dat
21: 1 0 0 1 0 22014452 1637313900 1637313906 LargeIndexedTestfile.txt
22: 1 1 1 1 21 35 1637302974 1637302976 System Volume Information
23: 1 1 1 1 22 33 1637303014 1632801936 MTP_Teensy
24: 3 0 0 3 0 115712 1546300932 1546300932 Screenshot from 2021-09-11 05-46-25.png
25: 3 0 0 3 24 113777 1546300939 1546300939 Screenshot from 2021-09-11 05-47-49.png
26: 1 0 0 23 0 66 1637303014 1632801578 .gitattributes
27: 1 0 0 23 26 47 1637303014 1632803648 .gitignore
28: 1 0 0 23 27 343 1637303014 1632802278 library.properties
29: 1 0 0 23 28 1113 1637303014 1632803784 LICENSE
30: 1 0 0 23 29 2498 1637303014 1632804752 README.md
31: 1 1 1 23 30 70 1637303014 1637231246 .git
32: 1 1 1 23 31 56 1637303044 1637210510 examples
33: 1 1 1 23 32 39 1637303046 1635684012 src
34: 1 0 0 22 0 12 1637302974 1637302976 WPSettings.dat
35: 1 0 0 22 34 76 1637302974 1637302976 IndexerVolumeGuid
36: 1 0 0 33 0 31374 1637303046 1636801596 MTP_Storage.cpp
37: 1 0 0 33 36 6570 1637303046 1634822652 MTP_Storage.h
38: 1 0 0 33 37 103975 1637303046 1637296668 MTP_Teensy.cpp
39: 1 0 0 33 38 7736 1637303046 1637054242 MTP_Teensy.h
40: 1 1 1 32 0 106 1637303044 1636440586 Bogus_MTP-logger
41: 1 1 1 32 40 103 1637303044 1634539842 format_timeout_test
42: 1 1 1 32 41 101 1637303044 1633671138 LFS_Program_MTP_Simple_Datalogger
43: 1 1 1 32 42 99 1637303044 1632804262 LFS_SPI_MTP_Simple_Datalogger
44: 1 1 1 32 43 97 1637303044 1632804262 LittleFS_Program_Simple_Datalogger-dates
45: 1 1 1 32 44 96 1637303044 1633670454 mtp-logger
46: 1 1 1 32 45 94 1637303044 1635593124 mtp-test
47: 1 1 1 32 46 90 1637303044 1632804262 SD_MTP-logger
48: 1 1 1 32 47 88 1637303044 1633672242 SD_Program_MTP-logger
49: 1 1 1 32 48 86 1637303044 1634552344 SD_Program_SPI_QSPI_MTP-logger
50: 1 1 1 32 49 83 1637303044 1635745786 SD_SPI_QSPI_MTP-logger
51: 1 1 1 32 50 81 1637303044 1633669952 simple
52: 1 1 1 32 51 79 1637303044 1634552344 simple_t41_qflash
53: 1 1 1 32 52 78 1637303044 1634279770 simple_t4_audio_sd
54: 1 1 1 32 53 76 1637303044 1635792194 USB_MTP-logger
55: 1 1 1 32 54 73 1637303046 1637210510 USB_MTP_IntegrityCheck
56: 1 1 1 32 55 72 1637303046 1632804262 USB_SPI_MTP-logger
57: 1 0 0 31 0 47 1637303014 1637231246 COMMIT_EDITMSG
58: 1 0 0 31 57 396 1637303014 1633667982 config
59: 1 0 0 31 58 36 1637303014 1632801578 description
60: 1 0 0 31 59 223 1637303014 1637233300 FETCH_HEAD
61: 1 0 0 31 60 21 1637303014 1633672244 HEAD
62: 1 0 0 31 61 3994 1637303014 1637231246 index
63: 1 0 0 31 62 41 1637303014 1637210510 ORIG_HEAD
64: 1 0 0 31 63 46 1637303014 1633623552 packed-refs
65: 1 0 0 31 64 41 1637303014 1633672242 REBASE_HEAD
66: 1 1 0 31 65 0 1637303014 1632801578 hooks
67: 1 1 0 31 66 0 1637303016 1632801578 info
68: 1 1 0 31 67 0 1637303016 1632801580 logs
69: 1 1 0 31 68 0 1637303016 1637233300 objects
70: 1 1 1 31 69 109 1637303042 1634552344 refs
71: 1 0 0 56 0 3870 1637303046 1631257372 Compile.cmd
72: 1 0 0 56 71 11472 1637303046 1633671222 USB_SPI_MTP-logger.ino
73: 1 0 0 55 0 18591 1637303046 1637210510 USB_MTP_IntegrityCheck.ino
74: 1 0 0 54 0 5377 1637303046 1636986844 BogusFS.h
75: 1 0 0 54 74 3404 1637303046 1636987038 Compile.cmd
76: 1 0 0 54 75 10342 1637303046 1636436736 USB_MTP-logger.ino
77: 1 0 0 53 0 3404 1637303044 1634537784 Compile.cmd
78: 1 0 0 53 77 8001 1637303044 1634279770 simple_t4_audio_sd.ino
79: 1 0 0 52 0 2222 1637303044 1634552344 simple_t41_qflash.ino
80: 1 0 0 51 0 3404 1637303044 1633670066 Compile.cmd
81: 1 0 0 51 80 7256 1637303044 1633669426 simple.ino
82: 1 0 0 50 0 3404 1637303044 1634364734 Compile.cmd
83: 1 0 0 50 82 12588 1637303044 1637041174 SD_SPI_QSPI_MTP-logger.ino
84: 1 0 0 49 0 3404 1637303044 1637041260 Compile.cmd
85: 1 0 0 49 84 3521 1637303044 1637218756 LittleFSCombine.h
86: 1 0 0 49 85 11264 1637303044 1637220392 SD_Program_SPI_QSPI_MTP-logger.ino
87: 1 0 0 48 0 3404 1637303044 1634282762 Compile.cmd
88: 1 0 0 48 87 9759 1637303044 1634283268 SD_Program_MTP-logger.ino
89: 1 0 0 47 0 3404 1637303044 1632556744 Compile.cmd
90: 1 0 0 47 89 7912 1637303044 1634278868 SD_MTP-logger.ino
91: 1 0 0 46 0 3404 1637303044 1634187894 Compile.cmd
92: 1 0 0 46 91 19690 1637303044 1635593124 mtp-test.ino
93: 1 0 0 46 92 789 1637303044 1636867226 mtp-test.sublime-project
94: 1 0 0 46 93 343272 1637303044 1635936528 mtp-test.sublime-workspace
95: 1 0 0 45 0 3404 1637303044 1633670454 Compile.cmd
96: 1 0 0 45 95 24412 1637303044 1633670616 mtp-logger.ino
97: 1 0 0 44 0 6721 1637303044 1632804262 LittleFS_Program_Simple_Datalogger-dates.ino
98: 1 0 0 43 0 3404 1637303044 1633671318 Compile.cmd
99: 1 0 0 43 98 5557 1637303044 1633671310 LFS_SPI_MTP_Simple_Datalogger.ino
100: 1 0 0 42 0 3404 1637303044 1633671140 Compile.cmd
101: 1 0 0 42 100 5802 1637303044 1633671220 LFS_Program_MTP_Simple_Datalogger.ino
102: 1 0 0 41 0 3404 1637303044 1634554384 Compile.cmd
103: 1 0 0 41 102 3126 1637303044 1634545026 format_timeout_test.ino
104: 1 0 0 40 0 5378 1637303044 1637256756 BogusFS.h
105: 1 0 0 40 104 7873 1637303044 1637257200 Bogus_MTP-logger.ino
106: 1 0 0 40 105 3404 1637303044 1637257042 Compile.cmd
107: 1 1 0 70 0 0 1637303042 1637231246 heads
108: 1 1 0 70 107 0 1637303044 1632804952 remotes
109: 1 1 0 70 108 0 1637303044 1632801578 tags
110: 1 1 0 69 0 0 1637303016 1634536266 01
111: 1 1 0 69 110 0 1637303016 1634653506 02
112: 1 1 0 69 111 0 1637303016 1635845614 03
113: 1 1 0 69 112 0 1637303016 1635593118 04
114: 1 1 0 69 113 0 1637303016 1637231246 06
115: 1 1 0 69 114 0 1637303016 1634279892 07
116: 1 1 0 69 115 0 1637303016 1636535882 08
117: 1 1 0 69 116 0 1637303016 1633671800 09
118: 1 1 0 69 117 0 1637303016 1637042864 0a
119: 1 1 0 69 118 0 1637303016 1632822408 0b
120: 1 1 0 69 119 0 1637303016 1633614742 0c
121: 1 1 0 69 120 0 1637303018 1634470136 0d
122: 1 1 0 69 121 0 1637303018 1637224260 0f
123: 1 1 0 69 122 0 1637303018 1636807764 11
124: 1 1 0 69 123 0 1637303018 1633672212 12
125: 1 1 0 69 124 0 1637303018 1637042862 14
126: 1 1 0 69 125 0 1637303018 1633001248 15
127: 1 1 0 69 126 0 1637303018 1636811178 16
128: 1 1 0 69 127 0 1637303018 1633692154 17
129: 1 1 0 69 128 0 1637303018 1634530154 18
130: 1 1 0 69 129 0 1637303018 1633534858 19
131: 1 1 0 69 130 0 1637303018 1632804938 1a
132: 1 1 0 69 131 0 1637303018 1636097836 1b
133: 1 1 0 69 132 0 1637303018 1634536266 1c
134: 1 1 0 69 133 0 1637303018 1633619560 1d
135: 1 1 0 69 134 0 1637303018 1635394146 1e
136: 1 1 0 69 135 0 1637303018 1634824754 1f
137: 1 1 0 69 136 0 1637303018 1634824798 20
138: 1 1 0 69 137 0 1637303018 1632812642 21
139: 1 1 0 69 138 0 1637303020 1634553506 22
140: 1 1 0 69 139 0 1637303020 1637224260 23
141: 1 1 0 69 140 0 1637303020 1635482694 24
142: 1 1 0 69 141 0 1637303020 1636807764 25
143: 1 1 0 69 142 0 1637303020 1636094740 27
144: 1 1 0 69 143 0 1637303020 1636535882 28
145: 1 1 0 69 144 0 1637303020 1637224260 29
146: 1 1 0 69 145 0 1637303020 1634358482 2a
147: 1 1 0 69 146 0 1637303020 1635593120 2b
148: 1 1 0 69 147 0 1637303020 1636535880 2d
149: 1 1 0 69 148 0 1637303020 1635239878 2e
150: 1 1 0 69 149 0 1637303020 1634145970 2f
151: 1 1 0 69 150 0 1637303020 1633672212 30
152: 1 1 0 69 151 0 1637303020 1633672244 31
153: 1 1 0 69 152 0 1637303020 1634552334 33
154: 1 1 0 69 153 0 1637303020 1633667914 34
155: 1 1 0 69 154 0 1637303020 1633672212 35
156: 1 1 0 69 155 0 1637303020 1637035710 38
157: 1 1 0 69 156 0 1637303020 1632816726 39
158: 1 1 0 69 157 0 1637303022 1636803640 3a
159: 1 1 0 69 158 0 1637303022 1634824754 3b
160: 1 1 0 69 159 0 1637303022 1633505448 3c
161: 1 1 0 69 160 0 1637303022 1634721018 3d
162: 1 1 0 69 161 0 1637303022 1632812418 3e
163: 1 1 0 69 162 0 1637303022 1637210508 3f
164: 1 1 0 69 163 0 1637303022 1633612632 40
165: 1 1 0 69 164 0 1637303022 1636094740 41
166: 1 1 0 69 165 0 1637303022 1633186126 42
167: 1 1 0 69 166 0 1637303022 1636811178 43
168: 1 1 0 69 167 0 1637303022 1634624850 44
169: 1 1 0 69 168 0 1637303022 1635746070 45
170: 1 1 0 69 169 0 1637303022 1637210506 46
171: 1 1 0 69 170 0 1637303022 1634824754 47
172: 1 1 0 69 171 0 1637303022 1637231246 48
173: 1 1 0 69 172 0 1637303022 1635845614 49
174: 1 1 0 69 173 0 1637303022 1634836256 4a
175: 1 1 0 69 174 0 1637303022 1633622566 4b
176: 1 1 0 69 175 0 1637303022 1634552336 4c
177: 1 1 0 69 176 0 1637303022 1634545164 4d
178: 1 1 0 69 177 0 1637303024 1633671800 4e
179: 1 1 0 69 178 0 1637303024 1637210508 50
180: 1 1 0 69 179 0 1637303024 1633534856 51
181: 1 1 0 69 180 0 1637303024 1635845614 52
182: 1 1 0 69 181 0 1637303024 1635593118 53
183: 1 1 0 69 182 0 1637303024 1634552322 54
184: 1 1 0 69 183 0 1637303024 1635845614 55
185: 1 1 0 69 184 0 1637303024 1634469778 56
186: 1 1 0 69 185 0 1637303024 1637036052 57
187: 1 1 0 69 186 0 1637303024 1634279892 58
188: 1 1 0 69 187 0 1637303024 1636803640 59
189: 1 1 0 69 188 0 1637303024 1637224260 5a
190: 1 1 0 69 189 0 1637303024 1634824798 5b
191: 1 1 0 69 190 0 1637303024 1637042862 5c
192: 1 1 0 69 191 0 1637303024 1633612632 5d
193: 1 1 0 69 192 0 1637303024 1634536266 5e
194: 1 1 0 69 193 0 1637303026 1633842402 5f
195: 1 1 0 69 194 0 1637303026 1634624850 60
196: 1 1 0 69 195 0 1637303026 1637042864 61
197: 1 1 0 69 196 0 1637303026 1633679746 62
198: 1 1 0 69 197 0 1637303026 1632804936 63
199: 1 1 0 69 198 0 1637303026 1634449658 64
200: 1 1 0 69 199 0 1637303026 1634279892 65
201: 1 1 0 69 200 0 1637303026 1635593118 66
202: 1 1 0 69 201 0 1637303026 1636803640 67
203: 1 1 0 69 202 0 1637303026 1636535882 68
204: 1 1 0 69 203 0 1637303026 1636535882 69
205: 1 1 0 69 204 0 1637303026 1636535882 6a
206: 1 1 0 69 205 0 1637303026 1636097836 6b
207: 1 1 0 69 206 0 1637303026 1636094740 6d
208: 1 1 0 69 207 0 1637303026 1637210506 6e
209: 1 1 0 69 208 0 1637303026 1632812646 6f
210: 1 1 0 69 209 0 1637303028 1637035710 70
211: 1 1 0 69 210 0 1637303028 1633671800 71
212: 1 1 0 69 211 0 1637303028 1633186168 72
213: 1 1 0 69 212 0 1637303028 1635409142 73
214: 1 1 0 69 213 0 1637303028 1634552322 74
215: 1 1 0 69 214 0 1637303028 1634552336 75
216: 1 1 0 69 215 0 1637303028 1634634324 76
217: 1 1 0 69 216 0 1637303028 1636094740 77
218: 1 1 0 69 217 0 1637303028 1633186168 78
219: 1 1 0 69 218 0 1637303028 1635409142 79
220: 1 1 0 69 219 0 1637303028 1634824798 7a
221: 1 1 0 69 220 0 1637303028 1634280140 7b
222: 1 1 0 69 221 0 1637303028 1636807764 7c
223: 1 1 0 69 222 0 1637303028 1636807764 7d
224: 1 1 0 69 223 0 1637303028 1636803640 7e
225: 1 1 0 69 224 0 1637303028 1633692162 7f
226: 1 1 0 69 225 0 1637303028 1634634324 80
227: 1 1 0 69 226 0 1637303028 1634530154 81
228: 1 1 0 69 227 0 1637303030 1635409142 82
229: 1 1 0 69 228 0 1637303030 1637224260 83
230: 1 1 0 69 229 0 1637303030 1634634324 84
231: 1 1 0 69 230 0 1637303030 1632816726 85
232: 1 1 0 69 231 0 1637303030 1635394148 86
233: 1 1 0 69 232 0 1637303030 1634131308 88
234: 1 1 0 69 233 0 1637303030 1633534858 89
235: 1 1 0 69 234 0 1637303030 1633612632 8a
236: 1 1 0 69 235 0 1637303030 1636807764 8b
237: 1 1 0 69 236 0 1637303030 1634824798 8c
238: 1 1 0 69 237 0 1637303030 1634552322 8f
239: 1 1 0 69 238 0 1637303030 1637042862 90
240: 1 1 0 69 239 0 1637303030 1636811178 91
241: 1 1 0 69 240 0 1637303030 1634653506 92
242: 1 1 0 69 241 0 1637303032 1636535882 93
243: 1 1 0 69 242 0 1637303032 1634634324 94
244: 1 1 0 69 243 0 1637303032 1637210506 95
245: 1 1 0 69 244 0 1637303032 1634390094 96
246: 1 1 0 69 244 0 1637303032 1634390094 96
247: 1 1 0 69 244 0 1637303032 1634390094 96
248: 1 1 0 69 244 0 1637303032 1634390094 96
249: 1 1 0 69 244 0 1637303032 1634390094 96
250: 1 1 0 69 244 0 1637303032 1634390094 96
251: 1 1 0 69 244 0 1637303032 1634390094 96
252: 1 1 0 69 244 0 1637303032 1634390094 96
253: 1 1 0 69 244 0 1637303032 1634390094 96
254: 1 1 0 69 244 0 1637303032 1634390094 96
255: 1 1 0 69 244 0 1637303032 1634390094 96
256: 1 1 0 69 244 0 1637303032 1634390094 96
257: 1 1 0 69 244 0 1637303032 1634390094 96
258: 1 1 0 69 244 0 1637303032 1634390094 96
259: 1 1 0 69 244 0 1637303032 1634390094 96
260: 1 1 0 69 244 0 1637303032 1634390094 96
261: 1 1 0 69 244 0 1637303032 1634390094 96
262: 1 1 0 69 244 0 1637303032 1634390094 96
263: 1 1 0 69 244 0 1637303032 1634390094 96
264: 1 1 0 69 244 0 1637303032 1634390094 96
265: 1 1 0 69 244 0 1637303032 1634390094 96
266: 1 1 0 69 244 0 1637303032 1634390094 96
267: 1 1 0 69 244 0 1637303032 1634390094 96
268: 1 1 0 69 244 0 1637303032 1634390094 96
269: 1 1 0 69 244 0 1637303032 1634390094 96
270: 1 1 0 69 244 0 1637303032 1634390094 96
271: 1 1 0 69 244 0 1637303032 1634390094 96
272: 1 1 0 69 244 0 1637303032 1634390094 96
273: 1 1 0 69 244 0 1637303032 1634390094 96
274: 1 1 0 69 244 0 1637303032 1634390094 96
275: 1 1 0 69 244 0 1637303032 1634390094 96
276: 1 1 0 69 244 0 1637303032 1634390094 96
277: 1 1 0 69 244 0 1637303032 1634390094 96
278: 1 1 0 69 244 0 1637303032 1634390094 96
279: 1 1 0 69 244 0 1637303032 1634390094 96
280: 1 1 0 69 244 0 1637303032 1634390094 96
281: 1 1 0 69 244 0 1637303032 1634390094 96
282: 1 1 0 69 244 0 1637303032 1634390094 96
283: 1 1 0 69 244 0 1637303032 1634390094 96
284: 1 1 0 69 244 0 1637303032 1634390094 96
285: 1 1 0 69 244 0 1637303032 1634390094 96
286: 1 1 0 69 244 0 1637303032 1634390094 96
287: 1 1 0 69 244 0 1637303032 1634390094 96
288: 1 1 0 69 244 0 1637303032 1634390094 96
289: 1 1 0 69 244 0 1637303032 1634390094 96
290: 1 1 0 69 244 0 1637303032 1634390094 96
291: 1 1 0 69 244 0 1637303032 1634390094 96
292: 1 1 0 69 244 0 1637303032 1634390094 96
293: 1 1 0 69 244 0 1637303032 1634390094 96
294: 1 1 0 69 244 0 1637303032 1634390094 96
295: 1 1 0 69 244 0 1637303032 1634390094 96
296: 1 1 0 69 244 0 1637303032 1634390094 96
297: 1 1 0 69 244 0 1637303032 1634390094 96
298: 1 1 0 69 244 0 1637303032 1634390094 96
299: 1 1 0 69 244 0 1637303032 1634390094 96
300: 1 1 0 69 244 0 1637303032 1634390094 96
301: 1 1 0 69 244 0 1637303032 1634390094 96
302: 1 1 0 69 244 0 1637303032 1634390094 96
303: 1 1 0 69 244 0 1637303032 1634390094 96
304: 1 1 0 69 244 0 1637303032 1634390094 96
305: 1 1 0 69 244 0 1637303032 1634390094 96
306: 1 1 0 69 244 0 1637303032 1634390094 96
307: 1 1 0 69 244 0 1637303032 1634390094 96
308: 1 1 0 69 244 0 1637303032 1634390094 96
309: 1 1 0 69 244 0 1637303032 1634390094 96
310: 1 1 0 69 244 0 1637303032 1634390094 96
311: 1 1 0 69 244 0 1637303032 1634390094 96
312: 1 1 0 69 244 0 1637303032 1634390094 96
313: 1 1 0 69 244 0 1637303032 1634390094 96
314: 1 1 0 69 244 0 1637303032 1634390094 96
315: 1 1 0 69 244 0 1637303032 1634390094 96
316: 1 1 0 69 244 0 1637303032 1634390094 96
317: 1 1 0 69 244 0 1637303032 1634390094 96
318: 1 1 0 69 244 0 1637303032 1634390094 96
319: 1 1 0 69 244 0 1637303032 1634390094 96
320: 1 1 0 69 244 0 1637303032 1634390094 96
321: 1 1 0 69 244 0 1637303032 1634390094 96
322: 1 1 0 69 244 0 1637303032 1634390094 96
323: 1 1 0 69 244 0 1637303032 1634390094 96
324: 1 1 0 69 244 0 1637303032 1634390094 96
325: 1 1 0 69 244 0 1637303032 1634390094 96
326: 1 1 0 69 244 0 1637303032 1634390094 96
327: 1 1 0 69 244 0 1637303032 1634390094 96
328: 1 1 0 69 244 0 1637303032 1634390094 96
329: 1 1 0 69 244 0 1637303032 1634390094 96
330: 1 1 0 69 244 0 1637303032 1634390094 96
331: 1 1 0 69 244 0 1637303032 1634390094 96
332: 1 1 0 69 244 0 1637303032 1634390094 96
333: 1 1 0 69 244 0 1637303032 1634390094 96
334: 1 1 0 69 244 0 1637303032 1634390094 96
335: 1 1 0 69 244 0 1637303032 1634390094 96
336: 1 1 0 69 244 0 1637303032 1634390094 96
337: 1 1 0 69 244 0 1637303032 1634390094 96
338: 1 1 0 69 244 0 1637303032 1634390094 96
339: 1 1 0 69 244 0 1637303032 1634390094 96
340: 1 1 0 69 244 0 1637303032 1634390094 96
341: 1 1 0 69 244 0 1637303032 1634390094 96
342: 1 1 0 69 244 0 1637303032 1634390094 96
343: 1 1 0 69 244 0 1637303032 1634390094 96
344: 1 1 0 69 244 0 1637303032 1634390094 96
345: 1 1 0 69 244 0 1637303032 1634390094 96
346: 1 1 0 69 244 0 1637303032 1634390094 96
347: 1 1 0 69 244 0 1637303032 1634390094 96
348: 1 1 0 69 244 0 1637303032 1634390094 96
349: 1 1 0 69 244 0 1637303032 1634390094 96
350: 1 1 0 69 244 0 1637303032 1634390094 96
351: 1 1 0 69 244 0 1637303032 1634390094 96
352: 1 1 0 69 244 0 1637303032 1634390094 96
353: 1 1 0 69 244 0 1637303032 1634390094 96
354: 1 1 0 69 244 0 1637303032 1634390094 96
355: 1 1 0 69 244 0 1637303032 1634390094 96
356: 1 1 0 69 244 0 1637303032 1634390094 96
357: 1 1 0 69 244 0 1637303032 1634390094 96
358: 1 1 0 69 244 0 1637303032 1634390094 96
359: 1 1 0 69 244 0 1637303032 1634390094 96
360: 1 1 0 69 244 0 1637303032 1634390094 96

So it looks like it totally scans the storage items up front. I have not even opened a window showing MTP yet...

Now if I run on Windows you see:
Note: this Teensy auto loads a window when plugged in:

Code:
Dump Storage list(4)
store:0 storage:10001 name:RAM fs:20005684
store:1 storage:20001 name:SD_Card fs:20004f24
store:2 storage:30001 name:Program fs:200055b8
store:3 storage:40001 name:SPI Flash fs:200054d4

Dump Index List
So the index list starts off only with the list of storage objects:

Now if I click to open up the SD Card I see the list grows to only include the root:
Code:
Dump Storage list(4)
store:0 storage:10001 name:RAM fs:20005684
store:1 storage:20001 name:SD_Card fs:20004f24
store:2 storage:30001 name:Program fs:200055b8
store:3 storage:40001 name:SPI Flash fs:200054d4

Dump Index List
0: 0 1 0 -1 0 0 0 0 /
1: 1 1 1 -1 0 22 0 0 /
2: 2 1 0 -1 0 0 0 0 /
3: 3 1 0 -1 0 0 0 0 /
20: 1 0 0 1 0 22014452 1637313900 1637313906 LargeIndexedTestfile.txt
21: 1 1 0 1 20 0 1637302974 1637302976 System Volume Information
22: 1 1 0 1 21 0 1637303014 1632801936 MTP_Teensy

Now will be interesting to see what happens with MSC drives
 
@KurtE
As you noticed, there is no standard implementation of the MTP initiator. Even different Linux implementations seem to behave differently.
MTP only defines the transport protocol and not the implementation, which made development a little bit complicated (especially on Windows).
 
@KurtE
As you noticed, there is no standard implementation of the MTP initiator. Even different Linux implementations seem to behave differently.
MTP only defines the transport protocol and not the implementation, which made development a little bit complicated (especially on Windows).
Yep thanks :D

What I have not tried out in a long time, is does any of it work on MAC? My impression is that there is probably not native support for MTP? I have seen some libraries and products to add some support, but..

Personally I don't like if Ubuntu does populate the whole tree, as if I have a 1tb hard disk plugged in, that might be a lot of files!
Needless to say, need to experiment more. Maybe there is some option to tell it, ask me later...
 
Quick update on MAC.

I don't know if there is any Native support on MAC.

But I did find with the OpenMTP application, that I can see The MTP now...

You have go use the connect (looks like electric plug) and then you can choose a storage, and I was able upload something...

If I remember correctly this is the free version which limited things like how many files I could copy...
 
Well with the latest set of changes decided to try and see what is working or not working correctly with the different storage media. Flash is already a know issue and will do that next but this is going to be a long list.

My configuration:
Code:
Dump Storage list(10)
store:0 storage:10001 name:sdio fs:2000cae0
store:1 storage:20001 name:RAM1 fs:2000c9b8
store:2 storage:30001 name:PROGM fs:2000c814
store:3 storage:40001 name:QSPI fs:2000c8e0
store:4 storage:50001 name:sflash5 fs:2000d480
store:5 storage:60001 name:sflash6 fs:2000d55c
store:6 storage:70001 name:WINBOND1G fs:2000c3c8
store:7 storage:80001 name:WINBOND2G fs:2000c4bc
store:8 storage:90001 name:MSC0-GPT32 fs:2000a370
store:9 storage:a0001 name:MSC1-GPTxFat fs:2000a840
Ids 8 and 9 will change based on the USB drive I am testing with.

Code:
[B]QSPI - 16MB Flash[/B]
Format - OK
14Mb file transfer from PC (SDTEST3.wav) - OK
Play with Media Player - OK
Copy 2 small wav files to flash - OK

Code:
[B]PSRAM - 4MB Drive[/B]
Format - OK
Copy 1MB png - OK
Open PNG in windows - OK
Copy 2 small wav files individually to flash - OK
Play with Media Player - OK
NOTE: Fails copy multiple files (hit or miss)

Code:
[B]Winbond 2G Nand 256MB[/B]
Format - OK
14Mb file transfer from PC (SDTEST3.wav) - OK
Play with Media Player - OK
16Mb file transfer from PC (SDTEST3.wav) - OK
Play with Media Player - OK
Copy 2 small <0.5Mb same time - OK
Copy 2 large files = 1 fails to copy

Code:
[B]Winbond 1G - 128Mb[/B]
Format - OK
14Mb file transfer from PC (SDTEST3.wav) - OK
Play with Media Player - OK
16Mb file transfer from PC (SDTEST3.wav) - OK
Play with Media Player - OK
Copy 2 small <0.5Mb same time - OK
Copy 2 large files = Ok but this is hit or miss whether it works

Code:
[B]Flash Drive 128MB GPT Partitioned[/B]
[COLOR="#FF0000"]Part1 - 29MB FAT32[/COLOR]
Format first - looses bytes free space,  and Hangs sketch have to restart or power cycle.  On power cycle drive appears correctly

14Mb file transfer from PC (SDTEST3.wav) - OK
copy 16mb file - Fails - hangs sketch.
[INDENT]LP:96070 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:28 : 90001 ffffffff
96070 DATA:100c(SEND_OBJECT_INFO)l: 164 T:28 : 0 3000 1060ca0 3000 0
SendObjectInfo: 589825 4294967295 200093c0: ST:0 F:3000 0 SZ:17173664 3000 0 0 0 0 0 0 0 0 0 0 : SDTEST4.wav
Read DateTime string: 20211120T105510.0
>> date/Time: 6198d40e 11/20/2021 10:55:10
Created: 6198d40e
Read DateTime string: 20210101T000000.0
>> date/Time: 5fee6600 1/1/2021 0:0:0
Modified: 5fee6600[/INDENT]

Restart - plays wav file

COpy 16mb file worked but failed on copying additional small files - seems to have issue with copying files after a large file copy and hangs sketch


[COLOR="#FF0000"]Part2 - 87MB exFat[/COLOR]
Format - looses drive and turns fat32 drive red have to reboot as sketch is hung
Copies single 14mb file - OK
Play with Media Player - OK
Copy 2nd 16mb wav file - fails on 0 len packets:
[INDENT]41139 RESP:2001(RSP:OK)l: 24 T:28 : a0001 ffffffff 15
LP:41140 CMD: 100d(SEND_OBJECT)l: 12 T:29
MTPD::SendObject: len:17173664

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 672
Writing a ExFatFile line 82
 # USB Packets: 33542 total: 1042 avg ms: 0 max: 1
 # Write: 8386 total:6665 avg ms: 0 max: 169(8386)
  >> >=100ms: 1 50:0 40:0 30:0 20:6 10:3
  >> Last write times
  169 1 1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 1
>>>Total Time: 9769315
50909 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:29
[/INDENT]
Copy 2 small wav files <0.5Mb same time - OK
Copy 2 large files at same time - 1 transfers 1 fails

Code:
[B]SDIO - FAT32 32GB SD Card[/B]
Format - OK
Copy large files - Failed - tried to copy 3 large files approx 16mb and all failed
Copied 1MB png - OK
Copied multiple small wav Files - OK
Copied 2 large files singuarly and this time - OK
Copied 2 large files at same time - OK this time

Code:
[B]SDIO - exFAT.[/B]
Reboots on formatting but may be due to SDIO being the drive with MTPindex.dat file.
Copied a whole directory - of several 13-16mb wave files and smaller files.  1 large file did not transfer.

Code:
[B]Extend Partitions - exFAT + Fat32 on USB Drive 64GB drive[/B]
See GPT Comments

Code:
[B]Single exFAT 128gb drive[/B]
Format - OK
Copy large file (22mb) - OK

Coping a second large file - Fails - looses drive in Windows explorer and can not copy any other files to other drives.  Sketch is still running and not frozen.

[INDENT]LP:185903 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:26 : 90001 ffffffff
185903 DATA:100c(SEND_OBJECT_INFO)l: 172 T:26 : 0 3000 169363c 3000 0
SendObjectInfo: 589825 4294967295 200093c0: ST:0 F:3000 0 SZ:23672380 3000 0 0 0 0 0 0 0 0 0 0 : 2106d.01974.pdf
Read DateTime string: 20211120T142802.0
>> date/Time: 619905f2 11/20/2021 14:28:2
Created: 619905f2
Read DateTime string: 20211106T211712.0
>> date/Time: 6186f0d8 11/6/2021 21:17:12
Modified: 6186f0d8
Writing a ExFatFile line 82
186060 RESP:2001(RSP:OK)l: 24 T:26 : 90001 ffffffff 15
LP:186060 CMD: 100d(SEND_OBJECT)l: 12 T:27
MTPD::SendObject: len:23672380

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 500
Writing a ExFatFile line 82
 # USB Packets: 19881 total: 1258 avg ms: 0 max: 1
 # Write: 4971 total:9978 avg ms: 2 max: 403(4958)
  >> >=100ms: 10 50:13 40:0 30:0 20:0 10:21
  >> Last write times
  0 97 97 98 98 97 97 95 96 97 101 228 287 403 12 13 13 15 98 100 126 64 64 235 76 132 136 1 1 1 1 1
>>>Total Time: 13909080
199969 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:27[/INDENT]


Fails to copy multiple small files < 0.5mb at the same time
Copy small files > 4 one at a time - OK
Play wav files in Media Player - OK

Ok guess need to start figuring out what is causing some of these issues.
 
Can see that MSC-test isn't the updated 'STORE:' version? It is part of the MTP LIB ... should I do a PR? Not sure if the Integrity bits are wanted or needed in there?

In making edits the Files bigFile write was failing some and leaving a 0 byte file on PROG and SD - and those could not be deleted ... like reported before - but this was on SD as well - so not just an LFS issue?
 
Can see that MSC-test isn't the updated 'STORE:' version? It is part of the MTP LIB ... should I do a PR? Not sure if the Integrity bits are wanted or needed in there?

In making edits the Files bigFile write was failing some and leaving a 0 byte file on PROG and SD - and those could not be deleted ... like reported before - but this was on SD as well - so not just an LFS issue?

Tim - thought I had copied your version as posted - seemed to be printing less dots will have to redo. As for Integrity file writes I have not had problem with 0byte files being created. Those writes always worked regardless of LFS or SD Card.

Issue has always been with when the copy fails going from PC to device.

Don't believe LFS is where the problem is. I had set it up to print traces, debug messsages, warn or errors and from what I can see LFS is doing what it is suppose to be doing up until the point 0 packets are received or incomplete transfers of packets. Here is a sample dump:
View attachment LFS_Trace_sflash_copy.txt

This was done from the other day.

Seems issue is either with USB or other MTP issue.

EDIT: Just double checked its printing the store - see first code block
Code:
store:0 storage:10001 name:sdio fs:2000cae0
store:1 storage:20001 name:RAM1 fs:2000c9b8
store:2 storage:30001 name:PROGM fs:2000c814
store:3 storage:40001 name:QSPI fs:2000c8e0
store:4 storage:50001 name:sflash5 fs:2000d480
store:5 storage:60001 name:sflash6 fs:2000d55c
store:6 storage:70001 name:WINBOND1G fs:2000c3c8
store:7 storage:80001 name:WINBOND2G fs:2000c4bc
store:8 storage:90001 name:MSC0-GPT32 fs:2000a370
store:9 storage:a0001 name:MSC1-GPTxFat fs:2000a840

EDIT 2:
For instance just tested transferring a 22mb file to a 4GB Fat32 drive and received an incomplete transfer:
Code:
LP:338266 CMD: 100d(SEND_OBJECT)l: 12 T:14
MTPD::SendObject: len:22015988

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 1524
 # USB Packets: 42999 total: 1388 avg ms: 0 max: 1
 # Write: 10750 total:13132 avg ms: 1 max: 89(185)
  >> >=100ms: 0 50:1 40:0 30:0 20:1 10:1
  >> Last write times
  0 0 1 2 1 1 1 1 1 1 2 1 2 2 1 1 1 1 1 2 2 1 0 0 1 1 2 1 1 2 1 1
>>>Total Time: 15563937
353831 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:14
But if you look closely looks like the file actually transferred successfully - 42999 packets is what the test file is suppose to be, and if you look at the contents of the transferred file its the same as whats on the PC - now this might not be case for all the failed files.

Yet writing a "B"ig file directly to the USB Drive:
Code:
Start Big write of 25124864 Bytes............................................................
Big write /0_bigfile.txt took 14.22 Sec for 25124864 Bytes : file3.size()=25122816
	Big write KBytes per second 1766.25 

Bytes Used: 50135040, Bytes Total:4098621440
- no issues
 
Last edited:
@Paul, @mjs513 @defragster and all:


I believe when we have failures on copy like the one @mjs513 had above:
Code:
Part2 - 87MB exFat
Format - looses drive and turns fat32 drive red have to reboot as sketch is hung
Copies single 14mb file - OK
Play with Media Player - OK
Copy 2nd 16mb wav file - fails on 0 len packets:
41139 RESP:2001(RSP:OK)l: 24 T:28 : a0001 ffffffff 15
LP:41140 CMD: 100d(SEND_OBJECT)l: 12 T:29
MTPD::SendObject: len:17173664

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 672
Writing a ExFatFile line 82
 # USB Packets: 33542 total: 1042 avg ms: 0 max: 1
 # Write: 8386 total:6665 avg ms: 0 max: 169(8386)
  >> >=100ms: 1 50:0 40:0 30:0 20:6 10:3
  >> Last write times
  169 1 1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 1 1
>>>Total Time: 9769315
50909 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:29
In cased like these, I don't think the different FS are the issue, but I believe there is some issue where we are losing some USB packets.

I am also seeing this on the Ubuntu setup. as I will edit in:

Edit: This is running on Ubuntu with MSC talking to SSD drive.
This is using the file I created that each logical 512 byte packet starts with sequence number...


Code:
LP:528593 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:65 : 40001 ffffffff
528593 DATA:100c(SEND_OBJECT_INFO)l: 118 T:65 : 40001 3004 14feff4 0 0
SendObjectInfo: 262145 4294967295 20008ac0: ST:40001 F:3004 0 SZ:22015988 0 0 0 0 0 0 0 ffffffff 0 0 0 : LargeIndexedTestfile.txt
Created: 0
Modified: 0
528763 RESP:2001(RSP:OK)l: 24 T:65 : 40001 ffffffff 1c
LP:528764 CMD: 100d(SEND_OBJECT)l: 12 T:66
MTPD::SendObject: len:22015988

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 500
&&DT (0,0) (1637413568,1637413568)
 # USB Packets: 42997 total: 1880 avg ms: 0 max: 5
 # Write: 10750 total:4158 avg ms: 0 max: 1(2)
  >> >=100ms: 0 50:0 40:0 30:0 20:0 10:0
  >> Last write times
  0 0 1 0 0 1 0 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0
>>>Total Time: 7042645
535828 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:66
LP:904397 CMD: 1015(GET_DEVICE_PROP_VALUE)l: 16 T:67 : d402
904397 RESP:2001(RSP:OK)l: 16 T:67 : d402
LP:1804409 CMD: 1015(GET_DEVICE_PROP_VALUE)l: 16 T:68 : d402
1804409 RESP:2001(RSP:OK)l: 16 T:68 : d402
 
Mike - my bad this line : storage_index = '0'; instead should be : storage_index = 0;
> as written it doesn't work on first '1' - doh :(
>> updated prior posted sketch

Seeing the MTP get messed up when doing CMSLine from SerMon ... or Integrity tasks at the 'wrong' time or when PC makes requested and mtp.loop() isn't called.

Interesting this is that '0' size file is "there' on media listing ... but won't get removed ...
 
Last edited:
Quick update on Ubuntu... Getting an error trying to download the large file back to the Ubuntu... So will do some debug here next...

Wondering about something I think I saw in code, where the last write, says it is writing the whole packet size, where maybe it should instead have the actual count of data left to output...

One crash:
Screenshot from 2021-11-20 17-01-44.png
 
Last edited:
KurtE said:
In cased like these, I don't think the different FS are the issue, but I believe there is some issue where we are losing some USB packets.

I am also seeing this on the Ubuntu setup. as I will edit in:

Edit: This is running on Ubuntu with MSC talking to SSD drive.
This is using the file I created that each logical 512 byte packet starts with sequence number...

I agree with your assessment that its not with the File Systems. One of the points of the comparisons was to determine a common thread if there was any as well as using direct write capability for each of the device types to ensure there were no underlining issues with the FS such as LFS etc. which don't believe there is any from what I can see. Testing has really only been done on the T4.1 but some preliminary testing with the T3.6 don't show the same type of issues but will play with that probably tomorrow.
 
Morning all
In a follow-up to post #555 I just finished testing the same devices using the same sketch and same process of formatting and copying large and small files except this time I am using Teens 3.6.

Basically I did not find any issues with any of the devices tested:
SDCards:
FAT32 32GB in SDIO
exFAT 512GB on Audio shield using pin 10.

SPI Flash
2 512mb Flash chips
1 N01 NAND
1 N02 NAND

USB Drives
Single FAT32 4GB
Single extFAT 128GB
GPT with 2 partitions (fat32 and extFAT)
MBR with 2 partition (extFAT and FAT32)
 
Morning:

@mjs513 - Good information. So T3.6 appears to be working well.

So again it points fingers at T4 implantation issues. Note: the SendObject code within the MTP_Teensy library is different. But there is an #ifdef version within the T4 part of the code, that works like T3 version, of receive data, write to disk, receive next packet write to disk... Only real difference in this version, is on T4.x typically 512 byte packets and on t3.x 64 byte packets.
The simple version fails even more often.

@Paul:
Again this morning trying some of the testing on Ubuntu (not my primary setup)... But for example running the USB_MTP-logger example, which locally I have edited to also include SD... Currently testing on MicroMod using your board, that has both SDIO and USB... Tried to both SD card as well as USB where I have a 240GB SSD plugged in.
Probably 9 out of 10 times it fails to fully transfer the file to the Teensy storage...

Note: could post file, but generated using simple sketch:
Code:
#include <SD.h>
#include <SPI.h>

File myFile;

const int chipSelect = BUILTIN_SDCARD;
#define BUFFER_SIZE 128
uint8_t write_buffer[BUFFER_SIZE];

void setup()
{
  while (!Serial && millis() < 5000);
  Serial.begin(9600);

  if (CrashReport) {
    Serial.print(CrashReport);
  }
  Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
  delay(3000);
  Serial.print("Initializing SD card...");

  if (!SD.begin(chipSelect)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

  // open the file.
  Serial.println("Write Large Index File");
  myFile = SD.open("LargeIndexedTestfile.txt", FILE_WRITE_BEGIN);
  if (myFile) {
    myFile.truncate(); // Make sure we wipe out whatever was written earlier
    for (uint32_t i = 0; i < 43000*4; i++) {
      memset(write_buffer, 'A'+ (i & 0xf), sizeof(write_buffer));
      myFile.printf("%06u ", i >> 2);  // 4 per physical buffer
      myFile.write(write_buffer, i? 120 : 120-12); // first buffer has other data...
      myFile.printf("\n");
    }
    myFile.close();
    Serial.println("\ndone.");
  }
}

void loop()
{
  // nothing happens after setup
}

Note it writes to SDCard... Which I then transfer to the PC...

Note: the USB_MTP_Logger sketch has another file: BogusFS.h which again is a simple FS, that does nothing. But it handles the writes, and understands the format of the file created with the above sketch. So it can locate missing packets...

This mornings run, output to Bogus:
Code:
LP:36182 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:51 : 20001 ffffffff
36182 DATA:100c(SEND_OBJECT_INFO)l: 118 T:51 : 20001 3004 14feff4 0 0
SendObjectInfo: 131073 4294967295 20008ac0: ST:20001 F:3004 0 SZ:22015988 0 0 0 0 0 0 0 ffffffff 0 0 0 : LargeIndexedTestfile.txt
Created: 0
Modified: 0
BogusFS::open(/LargeIndexedTestfile.txt, 2)
36182 RESP:2001(RSP:OK)l: 24 T:51 : 20001 ffffffff 18
LP:36182 CMD: 100d(SEND_OBJECT)l: 12 T:52
MTPD::SendObject: len:22015988
BF Sequence error 2119 2117
BF Sequence error 3583 3581
BF Sequence error 4362 4360

MTPD::SendObject *** USB Read 0 bytes ***

MTPD::SendObject *** USB Read 0 bytes ***
len 500
&&DT (0,0) (0,0)
Bogus::close(/LargeIndexedTestfile.txt) LPN:42999
Bogus::close(/LargeIndexedTestfile.txt) LPN:42999
Bogus::close(/LargeIndexedTestfile.txt) LPN:42999
 # USB Packets: 42997 total: 2550 avg ms: 0 max: 2
 # Write: 10750 total:221 avg ms: 0 max: 1(2)
  >> >=100ms: 0 50:0 40:0 30:0 20:0 10:0
  >> Last write times
  0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>Total Time: 3794864
39978 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:52
So the above shows it lost 3 packets out of 43000. 2118, 3582 and 4361

And it happens on both Windows and Ubuntu... Have not tried enough on MAC to say.

Again at this point, I have no clear idea on how to debug this! Will keep throwing darts on chance something works. Already tried increasing the number of RX buffers/transfers from 4 to 8, did not appear to make a difference.
 
@Paul and others...

Another quick observation/question:

When I download a file Teensy to host (GetObject) - it often feels like the object was downloaded, but the MTP is hung... Note on Ubutue again it feels like it is waiting for something in then awhile later it
brings up a error dialog saying it failed...

So theory from observation with SendObject - In order to know that the transfer (get object) is done, especially where maybe data can be lost, it may be waiting for a 0 length packet,
to signal the end of data for that file... So I thought I might try adding it:

So I tried editing the end of the GetObject like:
Code:
    printf("  >> Exit loop len:%u\n", len);
    if (len > 0) {
      push_packet(tx_data_buffer, len);
      len = 0;
    }
    // Try sending a 0 length packet to host to let them know we are done
    // sending data for this object... 
    printf("  >> Send 0 length packet\n"); Serial.flush();
    push_packet(tx_data_buffer, 0);
    printf("  >> Return\n"); Serial.flush();
  }
}
Note 2 logic changes here:
1) push_packet(tx_data_buffer, len); was changed before it sent full size packet.
2) Added the sending 0 length...

Appears like teensy hangs on the sending 0 length:
As this is the last output:
Code:
GetObject(22) size: 22014964
  >> Exit loop len:0
  >> Send 0 length packet
Note the usb_mtp_send, grabs one of the TX buffers, memcpy the data to it (just to make sure I put in test of len before the memcpy...) and does the
Code:
	usb_prepare_transfer(xfer, txdata, len, 0);
	usb_transmit(MTP_TX_ENDPOINT, xfer);
And this does not return for 0 length? Should it be able to send packet with no data?
 
@KurtE, @all - I have been following and testing MTP_Teensy as it develops. Am seeing the same issues on Ubuntu. Decided to do a complete rewrite of diskIO to use FS only. I wanted to test all of the recent changes to SD, LittleFS and MSC without MTP_Teensy. It all seems really stable. The only problems I am seeing is using more than two USB devices without a powered hub. This was causing problems when using my SSD drive. Copying a file from the SSD to the SDIO card would cause it to hang. There was no problem when using a powered hub.

I have a 102 MB wav file that I used to copy back and forth between all of the different devices including QPINAND. Was able to play the wav file from both MSC drives, SDIO, external SD and QPINAND device without issue. I think FS is working ok and the issues are with MTP_Teensy. Next up is to add the rest of LitteFS devices using the MEM board.

I know you guy's are really busy right now but if interested here is version 2 of DiskIO:
https://github.com/wwatson4506/DiskIO/tree/DiskIOV2
It uses @Kurte's latest version of USBHost_t36-FS_integratio_MSC here:
https://github.com/KurtE/USBHost_t36/tree/FS_Integration_MSC

UsbMscFat is no longer needed:)

EDIT: Forgot to mention that I tested DiskIOV2 on MicroMod with the ATP carrier board, T4.1, T4.0 and T3.6. They performed without any issues I could detect.
 
Last edited:
Just ran into a situation with the T4.1 audio board and SPINAND with chip select 4. If the audio board is plugged into the PJRC T4.1 breakout board and the MEM board together with SPINAND chip select 4 SPINAND CS 4 will not show up:
Code:
DiskIOMB

The original version of microBox found here:
 http://sebastian-duell.de/en/microbox/index.html

Initializing, please wait...

Type 'help' for a list of commands...

root@Teensy:/128GEXFAT/>ld

Found 8 logical drives.

Logical Drive Information For Attached Drives
Logical Drive #:  0: | Volume Label:   128GEXFAT | valid: 1 | Drive Type: USB
Logical Drive #:  1: | Volume Label:   120GEXGPT | valid: 1 | Drive Type: USB
Logical Drive #: 16: | Volume Label:        SDIO | valid: 1 | Drive Type: SDHC/SDXC
Logical Drive #: 20: | Volume Label:       SDSPI | valid: 1 | Drive Type: SDHC/SDXC ---> Chip select 10, External drive on Audio Board. Valid.
Logical Drive #: 24: | Volume Label:     QPINAND | valid: 1 | Drive Type: LFS
Logical Drive #: 26: | Volume Label:   SPIFLASH5 | valid: 1 | Drive Type: LFS
Logical Drive #: 27: | Volume Label:   SPIFLASH6 | valid: 1 | Drive Type: LFS
Logical Drive #: 28: | Volume Label:    SPINAND3 | valid: 1 | Drive Type: LFS ---> SPINAND3 but not SPINAND4
8 Logical Drives Found
Default Logical Drive: /128GEXFAT/ (0:)
root@Teensy:/128GEXFAT/>

Without Audio Board:
Code:
The original version of microBox found here:
 http://sebastian-duell.de/en/microbox/index.html

Initializing, please wait...

Type 'help' for a list of commands...

root@Teensy:/128GEXFAT/>ld

Found 8 logical drives.

Logical Drive Information For Attached Drives
Logical Drive #:  0: | Volume Label:    128GEXFAT | valid: 1 | Drive Type: USB
Logical Drive #:  1: | Volume Label:    120GEXGPT | valid: 1 | Drive Type: USB
Logical Drive #: 16: | Volume Label:         SDIO | valid: 1 | Drive Type: SDHC/SDXC
Logical Drive #: 24: | Volume Label:      QPINAND | valid: 1 | Drive Type: LFS
Logical Drive #: 26: | Volume Label:    SPIFLASH5 | valid: 1 | Drive Type: LFS
Logical Drive #: 27: | Volume Label:    SPIFLASH6 | valid: 1 | Drive Type: LFS
Logical Drive #: 28: | Volume Label:     SPINAND3 | valid: 1 | Drive Type: LFS
Logical Drive #: 29: | Volume Label:     SPINAND4 | valid: 1 | Drive Type: LFS ---> Now valid usable device...
8 Logical Drives Found
Default Logical Drive: /128GEXFAT/ (0:)
root@Teensy:/128GEXFAT/>

Is there conflict or am I missing Something...
 
Last edited:
wwatson said:
Just ran into a situation with the T4.1 audio board and SPINAND with chip select 4. If the audio board is plugged into the PJRC T4.1 breakout board and the MEM board together with SPINAND chip select 4 SPINAND CS 4 will not show up:

I was running into that early on in testing but with the latest changes seems to picking it up without a problem in windows. It has happened to me when I have had a external card reader attached to as well.

Code:
Dump Storage list(9)
store:0 storage:10001 name:sdio fs:2000cae0
store:1 storage:20001 name:sd1 fs:2000cfb0
store:2 storage:30001 name:RAM1 fs:2000c9b8
store:3 storage:40001 name:PROGM fs:2000c814
store:4 storage:50001 name:QSPI fs:2000c8e0
store:5 storage:60001 name:sflash5 fs:2000d480
store:6 storage:70001 name:sflash6 fs:2000d55c
store:7 storage:80001 name:WINBOND1G fs:2000c3c8
store:8 storage:90001 name:WINBOND2G fs:2000c4bc
 
I was running into that early on in testing but with the latest changes seems to picking it up without a problem in windows. It has happened to me when I have had a external card reader attached to as well.

Code:
Dump Storage list(9)
store:0 storage:10001 name:sdio fs:2000cae0
store:1 storage:20001 name:sd1 fs:2000cfb0
store:2 storage:30001 name:RAM1 fs:2000c9b8
store:3 storage:40001 name:PROGM fs:2000c814
store:4 storage:50001 name:QSPI fs:2000c8e0
store:5 storage:60001 name:sflash5 fs:2000d480
store:6 storage:70001 name:sflash6 fs:2000d55c
store:7 storage:80001 name:WINBOND1G fs:2000c3c8
store:8 storage:90001 name:WINBOND2G fs:2000c4bc

Thanks. It is several things I missed. First of all on this computer I was still on TD1.56B2. I updated and still had the problem. Ran MTP_Teensy and both sd1 and WINBOND2G showed up so I need to figure out what needs to be done. Also realized when I created the version 2 branch of DiskIO and uploaded the files that I did not delete some of the version 1 files that were renamed. Also fixed some bugs. Just noticed that free space on LFS drives is wrong. It's the same for all LFS drives:( More to explore in DiskIo...
 
Last edited:
Quick update:

Been looking into two fundamental issues:

1) Why we are losing data on receive (SendObject) as I have mentioned, like both windows and Ubuntu even with my BogusFs to rule out FS too slow or the like.
last run on Ubuntu lost 3 packets out of something like 42000 - No progress here.

2) Sending an object To the PC (GetObject) at times appears to send it but MTP appears to be hung... I think this may be that if last packet we send is FULL size, maybe the other side is waiting for us to send a
Zero length packet to let it know we are done...

End points do have the option to turn on Zero Length packets... I see in usb.c
void usb_config_tx(uint32_t ep, uint32_t packet_size, int do_zlp, void (*cb)(transfer_t *))

I see that most of the USB types are setting up with false passed in, currently including MTP... But Serial sets it true...

Now to experiment and set it true...

Edit: So far not appearing to help... Was wondering how that worked. Especially if for example we send to host (GetObject) the file that is something like 22mb
where you are sending like again like 42000 512 byte packets, if this would then cause the end point to send a ZLP after each full packet?
And what would the host think of this.

Note: To the host this is one complete stream of data for the whole file.

Maybe back to drawing board.
 
Last edited:
@KurtE - Ran into this while playing MTP_Teensy. It is not making sense and could be an issue or just me:) But testing on a 16Gig thumb drive I copied the DIskIOV2 directory to it and then copied it back to my Linux box. File sizes are different or not correct:
Screenshot at 2021-11-23 17-25-06.jpg

The pane on the left is the file sizes that was copied back from the 16Gig thumb drive by MTP. The pane on the right is what was copied to the 16Gig thumb drive. As you can see several file sizes are different. If I copy 32K file to the same thumb drive and copy it back the file size is the same.

Not sure if this is a clue or a result. Multiples of 2,4,8,16? This was a complete directory copy to and from the thumb drive. Will do more testing as I have 4 day's off this week:)

Edit: The pane on the right is the real file sizes. Did not run into MTP hanging in this session???

Edit2: Something else I just noticed is pin 13 (sclk) LED is blinking during the transfers to USB drives. Is this a debug feature?
 
Last edited:
Morning all (at least here)

Note: As @mjs513 and myself were testing some stuff yesterday, it looks like the GetObject stuff may have been a false problem. That is maybe not an issue of needing Zero length packet, in fact looks like best off to send full packet size even if only a few bytes left in the object. Note from previous post, turning on the ZLP option appears to hurt not help in this case.

@wwatson, thanks for the testing.

Yes there appears to be issues of files failing to fully transfer. Still trying to get hints on where/when packets lost.

Also good MTP not hanging now. That is we are detecting that the file transfer failed to give us the full contents... Will clean up some of this code. Right now will only bail if we get two zero length packets in a row. On the chance that they may send additional stuff, but have not seen any debug output showing this as a case.

Next debug thing on this, is to not only capture the size of each packet, but also any transfer status that it may contain...

Pin 13 flashing... Not that I am aware of... As it should be free to be used by SPI...

Now back to playing
 
Follow on from above:

I was curious about if maybe there might be hints in the USB information received on stuff missing.

So I updated the usb_mtp.c.h code to have a new extended function:
int usb_mtp_recv_extended(void *buffer, uint32_t *transfer_status, uint32_t timeout);

Which returned the status field of the transfer packets to caller... The existing api just simply called this one and did not return that value...

I pushed that code up in new branch of my fork of cores:
I then hacked up my t4 version of SendObject to check if this changes at all from packet to packet. Note Part of this field is used to know how many bytes the system returned.

Like:
Code:
    cb_recv = usb_mtp_recv_extended(rx_data_buffer, &rx_status, SENDOBJECT_READ_TIMEOUT_MS);
    if (rx_status != rx_status_last) {
      printf("  >> %u %x!=%x\n", len, rx_status, rx_status_last);
      rx_status_last = rx_status;
    }

Note: I did the 20+mb special file about 5 times to MSC drive and did not get any failures or any different data except for first packet as I init the... _last = 0...

And tried transferring to SD and got a failure and a different status:
Code:
LP:37089 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:4b : 80001 ffffffff
37089 DATA:100c(SEND_OBJECT_INFO)l: 194 T:4b : 0 3000 14feff4 3000 0
SendObjectInfo: 524289 4294967295 20004560: ST:0 F:3000 0 SZ:22015988 3000 0 0 0 0 0 0 0 0 0 0 : T4LargeIndexedTestfile.txt
Read DateTime string: 20211124T073717.0
>> date/Time: 619debad 11/24/2021 7:37:17
Created: 619debad
Read DateTime string: 20211105T072016.0
>> date/Time: 6184db30 11/5/2021 7:20:16
Modified: 6184db30
37095 RESP:2001(RSP:OK)l: 24 T:4b : 80001 ffffffff 18
LP:37095 CMD: 100d(SEND_OBJECT)l: 12 T:4c
MTPD::SendObject: len:22015988
  >> 22015488 8000!=0
  >> 1024 2008000!=8000

MTPD::SendObject *** USB Read 0 bytes ***
len 1024 diskpos: 1012
 # USB Packets: 42998 total: 356 avg ms: 0 max: 1
 # Write: 10750 total:1046 avg ms: 0 max: 10(9801)
  >> >=100ms: 0 50:0 40:0 30:0 20:0 10:1
  >> Last write times
  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>>>Total Time: 1416503
38512 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:4c
LP:38547 CMD: 1005(GET_STORAGE_INFO)l: 16 T:4d : 80001
524289 7 name:SD_Builtin
524289 7 name:SD_Builtin
38547 RESP:2001(RSP:OK)l: 16 T:4d : 80001

So now to look up what the 2008000 implies...

EDIT: Probably not related, but that high bit is bit 25 I believe, so looking at different flags/values I see
Code:
#define USB_USBSTS_TI1				((uint32_t)(1<<25))
Which is probably not the right thing, but...

EDIT2: Disregard previous edit:
What this implies is count of bytes received: (512-512) = 0;
int len = rx_packet_size - ((t->status >> 16) & 0x7FFF);
So no other indication of where we lost two packets.
 
Last edited:
Paul and others: @mjs513 had a good idea of trying to capture these USB issues of either windows dropping the MTP or we miss some packets when doing SendObject...
and sent me a capture of when it aborted quickly. It showed some interesting things about BULK transfers, that the host data in BULK...

So I was curious if I could capture when we may lose a few transfers of data.

Code:
LP:1599698 CMD: 100d(SEND_OBJECT)l: 12 T:117
MTPD::SendObject: len:22015988
  >> 22015488 8000!=0
  >> 512 2008000!=8000

MTPD::SendObject *** USB Read 0 bytes ***
count_bytes_left_ 512 diskpos: 1524
 # USB Packets: 42999 background: 0 total: 12 avg ms: 0 max: 1
 # Write: 10750 total:4180 avg ms: 0 max: 6(7185)
  >> >=100ms: 0 50:0 40:0 30:0 20:0 10:0
  >> Last write times
  0 1 0 0 1 0 0 1 0 1 0 0 1 0 0 1 0 1 0 0 1 0 0 1 0 1 0 0 1 0 1 0
>>>Total Time: 4195624
1603894 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:117
LP:1603931 CMD: 1005(GET_STORAGE_INFO)l: 16 T:118 : 50001
327681 4 name:MSC2-EXT_FAT32
327681 4 name:MSC2-EXT_FAT32
1604940 RESP:2001(RSP:OK)l: 16 T:118 : 50001
The line: count_bytes_left_ 512
Says we lost one line.

I plugged the SSD that was connected to teensy to pc and did a compare and sure enough we see one packets data missing:
screenshot.jpg
What is interesting that we see in wireshark is that while our packet sizes we ask for in the usb descriptors ask for 512 bytes, the host actually sends a lot of this in big "BULK" writes.

It alternates sending a 512 byte packet (plus overhead) followed by a 511*512 byte packet plus overhead and back to 1, followed by 11... As I scribbled in red

So now to see where/if the host tried to send a packet that has our index number: 12804

And it looks like it is in the middle of big transfer... 12801 through 12928
screenshot3.jpg

Again now have no idea how to debug how our underlying USB code works with this large bulk transfer...
 
@Paul and all,

Follow on to previous post. Tried similar on Ubuntu 20.04.. Installed Wireshark again plus modprobe ...

Moved the same Teensy board plus SSD to machine (running same sketch...)
This transfer looks like it lost 2 packets:

Code:
LP:156321 CMD: 100c(SEND_OBJECT_INFO)l: 20 T:164 : 40001 ffffffff
156321 DATA:100c(SEND_OBJECT_INFO)l: 118 T:164 : 40001 3004 14feff4 0 0
SendObjectInfo: 262145 4294967295 200098a0: ST:40001 F:3004 0 SZ:22015988 0 0 0 0 0 0 0 ffffffff 0 0 0 : LargeIndexedTestfile.txt
Created: 0
Modified: 0
156587 RESP:2001(RSP:OK)l: 24 T:164 : 40001 ffffffff 2a
LP:156587 CMD: 100d(SEND_OBJECT)l: 12 T:165
MTPD::SendObject: len:22015988
  >> 22015488 8000!=0
  >> 1024 2008000!=8000

MTPD::SendObject *** USB Read 0 bytes ***
count_bytes_left_ 1024 diskpos: 1012
&&DT (0,0) (1546300956,1546300956)
 # USB Packets: 42997 background: 1 total: 1503 avg ms: 0 max: 5
 # Write: 10750 total:2828 avg ms: 0 max: 16(1)
  >> >=100ms: 0 50:0 40:0 30:0 20:0 10:1
  >> Last write times
  0 1 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0 1
>>>Total Time: 4336921
160925 RESP:2007(RSP:INCOMPLETE_TRANSFER)l: 12 T:165

One interesting difference between windows and Ubuntu is the sizes of the bulk transfers. From looking at USB document, I believe it depends on how busy the USB is... And the USB controller can decide... Beyond my pay grade ;)

Screenshot from 2021-11-27 06-21-39.png
Where as the Windows ones looked like it was alternating sending 511 and 1 512 byte packets, this Ubuntu one looks like it is sending mostly bulks of 32 512 packets...

Also should note in both cases I believe after the Teensy hardware receives a URB_BULK it responds back with handshake, probably saying it received it... As USB spec chapter 5 mentions that guaranteed delivery, and retry...

Again I have not checked yet to see where in this capture the packets were probably lost.
 
@Paul - @KurtE and all
I did a similar capture for the T3.6 using a 128GB MSC drive and the results were similar to that of the T4.1 in that there is a small packet (91 bytes) then a small bulk out packet and then a 261K bulk transfer. The following 2 images illustrate that as well as that is a repeating pattern as the data is received.
InkedCapture0_LI.jpg
InkedCapture1_LI.jpg

In this case the file transfer completed successfully.
 
Back
Top