Thead Delete Problem

Kernel
1

anonymous wrote on Friday, June 15, 2012:

Hi,

I have a thread that runs PPP and works well sending/receiving data. When I try to close ppp and call the pppClose I encounter a hard fault. It appears when the thread ppp_input is deleted and in the line portYIELD_WITHIN_API(); a hard fault is occurred. In the main task where I do my PPP init,send data if I add a while loop as below and once a context switch occurs when the ppp_input task is deleted this doesnt crash the main task. I then set x = 1 with the debugger.

for(;;){

PPP…

pppClose(pd);

volatile x=0;

while(x==0);

}

I cant think of where the problem might be. Is the stack corrupting in some way?

Regards,

Nick

2

rtel wrote on Saturday, June 16, 2012:

You are asking people to speculate on an awful lot here, with very little assistance.

I have a thread that runs PPP and works well sending/receiving data.

Which stack are you using (curiosity, more than anything).

When I try to close ppp and call the pppClose I encounter a hard fault.

Which processor are you using?  Which code causes the hard fault?  You should be able to determine that from the register and/or stack when the hard fault occurs - but how that is done depends on the processor.

It appears when the thread ppp_input is deleted and in the line portYIELD_WITHIN_API();

The call to portYIELD_WITHIN_API() inside the vTaskDelete() function?  If so, then that would imply the ppp_input task was deleting itself.

In the main task where I do my PPP init,send data if I add a while loop as below and once a context switch occurs when the ppp_input task is deleted this doesnt crash

So it is not the vTaskDelete() function that is crashing, but completing correctly, and only if the main task continues from that point that the crash occurs?  Does the main task use the ppp task again after it is deleted?  Was the ppp task blocked on any semaphores or queues when it was deleted?

the main task. I then set x = 1 with the debugger.

….and what?  It crashes?  It doesn’t crash?

I cant think of where the problem might be. Is the stack corrupting in some way?

Maybe, but maybe not.  Do you have stack overflow checking on?

Regards.

3

anonymous wrote on Saturday, June 16, 2012:

Yeah sorry.

LPC1768 M3.
Yes stack overflow is enabled.

The problem occurred once it returned to the main PPP thread where I send the data:

ThreadPPP(){
   initPPP..
for(;;){
 PPPSend();
pppClose();
volatile int x= 0;
while(x==0);
}
}

Apparently the problem has been resolved by adding a function I had previously used.

WaitPPPClose();

When the pppClose is executed the modem then sends a NO CONNECT. It triggers an interrupt and the data is saved in a buffer.

By looking at the interrupt service routine its just a ring buffer. The interrupt may occur during the context switch can this be the problem?

Thanks

4

anonymous wrote on Saturday, June 16, 2012:

The:

WaitPPPClose();

Parses the NO CONNECT sent from the modem

5

rtel wrote on Saturday, June 16, 2012:

The interrupt may occur during the context switch can this be the problem?

If the interrupt is not making use of the FreeRTOS API, then it should not be a problem.  If the interrupt is making use of the FreeRTOS API, then it must use the API functions that end in “FromISR” - and the interrupt must have a priority at or below that set by configMAX_SYSCALL_INTERRUPT_PRIORITY (see http://www.freertos.org/RTOS-Cortex-M3-M4.html )

Regards.

6

anonymous wrote on Saturday, June 16, 2012:

Hi,

No the interrupt isn’t using freeRTOS API. What is the right thing to do? Ignore it or try and find why? :slight_smile:

7

anonymous wrote on Sunday, June 17, 2012:

Hi,

I changed the optimization of the ppp thread to -O0 and the problem fixed.

Regards,
Nick