[ECOS]Debugger fails when I add kernel support

[ECOS]Debugger fails when I add kernel support

[Robert Brusa]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Hi
I have written a small program to clear the memory (at91sam7x512-based  
board). Actually it works fine, but I can not debug it. The program uses  
cyg_user_start to initialize as task as follows:

#include <cyg/kernel/kapi.h>            /* All the kernel specific stuff */
#include <cyg/infra/diag.h>		// bring in e. g. cyg_type.h

void cyg_user_start(void)
{
     diag_printf("\nmemset start");
     cyg_thread_create(TASK_PRIO, mytask, (cyg_addrword_t) 0, "mytask",
			(void*) &stack, STACKSIZE, &thread, &thread_obj);
     diag_printf("\ncreate done\n");
     cyg_thread_resume(thread);
     diag_printf("\nresume done\n");	// never
}

I am working with Eclipse Ganymede/CDT conned via LAN to a BDI2000 JTAG  
device. When setting a breakpoint at diag_printf, the console output (see  
attachment) tells me it is reached, but no variables are displayed and the  
system can no longer be debugged (timeout). Having a closer look at the  
console output, it seams to me that gdb-command 104 looks suspicous. addr  
0x000000 is just plain wrong.

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

[-- Attachment #2: memset_debug.txt --]
[-- Type: text/plain, Size: 4772 bytes --]

88-gdb-set confirm off
88^done
89-gdb-set width 0
(gdb) 
89^done
90-gdb-set height 0
(gdb) 
90^done
91-interpreter-exec console echo
(gdb) 
91^done
92-gdb-show prompt
(gdb) 
92^done,value="(gdb) "
93-gdb-set new-console on
(gdb) 
93^error,msg="No symbol \"new\" in current context."
94 target remote 192.168.0.21:2001
(gdb) 
&"target remote 192.168.0.21:2001\n"
target remote 192.168.0.21:2001
=thread-created,id="1"
~"0x00000000 in ?? ()\n"
0x00000000 in ?? ()
*stopped
94^done
95 info proc
(gdb) 
&"info proc\n"
&"Undefined info command: \"proc\".  Try \"help info\".\n"
95^error,msg="Undefined info command: \"proc\".  Try \"help info\"."
96 info program
(gdb) 
&"info program\n"
~"Debugging a target over a serial line.\n"
~"Program stopped at 0x0.\n"
~"It stopped with signal SIGSTOP, Stopped (signal).\n"
~"Type \"info stack\" or \"info registers\" for more information.\n"
96^done
97 info threads
(gdb) 
&"info threads\n"
&"warning: RMT ERROR : failed to get remote thread list.\n"
~"* 1 Thread <main>  0x00000000 in ?? ()\n"
97^done
98-stack-info-depth
(gdb) 
98^done,depth="1"
99-stack-list-frames 0 1
(gdb) 
99^done,stack=[frame={level="0",addr="0x00000000",func="??"}]
100-data-list-changed-registers
(gdb) 
100^done,changed-registers=["0","1","2","3","4","5","6","7","8","9","10","11","12","13","14","15","16","17","18","19","20","21","22","23","24","25"]
101 info sharedlibrary
(gdb) 
&"info sharedlibrary\n"
~"No shared libraries loaded at this time.\n"
101^done
102-environment-directory -r /home/rwb/ws090108/memset /home/rwb/ws090108/memset/.settings /home/rwb/ws090108/memset/Debug
(gdb) 
102^done,source-path="/home/rwb/ws090108/memset:/home/rwb/ws090108/memset/.settings:/home/rwb/ws090108/memset/Debug:$cdir:$cwd"
103-data-list-register-names
(gdb) 
103^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","sp","lr","pc","f0","f1","f2","f3","f4","f5","f6","f7","fps","cpsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""]
104-break-insert memset.c:72
(gdb) 
104^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000",file="/home/rwb/ecos/packages/infra/current/src/memset.c",line="72",times="0",original-location="memset.c:72"}
(gdb) 
105-data-disassemble -s 0x0 -e 0x64 -- 0
105^done,asm_insns=[{address="0x00000000",inst="ldr\tpc, [pc, #24]\t; 0x20"},{address="0x00000004",inst="ldr\tpc, [pc, #24]\t; 0x24"},{address="0x00000008",inst="ldr\tpc, [pc, #24]\t; 0x28"},{address="0x0000000c",inst="ldr\tpc, [pc, #24]\t; 0x2c"},{address="0x00000010",inst="ldr\tpc, [pc, #24]\t; 0x30"},{address="0x00000014",inst="andeq\tr0, r0, r0"},{address="0x00000018",inst="ldr\tpc, [pc, #24]\t; 0x38"},{address="0x0000001c",inst="ldr\tpc, [pc, #24]\t; 0x3c"},{address="0x00000020",inst="andseq\tr0, r0, r0, asr #32"},{address="0x00000024",inst="andseq\tr0, r0, r0, lsl #4"},{address="0x00000028",inst="andseq\tr0, r0, r4, lsr #4"},{address="0x0000002c",inst="andseq\tr0, r0, r0, asr r2"},{address="0x00000030",inst="andseq\tr0, r0, r12, ror #4"},{address="0x00000034",inst="andeq\tr0, r0, r0"},{address="0x00000038",inst="andseq\tr0, r0, r12, ror #6"},{address="0x0000003c",inst="andseq\tr0, r0, r4, lsr r3"},{address="0x00000040",inst="mvn\tr0, #255\t; 0xff"},{address="0x00000044",inst="mov\tr1, #256\t; 0x100"},{address="0x00000048",inst="str\tr1, [r0, #96]"},{address="0x0000004c",inst="str\tr1, [r0, #112]"},{address="0x00000050",inst="ldr\tr0, [pc, #1268]\t; 0x54c"},{address="0x00000054",inst="ldr\tr1, [r0, #104]"},{address="0x00000058",inst="ands\tr1, r1, #8\t; 0x8"},{address="0x0000005c",inst="beq\t0x54"},{address="0x00000060",inst="mov\tr1, #0\t; 0x0"}]
(gdb) 
106-stack-list-arguments 0 0 0
106^done,stack-args=[frame={level="0",args=[]}]
107-stack-list-locals 0
(gdb) 
107^done,locals=[]
(gdb) 
108-exec-continue
108^running
*running,thread-id="1"
(gdb) 
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="1",frame={addr="0x00000000",func="??",args=[]}
109 info threads
(gdb) 
&"info threads\n"
&"warning: RMT ERROR : failed to get remote thread list.\n"
~"* 1 Thread <main>  0x00000000 in ?? ()\n"
109^done
110-stack-info-depth
(gdb) 
110^done,depth="1"
111-stack-list-frames 0 1
(gdb) 
111^done,stack=[frame={level="0",addr="0x00000000",func="??"}]
112-data-list-changed-registers
(gdb) 
112^done,changed-registers=["0","1","2","3","4","12","13","14","25"]
113 info sharedlibrary
(gdb) 
&"info sharedlibrary\n"
~"No shared libraries loaded at this time.\n"
113^done
(gdb) 
114-stack-list-arguments 0 0 0
114^done,stack-args=[frame={level="0",args=[]}]
115-stack-list-locals 0
(gdb) 
115^done,locals=[]
(gdb) 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

On Mon, Apr 06, 2009 at 08:35:22PM +0200, Robert Brusa wrote:
> Hi
> I have written a small program to clear the memory (at91sam7x512-based  
> board). Actually it works fine, but I can not debug it. The program uses  
> cyg_user_start to initialize as task as follows:
>
> #include <cyg/kernel/kapi.h>            /* All the kernel specific stuff */
> #include <cyg/infra/diag.h>		// bring in e. g. cyg_type.h
>
> void cyg_user_start(void)
> {
>     diag_printf("\nmemset start");
>     cyg_thread_create(TASK_PRIO, mytask, (cyg_addrword_t) 0, "mytask",
> 			(void*) &stack, STACKSIZE, &thread, &thread_obj);
>     diag_printf("\ncreate done\n");
>     cyg_thread_resume(thread);
>     diag_printf("\nresume done\n");	// never
> }
>
> I am working with Eclipse Ganymede/CDT conned via LAN to a BDI2000 JTAG  
> device. When setting a breakpoint at diag_printf, the console output (see 
> attachment) tells me it is reached, but no variables are displayed and 
> the system can no longer be debugged (timeout). Having a closer look at 
> the console output, it seams to me that gdb-command 104 looks suspicous. 
> addr 0x000000 is just plain wrong.
>
> 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.

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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

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

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

Re: [ECOS]Debugger fails when I add kernel support

[Robert Brusa]

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

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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

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

Re: [ECOS]Debugger fails when I add kernel support

[Robert Brusa]

On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov  
<sergei.gavrikov@gmail.com> wrote:

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

Sergei, I did it with brutal force: I modified the lines inside var_arch.h
in directory ecos/packages/hal/arm/at91/var/current/include such that the  
macro
HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I created a  
new ecos and linked my little project with this new ecos. The results are  
mixed:
a) As before, when switching power on with no JTAG debugger (BDI2000)  
connected, the program launches and works fine.

b) With the JTAG debugger connected, I am no longer in a position to  
launch it with the BDI go 0 command (via telnet). No output at all.

c) I can set breakpoints in cyg_user_start and the output of the  
diag_printf statement in this routine appear - but
    the output of the diag_printf routines in the thread created and  
resumed from this reoutine do not appear - although I can catch
    breakpoints in this thread.

Not a very clear situation. Do you have a good idea? Thanks and regards
    Robert



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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov  
> <sergei.gavrikov@gmail.com> wrote:
> 
> ..<cut>
> >>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
> 
> Sergei, I did it with brutal force: I modified the lines inside var_arch.h
> in directory ecos/packages/hal/arm/at91/var/current/include such that the  
> macro
> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I created a  
> new ecos and linked my little project with this new ecos. The results are  
> mixed:
> a) As before, when switching power on with no JTAG debugger (BDI2000)  
> connected, the program launches and works fine.
> 
> b) With the JTAG debugger connected, I am no longer in a position to  
> launch it with the BDI go 0 command (via telnet). No output at all.

IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
that your early startup has a loop in assembler during a few time to
give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
your hal_platform_startup.s (before any initialization, it should be
just a loop in asm).

> c) I can set breakpoints in cyg_user_start and the output of the  
> diag_printf statement in this routine appear - but
>    the output of the diag_printf routines in the thread created and  
> resumed from this reoutine do not appear - although I can catch
>    breakpoints in this thread.
>
> Not a very clear situation. Do you have a good idea? Thanks and regards
>    Robert

diag_printf() is good for asserts, diagnostic output, etc., i.e. for
debugging only. What is a reason to use it inside the threads?

every plf. diagnostic "putc" is something like this blocking loop:

	do {
	    // check UART status
	} while (!can_send);


It's not good for multi-threads applications. It blocks eCos, so, use
printf() inside the threads, interrupt-driven and non-blocking serial
I/O. Use a mutex to share printf() between the threads. I do not think
that eCos's the floating-points-less printf() is heavy stuff. Robert,
that is just my thoughts about your implementation. This is not JTAG
related things.


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

Re: [ECOS]Debugger fails when I add kernel support

[Robert Brusa]

On Tue, 07 Apr 2009 16:01:35 +0200, Sergei Gavrikov  
<sergei.gavrikov@gmail.com> wrote:

> On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
>> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov
>> <sergei.gavrikov@gmail.com> wrote:
>>
>> ..<cut>
>> >>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
>>
>> Sergei, I did it with brutal force: I modified the lines inside  
>> var_arch.h
>> in directory ecos/packages/hal/arm/at91/var/current/include such that  
>> the
>> macro
>> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I  
>> created a
>> new ecos and linked my little project with this new ecos. The results  
>> are
>> mixed:
>> a) As before, when switching power on with no JTAG debugger (BDI2000)
>> connected, the program launches and works fine.
>>
>> b) With the JTAG debugger connected, I am no longer in a position to
>> launch it with the BDI go 0 command (via telnet). No output at all.
>
> IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
> that your early startup has a loop in assembler during a few time to
> give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
> your hal_platform_startup.s (before any initialization, it should be
> just a loop in asm).

==> The BDI is configured to stop the target when it comes out of reset.  
And that it does wunderfully. I then click the run button and that's were  
the problems start :-(
>
>> c) I can set breakpoints in cyg_user_start and the output of the
>> diag_printf statement in this routine appear - but
>>    the output of the diag_printf routines in the thread created and
>> resumed from this reoutine do not appear - although I can catch
>>    breakpoints in this thread.
>>
>> Not a very clear situation. Do you have a good idea? Thanks and regards
>>    Robert
>
> diag_printf() is good for asserts, diagnostic output, etc., i.e. for
> debugging only. What is a reason to use it inside the threads?
>
> every plf. diagnostic "putc" is something like this blocking loop:
>
> 	do {
> 	    // check UART status
> 	} while (!can_send);
>
>
> It's not good for multi-threads applications. It blocks eCos, so, use
> printf() inside the threads, interrupt-driven and non-blocking serial
> I/O. Use a mutex to share printf() between the threads. I do not think
> that eCos's the floating-points-less printf() is heavy stuff. Robert,
> that is just my thoughts about your implementation. This is not JTAG
> related things.
>
>
> Sergei

Hi Sergei

Well, I used to have printf-statements in all my programs. But since  
working with the new arm-eabi toolchain, I found that all my programs  
crash in this printf statement. I reported this in the arm_gnu forum, but  
got no useful answer. :-(

Right now I have kicked out all diag_printf statements in the thread and  
put printf instead - No output in no case.
Then I changed it to fprintf(... and already the statement

fuser = fopen("/dev/ser1", "w");

comes back with fuser == 0 - even so I enabled ser0 and ser1 - the  
interrupt driven version at91serial - in configtool ...

Something very basic must be wrong in my case. If only I knew what??????  
:-(
   Robert



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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

On Tue, Apr 07, 2009 at 04:40:42PM +0200, Robert Brusa wrote:
> On Tue, 07 Apr 2009 16:01:35 +0200, Sergei Gavrikov  
> <sergei.gavrikov@gmail.com> wrote:
>
>> On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
>>> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov
>>> <sergei.gavrikov@gmail.com> wrote:
>>>
>>> ..<cut>
>>> >>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
>>>
>>> Sergei, I did it with brutal force: I modified the lines inside  
>>> var_arch.h
>>> in directory ecos/packages/hal/arm/at91/var/current/include such that 
>>> the
>>> macro
>>> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I  
>>> created a
>>> new ecos and linked my little project with this new ecos. The results 
>>> are
>>> mixed:
>>> a) As before, when switching power on with no JTAG debugger (BDI2000)
>>> connected, the program launches and works fine.
>>>
>>> b) With the JTAG debugger connected, I am no longer in a position to
>>> launch it with the BDI go 0 command (via telnet). No output at all.
>>
>> IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
>> that your early startup has a loop in assembler during a few time to
>> give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
>> your hal_platform_startup.s (before any initialization, it should be
>> just a loop in asm).
>
> ==> The BDI is configured to stop the target when it comes out of reset.  
> And that it does wunderfully. I then click the run button and that's were 
> the problems start :-(
>>
>>> c) I can set breakpoints in cyg_user_start and the output of the
>>> diag_printf statement in this routine appear - but
>>>    the output of the diag_printf routines in the thread created and
>>> resumed from this reoutine do not appear - although I can catch
>>>    breakpoints in this thread.
>>>
>>> Not a very clear situation. Do you have a good idea? Thanks and regards
>>>    Robert
>>
>> diag_printf() is good for asserts, diagnostic output, etc., i.e. for
>> debugging only. What is a reason to use it inside the threads?
>>
>> every plf. diagnostic "putc" is something like this blocking loop:
>>
>> 	do {
>> 	    // check UART status
>> 	} while (!can_send);
>>
>>
>> It's not good for multi-threads applications. It blocks eCos, so, use
>> printf() inside the threads, interrupt-driven and non-blocking serial
>> I/O. Use a mutex to share printf() between the threads. I do not think
>> that eCos's the floating-points-less printf() is heavy stuff. Robert,
>> that is just my thoughts about your implementation. This is not JTAG
>> related things.
>>
>>
>> Sergei
>
> Hi Sergei
>
> Well, I used to have printf-statements in all my programs. But since  
> working with the new arm-eabi toolchain, I found that all my programs  
> crash in this printf statement. I reported this in the arm_gnu forum, but 
> got no useful answer. :-(
>
> Right now I have kicked out all diag_printf statements in the thread and  
> put printf instead - No output in no case.
> Then I changed it to fprintf(... and already the statement
>
> fuser = fopen("/dev/ser1", "w");
>
> comes back with fuser == 0 - even so I enabled ser0 and ser1 - the  
> interrupt driven version at91serial - in configtool ...
>
> Something very basic must be wrong in my case. If only I knew what??????  
> :-(
>   Robert

I'm sure that is not "arm_gnu" related, something is wrong witch eCos
configuration. Forget about own application. You have to make work two
famous eCos examples for your target: these are `twotreads' and `serial'
(see $ECOS_REPOSITORY/../examples). Twothreads is exactly that what you
need. First, it's hardy help using a `configtool' way. I'm sorry. BUT, I
will try. What's your target's name exactly?  (It seems I missed the
name). As I could understand you use ROM startup and the target has at
the least two serial ports.

$ ecosconfig new <target> default

At least, you have to set the below options to get non-blocking serial
I/O.

cdl_component CYGPKG_IO_SERIAL_DEVICES {
    user_value 1
};

cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
    user_value 1
};

Put the above in serial.ecm and import this file then.

$ ecosconfig import serial.ecm

About printf() channel...

$ less -p 'DEFAULT_CONSOLE \{' ecos.ecc

cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE sets a device name which
will be used for printf(). Set it properly (edit ecos.ecc).

$ ecosconfig resolve && ecosconfig tree && make -s

cp -a $ECOS_REPOSITORY/../examples .

make -C examples INSTALL_DIR=`pwd`/install twothreads 
make -C examples INSTALL_DIR=`pwd`/install serial 

There will be your test stuff under examples directory. Make twothreads
works with JTAG.

Note: I do not know about your target, if your default startup RAM, it's
possible you have to import and the below before to build eCos examples

cdl_component CYG_HAL_STARTUP {
    user_value ROM
};

Robert, only if you will manage `twothreads' then you will manage own
application. 


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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

On Tue, Apr 07, 2009 at 07:05:29PM +0300, Sergei Gavrikov wrote:
> On Tue, Apr 07, 2009 at 04:40:42PM +0200, Robert Brusa wrote:
> > On Tue, 07 Apr 2009 16:01:35 +0200, Sergei Gavrikov  
> > <sergei.gavrikov@gmail.com> wrote:
> >
> >> On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
> >>> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov
> >>> <sergei.gavrikov@gmail.com> wrote:
> >>>
> >>> ..<cut>
> >>> >>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
> >>>
> >>> Sergei, I did it with brutal force: I modified the lines inside  
> >>> var_arch.h
> >>> in directory ecos/packages/hal/arm/at91/var/current/include such that 
> >>> the
> >>> macro
> >>> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I  
> >>> created a
> >>> new ecos and linked my little project with this new ecos. The results 
> >>> are
> >>> mixed:
> >>> a) As before, when switching power on with no JTAG debugger (BDI2000)
> >>> connected, the program launches and works fine.
> >>>
> >>> b) With the JTAG debugger connected, I am no longer in a position to
> >>> launch it with the BDI go 0 command (via telnet). No output at all.
> >>
> >> IMHO, it is a JTAG issue, jtag cannot halt CPU. Usually, they recommend
> >> that your early startup has a loop in assembler during a few time to
> >> give a chance JTAG halt CPU. A few ms it's enougth. You can put this in
> >> your hal_platform_startup.s (before any initialization, it should be
> >> just a loop in asm).
> >
> > ==> The BDI is configured to stop the target when it comes out of reset.  
> > And that it does wunderfully. I then click the run button and that's were 
> > the problems start :-(
> >>
> >>> c) I can set breakpoints in cyg_user_start and the output of the
> >>> diag_printf statement in this routine appear - but
> >>>    the output of the diag_printf routines in the thread created and
> >>> resumed from this reoutine do not appear - although I can catch
> >>>    breakpoints in this thread.
> >>>
> >>> Not a very clear situation. Do you have a good idea? Thanks and regards
> >>>    Robert
> >>
> >> diag_printf() is good for asserts, diagnostic output, etc., i.e. for
> >> debugging only. What is a reason to use it inside the threads?
> >>
> >> every plf. diagnostic "putc" is something like this blocking loop:
> >>
> >> 	do {
> >> 	    // check UART status
> >> 	} while (!can_send);
> >>
> >>
> >> It's not good for multi-threads applications. It blocks eCos, so, use
> >> printf() inside the threads, interrupt-driven and non-blocking serial
> >> I/O. Use a mutex to share printf() between the threads. I do not think
> >> that eCos's the floating-points-less printf() is heavy stuff. Robert,
> >> that is just my thoughts about your implementation. This is not JTAG
> >> related things.
> >>
> >>
> >> Sergei
> >
> > Hi Sergei
> >
> > Well, I used to have printf-statements in all my programs. But since  
> > working with the new arm-eabi toolchain, I found that all my programs  
> > crash in this printf statement. I reported this in the arm_gnu forum, but 
> > got no useful answer. :-(
> >
> > Right now I have kicked out all diag_printf statements in the thread and  
> > put printf instead - No output in no case.
> > Then I changed it to fprintf(... and already the statement
> >
> > fuser = fopen("/dev/ser1", "w");
> >
> > comes back with fuser == 0 - even so I enabled ser0 and ser1 - the  
> > interrupt driven version at91serial - in configtool ...
> >
> > Something very basic must be wrong in my case. If only I knew what??????  
> > :-(
> >   Robert
> 
> I'm sure that is not "arm_gnu" related, something is wrong witch eCos
> configuration. Forget about own application. You have to make work two
> famous eCos examples for your target: these are `twotreads' and `serial'
> (see $ECOS_REPOSITORY/../examples). Twothreads is exactly that what you
> need. First, it's hardy help using a `configtool' way. I'm sorry. BUT, I
> will try. What's your target's name exactly?  (It seems I missed the
> name). As I could understand you use ROM startup and the target has at
> the least two serial ports.
> 
> $ ecosconfig new <target> default
> 
> At least, you have to set the below options to get non-blocking serial
> I/O.
> 
> cdl_component CYGPKG_IO_SERIAL_DEVICES {
>     user_value 1
> };
> 
> cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
>     user_value 1
> };
> 
> Put the above in serial.ecm and import this file then.
> 
> $ ecosconfig import serial.ecm
> 
> About printf() channel...
> 
> $ less -p 'DEFAULT_CONSOLE \{' ecos.ecc
> 
> cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE sets a device name which
> will be used for printf(). Set it properly (edit ecos.ecc).
> 
> $ ecosconfig resolve && ecosconfig tree && make -s
> 
> cp -a $ECOS_REPOSITORY/../examples .
> 
> make -C examples INSTALL_DIR=`pwd`/install twothreads 
> make -C examples INSTALL_DIR=`pwd`/install serial 
> 
> There will be your test stuff under examples directory. Make twothreads
> works with JTAG.
> 
> Note: I do not know about your target, if your default startup RAM, it's
> possible you have to import and the below before to build eCos examples
> 
> cdl_component CYG_HAL_STARTUP {
>     user_value ROM
> };
> 
> Robert, only if you will manage `twothreads' then you will manage own
> application. 

Yet another 2 cents. Usually if I've got an issue I import the below too

cdl_option CYGPKG_INFRA_DEBUG {user_value 1};
cdl_option CYGDBG_USE_TRACING {user_value 1};
cdl_option CYGDBG_IO_INIT {user_value 1};

and I fix CYGBLD_GLOBAL_CFLAGS:

    s/ -O2// 

to turn off any optimization if I use GDB. After every tweak of ecos.ecc
be sure that you rebuild eCos from scratch.


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

Re: [ECOS]Debugger fails when I add kernel support

[Robert Brusa]

On Tue, 07 Apr 2009 18:05:29 +0200, Sergei Gavrikov  
<sergei.gavrikov@gmail.com> wrote:

<cut>
> I'm sure that is not "arm_gnu" related, something is wrong witch eCos
> configuration. Forget about own application. You have to make work two
> famous eCos examples for your target: these are `twotreads' and `serial'
> (see $ECOS_REPOSITORY/../examples). Twothreads is exactly that what you
> need. First, it's hardy help using a `configtool' way. I'm sorry. BUT, I
> will try. What's your target's name exactly?  (It seems I missed the
> name). As I could understand you use ROM startup and the target has at
> the least two serial ports.
>
> $ ecosconfig new <target> default
>
> At least, you have to set the below options to get non-blocking serial
> I/O.
>
> cdl_component CYGPKG_IO_SERIAL_DEVICES {
>     user_value 1
> };
>
> cdl_option CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING {
>     user_value 1
> };
>
> Put the above in serial.ecm and import this file then.
>
> $ ecosconfig import serial.ecm
>
> About printf() channel...
>
> $ less -p 'DEFAULT_CONSOLE \{' ecos.ecc
>
> cdl_option CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE sets a device name which
> will be used for printf(). Set it properly (edit ecos.ecc).
>
> $ ecosconfig resolve && ecosconfig tree && make -s
>
> cp -a $ECOS_REPOSITORY/../examples .
>
> make -C examples INSTALL_DIR=`pwd`/install twothreads
> make -C examples INSTALL_DIR=`pwd`/install serial
>
> There will be your test stuff under examples directory. Make twothreads
> works with JTAG.
>
> Note: I do not know about your target, if your default startup RAM, it's
> possible you have to import and the below before to build eCos examples
>
> cdl_component CYG_HAL_STARTUP {
>     user_value ROM
> };
>
> Robert, only if you will manage `twothreads' then you will manage own
> application.
>
>
> Sergei

Thanks a lot for your patience. I am really in a mess. The longer I play  
around with configtool the worse it gets. And the frustrating thing is  
that all my application worked using ecos.2 with gnu-elf toolchain. And  
then I decided I had to use something newer. Since then I am hangling from  
one problem to the next - and do not know why.....

Anyway, I will give it a try with the twothreads and serial and follow the  
path you outlined above. The (not so) funny thing is: These two examples I  
actually used as my "primer" with ecos.2 - and they worked. Hence back to  
field 1 :-(
    Robert


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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

On Tue, Apr 07, 2009 at 10:30:33PM +0200, Robert Brusa wrote:
> On Tue, 07 Apr 2009 18:05:29 +0200, Sergei Gavrikov  
> <sergei.gavrikov@gmail.com> wrote:
>
> <cut>
>> I'm sure that is not "arm_gnu" related, something is wrong witch eCos
>> configuration. Forget about own application. You have to make work two
>> famous eCos examples for your target: these are `twotreads' and `serial'
>> (see $ECOS_REPOSITORY/../examples). Twothreads is exactly that what you
>> need. First, it's hardy help using a `configtool' way. I'm sorry. BUT, I
>> will try. What's your target's name exactly?  (It seems I missed the
>> name). As I could understand you use ROM startup and the target has at
>> the least two serial ports.

<cut pastes>

>> Robert, only if you will manage `twothreads' then you will manage own
>> application.
>>
>>
>> Sergei
>
> Thanks a lot for your patience. I am really in a mess. The longer I play  
> around with configtool the worse it gets. And the frustrating thing is  
> that all my application worked using ecos.2 with gnu-elf toolchain. And  
> then I decided I had to use something newer. Since then I am hangling 
> from one problem to the next - and do not know why.....
>
> Anyway, I will give it a try with the twothreads and serial and follow 
> the path you outlined above. The (not so) funny thing is: These two 
> examples I actually used as my "primer" with ecos.2 - and they worked. 
> Hence back to field 1 :-(
>    Robert

Robert, you are not alone. A while ago I was configuring serial ports
for my project, and I had thoughts in those days: ECOS acronym stands
from Extra-Configurable OS :-) I did dance again with the options. I
remember what I _again_ forgot about some things. So, I decided to save
the ECMs for myself, e.g., I have FGETS.ECM, to manage input, on the
serial port, NONBLOCK.ECM, to manage an interrupt driven non-blocking
I/O, etc. Those are just the micro imports for ecosconfig.

I'd understood that if I do not work with eCos a few months I can quite
forget "important" things. I just remember: I managet it, it worked,
but, now it does not. It's pity, that eCos community has not own wiki.
I hope that in some day, someone will stand up it. We have alone
wellknown book and this discuss list (there are tons of the same of
questions and tons of the different answers in the list). The list is
just a gold for N.B. and for those who like me forgot something. eCos
documentation (IMHO) likes the man pages. How most of us (re)read man
pages? Scroll-down, scroll-down, scroll-down... Aha! I get it: 'Q'. 

Well, stop! The above likes a flame. I should confess that now I don't
use JTAG. From time to time I used a cheap parallel wiggler from Olimex
and OpenOCD JTAG. It works, but, I have not many advantages for my
target with it. The target has enough RAM. OpenOCD JTAG for me was: a
very few breakpoints, a wellknown "reset" problem, an absent support the
eCos threads. ... It was surprise for me when I discovered that I can
download a code with the modern (3.0) arm-eabi GDB and RedBoot set a
230400 bps baud rate. It works without any fails. I got download speed
into RAM exactly the same as I got with parallel wiggler and OpenOCD.

Some time ago, 0yvind Harboe said about an initiative:
http://ecos.sourceware.org/ml/ecos-discuss/2008-11/msg00038.html.
But, AFAIK, OpenOCD does not support eCos threads still, may be I am
wrong.

And yet another thing. Today, if I need to debug a skeleton of program
with serial connection, I use ecosynth serial driver from Savin Zlobec
and `nullmodem' from Juergen Rinas. This pair is here:
http://www.xylanta.com/WordPress/?page_id=22
http://www.ant.uni-bremen.de/whomes/rinas/nullmodem/index.html
What's the nice pair! I found this method is a very useful way to debug:
no JTAG, no board, just eCos portable source. And then, at the end, all
should run on the target. Using it I successfully did stand up lwIP
SLIP, PDCurses on synthetic target (via synth serial), and then it did
work on my board. I have a small install script to set up the pair on
Linux host for the nowadays eCos. I can send the script, but, I don't
know what is your host (linux/cygwin)?

I just have a bit of free time in these days: time to play with eCos
again. I liked new eCos 3.0, and perhaps, I'll try the twothreads 3.0
with my old JTAG. It's just interesting, where the problem seat?


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

Re: [ECOS]Debugger fails when I add kernel support

[Sergei Gavrikov]

[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]

On Tue, Apr 07, 2009 at 02:58:44PM +0200, Robert Brusa wrote:
> On Mon, 06 Apr 2009 23:39:24 +0200, Sergei Gavrikov  
> <sergei.gavrikov@gmail.com> wrote:
> 
> ..<cut>
> >>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
> 
> Sergei, I did it with brutal force: I modified the lines inside var_arch.h
> in directory ecos/packages/hal/arm/at91/var/current/include such that the  
> macro
> HAL_IDLE_THREAD_ACTION(_counter_) is no longer generated. Then I created a  
> new ecos and linked my little project with this new ecos. The results are  
> mixed:
> a) As before, when switching power on with no JTAG debugger (BDI2000)  
> connected, the program launches and works fine.
> 
> b) With the JTAG debugger connected, I am no longer in a position to  
> launch it with the BDI go 0 command (via telnet). No output at all.
> 
> c) I can set breakpoints in cyg_user_start and the output of the  
> diag_printf statement in this routine appear - but
>    the output of the diag_printf routines in the thread created and  
> resumed from this reoutine do not appear - although I can catch
>    breakpoints in this thread.
> 
> Not a very clear situation. Do you have a good idea? Thanks and regards
>    Robert

Hi

As I did promise I tried to reproduce your issue. My stuff was: eCos
3.0, OpenOCD (I built it this morning from SVN), parallel JTAG wiggler
from Olimex, CPU: ARM7TDMI-S (NXP LPC2294), board: Olimex LPC-H2294
header board.

I built eCos as I do it as well for tests using ecosconfig, template was
default. Only 2 imports were applied: 

cdl_component CYG_HAL_STARTUP {user_value ROM};
cdl_option CYGHWR_HAL_ARM_LPC2XXX_IDLE_PWRSAVE {user_value 0};

I reset the board, ran OpenOCD (see screenlog.0.txt) and did load a
built `twothreads' example. There is a full GDB session in the log. I
could stop a run at the outputs and before a start of a kernel and then.
All ouput will appear in minicom as I could expect. BTW, by default,
printf uses hal_if_diag_write_char(). See the log. I could output and
alone character and whole lines using breakpoints. ^C works as I could
expect too.

Yet another thing, if you could see, `serial' example uses printf(). BUT,

$ arm-eabi-nm examples/serial | grep -E '(printf|putc|_diag)'
00001cf8 t _GLOBAL__I.10100_diag_write_char
00001d24 t _ZL16_diag_write_charcPPv
8100027c d _ZL5_putc
00001ec8 t _ZL8_vprintfPFvcPPvES0_PKcS_
00005120 T cyg_hal_plf_serial_putc
00002a00 T diag_printf
00004eb8 T fputc
0000167c T hal_if_diag_init
000016bc T hal_if_diag_read_char
00001880 T hal_if_diag_write_char
00001244 t haldiag_putc
00004eb8 W putc
810002b8 D tty_io_diag
81003050 b tty_private_info_diag

There is no printf! Using CLI tools (arm-eabi-gdb) I at once noticed
that I cannot set a breakpoint on printf. And your IDE as I could see in
your pastes quite eats mice's breakpoints. AFAIR, I saw there

info threads
info sharedlibs

IDE shocks these requests the GDB for embedded. You set breakpoint, but,
program run. And I thought, that you can try `nm' on that your ELF to
check is there printf in text segment.  Well, it's just a guss only.

Certainly, when I ran `serial' I used stops on hal_if_diag_write_char().

So, what's difference in our environments

a) different JTAGs
b) CLI against IDE
c) Linux against Cygwin
d) different targets

and what's the same:

eCos 3.0 release.

I have no more ideas.


Sergei

[-- Attachment #2: screenlog.0.txt --]
[-- Type: text/plain, Size: 9435 bytes --]

* My JTAG engine
  --------------

$ sudo /opt/openocd/bin/openocd-ioperm -f ../openocd.cfg
Password:
Open On-Chip Debugger 1.0 (2009-04-08-08:48) svn:1454


BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS


$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
force hard breakpoints
Warn : No parport port specified, using default '0x378' (LPT1)
Info : JTAG tap: lpc2294.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
Warn : DBGACK set while target was in unknown state. Reset or initialize target.
target state: halted
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x60000013 pc: 0x00005110
dcc downloads are enabled


* My eCos stuff
  -------------

$ echo $ECOS_REPOSITORY
/opt/ecos/ecos-3.0/packages
$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: /home/test/src/toolchains/gcc/gcc-4.3.2/configure -v --target=arm-eabi --prefix=/home/test/build/toolchains/arm-eabi/tools --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-__cxa_atexit --enable-threads --with-bugurl=http://bugs.ecos.sourceware.org/ --with-pkgversion='eCosCentric GNU tools 4.3.2-sw' --with-cpu=arm7tdmi --with-gmp=/opt/gmp-4.2.2 --with-mpfr=/opt/mpfr-2.3.0
Thread model: single
gcc version 4.3.2 (eCosCentric GNU tools 4.3.2-sw) 


* Two threads debug
  -----------------

$ arm-eabi-gdb -nx
GNU gdb (eCosCentric GNU tools 4.3.2-sw) 6.8.50.20080706
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-eabi".
For bug reporting instructions, please see:
<http://bugs.ecos.sourceware.org/>.
(gdb) set logging on
Copying output to gdb.txt.
(gdb) file examples/twothreads
Reading symbols from /home/sg/prj09/openocd/ecos/examples/twothreads...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
printf (format=0x81006768 "¼V")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
74	    rc = vfnprintf(stdout, INT_MAX, format, ap);
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x0
Loading section .text, size 0xa820 lma 0x40
Loading section .rodata, size 0x318 lma 0xa860
Loading section .data, size 0x34c lma 0xab78
Start address 0x40, load size 44740
Transfer rate: 13 KB/sec, 7456 bytes/write.
(gdb) tb cyg_user_start
Temporary breakpoint 1 at 0x698: file twothreads.c, line 25.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, cyg_user_start () at twothreads.c:25
25	  printf("Entering twothreads' cyg_user_start() function\n");
Current language:  auto; currently c
(gdb) tb printf
Temporary breakpoint 2 at 0x5024: file /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx, line 74.
(gdb) c
Continuing.

Temporary breakpoint 2, printf (format=0x810066c0 "¼F")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
74	    rc = vfnprintf(stdout, INT_MAX, format, ap);
Current language:  auto; currently c++
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
idle_thread_main (data=0)
    at /opt/ecos/ecos-3.0/packages/kernel/v3_0/src/common/thread.cxx:1222
1222	idle_thread_main( CYG_ADDRESS data )
(gdb) tb hal_if_diag_write_char
Temporary breakpoint 3 at 0x18d8: file /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c, line 844.
(gdb) c
Continuing.

Temporary breakpoint 3, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
Current language:  auto; currently c
(gdb) bt
#0  hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
#1  0x000012a0 in haldiag_putc (chan=<value optimized out>, c=84 'T')
    at /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/haldiag.c:113
#2  0x00000dc4 in serial_write (handle=<value optimized out>, _buf=0x8100529c, 
    len=0x810052dc)
    at /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/serial.c:329
#3  0x00001b4c in cyg_io_write (handle=0x810002f8, buf=0x54, len=0x0)
    at /opt/ecos/ecos-3.0/packages/io/common/v3_0/src/iosys.c:177
#4  0x000011c4 in tty_write (handle=<value optimized out>, _buf=0x20612077, 
    len=0x6f6e2064)
    at /opt/ecos/ecos-3.0/packages/io/serial/v3_0/src/common/tty.c:200
#5  0x00001b4c in cyg_io_write (handle=0x810002f8, buf=0x54, len=0x0)
    at /opt/ecos/ecos-3.0/packages/io/common/v3_0/src/iosys.c:177
#6  0x000048b8 in Cyg_StdioStream::flush_output_unlocked (this=0x810040c0)
    at /home/sg/prj09/openocd/ecos/install/include/cyg/libc/stdio/io.inl:229
#7  0x00004b78 in Cyg_StdioStream::write (this=0x810040c0, 
    buffer=0xa8a8 " clock ticks\n", buffer_length=0, bytes_written=0x81005650)
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/common/stream.cxx:714
#8  0x00005454 in vfnprintf (stream=0x810040c0, n=2147483647, 
    format=<value optimized out>, arg=0x81005694)
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/vfnprin---Type <return> to continue, or q <return> to quit---
tf.cxx:276
#9  0x00005040 in printf (format=0x810066c0 "¼F")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
#10 0x0000066c in simple_program (data=<value optimized out>)
    at twothreads.c:56
#11 0x00002c34 in Cyg_HardwareThread::thread_entry (thread=0x810066c0)
    at /opt/ecos/ecos-3.0/packages/kernel/v3_0/src/common/thread.cxx:94
(gdb) b hal_if_diag_write_char
Breakpoint 4 at 0x18d8: file /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c, line 844.
(gdb) c
Continuing.

Breakpoint 4, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
(gdb) c
Continuing.

Breakpoint 4, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
(gdb) c
Continuing.

Breakpoint 4, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) b putc

Breakpoint 5 at 0x4ed8: file /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/fputc.cxx, line 71.
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
idle_thread_main (data=0)
    at /opt/ecos/ecos-3.0/packages/kernel/v3_0/src/common/thread.cxx:1222
1222	idle_thread_main( CYG_ADDRESS data )
Current language:  auto; currently c++
(gdb) b fputc
Note: breakpoint 5 also set at pc 0x4ed8.
Breakpoint 6 at 0x4ed8: file /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/fputc.cxx, line 75.
(gdb) c
Continuing.

Program received signal SIGINT, Interrupt.
idle_thread_main (data=0)
    at /opt/ecos/ecos-3.0/packages/kernel/v3_0/src/common/thread.cxx:1222
1222	idle_thread_main( CYG_ADDRESS data )
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) b hal_if_diag_write_char

Breakpoint 7 at 0x18d8: file /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c, line 844.
(gdb) c
Continuing.

Breakpoint 7, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
Current language:  auto; currently c
(gdb) c
Continuing.

Breakpoint 7, hal_if_diag_write_char ()
    at /opt/ecos/ecos-3.0/packages/hal/common/v3_0/src/hal_if.c:844
844	    if (__chan)
(gdb) d
Delete all breakpoints? (y or n) y
(gdb) b printf

Breakpoint 8 at 0x5024: file /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx, line 74.
(gdb) c
Continuing.

Breakpoint 8, printf (format=0x810066c0 "¼F")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
74	    rc = vfnprintf(stdout, INT_MAX, format, ap);
Current language:  auto; currently c++
(gdb) bt
#0  printf (format=0x810066c0 "¼F")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
#1  0x0000066c in simple_program (data=<value optimized out>)
    at twothreads.c:56
#2  0x00002c34 in Cyg_HardwareThread::thread_entry (thread=0x810066c0)
    at /opt/ecos/ecos-3.0/packages/kernel/v3_0/src/common/thread.cxx:94
(gdb) c
Continuing.

Breakpoint 8, printf (format=0x81006768 "¼V")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
74	    rc = vfnprintf(stdout, INT_MAX, format, ap);
(gdb) c
Continuing.

Breakpoint 8, printf (format=0x810066c0 "¼F")
    at /opt/ecos/ecos-3.0/packages/language/c/libc/stdio/v3_0/src/output/printf.cxx:74
74	    rc = vfnprintf(stdout, INT_MAX, format, ap);
(gdb) disconnect
Ending remote debugging.
(gdb) q


* Has `serial' example print?
  ---------------------------

$ arm-eabi-nm examples/serial | grep -E '(printf|putc|_diag)'
00001cf8 t _GLOBAL__I.10100_diag_write_char
00001d24 t _ZL16_diag_write_charcPPv
8100027c d _ZL5_putc
00001ec8 t _ZL8_vprintfPFvcPPvES0_PKcS_
00005120 T cyg_hal_plf_serial_putc
00002a00 T diag_printf
00004eb8 T fputc
0000167c T hal_if_diag_init
000016bc T hal_if_diag_read_char
00001880 T hal_if_diag_write_char
00001244 t haldiag_putc
00004eb8 W putc
810002b8 D tty_io_diag
81003050 b tty_private_info_diag
$ 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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