some newbie questions

[Ed Sutter]

Seb,
Well, beleive it or not, that makes sense.  Here's why...

One thing to realize when using a monitor to debug that way...
The monitor is using facilities in the CPU that the RTOS wants
to control; hence, there is a conflict of interest here so
you need to be careful.  For example, I'm guessing that "VBR"
is VectorBaseRegister.  That instruction is changing the
base of the vector table, so any further single stepping by
the monitor will get hosed because the exception table just
moved (hence, the trace exception needed for single stepping
is lost).  It's better to try to use a simpler means of debugging
at this level of RTOS startup simply because the RTOS is likely
to use all of the facilities that the CPU has to offer, but
the monitor-based-debugger is also likely to want to use them
to be able to do the fancier, cpu-dependent debugging.
Ed

sebastian ssmoller wrote:
> 
> i started debugging the start sequence (the monitor supports setting
> breakpoints) ...
> 
> from objdump i get
> 
> 0001041c <start>:
>    1041c:       007c 3000       oriw #12288,%sr
>    10420:       4ff9 ffc0 03c0  lea ffc003c0 <m360+0x3c0>,%sp
>    10426:       41fa fbd8       lea %pc@(10000 <_RamBase>),%a0
>    1042a:       4e7b 8801       movec %a0,%vbr
>    1042e:       4e7a 1001       movec %dfc,%d1
>    10432:       7007            moveq #7,%d0
>    10434:       4e7b 0001       movec %d0,%dfc
> ....
> 
> so i set a breakpoint to 1041c and go on step by step. i get:
> 
> BREAK AT  0001041C
> *ST
> 
> 0001041C    OR.W    #$3000,SR
> D0 = 00000000    D1 = 00000000    D2 = 00000000    D3 = 00000000
> D4 = 00000000    D5 = 00000000    D6 = 00000000    D7 = 00000000
> A0 = 00000000    A1 = 00000000    A2 = 00000000    A3 = 00000000
> A4 = 00000000    A5 = 00000000    A6 = 00000000    MS = 000004A0
> IS = 000004A0    US = 000004A0    SR = 0000B000    PC = 00010420
> VB = 00000000    SF = 00000000    DF = 00000000    CC = 00000000
> 
> *ST
> 
> 00010420    LEA     $FFC003C0.L,A7
> D0 = 00000000    D1 = 00000000    D2 = 00000000    D3 = 00000000
> D4 = 00000000    D5 = 00000000    D6 = 00000000    D7 = 00000000
> A0 = 00000000    A1 = 00000000    A2 = 00000000    A3 = 00000000
> A4 = 00000000    A5 = 00000000    A6 = 00000000    MS = FFC003C0
> IS = 000004A0    US = 000004A0    SR = 0000B000    PC = 00010426
> VB = 00000000    SF = 00000000    DF = 00000000    CC = 00000000
> 
> *ST
> 
> 00010426    LEA     $10000(PC),A0
> D0 = 00000000    D1 = 00000000    D2 = 00000000    D3 = 00000000
> D4 = 00000000    D5 = 00000000    D6 = 00000000    D7 = 00000000
> A0 = 00010000    A1 = 00000000    A2 = 00000000    A3 = 00000000
> A4 = 00000000    A5 = 00000000    A6 = 00000000    MS = FFC003C0
> IS = 000004A0    US = 000004A0    SR = 0000B000    PC = 0001042A
> VB = 00000000    SF = 00000000    DF = 00000000    CC = 00000000
> 
> *ST
> 
> and now the board hangs ...
> 
> i am not sure whether the "lea" command is the current command executed or
> the last one executed successfully but it seems that i have some really
> basic problems here :(
> 
> the next statement works with vbr which is assumed to be at 0x0. do i have
> to let rtems know that ?
> 
> thank u for ur help so far and for all ur hints. i will have to check all
> the addresses and the linkcmds script again. it seems to be still a problem
> with memory mapping, i guess.
> 
> the monitor support bdm i guess. unfortunately my system (freebsd) doesnt
> support it (no driver). i will setup a linux box these days and i'll try to
> run bdm+gdb on it ...
> 
> thx
> regards,
> seb