Hi All,

We are running multithreaded FreeRTOS application on 88MC200 Microcontroller.

1. We have created a interrupt service routines for handling a GPIO pin interrupt and sending Gpio change status into a queue from interrupt service task using “xQueueSendToBackFromISR”.

2. We have created 2 threads, One of the thread(Thread1) continuously receives the data from the message queue(GPIO change status sent from ISR()) using "xQueueReceive” and saves into the local buffer.

3. In another thread(Thread2) we have implemented TCP socket server which accepts the connection from remote PC application and performs the socket send and recv operation continuously.

4. Now the problem is, we are seeing that board hangs after some time ( 10-20 minutes of application start) and board is getting restarted after a while(No error message is displayed).During this scenario, We are receiving interrupts and Interrupt service routine fills the queue and becomes full but our thread is not able to receive(Looks like thread1 is not in active state). At this point, remote client application is also not getting the response from server which implies that thread2 is also not responding.

Can anyone explain why threads are not responding and is there any way to debug?

Thanks in advance,

Krishna

[sorry for the late reply, for some reason your post went into moderation, which it should not have done]

Most likely cause is an incorrect interrupt priority.

Which version of FreeRTOS are you using? As if it is a recent version then defining configASSERT() will catch most such issues. Do you have configASSERT() defined?

Are you using our own TCP/IP stack, or a different one?

Not related to your question - but depending on the frequency of the interrupt you may be better using a circular buffer rather than a queue to send data from the interrupt. The TCP/IP stack (link above) has a stream buffer implementation which some people are already using for this purpose - the link being such a discussion.

Regards.

Hi,

Thanks for the reply.

Using circular buffer implementation instead of queue, I am not facing board hang issue. Thanks for the suggestion. But not sure about Why I was facing board hang issue with queue usage.

Now when I am trying to create one more task (Already 2 tasks we crated), I am getting errCOULDNOTALLOCATEREQUIREDMEMORY error.

For first two taks, I have defined a stack of 3Kb and 1 Kb respectively. When I try to create a another task with 2 Kb stack I am facing memory problem.

If I am reducing the stack for 1 st thread to 2 KB, 3rd thread will run. But TCP server implemented thread in first thread will continuously throw accept error when client application trying to connect.

Board have 384 KB RAM and 1 MB flash embedded in it.

How I can overcome this memory issue?

Thanks in advance, Krishna

Hi,

Adding few things to my previous post. I am using heap4.c and available heap space is set to 72kb in FreeRTOSConfig.h using configTOTALHEAP_SIZE macro

Should I try heap_2.c?

Regards, Krishna

You have not said which TCP/IP stack you are using.

If you have 72K available, and have used up 4K in stacks, then something else must have consumed a lot of heap if you cannot then allocate another task. Do you know what that is? If not, find out by placing a break point in pvPortMalloc() to see what it is - or use FreeRTOS+Trace to log memory allocations.

Note stack sizes are defined in words, not bytes, so asking for a stack of 1000 on a 32-bit machine will result in a stack of 4000 bytes.

Regards.

By the way - our reply was late again because your post went into moderation again. Do you know why that might be?

Regards.

Hi,

I have no idea why my all posts are going to moderation.

I am using custom TCP/IP stack provided by WiFi vender. We are using additional 12 tasks for driver interfaces and all together 38K stacks allocated for all threads. If I am commenting any one of existing task, my application task will run.

Currently I am checking the places where and all used pvPortMalloc and eliminating the use of heap by declaring fixed array wherever possible.

Regards, Krishna