µTasker Forum > utFAT
Files saved on SD card dont show on PC
neil:
Hi Mark,
Hmmmm.. I think I must have copied the wrong card. When in operation, our board saves the data , and various setup for the board on the SD . The board then sends the data that was saved to our server, so we know the data is saved. I took out the card and simply done opened it up on Windows. One of our customers done the same with their board. We have quite a few SD cards about, so it could have well been the wrong card. Is it okay if I (I will make sure this time it is the correct card) send another file? Im on vacation at the moment, so will do it when I get back .
Best Regards
Neil
mark:
Neil
Resend an image when you are back so that I can compare.
Regards
Mark
neil:
Thanks Mark
Regards
Neil
neil:
Hi Mark,
I have ran my application now for several hours, and able to collect the data on the SD card, I can download the data at any point (I connect through tcp and download the data), the application opens the files and sends the data. I still cant see the data on a PC, when I run the test utasker application and do a dir I get no files , and when I look at the info I get the following below.
If I restart my application , I can see the files (I have debug code) being opened during initialization of the system, and when it downloads the data, I can see the files being opened, and data sent (which is correct info).
I have removed the sd card, and copied it now (attached), this time i know its teh same card :)
Following from dir and info:
Directory D:\
0 files with 0 bytes
0 directories, 1973481472 bytes free
D:\>info
SD-card (1977614336 bytes)
Bytes per sector: 512
Cluster size: 4096
Directory base: 0x00000002
FAT start: 0x0000005f
FAT size: 0x00000eb9
Number of FATs: 2
LBA: 0x00001dd1
Total clusters: 0x00075a45
Info sect: 0x00000040
Free clusters: 0x00075a0f
Next free: 0x00000038
CSD: 0x00 0x26 0x00 0x32 0x5f 0x5a 0x83 0xae 0xfe 0xfb 0xcf 0xff 0x92 0x80 0x40
0xdf
D:\>
Regards
Neil
mark:
Neil
With this image I can't see any content on the disk.
What I do see is that there is FAT content:
D:\>sect 5f
Reading sector 0x0000005f
0x0ffffff8 0xffffffff 0x00000003 0x00000005 0x0fffffff 0x00000007 0x00000036 0x00000009 0x0fffffff 0x0000000b 0x0000000d 0x0fffffff 0x00000035 0x0000000f 0x0fffffff 0x00000011
0x0fffffff 0x00000013 0x0fffffff 0x00000015 0x0fffffff 0x00000017 0x0fffffff 0x00000019 0x0fffffff 0x0000001b 0x0fffffff 0x0000001d 0x0fffffff 0x0000001f 0x0fffffff 0x00000021
0x0fffffff 0x00000023 0x0fffffff 0x00000025 0x0fffffff 0x00000027 0x0fffffff 0x00000029 0x0fffffff 0x0000002b 0x0fffffff 0x0000002d 0x0fffffff 0x0000002f 0x0fffffff 0x00000031
0x0fffffff 0x00000033 0x0fffffff 0x0fffffff 0x0fffffff 0x0fffffff 0x0fffffff 0x00000038 0x00000039 0x0000003a 0x0000003b 0x0000003c 0x0000003d 0x0000003e 0x0000003f 0x00000040
0x00000041 0x00000042 0x00000043 0x00000044 0x00000045 0x00000046 0x00000047 0x00000048 0x00000049 0x0000004a 0x0000004b 0x0000004c 0x0000004d 0x0000004e 0x0000004f 0x00000050
0x00000051 0x00000052 0x00000053 0x0fffffff 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
D:\>
This shows that there are some cluster chains (still) in use. For example, the root directories cluster chain starts in sector 1dd1 (Cluster 2 / 8 sectors per cluster), followed by 0x1dd9 (cluster 3), followed by 0x1de9 (cluster 5), followed by 0x1df9 (cluster 7), followed by 0x1e09 (cluster 9), followed by 0x1e19 (cluster 0xb) - end
What I notice is that each of these clusters has a single file in it (as if each were an independent sub-directory) with names like FLUSH, 2015, INDEX, CALIB etc., each marked as files.
There is also data content that can be seen in some clusters (possibly OK) but the strangest thing is that the root directory looks to be made up of a number of clusters, each with a single file name in each one. It is expected that the root (and any other directory) is made up of entries that are all alongside each other - each cluster can contain 128 such file objects (they are all short file names) and not just one per cluster (!)
The result is that the directory listing scans the cluster until it finds an empty entry signalling the end (which happens immediately since there is such a lot of space).
At the moment it is surprising that your firmware actually sees the content - it is clear that Windows also won't find anything, as the firmware that I am running doesn't. If I understnd correctly this is also the case when you take a 'standard' project build and only happens with your build (?)
At a first educated guess it looks like your code is not using 32 bytes as a directory entry size but instead using the cluster size (4k). File object increments look to be stepping by this amount. This supposedly works when written and read by code doing this but will not be understood by anything else.
I would: check with the debugger any code that is using a pointer to DIR_ENTRY_STRUCTURE_FAT32 and executing something like
ptrDirectoryEntry += ptr_disk_location->ucDirectoryEntry; // move to the present entry
Each ptrDirectoryEntry++ should be a 32 byte increment, whereby it looks like your compiled code may be incrementing in 4k steps instead.
Has something happened to DIR_ENTRY_STRUCTURE_FAT32 that explains this or is the compiler going crazy??
Hope you find something quickly based on this data.
Regards
Mark
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version