Hi,
I am building 100 radio astronomy receivers for the Molonglo Radio Observatory in Australia . The receivers use down converters, FPGA's and a eZ80F91 module. The module launches a FPGA bit file in to a FPGA whose purpose is to serialize the data and then transmit via optical fibre.

My problem at present is the dirty flash file space after deleting a bit file is not returned to the free memory. What is the remedy. It looks like I have the memory is in a data persistence mode. Suggestions most welcome.
Thanks
Rgds Duncan

Can you describe the storage scheme you use on the eZ80 a bit more. I assume you retrieve from onboard flash and send to the FPGA. Are you using the Zilog file system code ? I haven't used it, but I wouldn't mind reading about it.

System Overview:
The FPGA bit file is for a lattice FPGA . The bit file is generated from the Lattice Diamond software with the bit file header striped. The file is about 733kB . Consuming a large fraction of the flash memory I decide to "Run length encode". Some compression is achieved but this is not my ultimate goal of using a more compact form of file compression. Two files are is Ftp'ed to the flash memory. One contains the file length the second the bit file. Having both files on the flash the bit the file length on the flash is checked and the compressed bit file is decoded on the fly.
The decoded bit file is then JTAG'ed into the FPGA chip.

The files are binary. Written to or read from on flash by standard c calls fread etc.

I have a control system that reports the presence of the relevant files and am now putting in some house keeping to report file length to guard against bit error and file deletion.

The system is evolving from the development stage to an operational stage. I have 90 systems to be placed in the field spread over 1 mile.
Deployment is logistical issue so the system has to be bug free as best I can.
I will continue my system description tomorrow
Rgds Duncan

You mentioned fread() so I'm going to assume that you are using the Zilog File System with the RZK.

I read the documentation and there is only the slightest hint that a file system in ROM will be write-once and that only a RAM file system can be updated. The RAM file-system would be copied back to ROM. With an flash block size of 64k, it would be a huge burden for an embedded system to continually reorganize the individual blocks because each would require a full erase and recopy. A more sophisticated scheme could leave one or more blocks always empty for reorganization. All three documents about the Zilog File system list garbage collection as a feature but there is not a mention of when it is triggered or the resources it would require if implemented for a flash-based file system. Without any source code or more detailed documentation it's still mostly guesswork. Have you posed the question to tech support ?

Perhaps you can make a system function that unmounts the filesystem, erases the area of flash and remounts before you send fresh images. Are you using an external flash chip ? The internal flash should be directly supported by the RZK drivers.