MTP Responder Contribution

Post #766 file works on BUILTIN_SDCARD, FAILS the SAME on RAM1 at 3.81MB.

SDIO - Success:
Code: 
CMD: 100b(DELETE_OBJECT)l: 20 T:4e : 8 0
RESP:2001(RSP:OK)l: 20 T:4e : 8 0
CMD: 1005(GET_STORAGE_INFO)l: 16 T:4f : 1
RESP:2001(RSP:OK)l: 16 T:4f : 1
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:50 : 1 ffffffff
DATA:100c(SEND_OBJECT_INFO)l: 224 T:50 : 0 3000 f000 3000 0
SendObjectInfo: 1 4294967295 20202040: 0 3000 0 f000 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en.txt
sd_getReadOnYieldWrites store:0 count:3 0
RESP:2001(RSP:OK)l: 24 T:50 : 1 ffffffff a
CMD: 100d(SEND_OBJECT)l: 12 T:51
MTPD::SendObject: len:0 Use Yield:0
>>>Total Time: 11898
RESP:2001(RSP:OK)l: 12 T:51
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:52 : a dc02 (FORMAT)
RESP:2001(RSP:OK)l: 20 T:52 : a dc02
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:53 : a dc01 (STORAGE_ID)
RESP:2001(RSP:OK)l: 20 T:53 : a dc01
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:54 : a dc07 (OBJECT NAME)
RESP:2001(RSP:OK)l: 20 T:54 : a dc07
CMD: 9802(GET_OBJECT_PROP_DESC)l: 20 T:55 : dc0b 3000 (PARENT)
RESP:2001(RSP:OK)l: 20 T:55 : dc0b 3000
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:56 : a dc0b (PARENT)
RESP:2001(RSP:OK)l: 20 T:56 : a dc0b
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:57 : a dc41 (PERSISTENT_UID)
RESP:2001(RSP:OK)l: 20 T:57 : a dc41
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:58 : a dc44 (NAME)
RESP:2001(RSP:OK)l: 20 T:58 : a dc44
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:59 : a dc03 (PROTECTION)
RESP:2001(RSP:OK)l: 20 T:59 : a dc03
CMD: 9803(GET_OBJECT_PROP_VALUE)l: 20 T:5a : a dc04 (SIZE)
RESP:2001(RSP:OK)l: 20 T:5a : a dc04
CMD: 1008(GET_OBJECT_INFO)l: 16 T:5b : a
RESP:2001(RSP:OK)l: 16 T:5b : a
CMD: 1005(GET_STORAGE_INFO)l: 16 T:5c : 1
RESP:2001(RSP:OK)l: 16 T:5c : 1

RAM1 Fail - drag and drop and Teensy Copy starts and immediately exits/disconnects/restarts bypassing Fault Handler code:
Code: 
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:5e : 3 ffffffff
DATA:100c(SEND_OBJECT_INFO)l: 224 T:5e : 0 3000 f000 3000 0
SendObjectInfo: 3 4294967295 20202040: 0 3000 0 f000 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en.txt
sd_getReadOnYieldWrites store:2 count:3 0
RESP:2001(RSP:OK)l: 24 T:5e : 3 ffffffff b
CMD: 100d(SEND_OBJECT)l: 12 T:5f
MTPD::SendObject: len:0 Use Yield:0
[B][COLOR="#FF0000"]MTP_test[/COLOR][/B]  [U]// Re-enter setup[/U]
sd_addFilesystem: 0 20002b00 sdio 0
SDIO Storage 0 254 sdio 15923150848 15400960
sd_addFilesystem: 1 20002fbc RAM0 0
Storage 0 RAM0 1998848 4096
sd_addFilesystem: 2 20003084 RAM1 0
Storage 1 RAM1 3999744 4096

**** dir of sd[0] ****
mtpindex.dat
test1.txt
examples/
esp-psram64_esp-psram64h_datasheet_en.txt

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

This is a T_4.1 with TWIN 8MB PSRAMS.
I have the current FrankB HardFault code integrated into CORES - and testedto work enabling and causing a DIV by ZERO error, this code 'bug' bypasses it as it exists but SELF RESETS

Made a copy of the above file and truncated to 25 bytes reported with name : "esp-psram64_esp-psram64h_datasheet_en - Copy.txt":
Code: 
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:10 : 3 ffffffff
DATA:100c(SEND_OBJECT_INFO)l: 238 T:10 : 0 3000 19 3000 0
SendObjectInfo: 3 4294967295 20202040: 0 3000 0 19 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en - Copy.txt
sd_getReadOnYieldWrites store:2 count:3 0
RESP:2001(RSP:OK)l: 24 T:10 : 3 ffffffff 5
CMD: 100d(SEND_OBJECT)l: 12 T:11
MTPD::SendObject: len:0 Use Yield:0
RESP:2005(RSP:OPERATION_NOT_SUPPORTED)l: 12 T:11
CMD: 1005(GET_STORAGE_INFO)l: 16 T:12 : 3
RESP:2001(RSP:OK)l: 16 T:12 : 3
> same behavior removing space from the name: "esp-psram64_esp-psram64h_datasheet_en_-_Copy.txt"

So the HINT may be handling around :: "OPERATION_NOT_SUPPORTED"
 
Frank B said:
I can confirm that RAM does not like the file.
The length of the filename seems to be the problem.
Click to expand...

Indeed - the odd thing is it worked on QSPI 1Gb NAND when it was 6K or smaller - ( fails on RAM1 in mtp-test ).

Looking at : libraries\MTP_t4-MEM_send_object_large\src\MTP.cpp
That error code 0x2005 is found in about 14 places.

Suggests some damage may be done by the time it discovers there is a problem.
 
Was playing with the filename and coming up with test for the filename length. If you go to sendobjectinfo (there is two of them) and add the following line right after the printf(": %s\n", filename); it will skip any file with a file name > than the max file name length but keep copying:
Code: 
	  if(strlen(filename) > MAX_FILENAME_LEN) return MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED;
so should look like:
Code: 
      readstring(filename); len -= (2*(strlen(filename)+1)+1); 
      printf(": %s\n", filename);
	  if(strlen(filename) > 32) return MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED;
      // ignore rest of ObjectInfo
      while(len>=4) { read32(); len-=4;}
      while(len) {read8(); len--;}
in sendobjectinfo.
[/CODE]

Had to change MAX_FILENAME_LEN to 32 otherwise it still fails.

UPDATE: Just remembered and did a double check.

Storage.h has #define MAX_FILENAME_LEN 256 but didn't Paul limit the file name length in LittleFS to something in the 30's. Can't find it now?
 
Last edited:
Tracked death to line: 1943
Code: 
SendObjectInfo: 3 4294967295 20202040: 0 3000 0 f000 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en.txt
sd_getReadOnYieldWrites store:2 count:3 0
RESP:2001(RSP:OK)l: 24 T:a : 3 ffffffff 3
CMD: 100d(SEND_OBJECT)l: 12 T:b
MTPD::SendObject: len:0 Use Yield:0

1889 OP_NOT_SUPP 0x2005 
RESP:2005(RSP:OPERATION_NOT_SUPPORTED)l: 12 T:b
 UNKWN: 61616161l: 1633771873 T:61616161 : 41414141 41414141 41414141 61616141 61616161

[B][COLOR="#FF0000"]1943 OP_NOT_SUPP 0x2005 [/COLOR][/B]
MTP_test

Added Macro:
Code: 
uint32_t ShowLine( uint32_t myLine ) {
  printf("\n%lu OP_NOT_SUPP 0x2005 \n", myLine );
  delay(1000);
  return 0x2005;
}
#define tx2005 (ShowLine( __LINE__ ))

Code at MY line 1943:
Code: 
    void MTPD::loop(void)
    { if(usb_mtp_available())

      { if(fetch_packet(rx_data_buffer))
        { printContainer(); // to switch on set debug to 1 at beginning of file

          int op = CONTAINER->op;
          int p1 = CONTAINER->params[0];
          int p2 = CONTAINER->params[1];
          int p3 = CONTAINER->params[2];
          int id = CONTAINER->transaction_id;
          int len= CONTAINER->len;
          int typ= CONTAINER->type;
          TID=id;

          int return_code =0x2001; //OK use as default value

          if(typ==2) return_code=tx2005; // we should only get cmds

          switch (op)
          {
            case 0x1001:
              TRANSMIT(WriteDescriptor());
              break;

...

            case 0x9804:  // setObjectPropertyValue
                return_code = setObjectPropValue(p1,p2);
                break;

            default:
[B][COLOR="#FF0000"]                return_code = tx2005;  // operation not supported
[/COLOR][/B]                break;
          }
 
mjs513 said:
Was playing with the filename and coming up with test for the filename length. If you go to sendobjectinfo (there is two of them) and add the following line right after the printf(": %s\n", filename); it will skip any file with a file name > than the max file name length but keep copying:
Code: 
	  if(strlen(filename) > MAX_FILENAME_LEN) return MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED;
so should look like:
Code: 
      readstring(filename); len -= (2*(strlen(filename)+1)+1); 
      printf(": %s\n", filename);
	  if(strlen(filename) > 32) return MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED;
      // ignore rest of ObjectInfo
      while(len>=4) { read32(); len-=4;}
      while(len) {read8(); len--;}
in sendobjectinfo.
[/CODE]

Had to change MAX_FILENAME_LEN to 32 otherwise it still fails.
Click to expand...

@mjs513 : Cannot find this in code I have here? >> T:\tCode\libraries\MTP_t4-MEM_send_object_large\src\MTP.cpp

In either copy of sendobjectinfo() ???
 
mjs513 said:
Yes its in MTP.cpp at about lines 785 and about 1384. I am using the same branch you are.
Click to expand...

Here Neither sendobjectinfo() has : if(strlen(filename) > MAX_FILENAME_LEN) return MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED;

Maybe that is the source of the BUG ???

But the reported error is :: RESP:2005(RSP:OPERATION_NOT_SUPPORTED)l: 12 T:11
>> #define MTP_RESPONSE_OPERATION_NOT_SUPPORTED 0x2005

Error is not showing here as :: MTP_RESPONSE_OBJECT_PROP_NOT_SUPPORTED

Here is the mtp.cpp as I have it with the MACRO trapping 0x2005 using tx2005: View attachment MTP.cpp
 
Oh - got confused - I added that line in to return on filename length's greater than 32. It will keep copying files with filenames 32 or less.
 
Yep when that 1943 OP_NOT_SUPP 0x2005
That is after the code has not received anything from the host in at least 10 seconds, while still waiting for data to finish the transfer.

Some things I want to try, is maybe if we don't receive any data for a shorter period of time and instead of returning the not supported, instead return something
else like: MTP_RESPONSE_INCOMPLETE_TRANSFER

Will it recover? I am/was going to update the sendObject code to return a response code instead of bool, such that we could return different errors depending on
things...
 
opps ... POST #780 clearly shows "FIRST" Error is line is - the other line was a cascade error ...:
1889 OP_NOT_SUPP 0x2005
RESP:2005(RSP:OPERATION_NOT_SUPPORTED)l: 12 T:b
Click to expand...
Code: 
            case 0x100D:  // SendObject
                #ifdef MTP_SEND_OBJECT_YIELD
                if (read_on_yield_writes_)
                {
                  if(!SendObjectWithYield()) return_code = tx2005;
                }
                else
                #endif
                  [B][COLOR="#FF0000"]if(!SendObject()) return_code = tx2005;[/COLOR][/B]
                len = 12;
                break;
 
@mjs513 is right - error is FOUND in SendObject() - resulting in call to tx2005 - which in unedited code is :: return_code = 0x2005;

<EDIT>
Using this LONGER file name it is detected and TEENSY does not AUTO REBOOT and the ERROR is properly handled:
Code: 
SendObjectInfo: 3 4294967295 20202040: 0 3000 0 19 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en[B][COLOR="#FF0000"]_-_Copy.[/COLOR][/B]txt
sd_getReadOnYieldWrites store:2 count:3 0
RESP:2001(RSP:OK)l: 24 T:a : 3 ffffffff 3
CMD: 100d(SEND_OBJECT)l: 12 T:b
MTPD::SendObject: len:0 Use Yield:0

[B][COLOR="#FF0000"]1889 OP_NOT_SUPP 0x2005 
[/COLOR][/B]RESP:2005(RSP:OPERATION_NOT_SUPPORTED)l: 12 T:b
CMD: 1005(GET_STORAGE_INFO)l: 16 T:c : 3
RESP:2001(RSP:OK)l: 16 T:c : 3
 
Updated p#787 points to @mjs513 finding the error source - in this one case it causes corruption that cascades very badly.

Personal Note - that MACRO would be Handy (where like this error happens in 14 places) for Debug and could go away easily! (changes not tested)
Code: 
#if DEBUG>0
uint32_t showErrLine( uint32_t myLine, int err ) {
  printf("\nLINE: %lu Err#:%d \n", myLine, err );
  delay(1000); // Optional - just a flush wait?
  return err;
}
#define errReturn(a) (showErrLine( __LINE__, a ))
#else
#define errReturn(a) (a)
#endif
 
Mike: I finally decoded your post #779. Was looking for FIRST line shown to replace with 2nd diff :(

Indeed I can now COPY the T_4.1 folder ZIP shared on github earlier.

That is a GOOD fix for this problem!

The RAM1 was too small and some errors on disk space, but it continued when first tried - a good result. Windows 'chimed' on errors and continued.

I extended RAM1 to 12MB and every thing fits and the errors from my current directory are HANDLED - with Windows 'error sound chime':
Code: 
...
CMD: 1008(GET_OBJECT_INFO)l: 16 T:43 : 6
RESP:2001(RSP:OK)l: 16 T:43 : 6
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:44 : 3 3
DATA:100c(SEND_OBJECT_INFO)l: 224 T:44 : 0 3000 19 3000 0
[B]SendObjectInfo: 3 3 20202040: 0 3000 0 19 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_e2.txt
[/B]RESP:a80a(RSP:OBJECT_PROP_NOT_SUPPORTED)l: 24 T:44 : 3 3 20303030
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:45 : 3 3
DATA:100c(SEND_OBJECT_INFO)l: 224 T:45 : 0 3000 1484bb 3000 0
[B]SendObjectInfo: 3 3 20202040: 0 3000 0 1484bb 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en.pdf
[/B]RESP:a80a(RSP:OBJECT_PROP_NOT_SUPPORTED)l: 24 T:45 : 3 3 3e0a5d3e
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:46 : 3 3
DATA:100c(SEND_OBJECT_INFO)l: 224 T:46 : 0 3000 f000 3000 0
[B]SendObjectInfo: 3 3 20202040: 0 3000 0 f000 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en.txt
[/B]RESP:a80a(RSP:OBJECT_PROP_NOT_SUPPORTED)l: 24 T:46 : 3 3 20303030
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:47 : 3 3
DATA:100c(SEND_OBJECT_INFO)l: 238 T:47 : 0 3000 19 3000 0
[B]SendObjectInfo: 3 3 20202040: 0 3000 0 19 3000 0 0 0 0 0 0 0 0 0 0 : esp-psram64_esp-psram64h_datasheet_en_-_Copy.txt
[/B]RESP:a80a(RSP:OBJECT_PROP_NOT_SUPPORTED)l: 24 T:47 : 3 3 3e0a5d3e
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:48 : 3 3
DATA:100c(SEND_OBJECT_INFO)l: 180 T:48 : 0 3000 154c49 3000 0
SendObjectInfo: 3 3 20202040: 0 3000 0 154c49 3000 0 0 0 0 0 0 0 0 0 0 : NXP_i2c_UM10204.pdf
sd_getReadOnYieldWrites store:2 count:3 0
...
 
Note: for files that have names longer than file names supported by a specific FS, I believe that we probably need some more surgery to the code.

That is probably SendObjectInfo

When it calls: object_id = storage_->Create(store, parent, dir, filename);
It is here probably that the storage Create method

And then in: uint32_t MTPStorage_SD::Create(uint32_t store, uint32_t parent, bool folder, const char* filename)

It should probaby go to where it does OpenFileByIndex and that code should detect that the sd_open code failed and then somehow error status percolate up, the sendObjectInfo and then have it return some error.
 
defragster said:
The RAM1 was too small and some errors on disk space, but it continued when first tried - a good result. Windows 'chimed' on errors and continued.

I extended RAM1 to 12MB and every thing fits and the errors from my current directory are HANDLED - with Windows 'error sound chime':
Click to expand...
I added that test earlier to SendObjectInfo, which catches the obvious ones where it will not be able to store the file as the file size is > what I think is the free space.

The I think the free space, is total space minus used space...

But I don't know how fore example the used space is calculated and/or is updated.
That is, does the FS, simply sum the logical file sizes? Or does it calculate by knowing how many logical blocks (sectors? Clusters? ...) are used...

Also what the code does not catch, is suppose the file is 2kb in size and I have 2.5kb free, will it fit?

Depends on how much space the FS uses for the file... Also I simply bail out in some cases when the count of bytes written does not match the cb we asked to write.
Question is how best to handle that case. I think we just bail.

I think the spec implies we should continue to read all of the data for that stream and then return error status...
 
Glad the large name issue is resolvable. I was wondering if that explains any mystery hangs? Maybe not from that problem but from similar untrapped errors - where this one just RESET the Teensy and bypasses any Hard Fault detection. Though including the Fault Detect is a nice safety net for some feedback.


That SIZE and freespace was one of the first issues seen with LFSIntegrity.
> As noted back then RAM is AWFUL for using 1-16MB and 512Byte blocks on large files
> Large block NAND will have the opposite problem with small files - except where they stack into a DIR block.

The BLOCK size and efficiency of storing any file varies with media and how LFS chooses to store it - i.e. can the file fit in a DIR block, and when consuming blocks what is the overage for blocked data and any updates to DIR blocks used.

So no way to knwo in advance on any given media where the MATH is a majik factor of block size and LFS process.
 
KurtE said:
Note: for files that have names longer than file names supported by a specific FS, I believe that we probably need some more surgery to the code.

That is probably SendObjectInfo

When it calls: object_id = storage_->Create(store, parent, dir, filename);
It is here probably that the storage Create method

And then in: uint32_t MTPStorage_SD::Create(uint32_t store, uint32_t parent, bool folder, const char* filename)

It should probaby go to where it does OpenFileByIndex and that code should detect that the sd_open code failed and then somehow error status percolate up, the sendObjectInfo and then have it return some error.
Click to expand...

Probably correct need to determine max allowable file length based on storage type since I think for the SD card longer lengths may be allowed. Not sure.

Isn't putting the filenamelength test in openfilebyindex, or by testing on whether file was able to be opened too late - wouldn't once its tries to open the file it would fail? If you put it in create you would have to test before you do
Code: 
    ret = p.child = AppendIndexRecord(r);
    WriteIndexRecord(parent, p);
Not sure what the best approach would be.
 
defragster said:
Mike: I finally decoded your post #779. Was looking for FIRST line shown to replace with 2nd diff :(

Indeed I can now COPY the T_4.1 folder ZIP shared on github earlier.

That is a GOOD fix for this problem!

The RAM1 was too small and some errors on disk space, but it continued when first tried - a good result. Windows 'chimed' on errors and continued.

......
Click to expand...

The fix I put in was really only a kludge to see if we could trap that error and it would still keep copying the files. I think for me it beeped twice so not sure 32 is the max file length in reality.
 
Yes, at least for SD the filenames should be as long as possible.
If I take some of my MP3 files for example, that have a lot of meta information in their filenames, almost all are longer than 32.
For SD, there shouldn't be an artificial maximum without a technical reason.
 
Frank B said:
Yes, at least for SD the filenames should be as long as possible.
If I take some of my MP3 files for example, that have a lot of meta information in their filenames, almost all are longer than 32.
For SD, there shouldn't be an artificial maximum without a technical reason.
Click to expand...

Yes, that 'kludge' is an absolute limit that fixes/hides the discovered issue.

Problem is that used to copy ALL "T_4.1" files to SDIO - now it is bouncing the LONG names :(

KurtE's note rings to that - allowing it to percolate down and fail based on the FS the media at hand is using. But it needs to fail safely and not trash/restart the Teensy.

@mjs513: as noted when mtp-test failed to show the 1Gb NAND I went to LFSintegrity 'expecting it to fail. Of course it did as we know I was having issues with #ifdef's yesterday ... even in my own code :(

Though that does point out trouble in the MTP MOUNT code as well where there may be a file on the media that breaks the DirWalk to present the directory into to Windows. On that NAND LFSIntegrity choked through the files as left after the fail 'Reset' on mtp-test - but mtp-test gave only a blank DIR to Windows when in fact there were many valid files. I don't have that image now so I can't investigate the nature of the directory data issue.
 
mjs513 said:
Probably correct need to determine max allowable file length based on storage type since I think for the SD card longer lengths may be allowed. Not sure.

Isn't putting the filenamelength test in openfilebyindex, or by testing on whether file was able to be opened too late - wouldn't once its tries to open the file it would fail? If you put it in create you would have to test before you do
Code: 
    ret = p.child = AppendIndexRecord(r);
    WriteIndexRecord(parent, p);
Not sure what the best approach would be.
Click to expand...

That is an interesting question... The openfileByIndex I believe is the first place in that code path that actually talks to the underlying file system.

Code: 
void MTPStorage_SD::OpenFileByIndex(uint32_t i, uint32_t mode) 
  {
    if (open_file_ == i && mode_ == mode) return;
    char filename[MAX_FILENAME_LEN];
    uint16_t store = ConstructFilename(i, filename, MAX_FILENAME_LEN);

    mtp_lock_storage(true);
    if(sd_isOpen(file_)) file_.close();
    file_=sd_open(store,filename,mode);
    open_file_ = i;
    mode_ = mode;
    mtp_lock_storage(false);
  }
There are always questions on how robust and complete this should be made. Example it calls ConstructFilename, Which uses recursion to walk up the parent tree and when it hits the root
it copies in / then on the unwinding it strlcat on a / (except for root which already did so) and again strlcat the filename... Which more or less works.
But obviously if called rather large names, will end up returning a path with truncated name... Which is probably fine, alternative is to modify to allow it to return some form of error code.

The open by index closes any other open file ( for the cached file object).
it then calls through to the file system open function: File sd_open(uint32_t store, const char *filename, uint32_t mode) { return sdx[store]->open(filename,mode); }

And it returns a File object... And again we do not detect that the File object is valid or not (Only thing we can do at this point is call sd_isOpen to see if it opened.
Which we probably should do.

Now if the FS.open() file errors out, I don't know if there is any FS or File method in our base classes to try to determine what the last error was?
 
defragster said:
KurtE's note rings to that - allowing it to percolate down and fail based on the FS the media at hand is using. But it needs to fail safely and not trash/restart the Teensy.
Click to expand...

Yes it would be nice to not have some simple things not trash out the Teensy. So far things like responding too slowly to things and Windows or linux times out, and we are toast.

As I mentioned yesterday wondering about different ways to try to detect it before it is too late and try to abort before windows completely dies with it...

I am also wondering about maybe putting the Fancy copy code with background stuff on hold, and back up to the other WIP branch I have that has an open PR back to WMXZ and
migrate some of this error detection/recovery stuff into it and see if we can find simple solution for 80-90% of file copies and try to detect and recover from the others.
 
Today was closest I came to looking at the code. KurtE and WMXZ have best feel for it - certainly mjs513 more than my visit today.

If git.WMXZ is easier to clean and track maybe that would be best to get good general function refined for the variety of (L)FS issues that might show. Given T_4.0 and T_3_6 and prior might use this without the resources for more elaborate things memory.

When it works it looks amazing - especially the fast SDIO xfers!

But source of random hangs or restarts are ( based on what I saw and hangs it seems noted in some prior posts ) need to be discoverable. The FrankB HardFault show on power up is awesome extension of stuff that hung me up trying to evolve - but the LONG name crash seemed to evade Fault detection and crash the MCU :( - having __LINE__ info print before exit was critical to me.

@mjs513 took the opposite approach - reading the code - to the macro I created that pointed toward the error. But putting that ( like p#788 ) might expose the issue with hangs and other at the source if "return Err#" was wrapped in "return errMacro( Err#, __LINE__ )" for debug.

Question: On normal file copy errors Windows shows a dialog. Errors seen here just 'Err Beep' in Windows and continue. Is that an MTP limitation - or are there ways to post event to Windows to get 'Err Dialog "text"'?
 
@...

I just pushed up a change to mtp.cpp and storage.cpp that when the sendObjectInfo calls off to storage to create the file, if the storage fails to create, it deletes the new logical item and returns the sort of
error status index of: 0xFFFFFFFFUL

The MTP code detects this index and returns an error response of: MTP_RESPONSE_SPECIFICATION_OF_DESTINATION_UNSUPPORTED

It appeared to work when I kept creating directories and finally got a file to error out that way.

On the Beep versus dialog... Good question, I ran into this, but have no idea if there is a way to have windows give the user information...
 
You must log in or register to reply here.
Back
Top