RE: Re: PB555 and Codewarrior

The hex code for blrl should be 0x4e800021, not 0x00000000. So for some
reason, your code is getting corrupted before you get a chance to
execute it. You get the machine check exception since the code is
corrupted. You previously reported it was the "lis      r3,main@ha"
instruction that caused machine check, so it appears the location has
changed.

You have to figure out why the code is corrupted. Check the following:

1) is the code not getting built correctly (unlikely). Open the .mot
file within the bin folder in your project directory.  This is the
s-record. Find address 0x003FA03C and check it has 0x4e800021 and not
0x00000000.

2) is code getting downloaded? In the Debugger settings window, check
that program download options has 'executable', 'constant data' and
'initialised data' checked for both initial launch and initialised data.
I'm probably using a different version from you, so these settings may
not be available. If you can't find them, try quiting CW and then
reopening.
- As soon as you open the debugger, open a memory window and check
contents of 0x003fa03c.

3) Is code corrupting opcodes? As soon as you open the debugger, open a
memory window and check contents of 0x003fa03c. Now step through your
code and see if it changes to 0x00000000.

Depending on what you find, it may give you cluses as to where the
problem lies - compiler, debugger, linker settings, hardware...

Good luck,
Allan 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of coles555
Sent: Thursday, September 29, 2005 3:18 PM
To: [email protected]
Subject: [MPC500] Re: PB555 and Codewarrior


Hi Allan,
When I go into the mixed setting, this is the code:
	
	/*
	 *	initialization before main
	 */
	
#if defined(USE_FAR_ADDRESSING_TO_TEXT_SECTION)
	lis      r3,__init_user@ha
003FA030: 3C600040  lis      r3,64
	addi     r3,r3,__init_user@l
003FA034: 3863A33C  subi     r3,r3,23748
	mtlr     r3
003FA038: 7C6803A6  mtlr     r3
	blrl

003FA03C: 00000000  dc.l     0x00000000               ; Invalid 
opcode '....'

#else
	bl		__init_user
#endif

The machine check exception occurs at the following line: 

003FA03C: 00000000  dc.l     0x00000000               ; Invalid 
opcode '....'

I am kind of confused, can you advise?

Thanks,
Lei



--- In [email protected], "Dobbin Allan-r11834" 
<Allan.Dobbin@f...> wrote:
> This instruction is loading an immediate value into R3, so you
wouldn't
> expect this instruction to cause a machine check since it isn't
loading
> data from another address.  Perhaps this instruction isn't actually 
> getting executed - on the bottom of the debug window where it says 
> "Source" - click this and change to "Mixed".  Verify the address is 
> within range i.e. 3fa000-3fc000 and also verify the code has not
been
> corrupted i.e. the disassembled instruction should also be of the
form
> "lis r3,xxxxxx".
> 
> Regards,
> Allan
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
Behalf
> Of coles555
> Sent: Wednesday, September 28, 2005 3:09 PM
> To: [email protected]
> Subject: [MPC500] Re: PB555 and Codewarrior
> 
> 
> Hey guys,
> 
> These are my EPPC linker settings:
> Code Address: 0x003fa000
> Data Address: 0x003fc000
> RAM Buffer Address: 0x00000000
> ROM Image Address: 0x00000000
> Heap Address: 0x00000000
> Stack Address: 0x003ff000
> 
> EPPC Target Settings:
> Small Data: 8
> Small Data2: 8
> Heap Size: 4
> Stack Size: 4
> 
> With these settings established, the program exception for the
> init_registers went away. However I got another Machine Check 
> Exception at:
> 
> /*
>  *	branch to main program
>  */
> 	
> #if defined(USE_FAR_ADDRESSING_TO_TEXT_SECTION)
> 	lis      r3,main@ha      //Machine Check Exception 
> occurs         
> 	addi     r3,r3,main@l
> 	mtlr     r3
> 	blrl
> 
> Now I believe I have setup all the memory initialization within the
> chip, but I'm not sure why there is yet more of these exceptions. 
Anyone
> can help?
> 
> Thanks in advance,
> Lei
> 
> 
> 
> 
> --- In [email protected], Dees Randy-rsaf30 <randy.dees@f...>
> wrote:
> > you only have to worry about the SRAM area that the monitor uses,
> if you are actually using the monitor to download code, program
> flash, etc.
> > 
> > If you use BDM, then it doesn't matter. or if you never go back to
> the monitor after you run your program from internal memory (or
don't 
> care if the SRAM gets blown away when you return to the monitor.
> > 
> > randy
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] On 
> > > Behalf Of murphynetuk
> > > 
> > > 
> > > Just to let you know that it's possible I routinely build PB-
0555
> > > projects that operate entirely out of the internal SRAM,
> including
> > > the area 0x3f9800 -> 0x3fa000, even though the Axiom
> documentation
> > > claims that area for their monitor.
> > > Ian
> 
> 
> 
> 
> 
> -----------------------------------------------------------
> To learn more about Freescale Microcontrollers, please visit 
> http://www.freescale.com/mcu
> 
> 
>  
> Yahoo! Groups Links





-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links



 



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dN_tlB/TM
--------------------------------------------------------------------~-> 

-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MPC500/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/