infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

Dave

+ Reply to Thread
Results 1 to 10 of 10

Thread: FatFs returning error when writing large files.

  1. #1
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5

    FatFs returning error when writing large files.

    Hi, I am working on a Bootloader(XMC4700/DAVE432) that flashes the internal flash from SD-Card.

    With small .hex images all works fine, but if the image gets bigger (>600k)
    then the FatFs Function f_write() returns error code 1 (= FR_DISK_ERR).

    It seems that the app's "FATFS" or "SDMMC_BLOCK" cannot handle large files.

    Do you have any idea what might be causing this problem? Do you know of workarounds?

    best regards
    Hans

  2. #2
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5

    New findings

    With a "commercial" micro SD-Cards (tested with SanDisk Ultra 16 GB) there are no problems,
    also large files can be read and written.


    But with "industrial" micro SD-Cards (tested with Cactus 1 GB) the problem is not solved.

    Best regards
    Hans

  3. #3
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5

    More testresults

    I have testet the two SD-Cards with a program that writes
    40 000 * 100 Byte (4MB) to a file.


    With a 16 GB SD-Card (type=SDMMC_BLOCK_CARD_TYPE_HIGH_CAPACITY) there are no problems.

    But with the 1 GB SD-Card (type=SDMMC_BLOCK_CARD_TYPE_STANDARD_CAPACITY_V2) an
    error "SDMMC_BLOCK_MODE_STATUS_SECTOR_OUT_OF_BOUND" occours.


    I seems that the "SDMMC_BLOCK" app has problems with low capacity SD-Cards.

    Is it possible to fix this issue ? (..industrial grade 16GB SD-Cards are very expensive)




    Below are the output of the tesprogram for both SD-Cards.



    -----------------------------------------------------------------------------------------------------
    Test with 1GB SD-Card:


    ----- SD_CARD_TEST start ! -----
    check_SD_CARD()
    SDMMC_BLOCK_CARD_TYPE_STANDARD_CAPACITY_V2
    Ok mount SD-card
    open ok
    SDMMC_BLOCK_SD_lCheckSectorBound()
    SDMMC_BLOCK_MODE_STATUS_SECTOR_OUT_OF_BOUND, sector_num=3015, local_sector_count=2999
    i=5
    Error write data(100 byte)
    ErrCode=117 is_size=12
    close
    SDMMC_BLOCK_SD_lCheckSectorBound()
    SDMMC_BLOCK_MODE_STATUS_SECTOR_OUT_OF_BOUND, sector_num=3015, local_sector_count=2999
    --- unmount ---


    ----- SD_CARD_TEST end ! -----


    -----------------------------------------------------------------------------------------

    Test with 16GB SD-Card:

    ----- SD_CARD_TEST start ! -----
    check_SD_CARD()
    SDMMC_BLOCK_CARD_TYPE_HIGH_CAPACITY
    Ok mount SD-card
    open ok
    write file successful finished
    close
    --- unmount ---


    ----- SD_CARD_TEST end ! -----

    Best regards,
    Hans
    ?????

  4. #4
    Advanced Advanced David King is on a distinguished road
    Join Date
    Feb 2017
    Posts
    64
    Points
    815
    Hi Hans,

    This *might* fall into the category of ruling something out. But your second post made me think it could be worth a pre-test, of your various SD cards, 'commercial' and 'industrial', using the PC-based 'h2testw' tool, available for example, at https://www.portablefreeware.com/?id=1519.

    I know from the web and experience, that some cheaper SD cards have less capacity than they report, and are sold as. And this includes SD cards that are badged as from reputable manufacturers, but are infact clones. And this is not apparent until an attempt to use the card in excess of its actual capacity. For example, on writing a large number of files, in which case some go AWOL. Or with a single large file, in which case it reads corrupt, or not at all.

    The tool does take a while to run. But it writes 1MB files with various values to all reported available locations, and when done, reads back and checks the file values were as written. It's non-destructive, unless the card has issues, in which case data can be lost, so backup first. You'll need of course an SD port on your PC or eg USB-to-SD-port adaptor..

    Best regards,

    David King

  5. #5
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5
    Hi David,

    Thanks for your tip.
    I have tested my 1GB SD-Cards with 'h2testw'.

    All was ok, so I think the quality of the SD-Cards are not the problem.

    Best regards,

    Hans

  6. #6
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5

    I solved the Problem

    In the file "sdmmc_block_private_sd.c" the function SDMMC_BLOCK_SD_GetSectorCount()
    computes the wrong sectorCount for "Standard SD (and MMC) cards" if csd_v1.read_blk_len is zero.

    For all 1GB SD-Cards I have tested, the SDMMC functions gets a "..csd_v1.read_blk_len" value of zero.
    (This may be another problem.)

    mult was computed as:

    mult = (uint32_t)(((uint32_t)temp_csd_v1.dev_size_mult + (uint32_t)temp_csd_v1.read_blk_len) -
    (uint32_t)7U);

    I changed the computation to the formula that is given in the /*original comment*/ (read_blk_len not needed) :

    /* Left shift evaluates 1 * 2 ^ (TmpMmcCsd.DeviceSizeMult + 2) */
    mult = (uint32_t)temp_csd_v1.dev_size_mult + (uint32_t)2UL;

    With this changing everything works fine, I can write large files.


    Best regards,

    Hans

  7. #7

    Infineon Employee
    Infineon Employee
    jferreira will become famous soon enough
    Join Date
    Oct 2012
    Posts
    303
    Hi,

    Thanks for sharing the fix. The APP will be updated in the next release expected by the end of the month.

    Regards,
    Jesus
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  8. #8
    Advanced Advanced shenj is on a distinguished road
    Join Date
    Feb 2015
    Posts
    111
    Points
    1012.5
    could you please explain the technical reason why mult is so calculated? What and where is the reference for this calculation ?
    Last edited by shenj; Jun 9th, 2017 at 01:32 AM.

  9. #9
    Beginner Beginner Hans_ is on a distinguished road
    Join Date
    Mar 2017
    Posts
    9
    Points
    72.5
    Quote Originally Posted by shenj View Post
    could you please explain the technical reason why mult is so calculated? What and where is the reference for this calculation ?
    Hi shenj,

    mult is computed in the original code as:

    mult = dev_size_mult + read_blk_len - 7

    The main problem is, that "read_blk_len" is read as 0 !

    if read_blk_len is not available(=0), a good default value is 9 (2^9 = 512 byte)
    ( Standard SD cards until 1GB use a block_len of 512 byte. )

    This solution is not perfect, but better than the old one (..read_blk_len == 0)
    some information i found here: http://www.hjreggel.net/cardspeed/in...pecial-sd.html

    so we have:

    mult = dev_size_mult + 9 - 7
    mult = dev_size_mult + 2

    Sector_Count = (Device_Size + 1) << mult


    Best regards
    Hans

  10. #10
    Advanced Advanced shenj is on a distinguished road
    Join Date
    Feb 2015
    Posts
    111
    Points
    1012.5
    Hans_ many thanks for the wonderful explanation.

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.