1. Home
  2. Embedded Programming
  3. MPC5566 boot code

MPC5566 boot code

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

formatting link

Reply to
matrix13
Loading thread data ...

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
Reply to
Tim Wescott

debugger.

initialization

I have tried both - not running the debugger software and physically disconnecting the debugger from the board. Neither worked.

--------------------------------------- Posted through

formatting link

Reply to
matrix13

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 to
Rich Webb

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 to
David Brown

I

the

a

the

LED

I

debugger.

code

that

required?

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

formatting link

Reply to
matrix13

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 to
David Brown

Ah, the unique joys of embedded development. ;-)

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

True enough. It would be boring if it were easy!

Reply to
David Brown

that,

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

formatting link

Reply to
matrix13

The pre-generated startup code was originally written for earlier devices, and the CW developers then adapt it for newer devices. This history is one of the reasons why it is often quite bad - it is the product of lots of small changes, rather than a clear design. On the other hand, of course, clear new designs often have new bugs, and if you are using the free "special" edition, then there is a limit to how much one can complain!

Still, it is worth filling out a service request highlighting the problem. While I think the startup code is poor and needs re-writing, I think this is mainly a question of time, money and resources - the CW developers I have been in contact with through service requests take a pride in their work, and are trying to make the best tools they can. I think they will appreciate the feedback.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.