returning UTFAT_DISK_READ_ERROR during a write.

[neil]

Hi Mark,
  I have a few hundred units out in the field and working well, but occasionally I get a UTFAT_DISK_READ_ERROR (-4) error returned from a utWriteFile(..) command.  It doesn't always happen to the same units , but they all have the same firmware. I have one file for collecting data ,with 2 file handles (FileStruct) opened on it, one for writing and the other for reading .  I have set the read to UTFAT_MANAGED_MODE so its always updated on every write. I have looked through my code but cant see any problems, it can run for days, collecting data every minute before it happens.

Regards
Neil

[mark]

Hi Neil

It is interesting that you are getting a read error when writing, rather than a write error. This is however plausible if the read of the card data (before making changes to it) fails.
I think that in this case the read is taking 'too long' and it gives up waiting and returns an error - which results in this error number (the most likely cause).

The time given to read is not very scientific but rather just based on a polling counter:
eg. #define MAX_POLL_COUNT   10000 in fnSendSD_command() in the HW file.
What I have found is that SD cards will often work with read/write delays which are fairly consistent (a few ms for example) but occasionally they suddelny have a single access (or short period of operation) where they become very slow - eg. I have seen the write time suddenly go up from say 3ms to 250ms for a single write or a few writes, and then revert back to the more typical short time.
I would therefore (slightly) increase the maximum polling attempts (waiting for the card to report that it is ready to accept further operartions) since this may then give it a bit more 'worst-case' wait time before declaring an error.

I would also hope that such a read/write failure is only transitional and so if you try again/repeat (possibly at a slightly later point in time) it would work correctly because the card has recovered from whatever it was doing that was previously keeping it busy.

Regards

Mark

[neil]

Hi Mark,
  Thanks for the quick reply.

I dont have  MAX_POLL_COUNT   in fnSendSD_command(), and I was sure I had the latest SD card files. The updated entry at the top of mass_storage.c file is: 


    11.09.2013 Reduce sector reads when seeking and correct partial sector read when data is in local {59} utFAT1.13


Regards
Neil

[mark]

Neil

It also depends on whether using SPI or SDHC where the actual code is located (I was referencing SDHC code in the HW code).

The generic SPI one uses
static int CommandTimeout = 5000;
but the principle is the same.

Regards

Mark

[neil]

Hi Mark,
  Thanks for the reply.  I downloaded your latest version of ufat, but got some errors building my project. I haven't had time to see what they were, so I reverted back to the version before it.  Anyway, I noticed in your latest version that CommandTimeout = 20000. As the last version it was set to 5000, do you think me setting mines to 20000 is a too large value?

Best Regards
Neil

[mark]

Hi Neil

As I wrote, the value is not very scientific - it is a 'simple' protection against a read/write attempt from never completing.
Since some new devices are also faster they need a higher retry count value to get the same time as slower devices and that is mainly why the count value has increased.
Generally I would set up a factor higher (x10) if you encounter a timeout, under the assumption that it will only timeout when there is a real error and not generally slow things down.

Regards

Mark

[neil]

Hi Mark,
  As this happens only occasionally , is it possible that some cards (we buy them off the internet in batches) have a slower read/write times than others? Or do you find all about the same?

Regards
Neil

[mark]

Hi Neil

For standard sector read/writes the times for different cards are pretty much the same. The cards rated for higher speeds (Class) are probably only really different when using in multiple-block modes (which is not the case for the utFAT) and would require writing and reading large files to notice (like storing large photos as in a digital camera).
I don't have any figures on the occasional slowness of reads/writes, which is sporadic and I presume due to the card having to do some additional house-keeping/clean-up work (it has its own processor doing block management and level-wear algorithms).

Regards

Mark