topic Re: Problem with my FTP Client. in ColdFire/68K Microcontrollers and Processors

MCF52235 - Problem with my FTP Client.

Nilson — Mon, 30 Jul 2007 21:12:37 GMT

I built a FTP Server and its working flawless, i can connect, log in, tranfer big files and disconnect multiple times (like 1000) without problems.

My FTP Client works like this...after some time, it connects to a server, logs in, uploads a big file (1-8MB) and disconnects. The problems appears after some connections, it can open the control socket but cant open the data socket(the data socket remains invalid), looks like it runs out of memory and cant create the socket, its strange but it can create the control socket, but not the data socket...

Client and Server are in the same task and they use the same sockets.

I already tried to wait more time between connections, tried to reduce and increase stack sizes and buffer sizes.

Do you guys have any idea how can i try to solve this?

Thank you.

--
Alban Edit: FSL Part Number added to Message Subject line.

Message Edited by Alban on 2007-07-30 06:00 PM

Re: Problem with my FTP Client.

Alban — Mon, 30 Jul 2007 21:48:39 GMT

Hello Nilson,

It is generally a good idea to give as much details as possible

For instance we push everyone on this Forum to include the Freescale Part Number on the subject line, at least. Otherwise there are so many parts that it is difficult to guess what part you are talking about.

On top of this, if you need to guess a lot of information a lot of people will not bother guessing and will not try addressing it.

Regards,

Alban.

Re: Problem with my FTP Client.

Nilson — Mon, 30 Jul 2007 23:45:25 GMT

Sorry about that, im using a MCF52235.

Re: Problem with my FTP Client.

Nilson — Tue, 31 Jul 2007 01:44:14 GMT

If anyone has some questions, fell free to ask.

Looks like im having problem because of the lack of RAM in the device.

Anyone has some idea how could i save some RAM?

Re: Problem with my FTP Client.

Kremer — Tue, 31 Jul 2007 19:02:22 GMT

Assuming that your application is based on NicheLite port (Coldfire_Lite) you could try to reduce the NUMBIGBUFS macro to as minimum as possible to work. It saves some RAM space.

Also, if you are using many global buffers or even static local buffers, you could use the stack instead of reserving this space for them.

32K isn´t much space when we are talking about many tcp/ip protocolos running on same application.

Hope it helps

Re: Problem with my FTP Client.

Nilson — Tue, 31 Jul 2007 22:46:24 GMT

Assuming that your application is based on NicheLite port (Coldfire_Lite) you could try to reduce the NUMBIGBUFS macro to as minimum as possible to work. It saves some RAM space.

I did that.

Also, if you are using many global buffers or even static local buffers, you could use the stack instead of reserving this space for them.

Im using one big global buffer to send and receive ftp data. i don't how could i use the stack to reserve space for this, could you enlight me?

32K isn´t much space when we are talking about many tcp/ip protocolos running on same application.

Its funny that my Server can handle lots of connections in sequence, but not the Client. Looks like the Client isnt freeing memory and after some connections memory is full. Maybe its having problems closing the sockets? In Server i use the server socket as listen, but in Client i use as m_connect. do you have any idea i could i track if the memory isnt being released?

Thank you very much for the help.

Re: Problem with my FTP Client.

bkatt — Sun, 05 Aug 2007 07:51:12 GMT

The niche stuff was not designed for machines with small RAM memory like the 52233. When I was working with that part the most effective way to free up memory turned out to be making the stacks smaller, and reducing the number of such stacks by minimizing the number of active tasks.

Also, there are a many of tables of constants that niche neglected to mark with the "const" keyword, so they end up taking space in initialized RAM. Making them const causes the linker to keep only one copy in flash.

The console has a memory command to show dynamic memory statistics, but the statisitics keeping had bugs in the version shipped with the eval boards. If you watch memory behavior you will see that sockets are expensive, particularly when they hang around in time-wait state after being closed.

Now I use the 5282 with 64K of RAM, and the squeeze is not nearly as severe.