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]

Fw: Asynchronous GDB break serial target



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


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