[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pc386 bsp problem



Arquer Stephane wrote:
> Good morning,
>
> I changed the stack configuration to:
> #define CONFIGURE_EXTRA_TASK_STACKS (64*1024)
>
>   
That only reserves 64k more memory for task stacks.  It doesn't
result in any task getting more stack.

You need to increase the stack size on any task create operations
and define CONFIGURE_INIT_TASK_STACK_SIZE to
something other than the default below from confdefs.h.

#define CONFIGURE_INIT_TASK_STACK_SIZE    RTEMS_MINIMUM_STACK_SIZE


> The problem is the same, the task is deleted.
>
>
>   
If your task is calling the simulink generated code and that code
returns, your hand written task must be able to account for that.

{
  ....
  call simulink code
  ??? do something if it returns ???

  If you fall out the bottom of the task, it is a fatal error.
}
>> -----Message d'origine-----
>> De : Joel Sherrill [mailto:joel.sherrill at oarcorp.com] 
>> Envoy? : mercredi 23 mai 2007 17:22
>> ? : Arquer Stephane
>> Cc : Daron Chabot; rtems-users at rtems.org
>> Objet : Re: RE : RE : Pc386 bsp problem
>>
>>
>> Arquer Stephane wrote:
>>     
>>> Hi,
>>>
>>> Most of time I don't have any execption number, the task is 
>>>       
>> cancelled 
>>     
>>> while the other are continuing to work and sometimes there is an 
>>> exception raised but I can't catch it because the console displays 
>>> lines in continuous. It is the same with remote gdb, I 
>>>       
>> can't see the 
>>     
>>> problem with gdb in remote mode, there is no message.
>>>
>>> This problem occurs when I use complex simulnk models. I 
>>>       
>> think it is a 
>>     
>>> memory configuration allowed for a task. I use floating 
>>>       
>> point unit and 
>>     
>>> I need to do some calculations. The task which call the 
>>>       
>> step function 
>>     
>>> is created as follow:
>>>
>>>
>>> //*************************************************************
>>> mode = RTEMS_PREEMPT + RTEMS_TIMESLICE + RTEMS_INTERRUPT_LEVEL(0); 
>>> attributs = RTEMS_FLOATING_POINT + RTEMS_LOCAL ;
>>>
>>> status = rtems_task_create(nommage("simuLoi"),
>>> 				current_priority,
>>> 				RTEMS_MINIMUM_STACK_SIZE,
>>> 				mode,
>>> 				attributs, 
>>> 				&id_tLoi);
>>> //*************************************************************
>>>
>>>   
>>>       
>> You can try making the stack large like 64K and adding that to your 
>> confdefs.h
>> (EXTRA_STACKS).  If this is generated code, it can be very 
>> abusive on the stack.
>>
>> You could also switch the console to COM1 and using a 
>> terminal program to talk to the target.  That way you would 
>> have logs of the output.
>>     
>
> Can you tell me how to connect the console to com1 ?
> I've tried to use :
> #define USE_COM1_AS_CONSOLE	1
>
> But it doesn't work.
>
>
>
>   
>>> And my configuration is :
>>>
>>>
>>>       
>> /*------------------------------------------------------------
>> ---------------------
>>     
>>>   							
>>>       
>> configuration information  
>>     
>> ----------------------------------------------------------------------
>>     
>>> ------------*/
>>> #define CONFIGURE_TEST_NEEDS_CONSOLE_DRIVER
>>> #define CONFIGURE_TEST_NEEDS_CLOCK_DRIVER
>>> #define CONFIGURE_TEST_NEEDS_TIMER_DRIVER
>>> #define CONFIGURE_INIT_TASK_PRIORITY			110
>>> #define CONFIGURE_INIT_TASK_ATTRIBUTES			
>>>       
>> RTEMS_FLOATING_POINT + RTEMS_LOCAL
>>     
>>> #define CONFIGURE_MAXIMUM_TASKS				128
>>> #define CONFIGURE_MAXIMUM_SEMAPHORES			20
>>> #define CONFIGURE_MAXIMUM_MESSAGE_QUEUES			10
>>> #define CONFIGURE_MAXIMUM_TIMERS				16
>>> #define CONFIGURE_MAXIMUM_PERIODS				16
>>> #define CONFIGURE_MICROSECONDS_PER_TICK			
>>>       
>> 1000		// 1 tick every 1ms
>>     
>>> #define CONFIGURE_TICKS_PER_TIMESLICE			200
>>>
>>> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>>>
>>> #ifdef pc386
>>> #define CONFIGURE_HAS_OWN_DEVICE_DRIVER_TABLE
>>> rtems_driver_address_table Device_drivers[5] = {
>>>    CONSOLE_DRIVER_TABLE_ENTRY,
>>>    TTY1_DRIVER_TABLE_ENTRY,
>>>    TTY2_DRIVER_TABLE_ENTRY,
>>>    CLOCK_DRIVER_TABLE_ENTRY,
>>>    {NULL, NULL, NULL, NULL, NULL, NULL}
>>> };
>>> #endif	//pc386
>>>
>>> #define CONFIGURE_EXTRA_TASK_STACKS         (3 * 
>>>       
>> RTEMS_MINIMUM_STACK_SIZE)
>>     
>>> #define CONFIGURE_NUMBER_OF_TERMIOS_PORTS			10
>>> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS	10
>>>
>>> #include <confdefs.h>
>>>
>>> ----------------------------
>>>
>>> Thanks for your help.
>>>
>>> Stephane.
>>>
>>>
>>>   
>>>       
>>>> -----Message d'origine-----
>>>> De : Daron Chabot [mailto:daron.chabot at usask.ca]
>>>> Envoy? : mardi 15 mai 2007 17:35
>>>> ? : Arquer Stephane
>>>> Cc : rtems-users at rtems.org
>>>> Objet : Re: RE : Pc386 bsp problem
>>>>
>>>>
>>>> On Mon, 2007-05-14 at 17:34 +0200, Arquer Stephane wrote:
>>>>     
>>>>         
>>>>> The failure is an execption raised bay the "simuLoi" task when it
>>>>> calls the step function. The task is canceled by the 
>>>>>       
>>>>>           
>>>> scheduler, only
>>>>     
>>>>         
>>>>> "trwsr" and "trwsw" are running for a moment then a complete crash
>>>>> occurs. When I compile the same code with the leon3 bsp, tsim 
>>>>> simulator works fine.
>>>>>       
>>>>>           
>>>> Exactly what information does the exception provide ?
>>>> (exception number,
>>>> etc.)
>>>>
>>>> Can you use a debugger (gdb) to step through
>>>> "task_gestion_loi( )" and see precisely where the exception 
>>>> is being raised ?
>>>>
>>>>
>>>> -- dc
>>>>
>>>>
>>>>     
>>>>         
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com 
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>>       
>>