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?
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..