Pc386 bsp problem

Arquer Stephane stephane.arquer at stage.cnes.fr
Thu May 24 15:01:02 UTC 2007


Effectively, I changed the creation mode of the task and it's working fine.

Thanks.

> -----Message d'origine-----
> De : Daron Chabot [mailto:djc915 at mail.usask.ca] 
> Envoyé : jeudi 24 mai 2007 16:58
> À : Arquer Stephane
> Cc : RTEMS
> Objet : Re: RE : Pc386 bsp problem
> 
> 
> 
> On 24-May-07, at 8:13 AM, Arquer Stephane wrote:
> 
> > I redefined
> > #define CONFIGURE_INIT_TASK_STACK_SIZE (512*1024)
> > It doesn't do anything.
> 
> I believe you must explicitly set your tasks' stack size when you  
> create them. Simply setting CONFIGURE_EXTRA_TASK_STACKS will not  
> accomplish the desired effect.  And as Joel has pointed out, it is a  
> fatal error to have a task (thread) return in the RTEMS native API.
> 
> >
> > Can you tell me how to connect the console to com1 ?
> > I tried to use :
> > #define USE_COM1_AS_CONSOLE	1
> >
> > But it doesn't work.
> 
> I'll have to check this point...
> 
> >
> > I believe that the raise exception is 6 but I'm not sure. With the
> > terminal I'll catch the error code.
> 
> Exception 6 is an invalid opcode. Perhaps your matlab code is  
> attempting to perform SIMD (MMX) operations, while your 
> platform does  
> not support it ??  Just speculation....
> 
> What hardware are you running this on ?
> 
> 
> -- dc
> 
> >
> > Thanks.
> >
> > Stéphane.
> >
> >
> >> -----Message d'origine-----
> >> De : Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> >> Envoyé : jeudi 24 mai 2007 15:21
> >> À : Arquer Stephane
> >> Cc : Daron Chabot; rtems-users at rtems.org
> >> Objet : Re: RE : RE : RE : 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
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> 
> 




More information about the users mailing list