This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: PowerPC, cyg_thread_delay
- To: "Yuzo Kuramochi" <r25264 at email dot sps dot mot dot com>
- Subject: Re: [ECOS] PowerPC, cyg_thread_delay
- From: Jesper Skov <jskov at redhat dot com>
- Date: 08 Jan 2001 09:35:59 +0100
- Cc: ecos-discuss at sourceware dot cygnus dot com
- References: <3A58374F.3E968F3A@email.sps.mot.com>
>>>>> "Yuzo" == Yuzo Kuramochi <r25264@email.sps.mot.com> writes:
Yuzo> I assume eCos "ticks" are generated by decremeter.
Yes.
Yuzo> Trial one: Decrementer disabled It goes infinite loop of "thread
Yuzo> idle". Probably ths is suppoased to do.
Indeed. But have a look in the idle thread:
void
idle_thread_main( CYG_ADDRESS data )
{
CYG_REPORT_FUNCTION();
for(;;)
{
idle_thread_loops++;
HAL_IDLE_THREAD_ACTION(idle_thread_loops);
#if 0
// For testing, it is useful to be able to fake
// clock interrupts in the idle thread.
Cyg_Clock::real_time_clock->tick();
#endif
#ifdef CYGIMP_IDLE_THREAD_YIELD
// In single priority and non-preemptive systems,
// the idle thread should yield repeatedly to
// other threads.
Cyg_Thread::yield();
#endif
}
}
Change the #if 0 to #if 1 and you should get simulate system
ticks. You can use those to check that it is indeed an interrupt
problem as I suspect..
Yuzo> Trial two: Decrementer enabled
Yuzo> eCos won't resume threads, and Program counter loops around
Yuzo> 0x000020~30, where I don't know what lies beneath.
Compile with decrementer disabled, set a breakpoint in
idle_thread_main, and use the GDB 'x /8i 0x........' command to follow
the flow of an interrupt. I suspect some of the init code in
variant.inc does not do the right thing for some reason, and the
interrupt vectors do something silly.
You do not say if you run the application under eCos GDB stubs - i.e.,
what the ROM environment is. The RAM startup relies on the ROM to
provide compatible exception vectors. To configure a stand-alone RAM
application, disable the CYGSEM_HAL_USE_ROM_MONITOR option.
Jesper