[coldfire-gnu-discuss] Debugging/Running program in internal Flash.

[Nathan Sidwell]

Claude Sylvain wrote:
> Hello Nathan,

> (gdb) p/x $pc
> $2 = 0x400
> (gdb) continue
> Continuing.
> Note: automatically using hardware breakpoints for read-only addresses.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000404 in __start ()
> (gdb) disassemble 0x400 0x420
> Dump of assembler code from 0x400 to 0x420:
> 0x00000400 <__start+0>: moveal #536903680,%sp
> 0x00000406 <__start+6>: moveal #0,%fp
> 0x0000040c <__start+12>:        movel #0,%d1
> 0x00000412 <__start+18>:        movel %d1,%sp at -
> 0x00000414 <__start+20>:        movel %fp,%sp at -
> 0x00000416 <__start+22>:        jmp 0xc48 <__start1>
> 0x0000041c <__do_global_dtors_aux+0>:   linkw %fp,#0

Looking at the way the PC is behaving I think there's a cache problem.  The 
Icache has not been flushed and has something stale in it.  That would explain 
why the pc has landed at 404, which is not an instruction boundary.

I'm not sure how that's happened.  IIUC you're using the m52235evb config, 
right?  That does tell the sprite that there is a cache.  Here are some suggestions:

*) Reset or powercycle the board (the sprite should be resetting the board on 
first connection though)

*) Force a write to RAM from gdb.  this will cause the sprite to flush the Icache.
	p/x *(int *)__data_start  = 0x1234567

then reset the pc to 0x400 as you have been doing, and try again.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan at codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk