I am using SSP 1.4 on and S7G2
I have been running into an issue with FIleX on USB Mass Storage which appears to be dependent on the type of USB drive that is connected. I set up a test that creates, opens, write and closes files repeatedly to test the timing and durability of writing to the USB drive. Each file created and written is roughly 120kB to 180kB of logged data. When I run the test on a 64GB USB 3.1 drive (Samsung BAR Plus) I have not experienced any issues, however when I run the same test with an inexpensive (No Brand Name) 128MB USB drive the thread will eventually hang, typically it fails to return from a fx_file_write. I have tried multiple drives of the same type to see if it was just a bad USB device. Most times I run the test I am able to write between 3-10 files before the process fails to complete, occasionally it has failed even on the first file, sometimes it’s completed 20 files without issue.
I understand that a filex operation may occasionally fail but since it never returns, I am unable to continue using the USB device and thread. The thread is left in a “Semaphore Suspended” state. Is there any recommendation on ways to keep the thread alive, retry or abort?
The following is an overview of the process I have implemented
Opening the File -
If (status != FX_SUCCESS) from any of the previous commands I will stop the process and go to closing the file
Writing to File – This process will loop through up to 99 times to print out all of the log information. The file buffer and write length can be up to 4096 bytes
Closing File –
I am using the USBHS Controller, the USB High Speed Interrupt Priority is set to 4, USBX Pool Memory Size is set to 65536.
I have tried to put a delay of up to 60 seconds between each time the process is called without success.
In the past I had issues where fx_file_write appeared to be interfering with my SPI Interrupts causing missed readings from the SPI device. I changed some priorities and now I am not missing readings but it appears the fx_file_write is not completing. I am not certain if it is related at this point.
Are there any known issues with certain types of USB devices? Are there any recommendations on how to keep the thread alive?
In reply to KurtK:
In reply to JanetC:
Thanks for all of the information! I am not constrained to using low end USB drives, i was just doing some testing with what I had sitting around and had found the issue. It was concerning that it appeared to hang the thread and I didn't want a user to run into the issue in the field.
After some more testing last night and this morning I actually discovered that it was not hanging but taking a very long time to time out and return. I believe the timeout time involves a combination of the following settings.
After a period of time the fx_file_write does return with 0x04 (FX_NOT_FOUND) which isn't a return value listed in the FileX documentation.After the fx_file_write returns I then try fx_file_close followed by fx_media_flush both also take a long time to time out and return with an error code also not listed in the documentation.
So it appears the thread does returning after a very long time but I don't believe the USB drive is usable again until a power cycle or the user removes and plugs the drive back in. I have to find a way to catch the error condition and prevent the write attempt which causes the thread the hang.
I have tried to increase the USBX memory to roughly 100k with no difference.
Are there any guidelines or specifications to what USB drives may have issues? The product I am working would not be accessible by the user and rebooting everytime a write error occurs would not be acceptable.
I do not currently have the FIleX source code included, I do have USBX Host Class Mass Storage Source and USBX Source include.
I had a thought that slowing down the transfer speed may help so I put 50ms delays after each fx_file_write and tried to reduce the "Maximum transfer size in bytes in one BOT data-transport phase" from 1024 to 512bytes and it did not appear to help.I would really like the system to work with any drive the user may connect so I am open to any suggestions you may have.