This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Debugger fails when I add kernel support


On Tue, Apr 07, 2009 at 12:30:36AM +0300, Sergei Gavrikov wrote:
> On Mon, Apr 06, 2009 at 10:33:35PM +0200, Robert Brusa wrote:
> > On Mon, 06 Apr 2009 21:22:24 +0200, Sergei Gavrikov  
> > <sergei.gavrikov@gmail.com> wrote:
> >
> >> On Mon, Apr 06, 2009 at 10:16:00PM +0300, Sergei Gavrikov wrote:
> >>> On Mon, Apr 06, 2009 at 08:35:22PM +0200, Robert Brusa wrote:
> >>
> >> [snip]
> >>
> >>> > I also have a similar program that does not use a task, but instead
> >>> > mytask is replaced by a procedure - and hence kapi.h is not 
> >>> included. But
> >>> > all the rest is the same - especially the same ecos is used to 
> >>> build the
> >>> > program. With this simpler program - the debuggin works fine. I do not
> >>> > understand why.
> >>> >   Robert
> >>>
> >>> It's just a guess: It's possible that reason can be in an idle thread
> >>> stuff. The second version has no threads, hasn't it? And you debug the
> >>> version smoothly. So, be sure that HAL_IDLE_THREAD_ACTION does not turn
> >>> a power save mode (it is bad medicine for JTAG debugging). Well, it's
> >>> just a guess.
> >>
> >> Robert,
> >>
> >> I did talk about:
> >> /home/sg/repo/devo/ecos/packages/hal/arm/at91/var/current/include/var_arch.h:64
> >>
> >> I do not know, perhaps your target has CDL to disable power save mode.
> >>
> >> Sergei
> > Sergei
> > I think this macro could indeed be the problem. The statement there is:
> > #elif defined(CYGHWR_HAL_ARM_AT91_M42800A) || \
> >       defined(CYGHWR_HAL_ARM_AT91_M55800A) || \
> >       defined(CYGHWR_HAL_ARM_AT91SAM7)
> >
> > #define HAL_IDLE_THREAD_ACTION(_count_)                       \
> > CYG_MACRO_START                                               \
> >     HAL_WRITE_UINT32(AT91_PMC+AT91_PMC_SCDR, 1);              \
> > CYG_MACRO_END
> >
> > and actually this condition is true in my case (SAM7). And SCDR=1 
> > disables the processor clock!
> > This seems odd to me, but I do not really understand the logic behind 
> > this statement. Which kind of event would bring the clock back and have 
> > the processor run again? As far as I can see - nothing in my little app. 
> > There are only printf-Statements and a few pointer manipulations in it.
> >
> > Is it possible to avoid this macro by adding an option - e. g. to the  
> > platform.cdl(*) I have defined for my board? And how would this be done?
> > (configtool does not find the macro HAL_IDLE_THREAD_ACTION so there is no 
> > simple method to switch it off)
> >   Robert
> > (*) essentially a copy (very minor changes only) of the  
> > at91sam7xek-platform.
> > (**) I am working with ecos that I fetched from CVS a few weeks ago - not 
> > yes ecos.3
> 
> Robert, of course, the right way is to define own macro (= CDL rule) in
> the plf's stuff. But, that's not possible without a tweaking plf's code.
> I thought about a froud hack: to add something like the below in CFLAGS
> 
>     -D"HAL_IDLE_THREAD_ACTION(x)={}"
> 
> Well, it's ugly, but, if you do not want to mess up 3.0 sources, it would
> be a way.
> 
> Perhaps, eCos veterans know about another way.
> 

It's just for reference how it was done for lpc2xxx variants:
packages/hal/arm/lpc2xxx/var/current/include/var_arch.h:63

So, I can use 

cdl_option CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE {
    user_value 0
};

for my target to disable that "odd" mode. Certainly it can be disabled
with `configtool' too.

Sergei

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]