I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. I am quite new to this board and I am trying to execute a code from the MPC internal Flash. I use P&E Micro for debugging purposes. I opened a new 5566 project from CW. It automatically generated all the configuration files. I did not change any of those. I only modified the main.c file by initializing a GPIO. I use the GPIO to toggle a user LED on the board. I compiled the code for RAM and executed it out of RAM using the debugger. Everything is fine and the LED is toggling. Then I compiled the code for internal Flash and executed it using the debugger. Here also everything is fine and the LED is toggling, though the frequency is a little less. I expected the MPC to work by itself and toggle the LED (as code is still in Flash) when I remove the debugger. But, nothing happens. I believe that some initialization is done by the debugger for the code to execute properly from the Flash. Where can I find this initialization code? How can I make the MCU boot by itself? --------------------------------------- Posted through http://www.EmbeddedRelated.com
MPC5566 boot code
Started by ●May 25, 2012
Reply by ●May 25, 20122012-05-25
On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote:> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. I > am quite new to this board and I am trying to execute a code from the > MPC internal Flash. I use P&E Micro for debugging purposes. I opened a > new 5566 project from CW. It automatically generated all the > configuration files. I did not change any of those. I only modified the > main.c file by initializing a GPIO. I use the GPIO to toggle a user LED > on the board. I compiled the code for RAM and executed it out of RAM > using the debugger. Everything is fine and the LED is toggling. Then I > compiled the code for internal Flash and executed it using the debugger. > Here also everything is fine and the LED is toggling, though the > frequency is a little less. I expected the MPC to work by itself and > toggle the LED (as code is still in Flash) when I remove the debugger. > But, nothing happens. > I believe that some initialization is done by the debugger for the code > to execute properly from the Flash. Where can I find this initialization > code? How can I make the MCU boot by itself? > > > --------------------------------------- Posted through > http://www.EmbeddedRelated.comDo you mean when you physically remove the debugger, or when you just don't run the software on your PC? Some debuggers will hold the microprocessor in reset if they're left connected to the board and their software isn't active. If that's not it, then somewhere in all those automagically generated configuration files that you so trustingly used there is a problem that you need to find and fix. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●May 26, 20122012-05-26
>On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote: > >> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. I >> am quite new to this board and I am trying to execute a code from the >> MPC internal Flash. I use P&E Micro for debugging purposes. I opened a >> new 5566 project from CW. It automatically generated all the >> configuration files. I did not change any of those. I only modified the >> main.c file by initializing a GPIO. I use the GPIO to toggle a user LED >> on the board. I compiled the code for RAM and executed it out of RAM >> using the debugger. Everything is fine and the LED is toggling. Then I >> compiled the code for internal Flash and executed it using thedebugger.>> Here also everything is fine and the LED is toggling, though the >> frequency is a little less. I expected the MPC to work by itself and >> toggle the LED (as code is still in Flash) when I remove the debugger. >> But, nothing happens. >> I believe that some initialization is done by the debugger for the code >> to execute properly from the Flash. Where can I find thisinitialization>> code? How can I make the MCU boot by itself? >> >> >> --------------------------------------- Posted through >> http://www.EmbeddedRelated.com > >Do you mean when you physically remove the debugger, or when you just >don't run the software on your PC? > >Some debuggers will hold the microprocessor in reset if they're left >connected to the board and their software isn't active. > >If that's not it, then somewhere in all those automagically generated >configuration files that you so trustingly used there is a problem that >you need to find and fix. > >-- >My liberal friends think I'm a conservative kook. >My conservative friends think I'm a liberal kook. >Why am I not happy that they have found common ground? > >Tim Wescott, Communications, Control, Circuits & Software >http://www.wescottdesign.com >I have tried both - not running the debugger software and physically disconnecting the debugger from the board. Neither worked. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●May 26, 20122012-05-26
On Sat, 26 May 2012 00:25:19 -0500, "matrix13" <ravikrishnanunni@n_o_s_p_a_m.gmail.com> wrote:>>On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote: >> >>> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. I >>> am quite new to this board and I am trying to execute a code from the >>> MPC internal Flash. I use P&E Micro for debugging purposes. I opened a >>> new 5566 project from CW. It automatically generated all the >>> configuration files. I did not change any of those. I only modified the >>> main.c file by initializing a GPIO. I use the GPIO to toggle a user LED >>> on the board. I compiled the code for RAM and executed it out of RAM >>> using the debugger. Everything is fine and the LED is toggling. Then I >>> compiled the code for internal Flash and executed it using the >debugger. >>> Here also everything is fine and the LED is toggling, though the >>> frequency is a little less. I expected the MPC to work by itself and >>> toggle the LED (as code is still in Flash) when I remove the debugger. >>> But, nothing happens. >>> I believe that some initialization is done by the debugger for the code >>> to execute properly from the Flash. Where can I find this >initialization >>> code? How can I make the MCU boot by itself? >>> >>> >>> --------------------------------------- Posted through >>> http://www.EmbeddedRelated.com >> >>Do you mean when you physically remove the debugger, or when you just >>don't run the software on your PC? >> >>Some debuggers will hold the microprocessor in reset if they're left >>connected to the board and their software isn't active. >> >>If that's not it, then somewhere in all those automagically generated >>configuration files that you so trustingly used there is a problem that >>you need to find and fix. >> >>-- >>My liberal friends think I'm a conservative kook. >>My conservative friends think I'm a liberal kook. >>Why am I not happy that they have found common ground? >> >>Tim Wescott, Communications, Control, Circuits & Software >>http://www.wescottdesign.com >> > >I have tried both - not running the debugger software and physically >disconnecting the debugger from the board. Neither worked.Have you used this compiler+debugger combination on another project? This may not apply in your case but I have used embedded toolchains (e.g., Rowley's CrossWorks) that require an explicit #define to permit the application code to start by itself, otherwise it hangs in an endless loop just at the point where it would jump to main(). They do this so that the debugger can always get control before user code has a chance to, e.g., accidentally disable the JTAG port. Once the code is happy, define STARTUP_FROM_RESET in the build options (command line define) and it works stand-alone. Could something like this be required? -- Rich Webb Norfolk, VA
Reply by ●May 26, 20122012-05-26
On 26/05/12 13:18, Rich Webb wrote:> On Sat, 26 May 2012 00:25:19 -0500, "matrix13" > <ravikrishnanunni@n_o_s_p_a_m.gmail.com> wrote: > >>> On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote: >>> >>>> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. I >>>> am quite new to this board and I am trying to execute a code from the >>>> MPC internal Flash. I use P&E Micro for debugging purposes. I opened a >>>> new 5566 project from CW. It automatically generated all the >>>> configuration files. I did not change any of those. I only modified the >>>> main.c file by initializing a GPIO. I use the GPIO to toggle a user LED >>>> on the board. I compiled the code for RAM and executed it out of RAM >>>> using the debugger. Everything is fine and the LED is toggling. Then I >>>> compiled the code for internal Flash and executed it using the >> debugger. >>>> Here also everything is fine and the LED is toggling, though the >>>> frequency is a little less. I expected the MPC to work by itself and >>>> toggle the LED (as code is still in Flash) when I remove the debugger. >>>> But, nothing happens. >>>> I believe that some initialization is done by the debugger for the code >>>> to execute properly from the Flash. Where can I find this >> initialization >>>> code? How can I make the MCU boot by itself? >>>> >>>> >>>> --------------------------------------- Posted through >>>> http://www.EmbeddedRelated.com >>> >>> Do you mean when you physically remove the debugger, or when you just >>> don't run the software on your PC? >>> >>> Some debuggers will hold the microprocessor in reset if they're left >>> connected to the board and their software isn't active. >>> >>> If that's not it, then somewhere in all those automagically generated >>> configuration files that you so trustingly used there is a problem that >>> you need to find and fix. >>> >>> -- >>> My liberal friends think I'm a conservative kook. >>> My conservative friends think I'm a liberal kook. >>> Why am I not happy that they have found common ground? >>> >>> Tim Wescott, Communications, Control, Circuits& Software >>> http://www.wescottdesign.com >>> >> >> I have tried both - not running the debugger software and physically >> disconnecting the debugger from the board. Neither worked. > > Have you used this compiler+debugger combination on another project? > This may not apply in your case but I have used embedded toolchains > (e.g., Rowley's CrossWorks) that require an explicit #define to permit > the application code to start by itself, otherwise it hangs in an > endless loop just at the point where it would jump to main(). They do > this so that the debugger can always get control before user code has a > chance to, e.g., accidentally disable the JTAG port. Once the code is > happy, define STARTUP_FROM_RESET in the build options (command line > define) and it works stand-alone. Could something like this be required? >That's an interesting possibility, and one I'll remember for the future, but it's not likely to be the case here - Code Warrior doesn't do that. I haven't thought of any likely causes of the problem, however.
Reply by ●May 28, 20122012-05-28
>On 26/05/12 13:18, Rich Webb wrote: >> On Sat, 26 May 2012 00:25:19 -0500, "matrix13" >> <ravikrishnanunni@n_o_s_p_a_m.gmail.com> wrote: >> >>>> On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote: >>>> >>>>> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0.I>>>>> am quite new to this board and I am trying to execute a code fromthe>>>>> MPC internal Flash. I use P&E Micro for debugging purposes. I openeda>>>>> new 5566 project from CW. It automatically generated all the >>>>> configuration files. I did not change any of those. I only modifiedthe>>>>> main.c file by initializing a GPIO. I use the GPIO to toggle a userLED>>>>> on the board. I compiled the code for RAM and executed it out of RAM >>>>> using the debugger. Everything is fine and the LED is toggling. ThenI>>>>> compiled the code for internal Flash and executed it using the >>> debugger. >>>>> Here also everything is fine and the LED is toggling, though the >>>>> frequency is a little less. I expected the MPC to work by itself and >>>>> toggle the LED (as code is still in Flash) when I remove thedebugger.>>>>> But, nothing happens. >>>>> I believe that some initialization is done by the debugger for thecode>>>>> to execute properly from the Flash. Where can I find this >>> initialization >>>>> code? How can I make the MCU boot by itself? >>>>> >>>>> >>>>> --------------------------------------- Posted through >>>>> http://www.EmbeddedRelated.com >>>> >>>> Do you mean when you physically remove the debugger, or when you just >>>> don't run the software on your PC? >>>> >>>> Some debuggers will hold the microprocessor in reset if they're left >>>> connected to the board and their software isn't active. >>>> >>>> If that's not it, then somewhere in all those automagically generated >>>> configuration files that you so trustingly used there is a problemthat>>>> you need to find and fix. >>>> >>>> -- >>>> My liberal friends think I'm a conservative kook. >>>> My conservative friends think I'm a liberal kook. >>>> Why am I not happy that they have found common ground? >>>> >>>> Tim Wescott, Communications, Control, Circuits& Software >>>> http://www.wescottdesign.com >>>> >>> >>> I have tried both - not running the debugger software and physically >>> disconnecting the debugger from the board. Neither worked. >> >> Have you used this compiler+debugger combination on another project? >> This may not apply in your case but I have used embedded toolchains >> (e.g., Rowley's CrossWorks) that require an explicit #define to permit >> the application code to start by itself, otherwise it hangs in an >> endless loop just at the point where it would jump to main(). They do >> this so that the debugger can always get control before user code has a >> chance to, e.g., accidentally disable the JTAG port. Once the code is >> happy, define STARTUP_FROM_RESET in the build options (command line >> define) and it works stand-alone. Could something like this berequired?>> > >That's an interesting possibility, and one I'll remember for the future, >but it's not likely to be the case here - Code Warrior doesn't do that. > >I haven't thought of any likely causes of the problem, however. > >Thank you for all your help. I am posting some more information related to the code. The RCHW (0x5A) is at the 0x0000th location in Flash. And at 0x0004, the address to application code is present. It shows 0x008C and at that location '_start' is present. I am also able see the code jumping to '_start' (using the debugger) and executing the application code. I have checked the BOOTCFG pins. Since RSTCFG in de-asserted, the status of BOOTCFG doesn't matter. I also tried enabling RSTCFG and configuring BOOTCFG = 00. This also did not make the MCU run by itself. Is there anything else to be configured for a Flash execution? --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●May 28, 20122012-05-28
On 28/05/12 12:37, matrix13 wrote:>> On 26/05/12 13:18, Rich Webb wrote: >>> On Sat, 26 May 2012 00:25:19 -0500, "matrix13" >>> <ravikrishnanunni@n_o_s_p_a_m.gmail.com> wrote: >>> >>>>> On Fri, 25 May 2012 00:41:43 -0500, matrix13 wrote: >>>>> >>>>>> I am using Freescale MPC5566 Evaluation board with CodeWarrior 5.9.0. > I >>>>>> am quite new to this board and I am trying to execute a code from > the >>>>>> MPC internal Flash. I use P&E Micro for debugging purposes. I opened > a >>>>>> new 5566 project from CW. It automatically generated all the >>>>>> configuration files. I did not change any of those. I only modified > the >>>>>> main.c file by initializing a GPIO. I use the GPIO to toggle a user > LED >>>>>> on the board. I compiled the code for RAM and executed it out of RAM >>>>>> using the debugger. Everything is fine and the LED is toggling. Then > I >>>>>> compiled the code for internal Flash and executed it using the >>>> debugger. >>>>>> Here also everything is fine and the LED is toggling, though the >>>>>> frequency is a little less. I expected the MPC to work by itself and >>>>>> toggle the LED (as code is still in Flash) when I remove the > debugger. >>>>>> But, nothing happens. >>>>>> I believe that some initialization is done by the debugger for the > code >>>>>> to execute properly from the Flash. Where can I find this >>>> initialization >>>>>> code? How can I make the MCU boot by itself? >>>>>> >>>>>> >>>>>> --------------------------------------- Posted through >>>>>> http://www.EmbeddedRelated.com >>>>> >>>>> Do you mean when you physically remove the debugger, or when you just >>>>> don't run the software on your PC? >>>>> >>>>> Some debuggers will hold the microprocessor in reset if they're left >>>>> connected to the board and their software isn't active. >>>>> >>>>> If that's not it, then somewhere in all those automagically generated >>>>> configuration files that you so trustingly used there is a problem > that >>>>> you need to find and fix. >>>>> >>>>> -- >>>>> My liberal friends think I'm a conservative kook. >>>>> My conservative friends think I'm a liberal kook. >>>>> Why am I not happy that they have found common ground? >>>>> >>>>> Tim Wescott, Communications, Control, Circuits& Software >>>>> http://www.wescottdesign.com >>>>> >>>> >>>> I have tried both - not running the debugger software and physically >>>> disconnecting the debugger from the board. Neither worked. >>> >>> Have you used this compiler+debugger combination on another project? >>> This may not apply in your case but I have used embedded toolchains >>> (e.g., Rowley's CrossWorks) that require an explicit #define to permit >>> the application code to start by itself, otherwise it hangs in an >>> endless loop just at the point where it would jump to main(). They do >>> this so that the debugger can always get control before user code has a >>> chance to, e.g., accidentally disable the JTAG port. Once the code is >>> happy, define STARTUP_FROM_RESET in the build options (command line >>> define) and it works stand-alone. Could something like this be > required? >>> >> >> That's an interesting possibility, and one I'll remember for the future, >> but it's not likely to be the case here - Code Warrior doesn't do that. >> >> I haven't thought of any likely causes of the problem, however. >> >> > > Thank you for all your help. I am posting some more information related to > the code. > > The RCHW (0x5A) is at the 0x0000th location in Flash. And at 0x0004, the > address to application code is present. It shows 0x008C and at that > location '_start' is present. I am also able see the code jumping to > '_start' (using the debugger) and executing the application code. > I have checked the BOOTCFG pins. Since RSTCFG in de-asserted, the status of > BOOTCFG doesn't matter. I also tried enabling RSTCFG and configuring > BOOTCFG = 00. This also did not make the MCU run by itself. > > Is there anything else to be configured for a Flash execution? >It looks like the basic booting is working fine. There are two things that are likely problems if you are getting as far as "_start" but not as far as "main", while the code works fine from the debugger. One is that there is some part of the chip that is supposed to be initialised by the startup code, but is not being done. The other is that there is some issue with your linker script or specific section declarations which is accidentally putting code or data into ram instead of flash (the debugger will happily download it to the right place, but it will be missing in power-on startup). Look at your map file to see if this sounds possible. Also look at the debugger's "run from flash" debugger script, and check what it configures before starting the code from flash. The boot code (between "_start" and "main") needs to carry out mostly the same operations - something may be missing. One example I've seen is on an MPC with ECC on the sram (I don't know if the MPC5566 has) where the static ram was not properly initialised on bootup from flash. If I used the debugger, it ran fine, and it would run fine from flash after that, even after a hard reset - but if I powered off the board and started from flash, it failed.
Reply by ●May 28, 20122012-05-28
On Mon, 28 May 2012 14:09:00 +0200, David Brown <david.brown@removethis.hesbynett.no> wrote:> If I used >the debugger, it ran fine, and it would run fine from flash after that, >even after a hard reset - but if I powered off the board and started >from flash, it failed.Ah, the unique joys of embedded development. ;-) -- Rich Webb Norfolk, VA
Reply by ●May 28, 20122012-05-28
On 28/05/12 14:45, Rich Webb wrote:> On Mon, 28 May 2012 14:09:00 +0200, David Brown > <david.brown@removethis.hesbynett.no> wrote: > >> If I used >> the debugger, it ran fine, and it would run fine from flash after that, >> even after a hard reset - but if I powered off the board and started >>from flash, it failed. > > Ah, the unique joys of embedded development. ;-) >True enough. It would be boring if it were easy!
Reply by ●May 29, 20122012-05-29
>On 28/05/12 14:45, Rich Webb wrote: >> On Mon, 28 May 2012 14:09:00 +0200, David Brown >> <david.brown@removethis.hesbynett.no> wrote: >> >>> If I used >>> the debugger, it ran fine, and it would run fine from flash afterthat,>>> even after a hard reset - but if I powered off the board and started >>>from flash, it failed. >> >> Ah, the unique joys of embedded development. ;-) >> > >True enough. It would be boring if it were easy! > >Thank you for all your helps. The issue has been resolved. There was a small mistake in the start up code generated by Code Warrior. The internal SRAM size for MPC5566 is of 128KB and its an ECC SRAM. The start up code was assuming it to be of 64KB and initialized only that much. Now, this left the rest of the 64KB of internal SRAM uninitialized. In my linker code, the stack is defined to be at the last of this 128KB SRAM. Since the last 64KB is not initialized, ECC errors will be generated if the stack is accessed. The start up code was accessing the stack which resulted in a failure and the MCU stopped execution. Corrected the internal SRAM initialization code and the MCU booted itself from Flash (without the debugger). From this experience I understood one thing - do not be overly confident on the tool generated codes. :) Regards --------------------------------------- Posted through http://www.EmbeddedRelated.com
