FlashFS fdelete() - does it reclaim free space

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.

I have also dug into the datasheet for the part and the Keil driver code a little more. I discover that the ProgramPage() driver function uses a command (0x83) to the FLASH that automatically does an erase before programming. Perhaps this is why EraseSector() is not used except during formatting.

CH
==

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.

I have also dug into the datasheet for the part and the Keil driver code a little more. I discover that the ProgramPage() driver function uses a command (0x83) to the FLASH that automatically does an erase before programming. Perhaps this is why EraseSector() is not used except during formatting.

CH
==

> 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
==

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.