We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi there,
I am using an own PCB with Luminary lm3s8962 (based on the evaluation board) with LabVIEW for ARM and KEIL uVision V3.85
In the past I've been developing code to, Log some data to/Read logfiles from, a microSD card without problems.
The data that is being logged is become a little bit more and at this moment I get corrupted data on/from the microSD card. I am using SanDisk 2 GB microSD's.
problem one: When I write enough data for a longer time I see that sometimes the data is wrong. I tested this behavior and I can reproduce it. The data size is OK but where I expect data like: 112;112;112;112;112;112 I see: 112;112;11;111;1112;112
sometimes the SDcard copies old or wrong data to that position that is wrong.
I've made a change which decrease the buffer per write. Now I don't see this problem anymore. Is this an known issue?
problem two: When I read files from the microSD card on my embedded ARM and read the data via USB, I get wrong data (the first bytes are looking like a directory table of FAT) I didn't made any change to the USB Read protocol and I wipe the microSD before every test.
When I read the microSD card in Windows, there are no problems. Is there someone that is also getting strange behavior like this?
Yes I've tried that, with the same result as mkdosfs under linux. I also tried the EK-LM3S8962 evaluation board, with the same results!
I've made an dd image of the two different sd-cards. I see a kind of table at adress 0x8000 with characters from 0x04 untill 0x92. the one of sandisk (the one with errors) goes further until 0xFF. and afterwards there is another table like this..
the table looks like: 0400 0500 0600 0700 0800 etc.
what is this table?
or am I searching in the wrong direction?
For a FAT16 file system, you have a FAT - File Allocation Table - that stores a linked list of the blocks allocated for the individual files.
The directory entry contains the entry number of the first block of the file. And the FAT then points to the following blocks.
So if you have an empty FAT file system and copies in a file, the blocks will be allocated in sequence, making the FAT region look like a sequence counter.
So my guess is that the number sequence you see is the allocation information for one file chain.
Thanks, that could that be!
the read actions on the ARM that are wrong are one or two whole sectors (in the beginning of a read file) I see a part of the directory table instead of the real data. I made an dd image of the sdcards, the good one -> unbranded and the bad one -> SanDisk.
I see that the data is good and is written well! (I can read them good in windows/linux)
Why the SanDisk do this? Or is it KEIL RL-FLASHFS that cannot fully work with the (new) SanDisk microSD..
I have also an unbranded 2GB microSD, and that one has no errors!? 4 SanDisk microSD give 4 times the same errors in my file.
A 4G card must be SDHC; a 2G card is just SD - maybe that could account for the difference...?
www.sdcard.org/.../
www.sdcard.org/.../sdhc
I have one unbranded micro sd of 2GB I have four SanDisk micro sd of 2GB
the errors are in all the four SanDisk's
I know that my RL-ARM library doesn't support SDHC, but I don't have SDHC or SDXC.
So I've made an workaround for my write problems (write with smaller blocks of data, doesn't matter if I do 5 times a write operation in the same amount of time)
I still have the read problems on the SanDisk cards. I've made a dd image of it, and all the data stands correctly on the microSD card. There are no errors when I read the cards in windows. But, if I read the files on my embedded application, I get wrong data. It looks like the ARM sometimes get the wrong sector number to read, (the faults are in block of 512 bytes, the sector size on the microSD) But why only on the SanDisk cards and not on the other unbranded card.
Nobody having these errors?
The read error occurs when the file size is over approx. 500.000 bytes If the files are bigger then I'm going to miss data when I read in the ARM.
How different can a brand microSD be against an unbranded microSD!? Is SanDisk using a "extended protocol" or do they use other timings..
It's so strange that I get wrong data if it is right on the card.
Have you checked if the cards are created with same-size clusters or same-size sectors?
Since a FAT-16 file system can only map 2^16 different memory blocks, the data is stored in clusters of one or more sectors.
The cluster size controls how long the FAT chain needs to be for a given file size. And cluster size also controls how large partition that may be mapped by the 16-bit cluster numbers you have in FAT-16.
A 4GB card with 2^16 clusters needs 65536 byte large clusters. A 2GB card only needs 32768 byte large clusters.
The 2GB card will then have twice as long FAT chains for a file of same size.
The cards are exactly the same formatted, 512 bytes sectors, 32k clusters. under linux (fedora) with: dd if=/dev/zero of=/dev/sdc bs=2M <-- to wipe the cards mkdosfs -F 16 /dev/sdc -I <-- -F 16 for FAT16 -I to force it (no partition/MBR)
I Made dd copies of the unbranded and SanDisk, and those are the same written. (before and after the embedded write actions) but when I read on the ARM: unbranded = OK, SanDisk = strange data and sometimes faults in the data.
I've got a new version library of FlashFS (FS_CM3.lib), I've looked at the code of it and some timings (timeouts) are different. now the microSD's of SanDisk work perfect!
Strange.. but I'm happy now :)
Thank you for your support!
Wouter
I don't think it's strange at all:
When stuff "works" sometimes, and fails others, timing is always a prime suspect!
Was that a released version of FS_CM3.lib, if so what version.
Thanks Darren
I had the one that comes with LabVIEW for ARM 2010 -> RL-ARM V3.70
I have now RL-ARM V4.11, build myself but not changed the source
Thanks for the update..
sorry, in my previous post I meant LabVIEW for ARM 2009..