Did you know that the CodeWarrior IDE includes assemblers that support several specific processors? Well, it does, and for you, codewarrior programmer this is one of its many cool tools to develop great code!   Today I found this manual that helps us out and explains the corresponding assembly-language syntax and IDE settings for these assemblers, in this case, thesyntax for assembly-language statements that the CodeWarrior assemblers use.   These explanations not only cover simple statements, they also include macros and directives!   You might be thinking, "dude, all the assemblers share the same basic assembly-language syntax!". I won't argue that, it's true, but instruction mnemonics and register names are different for each target processor.   To get the most from this manual, you should be familiar with assembly language and with your target processor, so I'd recommend you to start getting into this whole low-level programming style!   Unless otherwise stated, all the information in this manual applies to all the assemblers, enjoy!   CodeWarrior Development Studio for Microcontrollers V10.x ColdFire Assembler Reference Manual

How to log an issue in Case system instead CRM (Service request)?     After the merge of Freescale and NXP, technical support cases are answered in a different system. To submit your case into the new system, please follow below steps:    1) Go to http://www.nxp.com/support/sales-and-support:SUPPORTHOME.    2) On the bottom of the page under Submit New Issues, click Hardware & Software.    3) Register with your business email to access NXP technical online support.    4) A verification email will be sent to your account. Click the link embedded in that email to verify your access.    5) On the NXP online support page, select Contact Support from the top menu and click “submit a new case” to start the process.   Attached you will find a video explaining the process to follow.

This project is an example of using the DSC CodeWarrior linker to place code in a different area of memory.  In this case, the FlexNVM flash block is used. The example uses three different methods in the linker command file to force specific code to a different memory segment, see examples below.  For more information on the linker syntax, see the manual installed with CodeWarrior at \CW MCU v10.6.x\MCU\Help\PDF\MCU_DSC_Compiler.pdf     This project was developed for the TWR-56F8400 Tower development board, using CodeWarrior for Microcontrollers v10.6.6.  The project was created using Processor Expert, and blinks an LED using the PIT timer interrupt.     The linker command file is located at \Project_Settings\Linker_Files\FLASH_SDM.cmd.Here are the key changes to the project:     MEMORY {         # Added .p_FlexNVM memory segment         .p_FlexNVM(RWX) : ORIGIN = 0x00068000, LENGTH = 0x00004000 }     # Added .FlexNVM_Code memory section .FlexNVM_Code : {   TI1_c.obj (.text) # Place whole source file in this section   OBJECT (FPE_low_level_init, cpu_c.obj) # Place individual function in this section   * (FlexNVM_code.text) # Place from section defined in source code, see main.c     } > .p_FlexNVM     and in main.c: #pragma define_section FlexNVM_code "FlexNVM_code.text"  RX #pragma section FlexNVM_code begin void main(void) {   /* Write your code here */ } #pragma section FlexNVM_code end

This document shows a general way how to preserve memory range using target task in CW10.6.   I am using k64 freedom board and Segger J-link in my project as an example. K64 freedom board use MK64FN1M0 MCU which has 1 M size flash.  In my project I divide the flash into two areas in the link file as below:   /* Specify the memory areas */ MEMORY { m_interrupts       (rx) : ORIGIN = 0x00000000, LENGTH = 0x198 m_cfmprotrom       (rx) : ORIGIN = 0x00000400, LENGTH = 0x10 m_text             (rx) : ORIGIN = 0x00000800, LENGTH = 512K m_text2            (rx) : ORIGIN = 0x00080800, LENGTH = 512K - 0x800 m_data         (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 64K                  /* Lower SRAM */ m_data2        (rwx) : ORIGIN = 0x20000000, LENGTH = 192K                 /* Upper SRAM */ } m_text2 is the memory area that I am trying to keep it from being erased while downloading the application to m_text memory area. Here are the steps to do this using target task in CW10.6. Add a target task view by clicking Window -> Show View -> other from menu bar, then select Debug -> Target Tasks view in the popup window. From the Target Tasks view, select “Import” from the context menu. Then select the flash (.xml) file for your target device. In this case I need to select MK64FN1M0.xml file. After that you will see a “MK64FN1M0” task in the list. Double click the task name, you will see there are two actions (“Erase” and “Program and Verify”) in the “Flash Programmer Actions” view.   The default Erase action will mass erase all flash, so I remove this action by unchecking the “Erase” action. I can add erase action in “Program and Verify” action later. Double click the “Program and Verify” action. In the popup dialog, check “Erase sectors before program” option. Check “Restrict to Addresses in this Range” option, and then specify the address range you want to program. The data/code out of this range will be preserved (will not be erased or changed). Click “Update Program Action” button to update the settings of this action. Move to Debug configurations window by clicking Run -> Debug configurations from Menu bar. Select a debug configuration, in this case I select the run configuration for Segger J-Link. Select Download tab which is under Debugger tab. By default, Standard Download will be executed and all the flash will be erased. As I am going to execute target task in this case, so uncheck “Perform Standard Download” and then check “Execute Tasks”. Click “Add” button to add a task. In this case I add K64F1M0M12 task which I created in previous step in target task view. Click “Debug” button, the application will be downloaded to flash but preserved area which was not specified in restrict flash range will not be erased. You can check this from memory view.   With the above steps, you can preserve a specified flash range while downloading application. I am using Segger J-link in my project as an example and the steps also work for other tools like P&E Multilink and USB Tap.

This post will step by step show how to report a software  defect or problem to NXP support team. Please take a few minutes to read it. This will help us investigate the issue more efficiently and quickly. Basically we need prepare:      1. Your IDE version: - If you use classic version: Start the IDE and click on Help | About Freescale CodeWarrior. Click on Installed Products. Save all info displayed into a txt file. - If you use eclipse version: Start the IDE and click on Help | About CodeWarrior Development Studio or About Kinetis Design Studio. Save the version and build id. 2. Demo Code: - Create a demo project to show the problem.  Then send the entire sample code folder in zip format. - If the problem is in NXP SW package, for example SDK package, please provide the SW version or download link.      3. Mention how to reproduce the problem step by step with the demo code.      4. Error screenshot.     Steps of submitting the case: 1. Go to Sales and Support page, click on Hardware & Software for Submit new ticket: http://www.nxp.com/support/sales-and-support:SUPPORTHOME    2. Then click on “Add a new case”   3. Fill the New Case form. Here is an example:                                                         

This document describes the steps required for U-Boot debugging using the CodeWarrior IDE for low-end and high-end Power Architecture CPU, from NOR, NAND, SPI and SD card flash devices.

How to install and use eGit plug-in in CodeWarrior

This document describes two sets of options and pragmas that can be used with the CodeWarrior tools to produce optimal code for the HCS08 cores. One set optimizes the size of the code; another set optimizes the execution speed.   You can use the build tools options and pragmas described in this document for optimal performance, but the build tools settings must be set according to the application being developed. Don't worry, DebuggerGuys provide you with app notes like this to make the job quickly and easy! Optimal Performance on HCS08 Cores (For more information on the HCS08 Compiler, refer to CodeWarrior Development Studio for Microcontrollers V10.x HC(S)08 web page.)  

If you mix the great new TAP kit for CodeWarrior with the right Tip, the possibilities of debugging your devices become bigger and more powerful. In this occasion I will show you one more removable probe Tip: the CWH-CTP-BDM-YE, meant for ColdFire processors connects your ColdFire microprocessor/microcontroller target system’s BDM port to the CodeWarrior TAP base unit’s 30-pin target connector.   The compatibility of this Tip and the CodeWarrior TAP CWH-CTP-BASE-HE base unit empowers your creations and helps you lowering costs. Note this Tip is not included within the TAP kit. Check out the cool features:   Features Removable probe tip Low cost and economical to order several spares Allows base unit to work with several different target types   System Requirements ColdFire based target system with BDM header CodeWarrior TAP  

In many of user applications we use a CRC/checksum to verify that the code/flash on the target is not modified. For this, not only the code/data in flash counts, but as well all the unused gaps in the memory map. Instead to leave it up to the flasher/debugger (which usually erases it to 0xFF), I want to fill it with my pattern. For example 0xAA.   How to implement? There may be several ways,  but I think the easiest way is to modify linker file.   the linker file structures are different for different MCUs.   For example, CW for 8bit/16bit and Coldfire V1 uses PRM file;  while CW for kinetis Gnu compiler uses ld file. We will talk about each of the case separately. 1. CW for 8bit/16bit and Coldfire V1. 1.1 .  NO FILL command involved. We define a segment  in prm file MYCONST_ROM     =  READ_ONLY    0x0870 TO 0x08FF; Then allocate MYCONST  into it inside PLACEMENT. MYCONST    INTO  MYCONST_ROM; In C code, we only define  my_const_var(0xCCDD) at this range. #pragma CONST_SEG MYCONST const unsigned int my_const_var = 0xCCDD; #pragma CONST_SEG DEFAULT   After build, we will see only 0xCCDD in this area in generated s19 file: S1050870CCDDD9   1.2  use FILL command to fill unused area of MYCONST_ROM With FILL command we can fill unused area of a section.  Add “FILL 0xAA” : MYCONST_ROM       =  READ_ONLY 0x0870 TO 0x08FF FILL 0XAA;   Rebuild the project. we will see the rest of the field of MYCONST_ROM  is filled in  S19 file: S1230870CCDDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACF S1230890AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA04 S12308B0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4 S12308D0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4 S11308F0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA54 2. CW for kinetis GNU compiler: 2.1 . No fill() command involed. Define segment in MEMORY section: my_section    (rx) : ORIGIN = 0X00000800, LENGTH = 0x20   define output  SECTION: .myData : {     . = ALIGN(4);           KEEP(*(.myData))     . = ALIGN(4); }> my_section In C code, define const variable “my_const” (0xCCCCDDDD) const int my_const __attribute__((section(".myData"))) = 0xCCCCDDDD;   After build, we will see only 0xCCCCDDDD in this area in generated s19 file: S1070800DDDDCCCC9E 2.2 Use FILL(0xaa)  command to fill unused area of my_section with 0xAA. Here is the modified code in ld file, I highlight the code I add: .myData : {        . = ALIGN(4);                   KEEP(*(.myData))     . = ALIGN(4);     FILL(0xaa)     . = ORIGIN(my_section) + LENGTH(my_section) ;   }> my_section Rebuild the project. we will see the rest of the field of my_section is filled with 0xAA in  S19 file: S1130800DDDDCCCCAAAAAAAAAAAAAAAAAAAAAAAA9A S1130810AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA34

From your perspective, a CodeWarrior compiler is a single program. Internally, however, a CodeWarrior compiler has two parts: • The front-end, shared by all CodeWarrior compilers, translates human-readable source code into a platform-independent intermediate representation of the program being compiled • The back-end, customized to generate software for a target platform, converts the intermediate representation into object code containing data and native instructions for the target processor A CodeWarrior compiler coordinates its front-end and back-end to translate source code into object code in several steps: • Configure settings requested from the compiler to the CodeWarrior IDE or passed to the linker from the command-line • Translate human-readable source code into an intermediate representation • Optionally output symbolic debugging information • Optimize the intermediate representation • Convert the intermediate representation to native object code • Optimize the native object code • Output the native, optimized object code   A linker combines and arranges the object code in libraries and object code generated by compilers and assemblers into a single file or image, ready to execute on the target platform. The CodeWarrior linker builds an executable image in several steps: • Configure settings requested from the linker to the CodeWarrior IDE or passed to the linker from the command-line • Read settings from a linker control file • Read object code • Search for and ignore unused objects (“deadstripping”) • Build and output the executable file • Optionally output a map file   You might think these are real hard to cambine and put together to get something to work. If you do think that, it's easier than it looks! I found this reference manual at Freescale web page describing how to use the CodeWarrior compiler and linker tools to build software.   As a little introduction, let me explain that CodeWarrior build tools are programs that translate source code into object code then organize that object code to create a program that is ready to execute; CodeWarrior often run on a different platform than the programs they generate, meaning, not the host platform but the target platform. The linker now comes into our lives to pull our code off! Great isn't it? Come on, take a look at it! CodeWarrior build Tools reference

If you would like to migrate a project which is created by classic CW to eclipse CW, this file illustrates one of the ways to import PE beans to eclipse IDE manually. Test environment: 56F8037 in CW for DSC V8.3, CW for MCU V10.3, CW for MCU V10.4.

CodeWarrior Development Studio is a complete integrated Development Environment (IDE) that provides a highly visual and automated framework to accelerate the development of the most complex embedded applications.   I now present you a manual that describes the CodeWarrior IDE and debugger features that are common across all the CodeWarrior products, in which you can find many interesting things for people who's just starting to break down CodeWarrior great features.   Within the overview of this manual you will also find: • Release Notes • Documentation Structure • Manual Conventions • CodeWarrior IDE Overview   Download CodeWarrior and get to see the Reference Manual right away!  

The CodeWarrior  Development Studio provides a common interface for developing, debugging, and analyzing your applications. The project-oriented Workbench window provides numerous perspectives containing views, editors, and controls that appear in menus and tool bars. After creating a project, build your application, define a launch configuration, and then wait for data collection and data display.   The StarCore Linker generates an executable file by combining the object files and libraries specified in your project. Using a linker command file (LCF), you can instruct the linker to store portions of your executable in different areas of memory. The linker relocates and binds symbols to addresses according to the directives in your LCF.   The StarCore linker supports the SC100 and SC3000 architectures, and all Freescale devices based on these architectures, including the SC140 and SC3400 and its variants.   The highlights of the linking process are:      1. Build a map of available memory according to the .memory and .reserve directives defined in the linker command file.      2. Read the input object files and libraries. Combine like-named sections, build the global symbol table, and resolve undefined references.      3. Strip data never used; strip the code of functions never called.      4. Place segments in memory, according to .firstfit, .org, and .segment directives. Place all absolute sections before placing relocatable sections. If any sections are left over after processing the segment directives, place those remaining sections in their own segments on a first-fit basis.      5. Generate any LoadAddr_ symbols for overlays. Check each module’s symbol table to ensure that there are no more undefined references.      6. Process the relocations to resolve external reference values.      7. Write the executable output file.   This and many more features are now updated in the SC100 Linker User Guide, take a look at it and start developing with CodeWarrior!

Recently we helped a customer resolve a question related with “asm_enhance”command line option usage. It’s strange there is no documentation of this knowledge in CodeWarrior help manual. After many discussions with development team, it gets clear to me. So I wrote an article on this topic for sharing.   “ -asm_enhance” option is added in ColdWarrior10 /CodeWarrior11 “compiler setting”, “General”, “Other Flags”:   "-asm_enhance" command line option can be used for two distinct aspects: Enabling inline assembly data optimizations Enabling stack effect computation through inline assembly code. These two aspects were all gathered under the same option because they both are referring to enhanced inline assembly – i.e. inline assembly code that gets handled almost as C code). Thank for the great support from Bogdan Ditu . For more information on -asm_enhance, see attached document.

The CodeWarrior Development Studio provides a common interface for developing, debugging, and analyzing your applications. The project-oriented Workbench window provides numerous perspectives containing views, editors, and controls that appear in menus and tool bars. After creating a project, build your application, define a launch configuration, and then wait for data collection and data display.   CodeWarrior Profiling and Analysis Tools provide visibility into an application as it runs on the simulator and hardware. This visibility can help you understand how your application runs, as well as identify operational problems.   The CodeWarrior Profiling and Analysis tool set to develop software for Freescale StarCore DSP processors make it easy to collect the data. The following are the basic features of this tool:   • The basic setup can be done using the Trace and Profile tab in the Debug launch configuration • The advanced setup can be done using the Advanced Settings panel; complex configurations can be defined for the Debug and Profiling Unit (DPU), Virtual Trace buffer (VTB), and On Chip Emulator (OCE) • Data files can be shared between teams • Fast trace collection through High Speed Simultaneous Transfer (HSST) and SmartDSP HEAT (Host Exchange over Asynchronous Transfer) • Displays trace buffer content on Attach to Process • and many  m a n y   more! Get the updates of this guide here!

Detailed analysis report, done by Micetek (Freescale subcontractor that manufactures USB TAPs), following incidents where Rev F USB TAP/COP units were failing.

T1040 is new to all the customers. The ecosystem is still not mature in this moment in Jan'2014 The note is for someone who is using Codewarrior PA10.3.3 for T1040 platform board bring up or debugging on this moment. if you have problem to connect T1040 platform with Codewarrior, the document might help you.