Re: Re: PB555 and Codewarrior

Well, you are calling constructor functions here. Look at the assembly 
code again and see which of the function calls is invalid.
Set a breakpoint at the actual branch and see where it is going. It is 
likely that one of them is going off into invalid memory.

coles555 wrote:

>Actually the machine check occurs at the static initializer function:
>
>#if defined(__cplusplus) || defined(__VEC__)
>static void __init_cpp(void)
>{
>	voidfunctionptr *constructor;
>
>	/*
>	 *	call static initializers
>	 */
>	for (constructor = _ctors; *constructor; constructor++) {
>		(*constructor)();
>	}  // MACHINE CHECK - 003FA384: 3BFF0004  addi     r31,r31,4
>}
>
>Any pointers would be greatly appreciated?
>
>Lei
>
>
>--- In [email protected], "coles555" <coles555@y...> wrote:
>  
>
>>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
>>>      
>>>
>
>
>
>
>
>-----------------------------------------------------------
>To learn more about Freescale Microcontrollers, please visit
>http://www.freescale.com/mcu
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

-- 
David Wybo                    mailto:[email protected]
RealTime Consultants, Inc.    Phone: 248.345.6160
www.realtimeconsultantsinc.com



[Non-text portions of this message have been removed]



------------------------ 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/