I found a work-around, but not sure I like it. It works OK (does not hang) if I configure FreeRTOS in NON-preemptive mode: #define configUSE_PREEMPTION 0
in my FreeRTOSConfig.h file. The thing is, I would like to use the OS in preemption mode... what's the trick? Thanks again On Mon, Sep 28, 2009 at 3:04 PM, Dany Thiffeault <[email protected]>wrote: > NO_SYS is 0, because I'm running it with FreeRTOS. > I modified those: > #define TCPIP_THREAD_STACKSIZE 512 > #define TCPIP_THREAD_PRIO 7 > #define TCPIP_MBOX_SIZE 6 > > It still hangs. According to my call stack, there is a > "_Handle_Bus_Error_Data_Fetch()" following the call in blue below... > > > /*----------------------------------------------------------- > * TASK CREATION API documented in task.h > *----------------------------------------------------------*/ > > signed portBASE_TYPE xTaskCreate( pdTASK_CODE pvTaskCode, const signed > portCHAR * const pcName, unsigned portSHORT usStackDepth, void > *pvParameters, unsigned portBASE_TYPE uxPriority, xTaskHandle *pxCreatedTask > ) > { > signed portBASE_TYPE xReturn; > tskTCB * pxNewTCB; > #if ( configUSE_TRACE_FACILITY == 1 ) > static unsigned portBASE_TYPE uxTaskNumber = 0; /*lint !e956 Static is > deliberate - this is guarded before use. */ > #endif > > /* Allocate the memory required by the TCB and stack for the new task. > checking that the allocation was successful. */ > pxNewTCB = prvAllocateTCBAndStack( usStackDepth ); > > if( pxNewTCB != NULL ) > { > portSTACK_TYPE *pxTopOfStack; > > /* Setup the newly allocated TCB with the initial state of the task. */ > prvInitialiseTCBVariables( pxNewTCB, pcName, uxPriority ); > > /* Calculate the top of stack address. This depends on whether the > stack grows from high memory to low (as per the 80x86) or visa versa. > portSTACK_GROWTH is used to make the result positive or negative as > required by the port. */ > #if portSTACK_GROWTH < 0 > { > pxTopOfStack = pxNewTCB->pxStack + ( usStackDepth - 1 ); > } > #else > { > pxTopOfStack = pxNewTCB->pxStack; > } > #endif > > /* Initialize the TCB stack to look as if the task was already running, > but had been interrupted by the scheduler. The return address is set > to the start of the task function. Once the stack has been initialised > the top of stack variable is updated. */ > pxNewTCB->pxTopOfStack = pxPortInitialiseStack( pxTopOfStack, pvTaskCode, > pvParameters ); > > /* We are going to manipulate the task queues to add this task to a > ready list, so must make sure no interrupts occur. */ > portENTER_CRITICAL(); > { > uxCurrentNumberOfTasks++; > if( uxCurrentNumberOfTasks == ( unsigned portBASE_TYPE ) 1 ) > { > /* As this is the first task it must also be the current task. */ > pxCurrentTCB = pxNewTCB; > > /* This is the first task to be created so do the preliminary > initialisation required. We will not recover if this call > fails, but we will report the failure. */ > prvInitialiseTaskLists(); > } > else > { > /* If the scheduler is not already running, make this task the > current task if it is the highest priority task to be created > so far. */ > if( xSchedulerRunning == pdFALSE ) > { > if( pxCurrentTCB->uxPriority <= uxPriority ) > { > pxCurrentTCB = pxNewTCB; > } > } > } > > /* Remember the top priority to make context switching faster. Use > the priority in pxNewTCB as this has been capped to a valid value. */ > if( pxNewTCB->uxPriority > uxTopUsedPriority ) > { > uxTopUsedPriority = pxNewTCB->uxPriority; > } > > #if ( configUSE_TRACE_FACILITY == 1 ) > { > /* Add a counter into the TCB for tracing only. */ > pxNewTCB->uxTCBNumber = uxTaskNumber; > uxTaskNumber++; > } > #endif > > prvAddTaskToReadyQueue( pxNewTCB ); > > xReturn = pdPASS; > } > portEXIT_CRITICAL(); > } > else > { > xReturn = errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY; > } > > if( xReturn == pdPASS ) > { > if( ( void * ) pxCreatedTask != NULL ) > { > /* Pass the TCB out - in an anonymous way. The calling function/ > task can use this as a handle to delete the task later if > required.*/ > *pxCreatedTask = ( xTaskHandle ) pxNewTCB; > } > > if( xSchedulerRunning != pdFALSE ) > { > /* If the created task is of a higher priority than the current task > then it should run now. */ > if( pxCurrentTCB->uxPriority < uxPriority ) > { > taskYIELD(); > } > } > } > > return xReturn; > } > /*-----------------------------------------------------------*/ > > > But maybe it's not related to lwip... Investigating. If somebody has a > clue, let me know please please! > DownyTif > > > > > On Mon, Sep 28, 2009 at 2:44 PM, Francois Bouchard < > [email protected]> wrote: > >> Do you have an RTOS or not? If you don't have an OS, no it is not >> needed. Check out the NO_SYS constant, It must match your system i.e. == 1 >> if you're running lwIP in stand alone mode. >> >> Francois >> >> ----- Original Message ----- >> *From:* Dany Thiffeault <[email protected]> >> *To:* Mailing list for lwIP users <[email protected]> >> *Sent:* Monday, September 28, 2009 2:39 PM >> *Subject:* Re: [lwip-users] Help needed with sequential API >> >> Thanks Bill, >> I found another way a second ago (before reading your answer). I just >> modified the tcp.h functions back and forth and it worked. Looks like the >> tcp.h file wasn't being rebuilt, not sure why, cause I was cleaning and >> building... >> >> Not it builds ok. My second problem is also gone. I sent the code on the >> AVR32 and tried to ping the address, it didn't work. By debug, I found out >> that this hangs: >> void >> tcpip_init(void (* initfunc)(void *), void *arg) >> { >> lwip_init(); >> >> tcpip_init_done = initfunc; >> tcpip_init_done_arg = arg; >> mbox = sys_mbox_new(TCPIP_MBOX_SIZE); >> #if LWIP_TCPIP_CORE_LOCKING >> lock_tcpip_core = sys_sem_new(1); >> #endif /* LWIP_TCPIP_CORE_LOCKING */ >> >> sys_thread_new(TCPIP_THREAD_NAME, tcpip_thread, NULL, >> TCPIP_THREAD_STACKSIZE, TCPIP_THREAD_PRIO); >> } >> >> I found in my lwipopts.h file that TCPIP_THREAD_STACKSIZE is defined at 0 >> and TCPIP_THREAD_PRIO to 1. Not sure why those are the defaults values. I >> definitly need to change that I think, but I'm not sure what to put there in >> terms of size and priority. Any advice? >> >> Thanks again >> DownyTif >> >> >> >> On Mon, Sep 28, 2009 at 1:44 PM, Bill Auerbach <[email protected] >> > wrote: >> >>> The problem is, only define ONE of these to 1, leave the #define for 0 >>> out >>> >>> >>> >>> //#define LWIP_EVENT_API 0 >>> >>> #define LWIP_CALLBACK_API 1 >>> >>> >>> >>> Bill >>> >>> >>> >>> *From:* [email protected] [mailto: >>> lwip-users-bounces+bauerbach <lwip-users-bounces%2Bbauerbach>= >>> [email protected]] *On Behalf Of *Dany Thiffeault >>> *Sent:* Monday, September 28, 2009 1:07 PM >>> *To:* Mailing list for lwIP users >>> *Subject:* [lwip-users] Help needed with sequential API >>> >>> >>> >>> Hi, >>> >>> >>> >>> I'm trying to make my application using the sequential API work. I'm on a >>> Atmel AVR 32, using the framework 1.4 and the LWIP version 1.3.1 (with port >>> 1.3.0). >>> >>> >>> >>> I'm not even able to compile my application. I'm having a hard time with >>> the configuration of the IP stack and help would be much appreciated. >>> >>> So, I'll start with my first problem and post the other one later when my >>> first is fixed. >>> >>> >>> >>> PROBLEM 1: >>> >>> The only code reference I have is the ControlPanel example provided by >>> the Atmel framework, but it uses the 1.2.0 LWIP version, so many things have >>> changes. Below is my init function and even this is problematic: >>> >>> >>> >>> // Setup lwIP. >>> >>> // Initialize lwIP and its interface layer. >>> >>> /* >>> >>> #if LWIP_STATS >>> >>> stats_init(); >>> >>> #endif >>> >>> sys_init(); >>> >>> mem_init(); >>> >>> memp_init(); >>> >>> pbuf_init(); >>> >>> netif_init(); >>> >>> */ >>> >>> // Once TCP stack has been initialized, set hw and IP parameters, >>> initialize MACB too. >>> >>> tcpip_init(CManagerEthernet::ConfigureInterfaceCallback, >>> (void*)this); >>> >>> >>> >>> First, I found out that I don't have to call the init functions myself, >>> since now in the lwip 1.3.1, all those are called by the tcpip_init() >>> function. Note that "ConfigureInterfaceCallback" is an empty function >>> (code in comments). If the line in blue is commented, my code build without >>> problems. When I uncomment the line in blue above, I get those errors: >>> >>> >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core\tcp_in.o: In >>> function `tcp_input': >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core/tcp_in.c:378: >>> undefined reference to `lwip_tcp_event' >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core\tcp_in.o: In >>> function `tcp_process': >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core/tcp_in.c:710: >>> undefined reference to `lwip_tcp_event' >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core\tcp.o: In >>> function `tcp_abandon': >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core/tcp.c:245: >>> undefined reference to `lwip_tcp_event' >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core\tcp.o: In >>> function `tcp_slowtmr': >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core/tcp.c:786: >>> undefined reference to `lwip_tcp_event' >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core\tcp.o: In >>> function `tcp_fasttmr': >>> >>> src\SOFTWARE_FRAMEWORK\SERVICES\LWIP\lwip-1.3.1\src\core/tcp.c:818: >>> undefined reference to `lwip_tcp_event' >>> >>> collect2: ld returned 1 exit status >>> >>> Build error occurred, build is stopped >>> >>> Time consumed: 4813 ms. >>> >>> >>> >>> The thing is that my configuration is like this: >>> >>> #define LWIP_EVENT_API 0 >>> >>> #define LWIP_CALLBACK_API 1 >>> >>> >>> >>> When I check in the IP stack, the code in tcp.h is correctly disabled >>> (the part using LWIP_EVENT_API is correctly disabled while the #else is >>> functionnal). >>> >>> I'm I missing something? Is there other parameters related to >>> "lwip_tcp_event" that needs to be checked? Also, my application is in C++, >>> while the lwip is in C. I'm using "extern C" everytime I need to #include >>> header files from the framework, but I mention it cause I really don't know >>> where to look for at the moment. >>> >>> >>> >>> Thanks, >>> >>> DownyTif >>> >>> >>> >>> PS: my second problem is related I think... when I uncomment another >>> portion of my ethernet code, I get undefined references for "lwip_tcp_event" >>> but also for all the "tcp_xxx" functions, ex. "tcp_recv" >>> >>> _______________________________________________ >>> lwip-users mailing list >>> [email protected] >>> http://lists.nongnu.org/mailman/listinfo/lwip-users >>> >> >> ------------------------------ >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users >> >> >> _______________________________________________ >> lwip-users mailing list >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/lwip-users >> > >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
