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

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]