Many TLAs: MTP MSC FS SD SDFat LittleFS UsbMSCFat to work with each other 8)

@KurtE - Nice. Looks like you have been hard at it again:) Will update and test today.

@All - I finally uploaded what I have so far with TeensyEXT4 to GitHub. It's not much at this time but is a start. WIP with lots more to do. The README will show how to setup a USB drive to be used with it. Also have added several links including the link to the original author of lwext4.

Here is the link:
https://github.com/wwatson4506/TeensyEXT4/tree/main

Here is the example output:
Code:
Teensy EXT4 file system testing

open_filedev: Passed
ext4_mbr_scan:
mbr_entry 0:
 offeset: 0x100000, 1MB
 size:    0x39a200000, 14754MB
mbr_entry 1:
	empty/unknown
mbr_entry 2:
	empty/unknown
mbr_entry 3:
	empty/unknown
mbr_scan() Passed

test_lwext4_mount() Passed

********************
ext4_mount_point_stats
inodes_count = 944704
free_inodes_count = 944691
blocks_count = 3777024
free_blocks_count = 3692116
block_size = 4096
block_group_count = 116
blocks_per_group= 32768
inodes_per_group = 8144
volume_name = TEENSYEXT4
********************

cleanup:
remove /mp/test1
remove /mp/dir1
cleanup: time: 0 ms
Done...

On this 16G thumb drive I only had one partition setup. Up to the usual 4 can be used each one being a separate block device. Multiple drives can be used (haven't tried that one yet). Each drive would have a separate mount point with up to 4 partitions each. On an ext4 formatted USB drive in the main directory you will in this case have a directory named 'mp'. This will require root access rights such as 'sudo' or being logged in as root. Use caution when working as root!
A newly formatted ext4 USB drive will have a lost and found folder that I moved into the mp folder. This was based on running Gkostka's original lwext4 in Linux.

That's what I have so far if anybody want's to play:)

EDIT: I am using lwext4's test program in steps to test TeensyEXT4
 
Last edited:
@Kurte - Hope you are having fun with the new MM:) I spent most of the day installing and testing your updates for time stamps. I finally got my Windows 7 working with Virtualbox and MTP_4. It is showing all of the drives and and partitions:) I found that using older and slower flash drives would intermittently fail to copy and or delete files but using the newer faster thumb drives and SSD drives worked without issue. The only other issue is the time stamping is not working. If I copy a file from Windows to any of the Teensy MTP devices the time stamp is not readable buy Windows or Linux after I plug the device directly into the computer. In Linux the time stamp comes up as unkown and in Windows it does not show a time stamp at all. Maybe I am missing something. As usual:)

Anyway, going back to work on ext4 tomorrow.
 
@KurtE - @wwatson

Hopefully tomorrow will download all the latest repositories again :)

Think if you are going to go all the way might be better to an enumerator. Might make it easier in the long run.

Almost forgot - hopefully will get to lwet4 as well - been too distracted with that darn camera :)

Almost ready for a test - wish the MM had a PSRAM chip on it.
 
@mjs513 - Want a viable distraction right now. Still to to short to look over the brick wall. You know, "can't seem to walk away from it" type:) Taking a break from it till tomorrow.
 
USB HOST on MM.Teensy w/USB-C can power a HDD

I copied libs yesterday - just got a compile done in USB_HOST_T36 :: mscTesting.ino

SerMon out put below shows it finding First the SINGLE 64MB Flash drive.

Wondering about a HUB ... my external (powerable HUB) with internal 120GB HDD
> The HUB/HDD is not plugged in to power - it is unpowered
> MM.Teensy is on USB-C cable and can provide enough power to bring up the drive!

After the two individual starts below plugged the 64GB Flash into the 120 GB HDD/HUB and BOTH are recognized together - Un still not plugged in!

Code:
MSC TEST

Initializing USB Drive(s)
msDrive1 not connected: Code: 40
msDrive2 not connected: Code: 40

Press a key to show USB drive info:
msDrive1  connected/initilized
msDrive1 is NOT Mounted
   connected 1
   initialized 1
   USB Vendor ID: 125f
  USB Product ID: db8a
      HUB Number: 0
        HUB Port: 0
  Device Address: 1
Removable Device: YES
        VendorID: ADATA   
       ProductID: USB Flash Drive 
      RevisionID: 1.00
         Version: 6
    Sector Count: 121241599
     Sector size: 512
   Disk Capacity: 62075698688 Bytes
msDrive2 not connected: Code: 40
Code:
Press a key to show USB drive info:
msDrive1  connected/initilized
msDrive1 is NOT Mounted
   connected 1
   initialized 1
   USB Vendor ID: 0080
  USB Product ID: a001
      HUB Number: 2
        HUB Port: 1
  Device Address: 3
Removable Device: NO
        VendorID: TO Exter
       ProductID: nal USB 3.0     
      RevisionID: 0203
         Version: 6
    Sector Count: 234441647
     Sector size: 512
   Disk Capacity: 120034123264 Bytes

msDrive2 not connected: Code: 40
 
Second test - Powered that Hub its internal HDD and added Flash come up.

Pulling USB cable turns off the Carrier board and also Using the Nifty Digistump USB power line switch it stays connected USB but switches off the carrier and the MCU board.

> Unlike T_3.6/4.1 which ends up back powered from the hub once connected and Device USB is connected.

ALSO: 15 sec Restore holding Program / BOOT button WORKS - except flashes then on release HOLDS ( a long 16MB time ) the Orange(?) Status LED on MM.T - and performs the reset
>> Returns with as USB HID with Blue LED_BUILTIN==13 blinking

Next upload works when that HID PORT is selected in T_ports list - without button push.
 
@defragster - confused
Code:
    Press a key to show USB drive info:
    msDrive1  connected/initilized
    msDrive1 is NOT Mounted
       connected 1
       initialized 1
       USB Vendor ID: 0080
      USB Product ID: a001
          HUB Number: 2
            HUB Port: 1
      Device Address: 3
    Removable Device: NO
 [COLOR="#FF0000"]           VendorID: TO Exter
           ProductID: nal USB 3.0     
          RevisionID: 0203
             Version: 6[/COLOR]
        Sector Count: 234441647
         Sector size: 512
       Disk Capacity: 120034123264 Bytes

    msDrive2 not connected: Code: 40

This one makes no sense:confused:

With MSC when a USB drive is unplugged the disconnect callback should clear the msDriveInfo struct for that instance of msController.

Code:
void msController::disconnect()
{
	deviceAvailable = false;
	println("Device Disconnected...");
	msDriveInfo.connected = false; [COLOR="#FF0000"]// Just noticed this line and the next should  be removed. (Redundant)[/COLOR]
	msDriveInfo.initialized = false;
	memset(&msDriveInfo, 0, sizeof(msDriveInfo_t));

No USB drive info should be retained if the device is unplugged. If not the disconnect interrupt did not happen for some reason.
That is if I understand what you are showing.
 
@defragster - confused
...
This one makes no sense:confused:

With MSC when a USB drive is unplugged the disconnect callback should clear the msDriveInfo struct for that instance of msController.

...
No USB drive info should be retained if the device is unplugged. If not the disconnect interrupt did not happen for some reason.
That is if I understand what you are showing.

The sketch ran one time - I hit enter with the FLASH drive directly plugged in > giving the first output block

I pulled the FLASH and plugged in the Single Hub Device that has a 120GB HDD in it ( while it was otherwise unpowered )

Then I hit send to prompt it to rescan and that > gave the second output block

If that shows a problem let me know and I can look deeper ...

If it helps this is what it shows doing an upload with both of those devices ( HDD internal to HUB and FLASH plugged in ) and hitting the 'ANY' key::
Code:
MSC TEST

Initializing USB Drive(s)
msDrive1 not connected: Code: 35

msDrive2  connected

Press a key to show USB drive info:

msDrive1  connected/initilized
msDrive1 is NOT Mounted

   connected 1
   initialized 1
   USB Vendor ID: 0080
  USB Product ID: a001
      HUB Number: 1
        HUB Port: 1
  Device Address: 2
Removable Device: NO
        VendorID: TO Exter
       ProductID: nal USB 3.0     
      RevisionID: 0203
         Version: 6
    Sector Count: 234441647
     Sector size: 512
   Disk Capacity: 120034123264 Bytes

msDrive2  connected/initilized
msDrive2 is NOT Mounted

   connected 1
   initialized 1
   USB Vendor ID: 125f
  USB Product ID: db8a
      HUB Number: 1
        HUB Port: 4
  Device Address: 3
Removable Device: YES
        VendorID: ADATA   
       ProductID: USB Flash Drive 
      RevisionID: 1.00
         Version: 6
    Sector Count: 121241599
     Sector size: 512
   Disk Capacity: 62075698688 Bytes

Is what puzzles you just the way the USB3 HUB NAME gets merged with the internal HDD that is coupled to the first device?
 
Last edited:
@defragster @wwatson and all- looks like we need some more testing/debugging it is possible that when we reuse some devices, that when the previous device goes away we (I) did not clear out some of the status correctly so it is sort of ghosting there.

My problem is what to play with first? MSC, MTP, MM, TyTools....
 
@defragster
Which MSC test sketch are you using. If you are using the one that is part of USBHost_t36 that one doesn't seem to work very well. I gave it a try with MicroMod, bus if you use the MSCDriveInfo sketch that is part of @wwatson UsbMscFat library it seems to work a alot better. BTW I am using a unpowered hub:
Code:
Initializing USB MSC drive 1...
UsbBase::mscBegin called 200023a0 1 1
    After usbDriveBegin
myDrive1 Info:
   connected 1
   initialized 1
   USB Vendor ID: 152d
  USB Product ID: 0578
      HUB Number: 1
        HUB Port: 1
  Device Address: 2
Removable Device: NO
        VendorID: HP SSD S
       ProductID: 600 120GB       
      RevisionID: 0509
         Version: 6
    Sector Count: 234441647
     Sector size: 512
   Disk Capacity: 120034123264 Bytes


Volume type is FAT64
Cluster Size (bytes): 131072
Volume size (Kbytes): 102394880
Volume size (Mbytes): 99995

Initializing USB MSC drive 2...
UsbBase::mscBegin called 20002ca0 1 1
    After usbDriveBegin
myDrive2 Info:
   connected 1
   initialized 1
   USB Vendor ID: 13fe
  USB Product ID: 6300
      HUB Number: 1
        HUB Port: 2
  Device Address: 3
Removable Device: YES
        VendorID:         
       ProductID: USB DISK 3.0    
      RevisionID: PMAP
         Version: 6
    Sector Count: 121145343
     Sector size: 512
   Disk Capacity: 62026415616 Bytes


Volume type is FAT64
Cluster Size (bytes): 131072
Volume size (Kbytes): 60539776
Volume size (Mbytes): 59120

@KurtE - so many choices to choose from on what to work on next :)
Think I may have just complicated it by kind of sort of getting the camera - display semi working. Have to figure out how to convert from Bayer to RGB
 
@defragster @KurtE - The two error codes I saw were 40 which is an SCSI error MS_NO_MEDIA_ERR and 35 which is MS_UNIT_NOT_READY a timeout error waiting for the device to become ready. In the USBHost_t36 library is 'msc.h' in the utility folder. If you open that up you will find two timeouts that can be adjusted for waiting longer for the drive to connect and become ready to use. Right around line 73.
Code:
// These two defines are timeouts for detecting a connected drive
// and waiting for it to be operational.
#define MEDIA_READY_TIMEOUT	1000
#define MSC_CONNECT_TIMEOUT 4000

I have found that certain drives can take up to 30 seconds to come up. Especially Hard Drives. Increasing those values will give the drives more time to come up.
They are used in 3 different places.
Code:
// Initialize Mass Storage Device
uint8_t msController::mscInit(void) {
Code:
uint8_t msController::WaitMediaReady() {
And
Code:
// Check if drive is connected and Initialized.
uint8_t msController::checkConnectedInitialized(void) {

@KurtE I am adding this:
Code:
	memset(&msDriveInfo, 0, sizeof(msDriveInfo_t));
to the end of the msController::claim() at line #113 in 'massStorageDriver.cpp'.
Hopefully that will take care of any ghosting problems:)
 
@...

Sounds good. I will sink up to your stuff, soon, Also I need to double check that I put in the timestamp code into the MSC drives. I was mostly testing on SDCards.

The MTP-Test on MM I have mine hacked up like:
Code:
#include "Arduino.h"

#include "SD.h"
#include <MTP.h>

#define USE_SD  1         // SDFAT based SDIO and SPI
#ifdef ARDUINO_TEENSY41
#define USE_LFS_RAM 1     // T4.1 PSRAM (or RAM)
#else
#define USE_LFS_RAM 0     // T4.1 PSRAM (or RAM)
#endif
[COLOR="#FF0000"]#ifdef ARDUINO_TEENSY_MICROMOD
#define USE_LFS_QSPI 0    // T4.1 QSPI
#define USE_LFS_PROGM 0   // T4.4 Progam Flash
#define USE_LFS_SPI 0     // SPI Flash
#define USE_LFS_NAND 0
#define USE_LFS_QSPI_NAND 0
#define USE_LFS_FRAM 0
#else[/COLOR]

Added the stuff in RED. Does come up. Just still trying to figure out why TyTools can program the MM when done from Arduino, but not from Ty...
Probably something simple...
 
Just pushed up a fix to UsbMscFat (FS_DATES) branch to pass through the timestamp from the MTP... So it now appears like when I copy a file into the MTP folder, it shows with the proper dates, and still shows up if your restart the program (or tell system to restart) in command line: r<cr>
 
@kurtE - Got family here so don't have much time today to play but tomorrow I will update and test. Forgot about the r<cr>:) Hope everybody is having a good day.
I am kinda wondering about @defragsters problem, if he was able to get his setup working properly...
 
@defragster
Which MSC test sketch are you using. If you are using the one that is part of USBHost_t36 that one doesn't seem to work very well. I gave it a try with MicroMod, bus if you use the MSCDriveInfo sketch that is part of @wwatson UsbMscFat library it seems to work a alot better. BTW I am using a unpowered hub:
...
@KurtE - so many choices to choose from on what to work on next :)
Think I may have just complicated it by kind of sort of getting the camera - display semi working. Have to figure out how to convert from Bayer to RGB

Noted sketch was the one in USB_HOST_T36 :: mscTesting.ino

Just ran bare 640MB HDD on SATA Adapter and like prior post is shows the APRICORN adapter not the Drive maker as VerndorID:
Code:
   connected 1
   initialized 1
   USB Vendor ID: 0984
  USB Product ID: 0301
      HUB Number: 0
        HUB Port: 0
  Device Address: 4
Removable Device: NO
        VendorID: Apricorn
       ProductID:                 
      RevisionID: 0026
         Version: 6
    Sector Count: 1250263726
     Sector size: 512
   Disk Capacity: 640135027712 Bytes

Was going to post output from using the indicated sketch - but it fails on MicroMod?
Code:
T:\tCode\libraries\UsbMscFat\examples\[B]MSCDriveInfo\MSCDriveInfo.ino[/B] Apr  4 2021 20:28:50

Initializing USB MSC drive 1... with bare 640MB HDD
UsbBase::mscBegin called 20002580 1 1
    After usbDriveBegin
initialization failed with code: 0

And fails on T_4.1 - with hub/drive and Flash:
Code:
T:\tCode\libraries\UsbMscFat\examples\[B]MSCDriveInfo\MSCDriveInfo.ino[/B] Apr  4 2021 20:30:55

Initializing USB MSC drive 1...
UsbBase::mscBegin called 20002580 1 1
initialization failed with code: 35
 
I just pushed up updates to the MTP and MSC github projects, that slightly changed the PFSLib formatter method to return a bool for success and to default most of parameters. You just need to pass in PFSVolume object.

I then updated the MTP code for MSC objects to use the PFSLib call instead of doing its own Formatter and ExFormatter objects calls.

I then added the callback code for SD cards to be able to use this.

Did one simple test to reformat an SD Card...

Note: I also updated the sketch for MicroMod to also do an LittleFS Program object. I assume that that object knows the size of the Flash...

Not sure how much more to do here, other than test things, until knowing if any of this will be integrated.
 
@all - OK, taking a break from TeensyEXT4. It's obvious that there will have to be a complete wrapper for it. There is to much memory stomping going and I have no real way at this point to track what's going on. MSC is locking up on reads before being able to get back the status of the of the disk read (msGetCSW()). If doing direct block device sector reads it works fine (reading the MBR). After that doing any file or directory read/write access fails. At that point it is going through ext4's interface to the block device and locks up MSC. I have check all parameters such as BlockAddress (blk_id), blocks (blk_cnt) and BlockSize (bdev->bdif->ph_bsize). The hard part is the buffer address. In ext4 it can go through several structs and several functions before it finally gets to msReadBlocks(). Not sure how to track that without being able to use Serial.print which with my understanding is not possible.

At this point it been almost 3 weeks since I started working with this. Then the brick wall:( I feel that after I take a break from this and clear my head I will see if using an image file as originally used by lwext4 on a ExFat formatted USB drive with an ext4 image file will work. Not the best choice but the other very time consuming alternative is a converting lwext4 to C++ and trying that:eek:

Opinions of any kind?
 
@KurtE
I just downloaded your latest changes to UsbMscFat and MTP_t4 and am trying it on a T4.1 with SD Card, SSD (2 volumes and a 64GB thumb drive. Uploaded the latest MTP-test sketch and see 2 problems right off the bat:
Capture.PNG
The SD Card on the 2nd volume of the thumb drive are both showing as RED (usually means full but MSC-0 New Volume is empty and the SDCard has only 2 files about 152kbytes:
Code:
MTP_test
sd_addFilesystem: 0 200047d0 sdio 200034d4 0
SDIO Storage 0 254 sdio 0 0
SD Storage 1 10 sd1 failed or missing
sd_addFilesystem: 1 20007768 RAM1 200034d0 20007768
RAM Storage 0 RAM1 199936 512
sd_addFilesystem: 2 20007830 RAM2 200034d0 20007830
RAM Storage 1 RAM2 3999744 4096
sd_addFilesystem: 3 2000522c PROGM 200034d0 2000522c
Program Storage 0 PROGM 983040 8192
sd_addFilesystem: 4 2000bb68 sflash5 200034d0 2000bb68
SPIFlash Storage 0 5 sflash5 67108864 8192
sd_addFilesystem: 5 2000bc40 sflash6 200034d0 2000bc40
SPIFlash Storage 1 6 sflash6 67108864 8192
SPIFlash Storage 2 7 prop failed or missing

Initializing USB MSC drives...
USB Drive Inserted
UsbBase::mscBegin called 20007900 1 1
    After usbDriveBegin

msc # Partition Table
	part,boot,bgnCHS[3],type,endCHS[3],start,length
exFAT:	1,0,0x20,0x21,0x0,0x7,0xFE,0xFF,0xFF,2048,204800000
FAT32:	2,0,0xFE,0xFF,0xFF,0xC,0xFE,0xFF,0xFF,204802048,29634560
pt_#0:	3,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	4,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
  Try Partiton:1 on MSC Index:0
UsbBase::mscBegin called 20007900 0 1
    After usbDriveBegin
    ** SUCCEEDED **
>> USB partition 1 volume ID: New Volume
sd_addFilesystem: 6 200095a8 MSC0-New Volume 200034c0 0
  Try Partiton:2 on MSC Index:1
UsbBase::mscBegin called 20007900 0 2
    After usbDriveBegin
    ** SUCCEEDED **
>> USB partition 2 volume ID: NEW VOLUME
sd_addFilesystem: 7 20009a60 MSC0-NEW VOLUME 200034c0 1
  Try Partiton:3 on MSC Index:2
UsbBase::mscBegin called 20007900 0 3
    After usbDriveBegin
  Try Partiton:4 on MSC Index:2
UsbBase::mscBegin called 20007900 0 4
    After usbDriveBegin
USB Drive Inserted
UsbBase::mscBegin called 20008200 1 1
    After usbDriveBegin

msc # Partition Table
	part,boot,bgnCHS[3],type,endCHS[3],start,length
exFAT:	1,0,0x20,0x21,0x0,0x7,0xFE,0xFF,0xFF,2048,121145343
pt_#0:	2,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	3,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
pt_#0:	4,0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0,0
  Try Partiton:1 on MSC Index:2
UsbBase::mscBegin called 20008200 0 1
    After usbDriveBegin
    ** SUCCEEDED **
sd_addFilesystem: 8 20009f18 MSC1-1 200034c0 2
  Try Partiton:2 on MSC Index:3
UsbBase::mscBegin called 20008200 0 2
    After usbDriveBegin
  Try Partiton:3 on MSC Index:3
UsbBase::mscBegin called 20008200 0 3
    After usbDriveBegin
  Try Partiton:4 on MSC Index:3
UsbBase::mscBegin called 20008200 0 4
    After usbDriveBegin

**** dir of sd[0] ****
OV7670.bmp
test1.txt
mtpindex.dat

Setup done
CMD: 1002(OPEN_SESSION)l: 16 T:0 : 1
RESP:2001(RSP:OK)l: 16 T:0 : 1
CMD: 1001(GET_DEVICE_INFO)l: 12 T:1
RESP:2001(RSP:OK)l: 12 T:1
CMD: 1014(GET_DEVICE_PROP_DESC)l: 16 T:2 : d402
RESP:2001(RSP:OK)l: 16 T:2 : d402
CMD: 1004(GET_STORAGE_IDS)l: 12 T:3
RESP:2001(RSP:OK)l: 12 T:3
CMD: 1005(GET_STORAGE_INFO)l: 16 T:4 : 10001
65537 0 name:sdio
65537 0 name:sdio
RESP:2001(RSP:OK)l: 16 T:4 : 10001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:5 : 20001
131073 1 name:RAM1
131073 1 name:RAM1
RESP:2001(RSP:OK)l: 16 T:5 : 20001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:6 : 30001
196609 2 name:RAM2
196609 2 name:RAM2
RESP:2001(RSP:OK)l: 16 T:6 : 30001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:7 : 40001
262145 3 name:PROGM
262145 3 name:PROGM
RESP:2001(RSP:OK)l: 16 T:7 : 40001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:8 : 50001
327681 4 name:sflash5
327681 4 name:sflash5
RESP:2001(RSP:OK)l: 16 T:8 : 50001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:9 : 60001
393217 5 name:sflash6
393217 5 name:sflash6
RESP:2001(RSP:OK)l: 16 T:9 : 60001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:a : 70001


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 6 0
458753 6 name:MSC0-New Volume


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 6 0
458753 6 name:MSC0-New Volume
RESP:2001(RSP:OK)l: 16 T:a : 70001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:b : 80001


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 7 1
MSCMTPCB::usedSizeCB called for Fat32
524289 7 name:MSC0-NEW VOLUME


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 7 1
MSCMTPCB::usedSizeCB called for Fat32
524289 7 name:MSC0-NEW VOLUME
RESP:2001(RSP:OK)l: 16 T:b : 80001
CMD: 1005(GET_STORAGE_INFO)l: 16 T:c : 90001


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 8 2
589825 8 name:MSC1-1


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 8 2
589825 8 name:MSC1-1
RESP:2001(RSP:OK)l: 16 T:c : 90001
CMD: 9801(GET_OBJECT_PROPS_SUPPORTED)l: 16 T:d : 3000
RESP:2001(RSP:OK)l: 16 T:d : 3000
CMD: 9801(GET_OBJECT_PROPS_SUPPORTED)l: 16 T:e : 3001
RESP:2001(RSP:OK)l: 16 T:e : 3001
CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:f : 80001 0 ffffffff
RESP:2001(RSP:OK)l: 24 T:f : 80001 0 ffffffff
CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:10 : 90001 0 ffffffff
RESP:2001(RSP:OK)l: 24 T:10 : 90001 0 ffffffff
CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:11 : 10001 0 ffffffff
RESP:2001(RSP:OK)l: 24 T:11 : 10001 0 ffffffff
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:12 : c dc02 (FORMAT)
RESP:2001(RSP:OK)l: 20 T:12 : c dc02
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:13 : dc03 3000 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:13 : dc03 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:14 : c dc03 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:14 : c dc03
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:15 : dc04 3000 (SIZE)
RESP:2001(RSP:OK)l: 20 T:15 : dc04 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:16 : c dc04 (SIZE)
RESP:2001(RSP:OK)l: 20 T:16 : c dc04
CMD: 1008(GET_OBJECT_INFO)l: 16 T:17 : c
RESP:2001(RSP:OK)l: 16 T:17 : c
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:18 : dc01 3000 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:18 : dc01 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:19 : c dc01 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:19 : c dc01
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:1a : dc07 3000 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:1a : dc07 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:1b : c dc07 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:1b : c dc07
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:1c : dc41 3000 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:1c : dc41 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:1d : c dc41 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:1d : c dc41
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:1e : dc44 3000 (NAME)
RESP:2001(RSP:OK)l: 20 T:1e : dc44 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:1f : c dc44 (NAME)
RESP:2001(RSP:OK)l: 20 T:1f : c dc44
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:20 : b dc02 (FORMAT)
RESP:2001(RSP:OK)l: 20 T:20 : b dc02
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:21 : b dc03 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:21 : b dc03
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:22 : b dc04 (SIZE)
RESP:2001(RSP:OK)l: 20 T:22 : b dc04
CMD: 1008(GET_OBJECT_INFO)l: 16 T:23 : b
RESP:2001(RSP:OK)l: 16 T:23 : b
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:24 : b dc01 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:24 : b dc01
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:25 : b dc07 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:25 : b dc07
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:26 : b dc41 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:26 : b dc41
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:27 : b dc44 (NAME)
RESP:2001(RSP:OK)l: 20 T:27 : b dc44
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:28 : a dc02 (FORMAT)
RESP:2001(RSP:OK)l: 20 T:28 : a dc02
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:29 : a dc03 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:29 : a dc03
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:2a : a dc04 (SIZE)
RESP:2001(RSP:OK)l: 20 T:2a : a dc04
CMD: 1008(GET_OBJECT_INFO)l: 16 T:2b : a
RESP:2001(RSP:OK)l: 16 T:2b : a
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:2c : a dc01 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:2c : a dc01
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:2d : a dc07 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:2d : a dc07
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:2e : a dc41 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:2e : a dc41
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:2f : a dc44 (NAME)
RESP:2001(RSP:OK)l: 20 T:2f : a dc44
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:30 : 9 dc02 (FORMAT)
RESP:2001(RSP:OK)l: 20 T:30 : 9 dc02
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:31 : dc03 3001 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:31 : dc03 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:32 : 9 dc03 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:32 : 9 dc03
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:33 : dc04 3001 (SIZE)
RESP:2001(RSP:OK)l: 20 T:33 : dc04 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:34 : 9 dc04 (SIZE)
RESP:2001(RSP:OK)l: 20 T:34 : 9 dc04
CMD: 1008(GET_OBJECT_INFO)l: 16 T:35 : 9
RESP:2001(RSP:OK)l: 16 T:35 : 9
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:36 : dc01 3001 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:36 : dc01 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:37 : 9 dc01 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:37 : 9 dc01
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:38 : dc07 3001 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:38 : dc07 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:39 : 9 dc07 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:39 : 9 dc07
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:3a : dc41 3001 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:3a : dc41 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:3b : 9 dc41 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:3b : 9 dc41
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:3c : dc44 3001 (NAME)
RESP:2001(RSP:OK)l: 20 T:3c : dc44 3001
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:3d : 9 dc44 (NAME)
RESP:2001(RSP:OK)l: 20 T:3d : 9 dc44
Most of the spew is from me opening the SD card.

Test 2: If I go to the 1st volume of the SSD I can open and play some wav files and open files. I can go to sub directories and play wav files and open files as well. I can also copy and paste files and replace files.
Potential problem: don't see any created or modifed dates in Win Explorer. Along those lines if I copy a file and edit it on windows and copy it back I still don't see a modified date.

Test 3: Copy @defragster's T4_1 directory to the thumb drive no problem. Am able to open files in the subdirectory but still no dates. I did try reformat for the thumb drive and it formated the 64GB drive as exFat, output looked familar:
Code:
CMD: 100f(FORMAT_STORE)l: 20 T:4b5 : 90001 0
 MTPD::formatStore called post:0
Format Callback: user_token:2 store: 8 p2:0 post:0 
RESP:2001(RSP:OK)l: 20 T:4b5 : 90001 0
 MTPD::formatStore called post:1
*** Start Interval Timer ***
Format Callback: user_token:2 store: 8 p2:0 post:1 
ExFatFormatter - WIP
    m_relativeSectors:2048
    m_totalSectors:121145343
Writing Partition Boot Sector
CMD: 1005(GET_STORAGE_INFO)l: 16 T:4b6 : 90001
RESP:2019(RSP:DEVICE_BUSY)l: 16 T:4b6 : 90001
Write eight Extended Boot Sectors
Write OEM Parameter Sector and reserved sector
Write Boot CheckSum Sector
Writing exFAT .......CMD: 1007(GET_OBJECT_HANDLES)l: 24 T:4b7 : 10001 0 ffffffff
RESP:2019(RSP:DEVICE_BUSY)l: 24 T:4b7 : 10001 0 ffffffff
..........................
Write cluster two, bitmap
Writing upcase table
Writing root
Format done
free clusters after begin on partVol: 470200
*** end Interval Timer ***
CMD: 1005(GET_STORAGE_INFO)l: 16 T:4b8 : 90001


}}}}}}}}} MSCMTPCB::usedSizeCB called 20009400 8 2
589825 8 name:MSC1-1

Test3: On the SDCard on SDIO I am able to open it and see the files. I then tried a format it and it formatted as an exFAT as it should since its a 64GB card.

Ok now something interesting - somewhere along the line I MSC1-NEW VOLUME is no longer red and I didn't do anything except reload the sketch?

Not sure what to test with it next.
 
@all - OK, taking a break from TeensyEXT4. It's obvious that there will have to be a complete wrapper for it. There is to much memory stomping going and I have no real way at this point to track what's going on. MSC is locking up on reads before being able to get back the status of the of the disk read (msGetCSW()). If doing direct block device sector reads it works fine (reading the MBR). After that doing any file or directory read/write access fails. At that point it is going through ext4's interface to the block device and locks up MSC. I have check all parameters such as BlockAddress (blk_id), blocks (blk_cnt) and BlockSize (bdev->bdif->ph_bsize). The hard part is the buffer address. In ext4 it can go through several structs and several functions before it finally gets to msReadBlocks(). Not sure how to track that without being able to use Serial.print which with my understanding is not possible.

At this point it been almost 3 weeks since I started working with this. Then the brick wall:( I feel that after I take a break from this and clear my head I will see if using an image file as originally used by lwext4 on a ExFat formatted USB drive with an ext4 image file will work. Not the best choice but the other very time consuming alternative is a converting lwext4 to C++ and trying that:eek:

Opinions of any kind?

@wwatson - I know the feeling - take a break and play with something that you know is going to work for awhile or something not as complicated as lwet4.
 
@mjs513 - Thanks. I really watch what is going on and you are right. Time to test and accomplish:)
 
@mjs513 and @wwatson - I second what @mjs513 said...

As for the RED, sometimes I think this is when the SD card is not ready or not inserted...

I am sort of torn on what to do with some of these drives when they don't have a card inserted... I do detect when the SDIO card is later inserted. Not sure yet about knowing when it is removed. Should it show up at startup?
Like CDROM shows on your computer even if there is nothing in it. But again probably need to debug the actual thing you found.
 
@mjs513 and @wwatson - I second what @mjs513 said...

As for the RED, sometimes I think this is when the SD card is not ready or not inserted...

I am sort of torn on what to do with some of these drives when they don't have a card inserted... I do detect when the SDIO card is later inserted. Not sure yet about knowing when it is removed. Should it show up at startup?
Like CDROM shows on your computer even if there is nothing in it. But again probably need to debug the actual thing you found.

My guess is that it might not be ready since the card was inserted when I loaded the sketch and later power-cycled the T4.1. But think you got enough on your plate.
 
With the CopyFilesUSB.ino sketch I tested with a begin function. I don't think that would be usable with MTP.
Code:
//------------------------------------------------------------------------------
// Check for a inserted SD card and try to mount if not mounted.
bool sdCardAvailable(SdFs *sdCard) {
	if(sdCard == &sdio) {
		if(!sdCard->begin(SD_CONFIG)) {
			return false;
		}
	}
	if(sdCard == &spi) {
		if(!sdCard->begin(SD_CONFIG1)) {
			return false;
		}
	}
	return true;
}

It took a long time for the card to init if it was not there previously.
Is there an interrupt that is generated of some sort when the SD card is plugged in? If so, is there a way of triggering an event in MTP to signal a new device and wait until any transfers or operation in progress have completed in MTP without terminating said transfers? Entering r<cr> is a refresh if I am right. Does that reset everything and does it terminate any transactions that have not completed? Those would be the considerations to look for.
Really have not played with or studied MTP so just curious and asking:)

These are the way I use MSC to detect hot plugging.
 
Morning all,

Most of the SD cards stuff use the simple if it begins it adds it to the list... For the SDIO, I have code in place like:
Code:
  if(cs[ii] == BUILTIN_SDCARD)
  {
    if(!sdx[ii].sdfs.begin(SdioConfig(FIFO_SDIO)))
    { Serial.printf("SDIO Storage %d %d %s failed or missing",ii,cs[ii],sd_str[ii]);  Serial.println();
      BUILTIN_SDCARD_missing_index = ii;
      #ifdef _SD_DAT3
      // for now lets leave it in PULLDOWN state...
      pinMode(_SD_DAT3, INPUT_PULLDOWN);
      // What happens if we add it and it failed to open?
      //storage.addFilesystem(sdx[ii], sd_str[ii]);
      #endif
    }
    else
    {
      storage.addFilesystem(sdx[ii], sd_str[ii], &sdsmtpcb, ii);
      uint64_t totalSize = sdx[ii].totalSize();
      uint64_t usedSize  = sdx[ii].usedSize();
      Serial.printf("SDIO Storage %d %d %s ",ii,cs[ii],sd_str[ii]);
      Serial.print(totalSize); Serial.print(" "); Serial.println(usedSize);
    }
  }
The interesting thing is the SD_DAT3 (Which I am missing the define for MICROMOD) Will fix!

Right now I add this item to end of list at the end of setting up the storages... Not sure if that is good or bad, but found on Linux adding new file systems, by event does not appear to do anything.

Later from the loop function, there is a call to checkUSBandSDIOStatus
Which checks the state of that pin: bool r = digitalReadFast(_SD_DAT3);
And if high it knows a card has been inserted. Talked about some in IMXRT pdf 26.5.7

I have not done anything yet for SPI versions, our test app is sort of hodge podge setup. Where we may setup 10 things hoping a few will actually be there. At some point probably need to configure a version for specific setup.

I have not (yet) added the calls like you mentioned for calling SD->begin... like things in the main loops as not sure how much overhead they may have when nothing is there. May have to try it and see.

Now for more coffee!
 
Quick update: Pushed up MTP change to define SD_DAT3 for Micromod, which is same pin as T4. I don't have a carrier board setup to test to see if that part works or not.
 
Back
Top