[ECOS] Fw: [ECOS] Asynchronous GDB break serial target

[ECOS] Fw: [ECOS] Asynchronous GDB break serial target

[RAY Electronic-Design GmbH]

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

Re: [ECOS] Fw: [ECOS] Asynchronous GDB break serial target

[Jesper Skov]

>>>>> "RAY" == RAY Electronic-Design GmbH <info@raygmbh.de> writes:

>> 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() &
RAY> 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
RAY> in
>> my redboot build, but tries to compare it with 0x41. The Version is
>> calculated:

The version is set to 0x41 in hal_ctrlc_isr_init which is (or should
be) called by RAM applications as they enable ctrl-c support.

Jesper

Re: [ECOS] Fw: [ECOS] Asynchronous GDB break serial target

[RAY Electronic-Design GmbH]

I was fooled by the GUI configtool, where I changed some options, but
hitting F7 for build didn't recompile vector.s, where hal_ctrlc_isr_init is
called.
After deleting all *.o files in the build tree's and remaking
hal_ctrlc_isr_init was called.
Asynchronous Break now seems to work, I'll have to test further...

Raymund Hofmann

----- Original Message -----
From: "Jesper Skov" <jskov@cambridge.redhat.com>
To: "RAY Electronic-Design GmbH" <info@raygmbh.de>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Thursday, August 02, 2001 8:51 AM
Subject: Re: [ECOS] Fw: [ECOS] Asynchronous GDB break serial target


> >>>>> "RAY" == RAY Electronic-Design GmbH <info@raygmbh.de> writes:
>
> >> 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() &
> RAY> 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
> RAY> in
> >> my redboot build, but tries to compare it with 0x41. The Version is
> >> calculated:
>
> The version is set to 0x41 in hal_ctrlc_isr_init which is (or should
> be) called by RAM applications as they enable ctrl-c support.
>
> Jesper