[ECOS] PowerPC, cyg_thread_delay

[ECOS] PowerPC, cyg_thread_delay

[Yuzo Kuramochi]

IF someone can advise, please.

I am trying to port eCos to my 850 board.

To the point of  "Hello" sample program,
it was not so difficult. However, so far,
I can not run thread program, which uses
"cyg_thread_delay".

I assume eCos "ticks" are generated by
decremeter.

Trial one:  Decrementer disabled
It goes  infinite loop of "thread idle".
Probably ths is suppoased to do.

Trial two:  Decrementer enabled

eCos won't resume threads, and Program counter
loops around 0x000020~30, where I don't
know what lies beneath.

If someone have similar experience, please
advise.

best regards,
========================
Yuzo Kuramochi

Senior Staff Engineer
e_MAIL:R25264@email.sps.mot.com

Re: [ECOS] PowerPC, cyg_thread_delay

[Jesper Skov]

>>>>> "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

Re: [ECOS] PowerPC, cyg_thread_delay

[Jesper Skov]

[please remember to CC the mailing list in the future]

>>>>> "Yuzo" == Yuzo Kuramochi <r25264@email.sps.mot.com> writes:

Yuzo> I really thank you for your quick adivse.  I am suprised for
Yuzo> this quick response, indeed.  Actually, I did not progress for
Yuzo> this whole week and I was just about to throw away this
Yuzo> development.  This quick response is a great help to me.

Yuzo> After I work through, I report the result.

Yuzo> By the way, I am using VisonProbe(ICE), RAM base and I set
Yuzo> Vector routines copied to 0x00000000, instead of 0xFFF00000,
Yuzo> where ROM vectors are supposed to be in default ROM mode.

Make sure the option CYGHWR_HAL_POWERPC_NEED_VECTORS is set in that
case. And that CYGHWR_HAL_POWERPC_VECTOR_BASE gets the proper value.

You should also enable CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS since it
results in some code which handle exceptions so that you can see them.

Jesper

Re: [ECOS] PowerPC, cyg_thread_delay

[Yuzo Kuramochi]

Jesper Skov wrote:
>
> 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..
>
It works.  I see two threads works alternatively. Thanks.
So, it wiil be interrupt problem.

>  Yuzo> By the way, I am using VisonProbe(ICE), RAM base and I set
> Yuzo> Vector routines copied to 0x00000000, instead of 0xFFF00000,
> Yuzo> where ROM vectors are supposed to be in default ROM mode.
>
> Make sure the option CYGHWR_HAL_POWERPC_NEED_VECTORS is set in that
> case. And that CYGHWR_HAL_POWERPC_VECTOR_BASE gets the proper value.
>

I could not find these option. Maybe I am using 1.3.1  relased version.
However, I read memory contents at 0x900, where decrementer code should be

there, and 0x3024 where VSR data should be there.
Both addresses are occupied some codes, so I beleive the vector loading is
done.

>
> You should also enable CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS since it
> results in some code which handle exceptions so that you can see them.
>

With cyg configuration tool, I can not select this one due to the template
I based
 is fads.  Well, I have difficulty to set the break points at 0x900, when
I try,
it always atexit.cxx  appears, and never stop.  Sorry, I am not fmiliar to

this. Please advise. If above option enables the check of  ISR region, I
will do
from start.


Best regards,
--
========================
Yuzo Kuramochi
Senior Staff Engineer
e_MAIL:R25264@email.sps.mot.com

Re: [ECOS] PowerPC, cyg_thread_delay

[Jesper Skov]

>>>>> "Yuzo" == Yuzo Kuramochi <r25264@email.sps.mot.com> writes:

Yuzo> By the way, I am using VisonProbe(ICE), RAM base and I set
Yuzo> Vector routines copied to 0x00000000, instead of 0xFFF00000,
Yuzo> where ROM vectors are supposed to be in default ROM mode.
>>  Make sure the option CYGHWR_HAL_POWERPC_NEED_VECTORS is set in
>> that case. And that CYGHWR_HAL_POWERPC_VECTOR_BASE gets the proper
>> value.
>> 

Yuzo> I could not find these option. Maybe I am using 1.3.1 relased
Yuzo> version.  However, I read memory contents at 0x900, where
Yuzo> decrementer code should be

Yuzo> there, and 0x3024 where VSR data should be there.  Both
Yuzo> addresses are occupied some codes, so I beleive the vector
Yuzo> loading is done.

If you do "powerpc-eabi-objdump -h file" you can see where the vectors
are located - which should be at 0.

>>  You should also enable CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS since it
>> results in some code which handle exceptions so that you can see
>> them.
>> 

Yuzo> With cyg configuration tool, I can not select this one due to
Yuzo> the template I based is fads.  Well, I have difficulty to set
Yuzo> the break points at 0x900, when I try, it always atexit.cxx
Yuzo> appears, and never stop.  Sorry, I am not fmiliar to

Using the FADS as a base was a bad choice. We don't support it and
have no means of testing eCos on that board, so (at least in CVS) it's
very out of date. It also does not have the stub support in place.

I don't even know if breakpoints would work. I think you're supposed
to rely on JTAG or similar HW magic to control the target.

Jesper