[coldfire-gnu-discuss] Debugging from flash

[Corrin Meyer]

I have been continuing to try to debug my problem.  While I am still not
sure if I am doing it correctly, I have at least been able to start
stepping though my code as long as after connecting with the sprite I
set PC to __cs3_reset.

The problem I have now is that I am getting an access error:


Remote debugging using | m68k-elf-sprite pe: versimation
m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF :
M52230DEMO (PE60))
m68k-elf-sprite: Target reset
0x00000000 in __cs3_interrupt_vector_coldfire ()
(gdb) set $pc=__cs3_reset
(gdb) si
0x00000406 in __cs3_reset_m52235evb ()
(gdb)
0x0000040a in __cs3_reset_m52235evb ()
(gdb)
0x00000410 in __cs3_reset_m52235evb ()
(gdb)
0x00000414 in __cs3_reset_m52235evb ()
(gdb)
0x00000416 in __cs3_reset_m52235evb ()
(gdb)
0x0000041c in __cs3_reset_m52235evb ()
(gdb)
0x00005620 in _start ()
(gdb)
0x00005622 in _start ()
(gdb)
Cannot access memory at address 0x5620
(gdb) x/4xw 0x401d0014
0x401d


The entire block (as far as I can tell; I haven't tested every entry) of
flash from 0x4000 to 0x5fff is inaccessible.

Corrin Meyer

> -----Original Message-----
> From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com]
> Sent: Monday, September 08, 2008 5:25 PM
> To: coldfire-gnu-discuss at codesourcery.com
> Subject: RE: [coldfire-gnu-discuss] Debugging from flash
> 
> Sorry, I forgot to include the exception frame.  That is actually what
I
> was trying to look into but it doesn't seem to make sense to me.  The
> following GDB session output was from attempting to debug the 'hello
> world' program from flash. This program, when run without GDB, runs
> fine.  It can be debugged fine by GDB when run from RAM.
> 
> 
> (gdb) target remote | m68k-elf-sprite pe: m52235evb Remote debugging
> using | m68k-elf-sprite pe: m52235evb
> m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF
:
> M52230DEMO (PE60))
> m68k-elf-sprite: Target reset
> 0x00000000 in __cs3_interrupt_vector_coldfire ()
> (gdb) c
> Continuing.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000f5e in __cs3_isr_illegal_instruction ()
> (gdb) p $sp
> $1 = (void *) 0x20007f88
> (gdb) x/4xw $sp
> 0x20007f88:     0x20007fd4      0x40102708      0x00000002
> 0xfffffffe
> (gdb)
> 
> 
> This exception frame doesn't seem to make a whole lot of sense to me.
> 
> I did make some progress though.  If I manually set $pc = __cs3_reset
> and $sp = 0x20008000 and then issue the continue command, it executes
as
> expected. Also I can add breakpoints if I use 'hbreak' but it doesn't
> seem to add hardware breakpoints by default.
> 
> Corrin Meyer
> 
> > -----Original Message-----
> > From: Corrin Meyer [mailto:Corrin.Meyer at dornerworks.com]
> > Sent: Monday, September 08, 2008 10:42 AM
> > To: coldfire-gnu-discuss at codesourcery.com
> > Subject: RE: [coldfire-gnu-discuss] Debugging from flash
> >
> > It actually is not a M52235EVB but the ColdFire is configured like a
> > M52235EVB.  I have been able to successfully run and debug
> applications
> > from RAM.  It is just once I go to Flash that I am getting this
> problem.
> >
> > Corrin Meyer
> >
> > > -----Original Message-----
> > > From: Daniel Jacobowitz [mailto:dan at codesourcery.com]
> > > Sent: Monday, September 08, 2008 9:42 AM
> > > To: Corrin Meyer
> > > Cc: coldfire-gnu-discuss at codesourcery.com
> > > Subject: Re: [coldfire-gnu-discuss] Debugging from flash
> > >
> > > On Mon, Sep 08, 2008 at 09:21:09AM -0400, Corrin Meyer wrote:
> > > > (gdb) target remote | m68k-elf-sprite pe: m52235evb
> > >
> > > Just checking, is your board actually an M52235EVB or is it
> something
> > > similar but slightly different?
> > >
> > > > Program received signal SIGTRAP, Trace/breakpoint trap.
> > > > 0x00000e12 in __cs3_isr_illegal_instruction ()
> > > > (gdb)
> > >
> > > At this point, I'd suggest you check the exception frame on the
> stack
> > > to see what instruction was illegal.
> > >
> > > > I would expect that after issuing the continue command that the
> > program
> > > > should execute just as if the board had been booted.  Am I
missing
> > > > something?
> > >
> > > Almost the same.  The only difference is that the initialization
> > > sequence in the board file is executed first; this is to support
> > > programs run from RAM, which may require the memory controller
> > > to be initialized first.  But in general the initialization
sequence
> > > does not cause a problem if executed twice.
> > >
> > > --
> > > Daniel Jacobowitz
> > > CodeSourcery