On Thu, Sep 3, 2009 at 2:22 PM, Simon Kallweit<[email protected]> wrote: > Mandeep Sandhu wrote: >>>>> >>>>> <snip> >>>>> >>>>> cyg_lwip_sequential_init(); >>>>> >>>>> cyg_lwip_thread_new( "My thread", m_main, (void *)"My thread", >>>>> my_stack, 0x1000, 5 ); >>>>> ... >>>>> ... >>>>> <snip> >>>>> >>>>> I'll enable more debugs to see where it's getting stuck. >>>> >>>> After changing it to 2, it's able to find the interface (et0) with all >>>> the right settings. >>> >>> Well, that does not really make sense. cyg_lwip_sequential_init() will >>> not >>> return until the lwip stack is initialized, and initializing ethernet >>> device >>> drivers is part of that. This *must* work even when the TCPIP thread has >>> lower priority, as long as you start your application thread *after* the >>> execution of cyg_lwip_sequential_init(). By starting *after* I mean that >>> you >>> also have to make sure that cyg_lwip_sequential_init() and starting your >>> applications thread is done in the same thread! >>> >>> I hope I didn't miss the obvious here, but that's how it should work. >> >> Well, I checked the code again. The netif init is done as part of >> tcpip_init_done(). >> This I see is being called in tcpip_thread(). This function is being >> executed in the >> tcpip thread's context. >> >> I guess this is why the priority of the threads matters. >> >> Would do you think? > > There is a semaphore created in cyg_lwip_sequential_init() which will block > until all initialization (including ethernet devices) in the tcpip thread is > done. Therefore it's priority does not matter. cyg_lwip_sequential_init() > should not return before initialization is completed. > > I just reviewed the code and found that the semaphore is initialized with 1, > which is clearly a bug, it should be initialized with 0 so that the > following call to cyg_semaphore_wait() is actually blocking the thread until > initialization is done. > > My mistake, sorry! Hope it works as intended now. New release: > > http://download.westlicht.ch/lwip-20090903.tar.gz
Thanks Simon. I totally missed the sem init part...i guess since the sem is init to 1...the thread never actually waits...and thats why I was seeing the problem. I'll try out the new build and let you know... Thanks, -mandeep > > Simon > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
