Re: PB555 and Codewarrior
"coles555" <[email protected]>
| Newsgroups | gmane.comp.hardware.motorola.microcontrollers |
|---|---|
| Message-ID | <[email protected]> |
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
------------------------ 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/