Release Notes
CodeWarrior Development Studio for MPC55xx/56xx Version 2.7
________________________________________________________________
I. About this Release
A. Version Information
CodeWarrior™ Development Studio for MPC55xx/MPC56xx Version 2.7
B. System Requirements
Recommended Configuration
• 1.8 GHz Pentium® compatible processor or better
• Microsoft Windows XP/Vista/7
• 2 GB
• 2 GB hard disk space, 400 MB on Windows system disk
• CD-ROM drive for installation
• USB port for communications with target hardware
• Ethernet port for communications with target hardware (optional) Operational Minimum Configuration
• 1.4 GHz Pentium® compatible processor or better
• Microsoft Windows XP
• 1 GB RAM
• 1 GB hard disk space, 400 MB on Windows system disk
• CD-ROM drive for installation
• USB port for communications with target hardware
• Ethernet port for communications
C. Installation and Licensing
To install CodeWarrior Development Studio for MPC55xx/MPC56xx V2.7, double- click the installation package and a wizard will guide you through the installation process.
This CodeWarrior release is available in two editions: Special Edition and Standard Edition.
The Special Edition supports C/C++ code up to 128k in both the compiler and the debugger.
The Standard Edition supports unlimited C/C++ code size in both the compiler and debugger. The Standard Edition also includes support for OSEK kernel-aware debugging..
The Standard Edition also has a plug-in which will integrate PC-Lint from Gimpel Software, so that you can call PC-Lint from the CodeWarrior IDE. PC-Lint is a
problems that the compiler alone cannot. Note that we do not include PC-Lint in the CodeWarrior tools; you need to purchase it separately from Gimpel Software.
An Evaluation Edition is available which includes all the functionality of the Standard Edition for 30 days, after which it reverts to the Special Edition.
Getting Help
All issues will be tracked through Freescale's normal Service Request Process. To report feature requests (enhancements) or defects for CodeWarrior Development Studio for MPC55xx/MPC56xx V2.7, please submit a Service Request.
1. Go to http://www.freescale.com/support 2. Log in.
3. On the resulting MyFreescale page, click Enter a Service Request 4. Choose category: Technical Request
5. Choose topic: CodeWarrior 6. Click Continue.
7. Provide the required information. An attachment up to 10 MB may be attached to the SR. You may also specify email addresses of people you would like to keep notified on the progress of the SR. Separate multiple email addresses with commas.
• Type: pick from Query (Question), Change Request (Enhancement) or Problem Report (Bug)
• Target: specify the hardware microcontroller/microprocessor family involved
• Priority: choose from Normal, High, or Highest
• Description: details of the issue or feature request 8. When finished, click Submit.
After Submit is selected, a confirmation page will be displayed with your SR number.
You will also receive a confirming email sent to the address specified in your Freescale account.
Freescale has well-established processes for moving SRs into our formal feature request/planning process and into the formal defect tracking tools used by the R&D team. There is no guarantee that a reported feature will be implemented, or a reported defect will be fixed in any particular period of time, but it does mean that your feedback will be seen, heard, listened to, and acted on in some way.
D. Supported Targets
CodeWarrior Development Studio for MPC55xx/MPC56xx V2.7 supports all the devices included in version 2.6 plus support for the following new derivatives:
MPC5675K MPC5602P MPC5602B MPC5602D
II. New Features
A. P&E ICDPPCNEXUS Debugger
• Debugger and flash programmer support for MPC5602B and MPC5602D devices
• Debugger and flash programmer support for MPC5602P devices
• Debugger and flash programmer support for MPC5675K devices
• Supports OSJTAG hardware interface
B. Compiler
• We've added an enhancement to complete program IPA (interprocedural analysis).
Overview:
When the feature is enabled, application global variables that are
only used in one function are re-scoped to be local static. The change to static enables other optimizations that improve alias analysis and load/store
optimizations. EEMBC AutoMark improved by about 11%.
Requirements:
Program IPA enabled in all application source files, use of
#pragma ipa_rescopes_globals on in all application source files (perhaps in a prefix file or with -flag ipa_rescopes_globals on the commandline), and main() is in one of the application files. It is not necessary, or even desirable,
to have standard library, runtime or startup code compiled with program IPA and ipa_rescopes_globals enabled. However it is important to have as many of your application sources as possible compiled with those options enabled. Since third-party libraries generally do not access your application variables, these libraries can be kept in archive form.
Simple example:
startup code, application code, standard C/C++ library archive,
and runtime library archive. (No other libraries used except third-party libraries as mentioned above.) You would compile/assemble your startup code without program IPA. You would compile all of your application code with program IPA and #pragma ipa_rescopes_globals on. You link the startup objects, your application objects and the library archives. (Program IPA linking procedures are in our documentation and CW C-C++ Notes release notes.)
Complex example:
If your application sources are put into groups, compiled and then pre-built into several archives or partially linked objects and you are unable to change the build procedure to match the simple example, then you have to make some changes to your build procedure. We suggest that you first try to make your build setup as similar to the simple example as possible. Making this effort should tell you whether your code will benefit from ipa_rescopes_globals or point you to the steps you will need to take to get a successful link. Since the compiler will not see all of your functions at once during program IPA, it is possible that a defined global variable in your core files may be used by only one core file but might also be used in one of your application archives that you were unable to build the simple way. If this is true, ipa_rescopes_globals will rescope the variable and at link time, your application archive will not be able to find
errors, you have a few options that will allow you to get a proper build but they involve source file changes. In your sources, find where the "undefined"
symbol is defined and try one of the following (in decreasing order of general preference):
1) move the definition of the symbol into the application archive (symbols undefined do not get re-scoped)
2) force the export of the symbol with __declspec(force_export) (exported symbols do not get re-scoped)
3) change to weak with __declspec(weak) (insert before definition) (weak symbols do not get re-scoped)
4) change to volatile (volatile symbols do not get re-scoped)
• EWL
EWL (Embedded Warrior Library) is the next generation of MSL. With this release, EWL will be an alternative library; all of your existing projects and makefile access paths will not use the EWL unless you specifically choose it.
The sources are based on MSL but they've been cleaned up and are more MISRA compliant. There are some changes to the standard prefix file name, library (archive) names, and we got rid of some of the legacy libraries and have a greater number of more processor core specific libraries.
Library naming conventions for EWL:
Each archive name has 3 pieces: prefix, core and flags. The prefix is one of:
libm_, librt_, libc_, libc99_, libstdc++__ and libc++_.In order, these prefix names refer to math, runtime, reduced code size C, faster and increased C99
conformant C, latest C++ and reduced code size C++. The core starts with the processor family (like e200 or e500) and optionally ends with the core name (such as z750). Current flags are VLE, Soft (software floating point) and SPFP_Only (math library only has single precision sources and source file doubles are treated as if they are single precision). SPFP_Only is only used with e200 and e500 which have single precision floating point instructions but no double precision instructions. Note that with EWL, we only build unsigned char libraries. Not all of the libraries below are available in this release
EWL Prefix Name MSL Prefix Name
ansi_prefix.PA_EABI.bare.h ansi_prefix.PPCEABI.bare.h EWL Library Core And Flag Name MSL Suffix Name Equivalent E200z0_VLE_Soft PPCEABI.VS.UC
E200z150_VLE_Soft PPCEABI.VS.UC E200z335_VLE PPCEABI.V.UC E200z335_VLE_SPFP_Only PPCEABI.V.SP.UC E200z336_VLE PPCEABI.V.UC E200z336_VLE_SPFP_Only PPCEABI.V.SP.UC E200z446_VLE PPCEABI.V.UC E200z446_VLE_SPFP_Only PPCEABI.V.SP.UC E200z448_VLE PPCEABI.V.UC E200z448_VLE_SPFP_Only PPCEABI.V.SP.UC E200z650 PPCEABI.E.UC E200z650_SPFP_Only PPCEABI.E.SP.UC E200z650_VLE PPCEABI.V.UC E200z650_VLE_SPFP_Only PPCEABI.V.SP.UC E200z652 PPCEABI.E.UC E200z652_SPFP_Only PPCEABI.E.SP.UC E200z652_VLE PPCEABI.V.UC
E200z652_VLE_SPFP_Only PPCEABI.V.SP.UC E200z750_VLE PPCEABI.V.UC E200z750_VLE_SPFP_Only PPCEABI.V.SP.UC E200z760_VLE PPCEABI.V.UC E200z760_VLE_SPFP_Only PPCEABI.V.SP.UC E300c1 PPCEABI.H.UC E300c2 PPCEABI.H.UC E300c3 PPCEABI.H.UC E300c4 PPCEABI.H.UC E500V1 PPCEABI.E.UC E500V1_SPFP_Only PPCEABI.E.SP.UC E500V2 PPCEABI.E2.UC E600 PPCEABI.A.UC
• MTWX36885 Compiler emits new VLE instructions in the interrupt prolog/epilog in C-functions with option "vle_multiple".
With this option, compiler
- emits e_lmvgprw and e_stmvgprw if any of [r3,r12] needs to be saved to stack; and
- emits e_lmvsprw and e_stmvsprw if any of the CR, LR, CTR and XER needs to be saved to stack; and
- emits e_lmvsrrw and e_stmvsrr if any of the SRR0 and SRR1 needs to be saved to stack; and
- emits e_lmvcsrrw and e_stmvcsrrw if any of the CSRR0 and CSRR1 needs to be saved to stack; and
- emits e_lmvdsrrw and e_stmvdsrrw if any of the DSRR0 and DSRR1 needs to be saved to stack
Note that enabling this option could increase the space being taken up by the stack especially when saving the volatile gprs.
This option is only valid only for e200 (Zen) core. Compile error will be returned if this option is used for any other cores.
Appendix A — Defects Fixed
The table below lists the defects that have been resolved in this release.
Issue Abstract Debugger
Debugger now properly handles wait and stop low power modes for MPC560xB and MPC560xS devices.
Build Tools
MTWX38342 Complex function parameters are not correctly evaluated if the float constants are used and the compiler optimization is turned on.
MTWX39600 Compiler incorrectly compiles the non-vle instruction "lis rx,0" into vle instruction
"se_bgeni rx,0" when "PPC to VLE Asm" option enabled.
MTWX39609
CodeWarrior backend optimizer for VLE code has been improved to use
“se_bgeni” instead of "e_lis" in certain cases.
MTWX40665 The assembler's pref panel option "GNU Compatible Syntax" is not a command line option.
MTWX41515 Problem with spe spilling MTWX38253
Disassembler generates wrong information for assembly instruction
"mtivor32". It's disassembled as "mtspr IBAT0U,r0" instead of " mtspr IVOR32,r0".
MTWX38251 Standalone assembler doesn't correctly translate "mtIVOR6" instruction.
Disassembled equivalent shows "mtspr IVOR5,xx" instead.
MTWX36885 Compiler now uses new VLE instructions in the interrupt prolog/epilog in C- functions tagged by __declspec(interrupt)
MTWX34534
Assembler/Inline assembler doesn't translate the instruction "rfmci"
for derivatives based on z200e7. Warnings occur when "mfmcsrr0" and
"mfmcsrr1" instructions are used.
MTWX32185 Unable to force compiler to generate correct code for custom small memory section.
MTWX41834 Internal linker error occurs when demo program of flash library is built with code_merging all.
MTWX41329 Compiler shows Error #10233 "cannot instantiate" with specialized template function.
MTWX41276 Command Line Tools cannot find license.dat.
MTWX30910 Internal compiler error displayed for inconsistency in -sym dwarf-2 option between compile and link time.
MTWX40552 Compiler/Linker generates incorrect addresses if switch tables are on MTWX41741 'wait' instruction not implemented
MTWX42085 Linker corrupts next instruction by using wrong relocation offset when accessing SDA variable in standalone assembler if VLE enabled.
MTWX42032 Pragma "warn_possiblyuninitializedvar" generates false positive when GCC style inline assembler uses initialized variable.
MTWX42293
e200z7 core(s) may include instructions mtpmr, mfpmr but these
instructions are not supported by the standalone/inline assembler when -proc Zen selected.
MTWX42381 Local variable is not visible
MTWX42478 Problem with #define macro in assembly file MTWX42501 Missing support for VLE instruction: e_add2is Documentation
MTWX37409 The documentation should be updated for directive KEEP_SECTION - The implemented directive is KEEP.
MTWX39084 INCLUDE command removed from Power Arch Build Tools Reference.pdf”
document and Help file as a supported command.
MTWX41713 Documentation - "Power Architecture Build Tools Reference.pdf" should update
"-noentry"/"-nomain" descriptions.
MTWX41718
Some command line options are order sensitive e.g. "-warnings full" should be used before using any other options that affect warnings. This should be documented.
MTWX39085 Inline assembly directive "entry" works only in function level inline assembly.
This is not documented properly.
MTWX39086 GCC asm sytax along with gcc "statements in expression" feature is supported by CW inline assembly but it's not documented properly.
MTWX39613 Documentation does not correctly describe compiler option "-func_align" and
"Function Alignment" IDE Project settings option.
Appendix B — Issues and Workarounds
The table below lists each unresolved issue in this release and its workaround.
Issue Abstract
None
