MCf52233 with coldfire_lite project freeze when it is idle for more then 10 minutes

[paddy]

Hi,

We are using MCF52233 processor and using coldfire_lite project as base v3.0
and target as freescale_tcp_client.

We are using as static IP address. The application works fine when we process contiously, if it is kept idle for more then 10 minutes the processor get frrezed(locked) the control hangs in q.c file in QUEUE_CHECK( ) in the while loop.

It was tried by  defining the  LINKED_PKTS and undefined also, but the problem exist.

could anyone please help me to solve this issue.

please have a look attached screen shot of control when freezed and some piece of code.

Thanks in advance.

Regards,

screenshot&pkt free code.zip

Message Edited by t.dowe on 2009-09-02 02:20 PM

[vier_kuifjes]

Hello Paddy,

I have a coldfire lite project that I've been working on for about 1,5 years now.  In that time I have encountered frequent lockup problems. I have managed to figure out what these lockups caused, and now my app can run for weeks without any problems at all.

I have posted a modified version of Coldfire Lite here on the forum. In fact, I have suggested to Freescale to apply my suggested changes in an official release of CF Lite.

You can find my modified version in this thread:

http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=7226

There's more than just a couple of bug fixes in my version, I have applied a couple of functional improvements too.

My version is based on the most recent CF Lite version released by Freescale, which is version 3.2.

Maybe you can give my version a try and see if it fixes your problems.

- Marc

[paddy]

Hi Marc,

I have attached the processor.h and ipport.h files for your refernce.

If no process is done in the application is there chance to receive the network packet. Any intterupt settings should be changed in fec_isr().

Header.zip

Message Edited by t.dowe on 2009-09-02 02:15 PM

[paddy]

Hi Marc,

Thanks for your input.

I checked your code and did changes in osport.h and processor.h macros changed according to your code.

APP_STACK_SIZE, IO_STACK_SIZE and MAX_ETH_PKT. The source code was almost same but still it gets locks after 15 minutes. Regarding this issue we did a workaround method by below method

    if (pkt->nb_blen == bigbufsiz)
      {
        qdel(&bigfreeq, (qp)pkt);
        q_add(&bigfreeq, (qp)pkt);
      }
         
      else
      {
        qdel(&lilfreeq, (qp)pkt);
        q_add(&lilfreeq, (qp)pkt);
      }

It was working more then one day witout locking. But logically qdel will delete the packet and again trying to adding it.

Is there any other way to overcome this issue. Need to concentrate on which part of the file. I have a query regarding this issue, when it is idle how come it reciving network packets. Because of reciving network packets this problem occurs. I have attached the recent screen shot of this issue.

Thanks in advance.

lock_screenshot.doc

Message Edited by t.dowe on 2009-09-02 02:12 PM

[vier_kuifjes]

Hi Paddy,

Apparently the zip file referenced to in my previous post did not contain a clear explanation of what exactly I did change to CF Lite. I have attached a .doc file to this message with a description of the changes.

You should look more specifically to the changes in the file tcpapi.c. There's a wait loop in the code that does not contain a timeout, if your program gets stuck in that loop it will hang (this was the main problem in my application).

The .doc file may not be completely up-to-date but the most important changes are in there. The modified source files in my version of CF Lite also contain comments. The easiest way to find all changes+comments is to compare the original CF Lite 3.2 with my version using the Codewarrior Search => Compare Files function. 

http://www.mvdh.be/cf%20lite%20mods.doc

[paddy]

Hi Marc,

In my case the control is not getting hangs in tcpapi.c , it recives network packet when idle this is handled by tk_netmain task and processing the data. The control flow can be seen in screen shot attached in my previous mail .

In the q.c file in QUEUE_CHECK()  there is a while loop, so control hangs there. It checks until the next node becomes NULL. But it not becoming NULL.

I have compared your files and my files, in this files no modification had done.

Regards

[vier_kuifjes]

This looks like one of those annoying, hard to solve problems. And there's hardly any official support for CF Lite from Freescale. One of those reasons to start looking into another operating system, like MQX or uTasker. Especially uTasker has very good support.

There's a similar bug in the DNS client also. It didn't make the system hang, at least - not directly, but it did in combination with the tcp bug. It returned false results when the URL could not be resolved.

I managed to correct that error but it took me a couple of days of intense debugging to figure out what was going on.

I'd love to help you out on your problem. It would be nice if I could have some working basic code that shows the problem. If the problem is in CF Lite and can be fixed, it would be a nice addition to my set of fixes!