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

FlashFS fdelete() - does it reclaim free space

Hi All,

I am using FlashFS (MDK-ARM V4.22) with an SPI FLASH (Atmel AT45DB321C) and STM32F207.

My problem is that when I delete files using fdelete() the free space (as reported by ffree()) is _never_ recovered, even though the files disappear from the file list (as reported using repeated calls to finfo()). I can delete ALL the files, and NONE of the space is recovered.

I realise that the FLASH can only be erased a block at a time, and indeed the manual says:

"When the file content is modified, the old file content is invalidated and a new memory block is allocated. The Flash Block is erased when all the data stored in the Flash Block have been invalidated."

This is perfectly reasonable. However, this reclamation of space when an entire block is invalidated never seems to happen; ffree() only ever reports a decreasing amount of free space, and I never hit the breakpoint I set on the SPI driver EraseSector() function.

The only way to recover the space seems to be to call fformat() which, as expected, erases the whole FLASH.

Does anyone have any ideas as to what I might be doing wrong?

Thanks in advance,

Christopher Hicks
==

Parents
  • > Thank you - that's a good point. It has also occurred to me to check whether the device
    > might be configured for 512 byte sectors instead of the default 528. Will check both.

    Have checked and all is in order here.

    I have tried calling the FLASH driver functions directly with toy code:

    uint8_t tmpbuf[2000];
    
    [...]
    
    Init(0,0);
    ReadData(1234, 2000, tmpbuf);
    for (int i=0; i<2000; i++) {
            tmpbuf[i] = tmpbuf[i] + i;
    }
    ProgramPage(1234, 1000, tmpbuf);
    ReadData(1234, 2000, tmpbuf);
    for (int i=0; i<2000; i++) {
            tmpbuf[i] = tmpbuf[i] + 1;
    }
    ProgramPage(1234+500, 1000, tmpbuf+500);
    ReadData(1234, 2000, tmpbuf);
    EraseSector (1234);
    ReadData(1234, 2000, tmpbuf);
    

    Stepping through carefully, examining the contents of tmpbuf in a (non-cached!) memory window shows everything apparently working correctly.

    I am now guessing that the library's use of the program command 0x83 that includes an erase (instead of calling EraseSector() explicitly) has the unanticipated side-effect of causing sectors never to be marked copmpletely invalid, erased, and added to the free list. However, this is in library code to which I do not have source, so I can't verify this.

    I'm a bit confused by this lack of source code, though, as I found a bug in FlashFS once before that was fixed by Keil (<http://www.keil.com/forum/14006/#msg69836>). Has poilcy about distributing source for FlashFS changed in the last three years, or am I just not looking in the right place?

    CH
    ==

Reply
  • > Thank you - that's a good point. It has also occurred to me to check whether the device
    > might be configured for 512 byte sectors instead of the default 528. Will check both.

    Have checked and all is in order here.

    I have tried calling the FLASH driver functions directly with toy code:

    uint8_t tmpbuf[2000];
    
    [...]
    
    Init(0,0);
    ReadData(1234, 2000, tmpbuf);
    for (int i=0; i<2000; i++) {
            tmpbuf[i] = tmpbuf[i] + i;
    }
    ProgramPage(1234, 1000, tmpbuf);
    ReadData(1234, 2000, tmpbuf);
    for (int i=0; i<2000; i++) {
            tmpbuf[i] = tmpbuf[i] + 1;
    }
    ProgramPage(1234+500, 1000, tmpbuf+500);
    ReadData(1234, 2000, tmpbuf);
    EraseSector (1234);
    ReadData(1234, 2000, tmpbuf);
    

    Stepping through carefully, examining the contents of tmpbuf in a (non-cached!) memory window shows everything apparently working correctly.

    I am now guessing that the library's use of the program command 0x83 that includes an erase (instead of calling EraseSector() explicitly) has the unanticipated side-effect of causing sectors never to be marked copmpletely invalid, erased, and added to the free list. However, this is in library code to which I do not have source, so I can't verify this.

    I'm a bit confused by this lack of source code, though, as I found a bug in FlashFS once before that was fixed by Keil (<http://www.keil.com/forum/14006/#msg69836>). Has poilcy about distributing source for FlashFS changed in the last three years, or am I just not looking in the right place?

    CH
    ==

Children
  • It occurs to me to mention one other thing. My implementation of the low-level SPI function SendBuf(U8 *buf, U32 sz) (which actually transmits data to the FLASH chip over SPI) overwrites buf.

    The protoype supplied by Keil does not specify that buf is const, so I assume I am allowed to do this. I cannot be certain, but I think the problem with the free space not being recovered pre-dates this change I made to the implementation of SendBuf() anyway.

    CH
    ==

  • > My implementation of the low-level SPI function SendBuf(U8 *buf, U32 sz) (which actually
    > transmits data to the FLASH chip over SPI) overwrites buf.

    This was the problem. Keil documentation and code ask for my implentation of

    BOOL SendBuf(U8 *buf, U32 n);
    

    but actually needs

    BOOL SendBuf(const U8 *buf, U32 n);
    

    in order for the filesystem to work properly. Have reported this as a bug to Keil/ARM.

    CH
    ==

  • => Has poilcy about distributing source for FlashFS changed in the last three years, or am I just not looking in the right place?

    Policy changed.

    http://www.keil.com/forum/18662/
    http://www.keil.com/forum/18702/

    Danny Curran, 27-Apr-2011 16:16 GMT
    -----------------------------------
    NDA signed and returned
    was given a link to a zip file and downloaded it.
    About approx 12 new files and 4 or so changed in the Flash FS
    Not looked a the USB side but can see differances there as well.