Writing data on CF card using EDK 10.1 and xilfatfs



Hi there,

I'm making a kind of sniffer for a small network with very low
traffic. I need to capture the traffic and store the packets in a
permanent storage medium. At this time I'm using the ML403 board from
Xilinx, EDK 10.1 and the xilfats library.

As a preliminary test, I'm sending controlled individuals packets, and
the device receive the packet and save it in a file into the CF card.
This works for a time but the application crash after some time.

With the xilfatfs library, I open a file, and at the reception of a
packet I write the content and close the file. This step is repeated
for every packet. I'm using a 64 K BRAM memory for the system. Using
the defaults options for the linker script, the system hangs after
receiving 15 packets (15 files). Increasing the stack size allows to
handle more files but the system always hangs. Increasing too much the
stack size is not a valid option, because in practice I need the
system being able to handle large amount of data.

Also, saving more packets in a single file allows to manage more
information. For example, in this case I can save a total of 60 KB of
data instead of 15 KB with small files before the system hangs. But in
any case, this is far for the limits imposed for the FAT16 file-
system, which is used in the CF card.

In summary, I save the data in a temporal array which have fixed size,
at the end I write the content of the array in a file and close the
file. So, my question is: If I'm using a fixed amount of memory for
the temporal data, and just one file open at any time, why the system
go out of memory?

I'm new on the embedded applications and I don't manage all the
concepts about memory maps, linkers, etc. So I'm generally using the
default options from the tools. I don't know if I 'm doing something
wrong or there are some conceptual misconceptions. But I have been
reading and trying a lot of hours without success.

Any clue would be really appreciated.

Cheers!
.



Relevant Pages

  • Re: [PATCH 00/28] Swap over NFS -v16
    ... To do so we need to distinguish needed from unneeded packets; ... our state must not consume memory, ... a/ in caches, such as the fragment cache and the route cache ...
    (Linux-Kernel)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... of dirty memory so that when we desperately need memory on the ... any incoming packets. ... So suppose we forgot about all the allocation tracking (that doesn't ... A packet is received, it can be a fragment, it will be placed in the ...
    (Linux-Kernel)
  • Panic: Kernel page fault with ath0_com_lock held, r211295
    ... Kernel page fault with the following non-sleepable locks held: ... Physical memory: 2031 MB ... Loaded symbols for /boot/kernel/tmpfs.ko ... data packets ...
    (freebsd-current)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... To do so we need to distinguish needed from unneeded packets; ... our state must not consume memory, ... a/ in caches, such as the fragment cache and the route cache ...
    (Linux-Kernel)
  • [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new Dell BIOS update driver
    ... This also has a fix where the packets were leaked in the function create_packet line#227. ... +The BIOS update is done by writing the new BIOS image in to contiguous physical ... +memory addressable by the BIOS. ... +The disadvantage of contiguous allocation is that it may not be always possible ...
    (Linux-Kernel)