MTP Responder Contribution

AH... Works now. I have updated the library and had to remove USB from the Teensy 2 times - now I see the Teensy MPT drive.
Thank you, Tim!

Windows reports it as "Com8(Teensy) Everything?" Is that normal?
 
Modified Tset.cmd to add p#691 mtpserial use

Not sure about Everything?

As noted in TSET I had 'g'=mtp and just added 'o'=mtpserial as directed in p#691.

If you are seeing MTP work then okay? If the build for MTP doesn't see 'mtp' #defined as needed it errors out.

Here is the edited tset.cmd renamed .txt : View attachment TSet .cmd.txt

That can be used with the 'o' USB type with the edits according to p#691
 
Windows: MTP works now.
I theen tried a Linux VM (Virtual Box), start dmesg, and i see:
Code:
[   58.300446] usb 1-1: new high-speed USB device number 2 using ehci-pci
[COLOR=#ff0000][   58.659302] usb 1-1: config 1 has an invalid interface number: 3 but max is 2[/COLOR]
[COLOR=#ff0000][   58.659305] usb 1-1: config 1 has no interface number 0[/COLOR]
[   58.673878] usb 1-1: New USB device found, idVendor=16c0, idProduct=0476
[   58.673881] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   58.673883] usb 1-1: Product: Teensy MTP Disk/Serial
[   58.673884] usb 1-1: Manufacturer: Teensyduino
[   58.673885] usb 1-1: SerialNumber: 7820070
[   58.690544] cdc_acm 1-1:1.1: ttyACM0: USB ACM device
[   58.693345] usbcore: registered new interface driver cdc_acm
[   58.693346] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[COLOR=#ff0000][   98.089536] usb 1-1: USB disconnect, device number 2[/COLOR]
[   98.130423] cdc_acm 1-1:1.1: failed to set dtr/rts
 
@Frank - what sketch is that? Were all extra interfaces #ifdef'd out? If so or maybe if not - it might reserve space for various media not present?

Maybe because it is a single descriptor that has to have room for: SPI, QSPI, RAM, PROG, ... ???
 
This is the sketch MTP-Test.
It uses the inbuilt-SD only.
Code:
#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
#define USE_LFS_QSPI 0    // T4.1 QSPI
#define USE_LFS_PROGM 0   // T4.4 Progam Flash
#define USE_LFS_SPI 0     // SPI Flash
 
Last edited:
Is that the PJRC mtp included or using the WMXZ add in mtpserial?

Does it work on linux with those noted issues? No idea if it is ill formed or formed so as to be 'generic and expandable.'

Zzzz...
 
I edited the config:
Code:
  #define VENDOR_ID             0x16C0
  #define PRODUCT_ID        0x0476 //fake an include everything device
  #define RAWHID_USAGE_PAGE    0xFFAB  // recommended: 0xFF00 to 0xFFFF
  #define RAWHID_USAGE        0x0200  // recommended: 0x0100 to 0xFFFF
  #define DEVICE_CLASS        0xEF
  #define DEVICE_SUBCLASS    0x02
  #define DEVICE_PROTOCOL    0x01


  #define MANUFACTURER_NAME     {'T','e','e','n','s','y','d','u','i','n','o'}
  #define MANUFACTURER_NAME_LEN 11
  #define PRODUCT_NAME          {'T','e','e','n','s','y',' ','M','T','P',' ','D','i','s','k','/','S','e','r','i','a','l'}
  #define PRODUCT_NAME_LEN      22
  #define EP0_SIZE              64


  #define NUM_INTERFACE        3
  #define NUM_ENDPOINTS         5


  #define CDC_IAD_DESCRIPTOR      1 //1
  #define CDC_STATUS_INTERFACE    0 //1


  #define CDC_DATA_INTERFACE      1    // Serial //2
  #define CDC_ACM_ENDPOINT        2 //2
  #define CDC_RX_ENDPOINT       3 //3
  #define CDC_TX_ENDPOINT       3 //3
  #define CDC_ACM_SIZE          16
  #define CDC_RX_SIZE_480       512
  #define CDC_TX_SIZE_480       512
  #define CDC_RX_SIZE_12        64
  #define CDC_TX_SIZE_12        64
  #define ENDPOINT2_CONFIG    ENDPOINT_RECEIVE_UNUSED + ENDPOINT_TRANSMIT_INTERRUPT
  #define ENDPOINT3_CONFIG    ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK


  #define MTP_INTERFACE         2 // MTP Disk
  #define MTP_TX_ENDPOINT       4
  #define MTP_RX_ENDPOINT       4
  #define MTP_EVENT_ENDPOINT    5
  #define MTP_TX_SIZE_480       512
  #define MTP_RX_SIZE_480       512
  #define MTP_TX_SIZE_12        64
  #define MTP_RX_SIZE_12        64
  #define MTP_EVENT_SIZE        32


  #define MTP_EVENT_INTERVAL_12    10    // 10 = 10 ms
  #define MTP_EVENT_INTERVAL_480 7    // 7 = 8 ms


  #define ENDPOINT4_CONFIG    ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK
  #define ENDPOINT5_CONFIG    ENDPOINT_RECEIVE_INTERRUPT + ENDPOINT_TRANSMIT_INTERRUPT  // ????

Now, Linux detects the new device.
My lubuntu shows this:
Code:
[ 2886.739547] usb 1-1: USB disconnect, device number 4
[ 2954.164913] usb 1-1: new high-speed USB device number 5 using ehci-pci
[ 2954.572478] usb 1-1: New USB device found, idVendor=16c0, idProduct=0476
[ 2954.572480] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2954.572482] usb 1-1: Product: Teensy MTP Disk/Serial
[ 2954.572483] usb 1-1: Manufacturer: Teensyduino
[ 2954.572484] usb 1-1: SerialNumber: 7820070
[ 2954.580238] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
It wants to access a camera:
2021-02-09 10_36_02-Start.png

If I try to open the filemanager, it shows nothing - maybe the config I posted above is still not 100% correct.
 
Last edited:
After disconnect / connect to the Virtual Box Lubuntu, now it shows the files:
2021-02-09 10_49_24-Start.png
But reading the text file does not work.
 
I edited the config:
Code:
  #define VENDOR_ID             0x16C0
  #define PRODUCT_ID        0x0476 //fake an include everything device
  #define RAWHID_USAGE_PAGE    0xFFAB  // recommended: 0xFF00 to 0xFFFF
  #define RAWHID_USAGE        0x0200  // recommended: 0x0100 to 0xFFFF
  #define DEVICE_CLASS        0xEF
  #define DEVICE_SUBCLASS    0x02
  #define DEVICE_PROTOCOL    0x01


  #define MANUFACTURER_NAME     {'T','e','e','n','s','y','d','u','i','n','o'}
  #define MANUFACTURER_NAME_LEN 11
  #define PRODUCT_NAME          {'T','e','e','n','s','y',' ','M','T','P',' ','D','i','s','k','/','S','e','r','i','a','l'}
  #define PRODUCT_NAME_LEN      22
  #define EP0_SIZE              64


  #define NUM_INTERFACE        3
  #define NUM_ENDPOINTS         5


  #define CDC_IAD_DESCRIPTOR      1 //1
  #define CDC_STATUS_INTERFACE    0 //1


  #define CDC_DATA_INTERFACE      1    // Serial //2
  #define CDC_ACM_ENDPOINT        2 //2
  #define CDC_RX_ENDPOINT       3 //3
  #define CDC_TX_ENDPOINT       3 //3
  #define CDC_ACM_SIZE          16
  #define CDC_RX_SIZE_480       512
  #define CDC_TX_SIZE_480       512
  #define CDC_RX_SIZE_12        64
  #define CDC_TX_SIZE_12        64
  #define ENDPOINT2_CONFIG    ENDPOINT_RECEIVE_UNUSED + ENDPOINT_TRANSMIT_INTERRUPT
  #define ENDPOINT3_CONFIG    ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK


  #define MTP_INTERFACE         2 // MTP Disk
  #define MTP_TX_ENDPOINT       4
  #define MTP_RX_ENDPOINT       4
  #define MTP_EVENT_ENDPOINT    5
  #define MTP_TX_SIZE_480       512
  #define MTP_RX_SIZE_480       512
  #define MTP_TX_SIZE_12        64
  #define MTP_RX_SIZE_12        64
  #define MTP_EVENT_SIZE        32


  #define MTP_EVENT_INTERVAL_12    10    // 10 = 10 ms
  #define MTP_EVENT_INTERVAL_480 7    // 7 = 8 ms


  #define ENDPOINT4_CONFIG    ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK
  #define ENDPOINT5_CONFIG    ENDPOINT_RECEIVE_INTERRUPT + ENDPOINT_TRANSMIT_INTERRUPT  // ????

Now, Linux detects the new device.
My lubuntu shows this:
Code:
[ 2886.739547] usb 1-1: USB disconnect, device number 4
[ 2954.164913] usb 1-1: new high-speed USB device number 5 using ehci-pci
[ 2954.572478] usb 1-1: New USB device found, idVendor=16c0, idProduct=0476
[ 2954.572480] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2954.572482] usb 1-1: Product: Teensy MTP Disk/Serial
[ 2954.572483] usb 1-1: Manufacturer: Teensyduino
[ 2954.572484] usb 1-1: SerialNumber: 7820070
[ 2954.580238] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
It wants to access a camera:
View attachment 23652

If I try to open the filemanager, it shows nothing - maybe the config I posted above is still not 100% correct.

AFAIK, Paul has some design rules on interfaces and endpoint numbers, so simply changing some numbers may not work.
 
At least linux shows no usb-config error anymore, as it did before! And it shows the filenames.
So, its needed to change the numbers. Linux reported invalid interfaces, as I wrote.
Yes, the numbers may be still wrong, but for linux they are better than before.

This is interesting, too:
The sizes are wrong.
2021-02-09 11_14_57-Suche.png
 
@KurtE - @all
Been trying to debug what's going on with the 25Q512 (64MB) flash. So I uncommented some of extra printfs.

On a T4.0 is seems to be going to this version of SendObject.
Code:
    #if !defined(MTP_SEND_OBJECT_SIMPLE)
    bool MTPD::SendObject() 
    { 
      pull_packet(rx_data_buffer);
      read(0,0);
//      printContainer();

On transferring a 1.15MB PDF:

Code:
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:27 : 1 ffffffff
DATA:100c(SEND_OBJECT_INFO)l: 172 T:27 : 0 3000 11a470 3000 0
SendObjectInfo: 1 4294967295 20202000: 0 3000 0 11a470 3000 0 0 0 0 0 0 0 0 0 0 : aoyue-8032a.pdf
sd_getReadOnYieldWrites store:0 count:1 0
RESP:2001(RSP:OK)l: 24 T:27 : 1 ffffffff 4
CMD: 100d(SEND_OBJECT)l: 12 T:28
MTPD::SendObject: len:0 Use Yield:0
MTPD::SendObject: len:1156208 Use Yield:0
a 1155708 500 8192 0 12 500
a 1155196 1012 8192 0 0 512
a 1154684 1524 8192 0 0 512
a 1154172 2036 8192 0 0 512
a 1153660 2548 8192 0 0 512
a 1153148 3060 8192 0 0 512
a 1152636 3572 8192 0 0 512
a 1152124 4084 8192 0 0 512
a 1151612 4596 8192 0 0 512
a 1151100 5108 8192 0 0 512
a 1150588 5620 8192 0 0 512
a 1150076 6132 8192 0 0 512
a 1149564 6644 8192 0 0 512
a 1149052 7156 8192 0 0 512
a 1148540 7668 8192 0 0 512
a 1148028 8180 8192 0 0 512
a 1148016 8192 8192 500 0 12
b 1147516 500 500 0 12
....
.....
b 901756 500 500 0 12
a 901244 1012 8192 0 0 512
a 900732 1524 8192 0 0 512
a 900220 2036 8192 0 0 512
a 899708 2548 8192 0 0 512
It just dies at this point - no further transfers occur. The only function in Storage.cpp that gets call is write(data, bytes) which in turn is using LittleFS lfs_file_write(lfs, file, buf, size); which then brings us to the flash prog function for the 25Q512. For small files it seems to work no problem. So not sure what is causing it to stop writing to the flash chip.

Note: On the T4.1 the same function is being called and the transfer gets to about the same place the stops:
Code:
CMD: 100c(SEND_OBJECT_INFO)l: 20 T:27 : 1 ffffffff
DATA:100c(SEND_OBJECT_INFO)l: 172 T:27 : 0 3000 11a470 3000 0
SendObjectInfo: 1 4294967295 20202000: 0 3000 0 11a470 3000 0 0 0 0 0 0 0 0 0 0 : aoyue-8032a.pdf
sd_getReadOnYieldWrites store:0 count:1 0
RESP:2001(RSP:OK)l: 24 T:27 : 1 ffffffff 4
CMD: 100d(SEND_OBJECT)l: 12 T:28
MTPD::SendObject: len:0 Use Yield:0
MTPD::SendObject: len:1156208 Use Yield:0
.....
.....
b 918140 500 500 0 12
a 917628 1012 8192 0 0 512
a 917116 1524 8192 0 0 512
a 916604 2036 8192 0 0 512
a 916092 2548 8192 0 0 512
 
One more observation:
Windows can read it, but linux (lubuntu) has problems reading manufacturer, product and serial strings:
Code:
Bus 001 Device 003: ID 16c0:0476 Van Ooijen Technische Informatica 


Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x0476 
  bcdDevice            2.80
  iManufacturer           1 (error)
  iProduct                2 (error)
  iSerial                 3 (error)
  bNumConfigurations      1
[..]
 
"Functional mode" 0 (Windows calls it "Current config") is invalid.
It must be 1.
Code:
    write16(100);  // MTP version
    writestring("microsoft.com: 1.0;");
    write16([COLOR=#ff0000][B]1[/B][/COLOR]);    // functional mode

Now this works with my linux:
Code:
Bus 001 Device 006: ID 16c0:0476 Van Ooijen Technische Informatica 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x0476 
  bcdDevice            2.80
[COLOR=#008000]  iManufacturer           1 Teensyduino
  iProduct                2 Teensy MTP Disk/Serial
  iSerial                 3 7820070[/COLOR]
  bNumConfigurations      1
 
This I find quite strange - I do not know if this is correct(?):

[...]
Code:
[B]
      ========================== Summary =========================
Vendor ID                : 0x16C0 (Van Ooijen Technische Informatica)
Product ID               : 0x0476
USB version              : 2.00
Port maximum Speed       : High-Speed (Companion Port 8 supports SuperSpeed)
Device maximum Speed     : High-Speed
Device Connection Speed  : High-Speed
Self Powered             : yes
Demanded Current         : 100 mA
[COLOR=#ff0000]Used Endpoints           : 1[/COLOR][/B]
(output from Windows - USBtreeview)
 
WTf... a funny Windows observation:
Tried to create a new directory on SD. Right mouse click "create directory" - The explorer jumps to a random file and shows the "rename" field. I enter a new name, and the file gets replaced by a directory with the new name... the file is gone.
 
Morning all (Or at least for me ;) )

Sorry been distracted.

Note: I am currently working with the branch: MEM_send_object_Large

I am not really sure if the background reading stuff is helping in many of the cases and some may be hurting.

@mjs513 - I was integrating in the changes from your version of the sketch and I don't think yours is actually ever using the large buffer stuff...
With the current library I hacked it up such that per storage you could choose to use it or the default read USB buffers into large buffer, do write to FS, repeat...

The way I enabled this was with optional parameter on the addFileSystem, example from my SPI section:
Code:
#if USE_LFS_QSPI==1
                            for(int ii=0; ii<nfs_qspi;ii++)
                            {
                            if(!qspifs[ii].begin())
                            { Serial.printf("QSPI Storage %d %s failed or missing",ii,lfs_qspi_str[ii]); Serial.println();
                            }
                            else
                            {
                            storage.addFilesystem(qspifs[ii], lfs_qspi_str[ii][COLOR="#FF0000"], true[/COLOR]);
                            uint64_t totalSize = qspifs[ii].totalSize();
                            uint64_t usedSize  = qspifs[ii].usedSize();
                            Serial.printf("QSPI Storage %d %s ",ii,lfs_qspi_str[ii]); Serial.print(totalSize); Serial.print(" "); Serial.println(usedSize);
                            }
                            }
#endif

So when I copied the section from your version for NAND like:
Code:
#if USE_LFS_NAND == 1
                            for(int ii=0; ii<nspi_nsd;ii++) {[CODE]
pinMode(nspi_cs[ii],OUTPUT); digitalWriteFast(nspi_cs[ii],HIGH);
if(!nspifs[ii].begin(nspi_cs[ii], SPI)) {Serial.println("No storage"); while(1);}
storage.addFilesystem(nspifs[ii], nspi_str[ii], true);

uint64_t totalSize = nspifs[ii].totalSize();
uint64_t usedSize = nspifs[ii].usedSize();
Serial.printf("Storage %d %d %s ",ii,nspi_cs[ii],nspi_str[ii]); Serial.print(totalSize); Serial.print(" "); Serial.println(usedSize);
}
#endif
[/CODE]
Before I added that true, it worked most of the time. When I added the true, it works some of the time.

@Frank B - Compile warning, Not sure which version you are running, I put in a suppress of that warning awhile ago in other branches and @WMXZ then took that in back in I think December...
It currently looks like:
Code:
    writestring( buf );    
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Warray-bounds"
    for (size_t i=0; i<10; i++) buf[i] = usb_string_serial_number.wString[i];
    #pragma GCC diagnostic pop

Now back to playing
 
Yes, Tim sent me the link to the new version.

I found some little problems.

My linux now shows the Teensy MTP. But it crashes if I want to access the files.
Newest observation:
Trying to delete a file, linux throws this errormessage:
Code:
test1.txt: Fehler beim Löschen der Datei: -10: Timeout reading from or writing to the port
(error deleting the file)

Nothing but displaying the filelists work so far :)
- new directory: no
- new file: no
- delete file: no
- read file: no

The usb descriptor has a problem (fix is some posts above - not sure if this the absolutely right version ;) )

Edit:
Timeout when creating a folder:
Code:
Fehler beim Erstellen des Ordners: -10: Timeout reading from or writing to the port

looks like linux is waiting for a response.

You got two pullrequests with minor fixes.
 
Last edited:
Morning @KurtE
Forgot my manners - way too early for me and probably way to late for @Frank B.

Anyway I missed that option to use large buffers in addFileSystem. Anyway just added it for the W25Q512JV Flash and the 33MB Audio_workshop pdf transferred with no issue. Was able to open it and read it. All 31 pages were there.

For the NAND interesting enough for SPI transfers were completed with no issue, at least for me with large buffer set to false. Haven't tried it on QSPI but for NAND the read/writes are done differently from other flash chips. But from what I remember I didn't have any problem transferring the files to NAND on QSPI with my test rig or when soldered directly to the T4.1.

Guess I should now test with the W25Q64 chip with the large buffer.

EDIT: just for reference all my testing is done on a Windows 10x64 PC and a T4.1

UPDATE: Just replaced the T4.1 with a T4.0 and left Large Buffer enabled.

1. For the 1G/2G winbonds it transferred the the workshop pdf no issue and still was able to read the whole document.
2. For the 25Q512 the transfer failed the same way as previously mentioned. Guess if the T4.0 it defaults to small buffer if T4.1 is selected.
 
Last edited:
Maybe I should try it on my older Linux box and get an idea of what is going on.

Windows times out as well, but as far as I can tell there is no where the defines what the timeouts are...

The branch I have been playing with added a different way to try to pace the reads and writes on the copy new file to storage area.

There is actually 3 different versions of the SendObject code.

The Send object stuff, basically starts off with first USB packet has the MTP header data 12 bytes (Len, TYPE, OP, Transaction ID) followed by
the contents of the object(file) being sent to us. So first 512 byte USB packet has 12 bytes of header and 500 bytes of data, next packets are 512 bytes of data
up until the last packet which has the remaining bytes of data... This is on the same endpoint as we get messages, so MTP can not send us any other messages until this
is completed. When completed we send back a reply on another endpoint.

The T3.x version is the KISS version, I have a version of it under #ifdef as was curious about speed differences.
So this version simply does File writes of each packet as it comes in (first 500 bytes, others 512) until the end...

The released T4.x version and default in my branch if you don't do the true on the add file system

Instead, has a 8KB buffer, and it copies the data that it receives into the 8kb buffer until it fills it and then call write on the 8KB buffer (8KB is configurable), it does a write, copies the rest
of that last read into start of it again and continue... My version of this is slightly different than the released version in that easily possible I do the read calls into the actual buffer location
as to avoid an extra memcpy operation. Note: this version on SDCards is significantly faster than the simple method) as SD writes are than by sector/cluster ...

Problem with the two versions above are that in some cases like my QSPI chip on at least one of my T4.1s and some of the SPI flash chips can be darn slow. For example on my QSPI setup
some writes when it had to do erase operations, may take > 100ms... During some of these windows would give up on us and timeout. So far trying to figure out what the rules are for windows giving up on us....

So the version I have been playing with, instead of reading USB packets until I get 8KB do write, do more reads to fill 8KB...
I instead, fill currently 2KB, start a write, and have a yield call back that sees if there are more USB packets available and if so read one one in... But again I don't want to fill my next set of buffers too fast so I try to figure out a reasonable time to wait between reads... If the write completes before I have enough for the next 2KB, I continue checking for USB... But I also then stop reading if my total buffer is filled and restart it once a write completes....
In addition to this, I allow you to make a call to add a secondary buffer that can be filled. My test sketch tries to add a 1MB cache if you have PSRAM , else something like 128kb DMAMEM... And so it can continue to read more of the file.
Again trying to pace the reads such that it keeps windows happy but not too fast as to fill my cache. In addition to this, windows also appears to want to timeout, that if I read in the last bytes of the object, how long do I have to send a response back to windows saying the transfer is OK before windows times out.... Right now I keep doing writes for up to 2 seconds after the last read before I return a OK... After windows sees the OK, it sends out query for information on the file.
I still have it open and MTP sends back that file is 0 bytes in length. The loop function, continues to try to write out the remaining parts of the file in this case and when it completes it sends a notification to windows saying the size parameter changed. Windows does not appear to automatically update the explorer window in this case, but hitting refresh does show the updated size then...

But so far all of these timeouts and pacing is trial and error, wish there was some spec somewhere on how long things will wait for what...

I am tempted to PUNT on this version of send object and instead see if we can find a different fix/recovery. That is currently windows when a sendObject fails like it, it more or less crashes the connection. Nothing else works until teensy reboots.
So far tried to send reset, which did not work... Will try some other things.

like maybe see if detecting sooner that we have not received any data in time N than the host canceled. Currently I wait 10 seconds for data before I bail. Also I report error un supported, maybe should try different report...
 
Good Morning Kurt!
Good Morning Mike!


I'm working with your latest version from github.
The errormessages re: timout came from linux. So linux seems to wait for a response.
In the meantime, I tried MTP DISK, (without serial)
Interesting: It does the same, but much faster. If i open a file now, I get a fast reponse (screenshot in a post above "Buffer problem")
Trying to delete still results in a linux timeout, or , new "Error 7, IO Error"

One time, it seemed to delete the file - the icon was removed and nor errormessage. But then i refreshed the window, and the file was still there? So, it appears to me, the the code does not even try to delete the file.
Perhaps it gets the wrong command?
I'm working with the SD-Card.
 
Back
Top