Main Site Documentation

File copy from SD to USB fubar?



I have a data logger that writes 100 byte packets to data files on an SD card. Then when it detects a USB mass storage device being plugged in it copies all the data files from the SD card to the USB memory stick.

See below for the relevant source code:

void USBHostController_DeviceConnectedEvent(USBH_Device device)
	Debug.Print("USB Device Connect");

	if (device.TYPE == USBH_DeviceType.MassStorage)
		_usbStorage = new PersistentStorage(device);

void RemovableMedia_Insert(object sender, MediaEventArgs e)
	Debug.Print("Removable Media Insert");

	if (_usbStorage == null)

	string usbRootDirectory = e.Volume.RootDirectory;

	// Copy data log files
	char[] split = new char[] { '\\' };
	foreach(string file in Directory.GetFiles(_sdRootDirectory))
		if (file.IndexOf(".ftilog") != -1)
			string[] parts = file.Split(split);
			if (parts.Length == 3)
					File.Copy(file, usbRootDirectory + @ "\" + parts[2], true);
				catch (Exception)



Now in my testing the files that end up on the USB memory stick, in the current testing a 16GB memory stick formatted FAT32 and with 7GB free, don’t match the original files on the SD card.

I even ran a chkdsk on the USB memory stick in between in case it’s FAT was messed up.

So far the current set of data files range in size from 49KB to 3MB.

Any hints on what might be causing this problem? Are USB mass storage devices > 4GB supported?

If it might help I can upload some sample files from the SD card and the files that end up being copied onto the USB memory stick.


I’m using the latest SDK 1.0.14 and have updated the FEZ Rhino firmware.


Yes of course. You can try a simple test to verify what is going on…put a file on SD card using a PC then on FEZ copy it to USB stick


When I put the SD card into my laptop the actual bits on the SD card are correct based on the headers in the packets and the CRC that is included in each packet from the sending device.

However when the same files on the SD card are copied across using the code shown then something gets garbled in the files.

I’ll do the test as you suggested although I’m not sure how that will help.



In your catch statement put debug.print to see if there are any exceptions.


The only exception is:

    #### Exception System.IO.IOException - CLR_E_UNAUTHORIZED_ACCESS (4) ####
    #### Message: 
    #### System.IO.FileSystemManager::AddToOpenList [IP: 007e] ####
    #### System.IO.FileStream::.ctor [IP: 0052] ####
    #### System.IO.File::Copy [IP: 001c] ####
    #### System.IO.File::Copy [IP: 0007] ####
    #### FTILogger.Logger::RemovableMedia_Insert [IP: 0062] ####
    #### Microsoft.SPOT.IO.RemovableMedia::MessageHandler [IP: 0041] ####

Which is expected since the current data log file is in use. The other older 4 data files of a couple of MB get copied over to the memory stick.



Please make a program we can try here and a also include a small file with few bytes. You can email it to ghielec at ghielectronics . com

Something like this:
sd = new Persistant(…);
usb = new Persistant(…);

Copy("\USB\myfile", "\SD\myfile…

Start with Windows formatted SD and USB memories to rule out previous file systems corruptions.
Do you see any problems when you do this?


I noticed when looking at one of the 4 data files that are being copied to the USB memory stick that one of them always (I’d been testing the copy process multiple times) had part of the contents of another totally unrelated file that already existed on the USB memory stick.

I had previously when I initially saw this issue and suspected it may be related to a partly corrupt filesystem on the USB memory stick run a chkdsk fix on the USB memory stick but this had made no difference and I continued to see the same issue.

I found another USB memory stick (256MB FAT32) and tested with that and the file copy process worked.

So I went back to my 16GB (7GB free) memory stick and deleted roughly 100MB of data off it and ran another chkdsk fix which again reported no errors. However now the file copies from SD to USB result in the same bits ending up on the USB memory stick.

So it would appear that the issue was related to some sort of filesystem or flash corruption on the USB memory stick that I was using. Although I’ve been using this same 16GB memory stick for about 3 years whenever I need a memory stick and have never noticed any sort of data corruption in the past.


It could be a bug in the file system. We need a simple program to reproduce it so we can look into it.