This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error while reading more than 65k data using fatfs

Hi, can any one plz help me to solve fatfs read problem?

I am using Cortex-M3 luminary lm3s6965 controller. My application is such that I am writing
100-150k data(1024 bytes at a time; i.e. using for loop), in single .csv file, in 4GB micro SD card using fat16. and it is working perferctly.

Bt when I am trying to read data from sd card(1024 bytes at a time), then it will read data upto 65535 bytes and then it gets hang.

So can i read complete 100-150k data from sd card.

Could any body help?
Thanks in advance...

Parents
  • "So what is real problem?"

    That you don't seem to like to perform any debugging.

    Haven't you taken a closer look at the low-level SPI code and seen if it does what it should?

    I'm not too impressed with an implementation that requires the interrupts to be disabled while you read 1023 bytes - that's a significant amount of time, which means serial ports, timers etc will not be properly serviced during this time. Maybe you don't use other time-critical peripherial hardware, but real-world applications normally do. Correct code should only need to turn off interrupts around a few processor instructions, when something needs to be performed atomically.

    By the way - if 1024 is too large block size then I would have tried 512 instead of selecting 1023. It's so very often faster to use a block size that is 2^n bytes large when there is a lower layer that may contain buffering, or when there is hardware that is block-based.

Reply
  • "So what is real problem?"

    That you don't seem to like to perform any debugging.

    Haven't you taken a closer look at the low-level SPI code and seen if it does what it should?

    I'm not too impressed with an implementation that requires the interrupts to be disabled while you read 1023 bytes - that's a significant amount of time, which means serial ports, timers etc will not be properly serviced during this time. Maybe you don't use other time-critical peripherial hardware, but real-world applications normally do. Correct code should only need to turn off interrupts around a few processor instructions, when something needs to be performed atomically.

    By the way - if 1024 is too large block size then I would have tried 512 instead of selecting 1023. It's so very often faster to use a block size that is 2^n bytes large when there is a lower layer that may contain buffering, or when there is hardware that is block-based.

Children
No data