public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "RAY Electronic-Design GmbH" <info@raygmbh.de>
To: <ecos-discuss@sources.redhat.com>
Subject: [ECOS] Fw: [ECOS] Asynchronous GDB break serial target
Date: Wed, 01 Aug 2001 08:33:00 -0000	[thread overview]
Message-ID: <006001c11aa7$bd4e2400$fe78a8c0@raypc2> (raw)

----- Original Message -----
From: "RAY Electronic-Design GmbH" <info@raygmbh.de>
To: "Jesper Skov" <jskov@cambridge.redhat.com>
Sent: Wednesday, August 01, 2001 4:48 PM
Subject: Re: [ECOS] Asynchronous GDB break serial target


> I traced so far now, that the hal_default_isr is called, but in there is
> going on something i don't understand:
>
>
> __
> #ifndef CYGSEM_HAL_ROM_MONITOR
>     if (CYGNUM_CALL_IF_TABLE_VERSION_CALL_HACK ==
>         (CYGACC_CALL_IF_VERSION() &
CYGNUM_CALL_IF_TABLE_VERSION_CALL_MASK))
> #endif
>     {
>         hal_virtual_comm_table_t* __chan = CYGACC_CALL_IF_DEBUG_PROCS();
>         if (__chan)
>             gdb_vector = CYGACC_COMM_IF_CONTROL(*__chan,
> __COMMCTL_DBG_ISR_VECTOR);
>     }
>     if( vector == gdb_vector )
> __
>
> in there it reads the version of the virtual vector table, which is 0x18
in
> my redboot build, but tries to compare it with 0x41. The Version is
> calculated:
>
> __
> #define CYGNUM_CALL_IF_FLASH_CFG_OP               20
>
> #define CYGNUM_CALL_IF_LAST_ENTRY
> CYGNUM_CALL_IF_FLASH_CFG_OP
>
> #define CYGNUM_CALL_IF_TABLE_VERSION_CALL
CYGNUM_CALL_IF_LAST_ENTRY
>
> #define CYGNUM_CALL_IF_TABLE_VERSION_COMM_shift   16
>
> #define CYGNUM_COMM_IF_TABLE_SIZE                 8
>
> #define CYGNUM_CALL_IF_TABLE_VERSION_COMM
CYGNUM_COMM_IF_TABLE_SIZE
>
>
>
>         // Version number
>         CYGACC_CALL_IF_VERSION_SET(CYGNUM_CALL_IF_TABLE_VERSION_CALL
>
>
|((CYG_ADDRWORD)CYGNUM_CALL_IF_TABLE_VERSION_COMM<<CYGNUM_CALL_IF_TABLE_VERS
> ION_COMM_shift));
> __
>
> And Compare:
>
> __
> #define CYGNUM_CALL_IF_TABLE_SIZE                 64
> #define CYGNUM_CALL_IF_TABLE_VERSION_CALL_HACK
> (CYGNUM_CALL_IF_TABLE_SIZE+1)
> __
>
> and becaus gdb_vector stays -1 because CYGACC_COMM_IF_CONTROL is not
called,
> it doesn't get interrupted by gdb.
>
> Did i mess something up in my effort to port my package to the current cvs
?
> Raymund Hofmann
>
>
> ----- Original Message -----
> From: "Jesper Skov" <jskov@cambridge.redhat.com>
> To: "Raymund Hofmann" <rhofmann@raygmbh.de>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, August 01, 2001 12:44 PM
> Subject: Re: [ECOS] Asynchronous GDB break serial target
>
>
> > >>>>> "Raymund" == Raymund Hofmann <rhofmann@raygmbh.de> writes:
> >
> > Raymund> I ported a existing 1.3.1 board package (Triscend A7(ARM))
> > Raymund> for operation with the current cvs.  Most of the things seem
> > Raymund> to work, but one particular thing does not:
> >
> > Raymund> Asynchronous GDB break (serial).
> >
> > Raymund> I installed a Redboot rom monitor and use this to debug a
> > Raymund> application in ram.
> >
> > Raymund> From my investigation so far, i have come tho know:
> >
> > Raymund> For the RAM application library:
> >
> > Raymund> i deactivated "initialize whole virtual vector table"
> >
> > Raymund> i deactivated "claim comms virtual vector table"
> >
> > Raymund> But i don't understand how the rom-monitor should receive
> > Raymund> control in case of a GDB serial interrupt because:
> >
> > Raymund> The processor vector table points to IRQ handler in the RAM.
> > Raymund> The entries in 'hal_interrupt_handlers' table do not point to
> > Raymund> ROM, it points to a default handler in RAM except one timer
> > Raymund> interrupt handler in RAM.
> >
> > Raymund> So redboot in ROM has no chance of noteicing the break.
> >
> > It will be called via the virtual vectors from the function
> > cyg_hal_user_break, being told to place a breakpoint at the $pc.
> >
> > Jesper
>

             reply	other threads:[~2001-08-01  8:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-01  8:33 RAY Electronic-Design GmbH [this message]
2001-08-02  0:53 ` Jesper Skov
2001-08-02  3:22   ` RAY Electronic-Design GmbH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='006001c11aa7$bd4e2400$fe78a8c0@raypc2' \
    --to=info@raygmbh.de \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).