public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* Scheduler problem with MPC855T port
@ 2007-03-14  8:06 khoffmann
  2007-03-14  8:55 ` Andrew Lunn
  0 siblings, 1 reply; 5+ messages in thread
From: khoffmann @ 2007-03-14  8:06 UTC (permalink / raw)
  To: ecos-devel

Hello everybody,

I've got a problem with my attempts to port eCos to our MPC855T board:

I started with the FADS template (which I now know, was not the best idea) 
and got so far that I can access my RAM, my FLASH, the UARTs and the FEC 
(at least I can see the DHCP requests on the net).

When I compile the 'twothreads' example, I can find a bunch of threads in 
the internal threadlist, obviously everything fine, some 'SLEEPING', some 
'RUNNING'.

But after each thread has  run once, the processor is only looping  throug 
the main_idle_thread() and it's doing nothing else. The trace issues the 
following a short time before the endless 'loop' (where the 'loop' is 
probably triggered by an external interrupt).

TRACE: <2>[447]void Cyg_Mutex::unlock() return void
TRACE: <2>[709]void Cyg_Alarm::initialize() enter
TRACE: <2>[277]void Cyg_Counter::add_alarm() enter
TRACE: <2>[277]void Cyg_Counter::add_alarm() RETURNING UNSET!
TRACE: <2>[709]void Cyg_Alarm::initialize() RETURNING UNSET!
TRACE: <2>[351]static void Cyg_Thread::sleep() enter
TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() enter
TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() 
thread=0045de10
TRACE: <2>[325]void Cyg_Scheduler_Implementation::rem_thread() return void
TRACE: <2>[372]static void Cyg_Thread::sleep() return void
TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() enter
TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() 
thread=0045de10
TRACE: <2>[818]void Cyg_ThreadQueue_Implementation::enqueue() return void
TRACE: <2>[119]Cyg_Thread* Cyg_Scheduler_Implementation::schedule() enter
TRACE: <2>[192]Cyg_Thread* Cyg_Scheduler_Implementation::schedule() 
returning thread 00419070
TRACE: <2>[87]static void Cyg_HardwareThread::thread_entry() enter
TRACE: <1>[1239]void idle_thread_main() enter
TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40000000
TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40000000
... ad infinitum ...

I probably missed something, but what?

Any help is appreciated!

With kind regards,

Karsten Hoffmann

-- 
3M Deutschland GmbH
Telecommunications
Carl-Schurz-Straße 1
D-41453 Neuss
Tel:   +49-2131-14 58 73 
Fax:  +49-2131-14 12 58 73

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Scheduler problem with MPC855T port
  2007-03-14  8:06 Scheduler problem with MPC855T port khoffmann
@ 2007-03-14  8:55 ` Andrew Lunn
  2007-03-15  7:53   ` khoffmann
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2007-03-14  8:55 UTC (permalink / raw)
  To: khoffmann; +Cc: ecos-devel

On Wed, Mar 14, 2007 at 09:06:06AM +0100, khoffmann@mmm.com wrote:
> Hello everybody,
> 
> I've got a problem with my attempts to port eCos to our MPC855T board:
> 
> I started with the FADS template (which I now know, was not the best idea) 
> and got so far that I can access my RAM, my FLASH, the UARTs and the FEC 
> (at least I can see the DHCP requests on the net).
> 
> When I compile the 'twothreads' example, I can find a bunch of threads in 
> the internal threadlist, obviously everything fine, some 'SLEEPING', some 
> 'RUNNING'.
> 
> But after each thread has  run once, the processor is only looping  throug 
> the main_idle_thread() and it's doing nothing else. The trace issues the 
> following a short time before the endless 'loop' (where the 'loop' is 
> probably triggered by an external interrupt).
> 
> TRACE: <2>[447]void Cyg_Mutex::unlock() return void
> TRACE: <2>[709]void Cyg_Alarm::initialize() enter
> TRACE: <2>[277]void Cyg_Counter::add_alarm() enter
> TRACE: <2>[277]void Cyg_Counter::add_alarm() RETURNING UNSET!
> TRACE: <2>[709]void Cyg_Alarm::initialize() RETURNING UNSET!
> TRACE: <2>[351]static void Cyg_Thread::sleep() enter
> TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() enter
> TRACE: <2>[271]void Cyg_Scheduler_Implementation::rem_thread() 
> thread=0045de10
> TRACE: <2>[325]void Cyg_Scheduler_Implementation::rem_thread() return void
> TRACE: <2>[372]static void Cyg_Thread::sleep() return void
> TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() enter
> TRACE: <2>[741]void Cyg_ThreadQueue_Implementation::enqueue() 
> thread=0045de10
> TRACE: <2>[818]void Cyg_ThreadQueue_Implementation::enqueue() return void
> TRACE: <2>[119]Cyg_Thread* Cyg_Scheduler_Implementation::schedule() enter
> TRACE: <2>[192]Cyg_Thread* Cyg_Scheduler_Implementation::schedule() 
> returning thread 00419070
> TRACE: <2>[87]static void Cyg_HardwareThread::thread_entry() enter
> TRACE: <1>[1239]void idle_thread_main() enter
> TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
> TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
> TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40000000
> TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40020000
> TBSCR 0001, vec 15: sivec 3c000000, simask 10010000, sipend 40000000
> ... ad infinitum ...
> 
> I probably missed something, but what?


Timer tick. Run some of the kernel timer tests. I expect they will all
fail because your timer is not ticking.

     Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Scheduler problem with MPC855T port
  2007-03-14  8:55 ` Andrew Lunn
@ 2007-03-15  7:53   ` khoffmann
  2007-03-15  8:28     ` Andrew Lunn
  0 siblings, 1 reply; 5+ messages in thread
From: khoffmann @ 2007-03-15  7:53 UTC (permalink / raw)
  To: ecos-devel

Hello Andrew, thanks for your quick reply!

Andrew Lunn <andrew@lunn.ch> wrote on 14.03.2007 09:55:36:
> 
> Timer tick. Run some of the kernel timer tests. I expect they will all
> fail because your timer is not ticking.

Is there a function, that I have to hook on a special interrupt? 

I tried to compile the tests, but the compiler always aborts with a 
SEGVFAULT when compiling the test for 'ctime' :-(

> /opt/ecos/ecos-2.0/packages/language/c/libc/time/v2_0/tests/ctime.c: In 
function `test':
> /opt/ecos/ecos-2.0/packages/language/c/libc/time/v2_0/tests/ctime.c:124: 
internal error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.



Mit freundlichen Grüßen
Karsten Hoffmann

-- 
3M Deutschland GmbH
Telecommunications
Carl-Schurz-Straße 1
D-41453 Neuss
Tel:   +49-2131-14 58 73 
Fax:  +49-2131-14 12 58 73

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Scheduler problem with MPC855T port
  2007-03-15  7:53   ` khoffmann
@ 2007-03-15  8:28     ` Andrew Lunn
  2007-03-15 11:15       ` Gary Thomas
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Lunn @ 2007-03-15  8:28 UTC (permalink / raw)
  To: khoffmann; +Cc: ecos-devel

On Thu, Mar 15, 2007 at 08:53:02AM +0100, khoffmann@mmm.com wrote:
> Hello Andrew, thanks for your quick reply!
> 
> Andrew Lunn <andrew@lunn.ch> wrote on 14.03.2007 09:55:36:
> > 
> > Timer tick. Run some of the kernel timer tests. I expect they will all
> > fail because your timer is not ticking.
> 
> Is there a function, that I have to hook on a special interrupt? 

Yes, look at the HAL. It will initialize the timer. eg normally
hal_clock_initialize, and the macro CYGNUM_HAL_INTERRUPT_RTC should be
the timer interrupt.

    Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Scheduler problem with MPC855T port
  2007-03-15  8:28     ` Andrew Lunn
@ 2007-03-15 11:15       ` Gary Thomas
  0 siblings, 0 replies; 5+ messages in thread
From: Gary Thomas @ 2007-03-15 11:15 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: khoffmann, ecos-devel

Andrew Lunn wrote:
> On Thu, Mar 15, 2007 at 08:53:02AM +0100, khoffmann@mmm.com wrote:
>> Hello Andrew, thanks for your quick reply!
>>
>> Andrew Lunn <andrew@lunn.ch> wrote on 14.03.2007 09:55:36:
>>> Timer tick. Run some of the kernel timer tests. I expect they will all
>>> fail because your timer is not ticking.
>> Is there a function, that I have to hook on a special interrupt? 
> 
> Yes, look at the HAL. It will initialize the timer. eg normally
> hal_clock_initialize, and the macro CYGNUM_HAL_INTERRUPT_RTC should be
> the timer interrupt.

On the PowerPC, this is almost always the decrementer interrupt.
On some cores, the decrementer has to be enabled - check your
hardware manual.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-03-15 11:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-14  8:06 Scheduler problem with MPC855T port khoffmann
2007-03-14  8:55 ` Andrew Lunn
2007-03-15  7:53   ` khoffmann
2007-03-15  8:28     ` Andrew Lunn
2007-03-15 11:15       ` Gary Thomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).