* [ECOS] PowerPC, cyg_thread_delay @ 2001-01-07 1:29 Yuzo Kuramochi 2001-01-08 0:36 ` Jesper Skov 0 siblings, 1 reply; 5+ messages in thread From: Yuzo Kuramochi @ 2001-01-07 1:29 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] PowerPC, cyg_thread_delay 2001-01-07 1:29 [ECOS] PowerPC, cyg_thread_delay Yuzo Kuramochi @ 2001-01-08 0:36 ` Jesper Skov [not found] ` <3A5A5C22.954DAB65@email.sps.mot.com> 0 siblings, 1 reply; 5+ messages in thread From: Jesper Skov @ 2001-01-08 0:36 UTC (permalink / raw) To: Yuzo Kuramochi; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <3A5A5C22.954DAB65@email.sps.mot.com>]
* Re: [ECOS] PowerPC, cyg_thread_delay [not found] ` <3A5A5C22.954DAB65@email.sps.mot.com> @ 2001-01-08 23:03 ` Jesper Skov 2001-01-09 6:00 ` Yuzo Kuramochi 0 siblings, 1 reply; 5+ messages in thread From: Jesper Skov @ 2001-01-08 23:03 UTC (permalink / raw) To: Yuzo Kuramochi; +Cc: ecos-discuss [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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] PowerPC, cyg_thread_delay 2001-01-08 23:03 ` Jesper Skov @ 2001-01-09 6:00 ` Yuzo Kuramochi 2001-01-09 6:29 ` Jesper Skov 0 siblings, 1 reply; 5+ messages in thread From: Yuzo Kuramochi @ 2001-01-09 6:00 UTC (permalink / raw) To: Jesper Skov; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] PowerPC, cyg_thread_delay 2001-01-09 6:00 ` Yuzo Kuramochi @ 2001-01-09 6:29 ` Jesper Skov 0 siblings, 0 replies; 5+ messages in thread From: Jesper Skov @ 2001-01-09 6:29 UTC (permalink / raw) To: Yuzo Kuramochi; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-01-09 6:29 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-01-07 1:29 [ECOS] PowerPC, cyg_thread_delay Yuzo Kuramochi 2001-01-08 0:36 ` Jesper Skov [not found] ` <3A5A5C22.954DAB65@email.sps.mot.com> 2001-01-08 23:03 ` Jesper Skov 2001-01-09 6:00 ` Yuzo Kuramochi 2001-01-09 6:29 ` Jesper Skov
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).