Callback functions return where?

Kernel
1

chaalar wrote on Sunday, September 24, 2006:

I have task named X. I’m registering for a callback function in my task X and then start blocking on a queue Y. When a packet is recieved from MAC my registered callback function is called. Everything is ok up to this point.

But when I try to post to queue Y in this function I  face some problems. I could not localize the problem because of these questions.

1) Can we say this callback function is running in the context task X? or it is running in the context of MAC task(namely lwip’ tcp_ip_thread).
2) Where does this callback function returns?

Thanks…

2

nobody wrote on Sunday, September 24, 2006:

I don’t understand your question - sorry.

A function will run in the context of the task from which it is called, if this helps.

3

nobody wrote on Monday, September 25, 2006:

Yes, it helps a lot. Thanks for the reply.

But I could not solve it. Let me clarify my situtaion with my source code. I’m using Sam7x Web server demo. There is two tasks which I’m interested. task_debug_info and tcp_ip_thread. As it is seen in the code, task_debug_info start receiving from a queue. When data arrives from ethernet tcp_ip_thread  calls a function named net_recv. And net_recv sends data to the queue. Problem is if I don’t post to the queue in the net_recv, everything is ok. But,if I call QueueSend than ethernet comm becomes faulty( I think tcp_ip_thread).

Below is my source-code. Thanks
void task_debug_info( void *pvParameters )
{
    //Task specific variables
    debug_info dbg;   
   
    //Ethernet variables.
    struct netconn *listen_pc, *conn_pc = NULL;   
   
    /* Parameters are not used - suppress compiler error. */
    (void ) pvParameters;
   
    //Create debugging queue
    debug_mes_queue = xQueueCreate( DEBUGGING_QUEUE_LENGTH, ( unsigned portBASE_TYPE ) sizeof( debug_info ) );
    if( debug_mes_queue == NULL )
        task_state = 0;   
       
    /* Create a new tcp connection handle */
     listen_pc = netconn_new( NETCONN_TCP );
    
    netconn_bind( listen_pc, NULL, DEBUG_LISTENING_PORT );       
    netconn_listen( listen_pc );   
    for(;:wink: {
        if(conn_pc == NULL) {
            conn_pc = netconn_accept(listen_pc);           
            //register for callback
            tcp_recv( conn_pc->pcb.tcp , net_recv );
        } else {
            /* Send debugging info. */
            switch ( conn_pc->pcb.tcp->state ) {
                case 0: //Connection is closed, wait for another.               
                    conn_pc = NULL;
                    break;       
                case 4: //Connection is established, send.                                       
                    if( xQueueReceive( debug_mes_queue, &dbg , DEBUG_BLOCK_TIME ) )
                        send_the_state( &dbg , conn_pc );                       
                    break;           
            }   
        }       
    }   
}
err_t net_recv(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err)
{
    debug_info dbg;       
    if ( p != NULL ) {
        //Post something to the queue       
        dbg.reg[0] = 48;       
        dbg.reg[1] = 49;
        //Needed by the tcp_ip_thread
        pbuf_free(p);   
        //This sending operation causes the problem
        xQueueSend( debug_mes_queue , &dbg , 0 );                    
    }   
    return err;
}

4

nobody wrote on Monday, September 25, 2006:

Looks ok.  Could it simply be a stack problem?  Have you tried increasing the task stacks?

5

chaalar wrote on Monday, September 25, 2006:

First of all, thanks for reviewing my code.

Yes, you were right, it is somewhat related to the stack. I increased the stack size and imposed some other precautions.

Best regards.