Hi,

I'm using FreeRTOS 7.5.3 and lwIP 1.4.1 on a NXP LPC1776 Cortex M3 device. The development environment I use is IAR embedded workbench and the C-SPY debugger.

After about 30 minutes of operation without any problems receiving data via ethernet stops. Using the debugger I could see that the receive interrupt is fired and the interrupt handler tries to wakeup the receive task by calling xQueueGenericSendFromISR. This fails because the queue is not empty.

But the receive task remains in the blocked state. The task stays in xQueueGenericReceive with BlockTime set to portMAX_DELAY.

best regards, Alex

Can you post screen shots of the state viewer again. This time add the queue to the queue registry so you can include the queue table in the screen shot.

Here it is

I can't think you you would get into that state without some kind of data corruption or breaking some rules on how you use the API. Look through the following list if you have not done so already and carefully consider if you could have done something wrong http://www.freertos.org/FAQHelp.html

If you are using 7.5.3 and have configASSERT() defined to something that will halt your program then bad interrupt priority assignments is probably not the problem this time.

Hi,

today I've had a hard fault in the tick interrupt handler.

Attached you will find a screenshot showing the call stack, the local variables of xTaskIncrementTick, the task state window and the register settings of the NVIC.

The reason for the hardfault seems to be that pxTCB points to 0 but why does it? Another strange thing is that the task state window shows a task without name and strange parameters.

I set #define configCHECKFORSTACK_OVERFLOW 2 and took a look at the task stacks to make sure that there is no stack overflow.

[since when did posts start needing moderation? I will see if I can turn that off]

As per Dave's post (which I have just moved out of the moderation queue), the most likely cause of your issues is an old fashioned data corruption. Something is writing over your RAM, and as you are using lwIP, I would hazard a guess something there is to blame (maybe the MAC driver?).

Regards.