* 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).