It looks like the main TCPIP thread must be started from the main thread. I
moved the tcpip_init() function in the main thread instead of another thread
and it works with and without preemptive mode...
Does that make sense at all?






On Mon, Sep 28, 2009 at 3:59 PM, Dany Thiffeault <[email protected]>wrote:

> 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

Reply via email to