Teensyduino File System Integration, including MTP and MSC

Kinda makes me wonder if SDIO is really working on Teensy 4.0 with the change to SdFat? Maybe I'll dig out one of those early breakout boards from the 2019 beta test...
Ok found one of the later boards with a 1062. SDIO doesn't seem to work on that breakout board but then I seem to remember we had to access it as SPI1? Too long ago now. Audio files do play from the audio shield though but can't seem to play anything but wav files from the USB drive.

But I did try it on Longlow's early breakout board for T4 and SDIO works from there - didn't hook up the Audio card yet maybe tomorrow to try SDIO and USB from there.

IMG-0550.jpg
 
Last edited:
Just a follow on. Using the Loglow board with SDIO and USB:
View attachment 26801

Did verify it plays .wav files and other codecs not issue from SDIO. However, only wav files seem to be playing from USB on the board.
 
Kinda makes me wonder if SDIO is really working on Teensy 4.0 with the change to SdFat? Maybe I'll dig out one of those early breakout boards from the 2019 beta test...

Same here. Tested with the PJRC T4.0 breakout board. Played several Wav, MP3, FLAC files on it. They all played as expected on SDIO, external SD, and USB devices. With and without a USB Hub on the host USB port.
 
Hmm wonder why my board isn’t recognizing ship?

Interesting. Was there more than one version of the PJRC T4.0 Breakout board? Going to try some different USB devices and see what the results are. Physically they look the same but electrically maybe not. Got to get ready for work tomorrow:)

Out of being totally curious, what is the current state of MTP_Teensy?
 
Interesting. Was there more than one version of the PJRC T4.0 Breakout board?

Yes, several different breakout boards were made, but only the last 2 versions gave access to SDIO. The first SDIO breakout used tiny pogo pins. I'm pretty sure I only made 1 which never left my workbench, since it was almost impossible to get the pins to mate successfully. The final breakout had the FFC connector. The last version was also the only board to have the coin cell holder for VBAT.

Only a few people received breakboard boards before this final version with SDIO and the VBAT coin cell.

An early breakout, before the change to the final pinout which gave up Serial8 to get FlexCAN3, had 8 serial port headers and 5 mux chips for both I2S ports controlled by a toggle switch.

There was also a breakout similar to the final one without the mux chips and toggle switch, which is the point where we learned about the high speed signal quality issue with MCLK (the mux chips on earlier versions added enough series resistance and extra capacitive load than MCLK wasn't a problem). Some copies of that breakout board were made with the MCLK trace cut and a resistor soldered over the gap.

Very early breakouts had boards with the 1052 chip and an early "fat" Teensy 4 which was 0.9 inches wide, before I managed to get it all crammed into the 0.7 inch form factor.

Many other very early breakout never left my workbench. Some even were even a pair of boards with pogo pins hitting the prototype from both sides, in the very early days before I had FlexSPI working and needed to watch lots of signals.
 
Did some more testing with the Teensy 4.0 and play all file MTP_test_audio sketch.
  1. Using loglow's breakout board was able to verify that all file types played from SDIO: wav, mp3, flac, and aac. However only wav files played from a USB SanDisk 128gb mem stick as well as from a Crucial 500gb SSD drive. Interesting enough had no issues with transferring large files to the USB drive. Forgot to try on the SDIO drive.
  2. On the original T4 breakout could get SDIO to be recognized. The one I have is the one with the white wire on the bottom, a battery holder and a FFC cable? USB results same as for loglow's board
  3. On one of my custom T4 breakout boards I tried a T4 (non-lockable) with the USB and same thing so thing its real. Funny thing is if I used the latest lockable T4 almost impossible to get it to recognize a USB drive in my breakout but so thats when I switched over to an un-lockable T4.
 
Hmm wonder why my board isn’t recognizing ship?

Not sure Mike- pulled out the T_4 beta w/battery looks like p#601 pic.
>> Works here, and got a bootloader update 1.05 to 1.07 in the process of doing just SDIO listfiles.ino
- it has FFC connector cable and USB Host Pogo pin connects here.

And weeks back soldered a last Lockable T_4 beta board to a FRDM 4236 to get working USB Host and SDIO SD socket.

Neither tried audio playing - but DumpFile.ino works

EDIT: Yes, that is the white wire included breakout - seems to work here.
 
Hi Tim
Not sure why SDIO is not working on the breakout either
>Yes it updated to bootloader 1.07 as well - just double checked
> Issue with lockable T4 with usb and my breakout I am pretty sure is just an issue with getting a good connection because I tested it before in a different breakout but figure wanted to just document what I am seeing.
> Ran SDINFO directly from SDFat and it returned a 0x17 error on ACMD41 which an error that the card needs to be initialized - so.....

So have no idea why my board not working - going to try and troubleshoot in the morning - too late now.

EDIT: @defragster - couldn't wait - went the simple route first - took t4 out and push the cable on the T4 and breakout and SDIO now working - funny thing though didn't even seem like it moved.
 
Last edited:
You can rest easy now it works - even if not clear it shifted enough to explain it - maybe it just wiped something clean after sitting?

I pulled the T_4 up to see the white wire and pushed it back - still working here - so cable stayed connected.

<edit>: been scanning posts, but otherwise wholly distracted again, not sure what changes needed to catch up with current WIP ...
 
As I mentioned I was playing around with one of the FRDM4236 break out board kits...
http://www.trainer4edu.com/edubase_teensy/frdm_4236.html

Mine has the 5 pin USB connection on it, although never soldered pins into it...

Have one of those as well but never could get the soldering straight with the sd card connections.

Anyway the good news I found out why my USB wasn;t working - had a typo in the massdriverstorage.cpp file for the read. Once fixed all worked fine both for both drives I mentioned earlier.
 
Interesting. Was there more than one version of the PJRC T4.0 Breakout board? Going to try some different USB devices and see what the results are. Physically they look the same but electrically maybe not. Got to get ready for work tomorrow:)

As has been mentioned since you posted, there have been a few different ways people have connected up the SDIO on the T4. I have a few different ones including the ones from Paul, which uses the connectors and ribbon cable. I tried doing my own boards with these, but had hard time getting two of those dinky connectors soldered up such that all of the connections work along with the ribbon cable. I had better luck with the FRDM... castellated boards, although not all of my solder attempts worked with these either. So was glad when the T4.1 arrived!

Out of being totally curious, what is the current state of MTP_Teensy?
Not sure what fully you are asking, but my 2 cents

I think there are working well, but others that still need some more tweaks and the like, plus lots of testing...
Currently I am sort of in a holding pattern hoping Paul will find the issue where on T4.x sometimes we lose packets within a transfer.

Then will work some more on trying to figure out how to avoid MTP timing out on us. We hit this reasonably often on things like SendObject to some LittleFS stores...
Likewise copy a file from one store to another again with LittleFS...

If you are asking will MTP_Teensy library ship with Teensyduino soon? My impression is that once we are happy with how it is working, we will integrate it into the core code instead of independent library, in the same way as the code for other USB types.
 
Now for a completely random Side Note: yesterday while wondering what was going on with MMOD, like: does the file look reasonable...

I hacked up sketch that listed the contents of the SD Card, and then you could dump a file... One block at a time, or at end of block type a<cr> would dump the rest...

Well I did not like that the MemoryHexDump would display the address of the buffer, so added the ability to set the logical address for starting to display for each block, by location on disk... So updated it,
decide OK for example sketch... So now changed pushed up to github...
Code:
D:\GitHub\MemoryHexDump\examples\SDFileDump\SDFileDump.ino Dec  6 2021 09:35:27  - Teensy 40
Date: 6 Dec 2021 9:35:34

Setup done
Directory
---------
System Volume Information/
  WPSettings.dat                      12
  IndexerVolumeGuid                   76
odd1.wav                              553004
zarathustra.mp3                       489461
2001/
  calculations.wav                    426300
  completed.wav                       276460
  dangerous_to_remain.wav             372892
  enough_info.wav                     513388
  functional.wav                      237356
  one_moment.wav                      202236
  operational.wav                     772140
  sorry_dave.wav                      791164
  stop.wav                            200844
Audacity/
  Away_in_a_Manger.mp3                2014737
  Dont_Rain_on_My_Parade.mp3          3944449
  Take_My_Breathe_Away.mp3            5740819
  Welcome_Christmas.mp3               2985790
FLAC/
  T1_1024.FLA                         9802802
  T1_128.FLA                          11126659
  T1_256.FLA                          10415954
  T1_512.FLA                          10007370
Candyman.aac                          3177823
Dont Rain on My Parade.mp3            3944449
mtpindex.dat                          0
odd1.mp3                              46888

Enter new file name to dump or hit enter to dump: 2001/stop.wav
Dumping 2001/stop.wav

File Offset: 0
00000000 - 52 49 46 46 84 10 03 00  57 41 56 45 66 6D 74 20  : RIFF.... WAVEfmt 
00000010 - 10 00 00 00 01 00 02 00  44 AC 00 00 10 B1 02 00  : ........ D.......
00000020 - 04 00 10 00 64 61 74 61  60 10 03 00 03 FC 03 FC  : ....data `.......
00000030 - EC FA EC FA 19 FA 1A FA  8D F9 8A F9 3E F9 41 F9  : ........ ....>.A.
00000040 - 06 F9 06 F9 C3 F8 C0 F8  47 F8 4C F8 8F F7 8A F7  : ........ G.L.....
00000050 - 87 F6 89 F6 4B F5 4C F5  EE F3 EB F3 8E F2 92 F2  : ....K.L. ........
00000060 - 43 F1 40 F1 21 F0 22 F0  29 EF 29 EF 61 EE 60 EE  : C.@.!.". ).).a.`.
00000070 - C3 ED C4 ED 43 ED 42 ED  EA EC EC EC AA EC A7 EC  : ....C.B. ........
00000080 - 91 EC 94 EC A4 EC A2 EC  E1 EC E2 EC 4E ED 4D ED  : ........ ....N.M.
00000090 - CC ED CC ED 4B EE 4C EE  A4 EE A4 EE BD EE BC EE  : ....K.L. ........
000000A0 - 8F EE 90 EE 22 EE 21 EE  A2 ED A3 ED 38 ED 37 ED  : ....".!. ....8.7.
000000B0 - 1D ED 1E ED 5D ED 5C ED  FB ED FC ED CE EE CE EE  : ....].\. ........
000000C0 - A7 EF A6 EF 5C F0 5E F0  D8 F0 D5 F0 29 F1 2C F1  : ....\.^. ....).,.
000000D0 - 7D F1 7A F1 FA F1 FD F1  CB F2 CA F2 DE F3 DD F3  : }.z..... ........
000000E0 - 10 F5 12 F5 1F F6 1D F6  D5 F6 D5 F6 19 F7 1B F7  : ........ ........
000000F0 - 10 F7 0E F7 F7 F6 FA F6  2D F7 2A F7 EC F7 ED F7  : ........ -.*.....
00000100 - 43 F9 44 F9 03 FB 01 FB  BB FC BF FC 11 FE 0C FE  : C.D..... ........
00000110 - 9D FE A2 FE 72 FE 6D FE  B4 FD BA FD FD FC F7 FC  : ....r.m. ........
00000120 - AE FC B3 FC 49 FD 45 FD  C9 FE CB FE 00 01 01 01  : ....I.E. ........
00000130 - 84 03 80 03 B0 05 B6 05  4A 07 44 07 FC 07 01 08  : ........ J.D.....
00000140 - 05 08 00 08 A0 07 A5 07  33 07 2F 07 01 07 03 07  : ........ 3./.....
00000150 - 21 07 21 07 7D 07 7C 07  DA 07 DB 07 01 08 FF 07  : !.!.}.|. ........
00000160 - CA 07 CC 07 43 07 43 07  95 06 95 06 FF 05 FE 05  : ....C.C. ........
00000170 - C7 05 C8 05 0C 06 0A 06  D4 06 D8 06 02 08 FE 07  : ........ ........
00000180 - 51 09 54 09 8F 0A 8C 0A  7A 0B 7E 0B 01 0C FC 0B  : Q.T..... z.~.....
00000190 - 13 0C 18 0C D9 0B D5 0B  6C 0B 6F 0B 02 0B FE 0A  : ........ l.o.....
000001A0 - BA 0A BF 0A AA 0A A5 0A  C8 0A CD 0A 03 0B FE 0A  : ........ ........
000001B0 - 23 0B 27 0B 17 0B 14 0B  AD 0A B0 0A 00 0A FF 09  : #.'..... ........
000001C0 - 18 09 16 09 29 08 2D 08  73 07 70 07 02 07 03 07  : ....).-. s.p.....
000001D0 - ED 06 EE 06 10 07 0E 07  24 07 26 07 FC 06 FC 06  : ........ $.&.....
000001E0 - 49 06 47 06 03 05 05 05  30 03 2F 03 0B 01 0A 01  : I.G..... 0./.....
000001F0 - CD FE D0 FE CD FC CA FC  23 FB 25 FB F4 F9 F3 F9  : ........ #.%.....
(Q/A):

Now back to the next random thing ;)
 
@Paul - Thanks for the explanation. I Probably have one of the last versions. I think by looking at @mjs513's photo our T4.0 breakout boards are the same ones. Have not had any issues with it so far that I can detect. The Audio board, SDIO and Host USB seem to perform the same as the your T4.1 break out board without issue hardware wise. The only thing I have not worked with is the CAN buss break out on the T4.0 board. Maybe some time soon I will get the time.
 
@KurtE - @Paul gave me a heads up on his the T4.0 breakout boards. As far as MTP_Teensy is concerned, I guess it's still a moving target. Not trying to be pushy just curious is all:)
 
I'm looking into the packet loss issue. I'm able to reproduce it with Kurt's BogusFS code and LargeIndexedTestfile.txt (which really should win an award or something for the most reproducible test case....)

Here is a screenshot from the Beagle 480 protocol analyzer on a run with "BF Sequence error 3106 3104".

screenshot.jpg

Looks like the packet was received by the Teensy 4.1 hardware and a NYET reply was sent. NYET is a special token used only at high speed which means the same as ACK, but also indicates the receive buffer does not have room for another packet. The host is supposed to first send a PING token if it's heard NYET, and you can see that is indeed happening. The data 0/1 toggle is also correct on the data tokens. Everything appears to be as it should be, at least externally viewable.

Now I'm re-reading the USB dTD info in the reference manual and considering how to dig into this problem on the Teensy side.
 
Glad you are able to reproduce. So keeping fingers crossed it won’t be too hard to resolve
 
Continuing work on this. The received packet loss bug is definitely on the Teensy side in managing the linked list of dTD structures.
 
Continuing work on this. The received packet loss bug is definitely on the Teensy side in managing the linked list of dTD structures.

Just having morning coffee and catching up = as Kurt said glad you are able to reproduce the problem and looks like you have it isolated it down to the linked list. Keeping fingers crossed it won't be too much of a headache to fix.
 
@KurtE - @Paul gave me a heads up on his the T4.0 breakout boards. As far as MTP_Teensy is concerned, I guess it's still a moving target. Not trying to be pushy just curious is all:)

Not a problem... So am I (curious)...

Once we have reliable USB communications, there are some more moving parts to figure out and finalize (at least for this next release). How many of these that need to get done and what changes that will likely be made are things that Paul will have to decide. Some of the things I see include:

a) MSC migration into USBHost library: I believe is working well, but I did change the directory layout of this library to make it build using the newer library layout, where the sources go into src directory. Assuming that this is agreed to, then there are probably still some stuff that needs to be cleaned up, including the 2nd header file I added as was having issues with files that included both USBHost_t36.h and FS.h

Also some of the sources in sub-directories, maybe can be thinned out. That is how many of these files are needed for MSC to work here... That is an area that you for sure can help out on.

b) FS.h - Are there more enhancements we should do for this release. Again things like: File Pre-allocate, Information on preferred file operations (logical sector, cluster size), Some way to know what type of File system you are connected to. This might include information on like, is this (SD, LittleFS, or other) and is stored using (SPI, QSPI, RAM, MSC)...

c) MSC stuff... As I mentioned at some point probably merge into cores. But there are still lots of things to fix and extend, like:
1) Timeouts - When the host (Windows lets say) decides it waited to long for an operation to complete, it more or less crashes the USB connection. This happens mostly, when we are uploading files to places like LittleFS (Flash). So trying to minimize how often that happens, and potentially have code that reports back to PC before the operation fully completes and/or tries to pace the operations, to keep host ahppy.

2) Make Storage Index file more robust. For example suppose the chosen drive is an SD and you pull out the card... It can not write there so everything crashes. Maybe good if we work around it and maybe choose different drive or...

3) SD cards and handle card insertions and removals.

d) Notification/events How to let other sub-systems know that something changed.
You add3d a storage to MTP and your underlying code, creates a new file. How do you let MTP know that something changed as to let it notify host... Likewise suppose you have your SD shared out on MTP, and the user copies a new file to your storage. How does your sketch learn about what has changed.

Probably more things, that I forgot here, but maybe enough here to keep a few of us busy!
 
I'm still working on the USB received packet loss issue. It's a tough one.

But if you'd like an ugly & slow workaround to at least get reliable communication now, try adding delayMicroseconds(10) at the end of schedule_transfer() in usb.c.

It's also becoming apparent we could do quite a lot of improve performance in the future. But right now I just want to get it to a stable & usable point which we could include in release 1.56. Performance optimization can always come later.
 
That sounds like a tough thing! At least you found some hackable indication of a work around that might lead to understanding and toward a solution. And you have a good repro case to work with.
 
Back
Top