This is the mail archive of the ecos-discuss@sources.redhat.com 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: limit on the number of diag_printf(s) ????


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


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