RE: [ECOS] limit on the number of diag_printf(s) ????

RE: [ECOS] limit on the number of diag_printf(s) ????

[Rycerz Roman-G11565]

The diag_printf(s) are in Redboot, in the single stepping code...
There are no printf's of any kind in the application

The failure occurs when insight tries to download into the target ram.  It just returns immediately
And no code is loaded.  I do not try any printf's during the download


Roman



-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com] 
Sent: Monday, April 12, 2004 11:26 AM
To: Rycerz Roman-G11565
Cc: Ecos-Discuss@Sources. Com (ecos-discuss@sources.redhat.com)
Subject: Re: [ECOS] limit on the number of diag_printf(s) ????


On Mon, 2004-04-12 at 09:44, Rycerz Roman-G11565 wrote:
> Hi
> 
>     I am trying to get a port of Redboot running, right now I am 
> dealing
> with single stepping.  At this point in the debug process I can no longer 
> use a BDM (it permanently changes the core behavior) so I have resorted to 
> some well placed diag_printf(s) to give me clues.  If I only have 2 or less 
> diag_printf(s) all works fine.  as soon as I add the 3rd one, gdb (insight) 
> will not load my application, it just comes right back....
> 
> 
>     does anyone know what is the limiting factor here ????

There's no limit on such prints, so there must be something else 
happening.  Can you give more detail?  exactly what are you trying to test/debug?  What foes "will not load my application" mean? 
What commands (to GDB) did you issue that failed?

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

-- 
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] limit on the number of diag_printf(s) ????

[Nick Garnett]

Rycerz Roman-G11565 <roman.rycerz@motorola.com> writes:

> The diag_printf(s) are in Redboot, in the single stepping code...
> There are no printf's of any kind in the application
> 
> The failure occurs when insight tries to download into the target ram.  It just returns immediately
> And no code is loaded.  I do not try any printf's during the download

Check where the code is being loaded against the size of RedBoot. It
may be that an extra diag_printf() pushes the BSS of RedBoot up into
the RAM where the application is being loaded. 

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
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] limit on the number of diag_printf(s) ????

[Rycerz Roman-G11565]

HI..

I have looked a little closer and found the reason it wouldn't load was it failed to connect, even though
Insight said it did.  If I disconnect and reconnect it is successful and will download the application.  
I will let you all know what I find

Roman


-----Original Message-----
From: nickg@miso.calivar.com [mailto:nickg@miso.calivar.com] On Behalf Of Nick Garnett
Sent: Tuesday, April 13, 2004 9:27 AM
To: Rycerz Roman-G11565
Cc: Ecos-Discuss@Sources. Com (ecos-discuss@sources.redhat.com)
Subject: Re: [ECOS] limit on the number of diag_printf(s) ????


Rycerz Roman-G11565 <roman.rycerz@motorola.com> writes:

> The diag_printf(s) are in Redboot, in the single stepping code... 
> There are no printf's of any kind in the application
> 
> The failure occurs when insight tries to download into the target ram.  
> It just returns immediately And no code is loaded.  I do not try any 
> printf's during the download

Check where the code is being loaded against the size of RedBoot. It may be that an extra diag_printf() pushes the BSS of RedBoot up into the RAM where the application is being loaded. 

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts

-- 
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] limit on the number of diag_printf(s) ????

[Grant Edwards]

On Mon, Apr 12, 2004 at 06:01:54PM +0100, Bart Veer wrote:

>>> The problem tends to be that the diag_printf() and gdb traffic
>>> can interfere with each other. After all they share the same
>>> communication hardware, usually a uart. If you put a
>>> diag_printf() in the wrong place then it may e.g. overwrite a
>>> buffer that already contains a partial response to a gdb
>>> request.
> 
>  Grant> But, that failure occurs at run-time, not at load-time.
>  Grant> Right?
> 
> If the diag_printf()'s are in the application then yes. In this case
> it is the gdb stubs that are causing problems so I had assumed the
> diag_printf()'s were being added to RedBoot rather than the
> application. That makes the distinction between run-time and load-time
> rather blurred.

Of course you're right.  I misread the OP and thought the
printf() that was breaking the camel's back was in the loaded
application.

-- 
Grant Edwards
grante@visi.com

-- 
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] limit on the number of diag_printf(s) ????

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> On Mon, Apr 12, 2004 at 05:26:40PM +0100, Bart Veer wrote:

    Roman> I am trying to get a port of Redboot running, right now I
    Roman> am dealing with single stepping. At this point in the debug
    Roman> process I can no longer use a BDM (it permanently changes
    Roman> the core behavior) so I have resorted to some well placed
    Roman> diag_printf(s) to give me clues. If I only have 2 or less
    Roman> diag_printf(s) all works fine. as soon as I add the 3rd
    Roman> one, gdb (insight) will not load my application, it just
    Roman> comes right back....

    Roman> does anyone know what is the limiting factor here ????

    >> The problem tends to be that the diag_printf() and gdb traffic
    >> can interfere with each other. After all they share the same
    >> communication hardware, usually a uart. If you put a
    >> diag_printf() in the wrong place then it may e.g. overwrite a
    >> buffer that already contains a partial response to a gdb
    >> request.

    Grant> But, that failure occurs at run-time, not at load-time.
    Grant> Right?

If the diag_printf()'s are in the application then yes. In this case
it is the gdb stubs that are causing problems so I had assumed the
diag_printf()'s were being added to RedBoot rather than the
application. That makes the distinction between run-time and load-time
rather blurred.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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] limit on the number of diag_printf(s) ????

[Grant Edwards]

On Mon, Apr 12, 2004 at 05:26:40PM +0100, Bart Veer wrote:
> 
>     Roman> I am trying to get a port of Redboot running, right now I
>     Roman> am dealing with single stepping. At this point in the debug
>     Roman> process I can no longer use a BDM (it permanently changes
>     Roman> the core behavior) so I have resorted to some well placed
>     Roman> diag_printf(s) to give me clues. If I only have 2 or less
>     Roman> diag_printf(s) all works fine. as soon as I add the 3rd
>     Roman> one, gdb (insight) will not load my application, it just
>     Roman> comes right back....
> 
>     Roman>  does anyone know what is the limiting factor here ????
> 
> The problem tends to be that the diag_printf() and gdb traffic can
> interfere with each other. After all they share the same communication
> hardware, usually a uart. If you put a diag_printf() in the wrong
> place then it may e.g. overwrite a buffer that already contains a
> partial response to a gdb request.

But, that failure occurs at run-time, not at load-time.  Right?

-- 
Grant Edwards
grante@visi.com

-- 
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] limit on the number of diag_printf(s) ????

[Bart Veer]

>>>>> "Roman" == Rycerz Roman-G11565 <roman.rycerz@motorola.com> writes:

    Roman> I am trying to get a port of Redboot running, right now I
    Roman> am dealing with single stepping. At this point in the debug
    Roman> process I can no longer use a BDM (it permanently changes
    Roman> the core behavior) so I have resorted to some well placed
    Roman> diag_printf(s) to give me clues. If I only have 2 or less
    Roman> diag_printf(s) all works fine. as soon as I add the 3rd
    Roman> one, gdb (insight) will not load my application, it just
    Roman> comes right back....

    Roman>  does anyone know what is the limiting factor here ????

The problem tends to be that the diag_printf() and gdb traffic can
interfere with each other. After all they share the same communication
hardware, usually a uart. If you put a diag_printf() in the wrong
place then it may e.g. overwrite a buffer that already contains a
partial response to a gdb request.

What I did when porting to mcf5272 was to temporarily define an
additional function diag_printf2() in the main diagnostic code,
infra/current/src/diag.cxx. This installed an alternative character
output function using diag_init_putc(), then called diag_vprintf(),
and finally restored the original output function. My alternative
character output function just sent the data directly out of the
second on-chip uart, rather than going via virtual
vectors/RedBoot/uart0.

The net effect was that diag_printf2() output did not use the same
communication channel as gdb debug traffic, so the two no longer
interfered. Obviously there are many possible variations on this basic
theme, depending on exactly what problem you are trying to track down
and what the hardware is capable of.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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] limit on the number of diag_printf(s) ????

[Gary Thomas]

On Mon, 2004-04-12 at 09:44, Rycerz Roman-G11565 wrote:
> Hi
> 
>     I am trying to get a port of Redboot running, right now I am dealing 
> with single stepping.  At this point in the debug process I can no longer 
> use a BDM (it permanently changes the core behavior) so I have resorted to 
> some well placed diag_printf(s) to give me clues.  If I only have 2 or less 
> diag_printf(s) all works fine.  as soon as I add the 3rd one, gdb (insight) 
> will not load my application, it just comes right back....
> 
> 
>     does anyone know what is the limiting factor here ????

There's no limit on such prints, so there must be something else 
happening.  Can you give more detail?  exactly what are you trying
to test/debug?  What foes "will not load my application" mean? 
What commands (to GDB) did you issue that failed?

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

[ECOS] limit on the number of diag_printf(s) ????

[Rycerz Roman-G11565]

Hi

    I am trying to get a port of Redboot running, right now I am dealing with single stepping.  At this point in the debug process I can no longer use a BDM (it permanently changes the core behavior) so I have resorted to some well placed diag_printf(s) to give me clues.  If I only have 2 or less diag_printf(s) all works fine.  as soon as I add the 3rd one, gdb (insight) will not load my application, it just comes right back....


    does anyone know what is the limiting factor here ????


roman
Roman F. Rycerz
Engr Section Mgr
Motorola IESS, ACES, PCSG, PCG

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