Re: PB555 and Codewarrior

Hi Allan,
I went back and recompiled my code and address 0x003FA03C has 
0x4e800021, which is corrected from the old 0x00000000. However I do 
get another machine check exception at the next line of code:

/*
 *	branch to main program
 */
	
#if defined(USE_FAR_ADDRESSING_TO_TEXT_SECTION)
	lis      r3,main@ha
003FA040: 3C600040  lis      r3,64              // -> machine check
	addi     r3,r3,main@l
003FA044: 3863A3AC  subi     r3,r3,23636
	mtlr     r3
003FA048: 7C6803A6  mtlr     r3
	blrl
003FA04C: 4E800021  blrl
#else
	bl		main
#endif

/*
 *	exit program
 */

I really don't see why there would be another machine check exception 
at this line of code. From the looks of it, this line of code is 
trying to branch to the main program, do you think there is some kind 
of address or data conflict? Thanks so much for your help.

Lei


--- In [email protected], "Dobbin Allan-r11834" 
<Allan.Dobbin@f...> wrote:
> 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 --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/