Introduction to CodeWarrior™ –

Simulating the Microcontroller in

Assembly Language
Applications / Solutions / Products

Overview
A laboratory experience is vital for us to be able to start programming the microcontroller and to be
able to really understand how it works and to apply it in embedded system designs. This module
shows the student how to enter an assembly language program in the CodeWarrior® integrated
development environment and then to simulate its execution using the True-Time
simulator/debugger.

Learning Objectives
In this module we introduce you to the CodeWarrior® programming environment. We will see how to
start the system and enter a program to be run with the debugger. In the next module we will give
you a program and you will start to learn to use the HCS12 instruction set by modifying if to change
how it operates.

Success Criteria
At the end of this module you will be able to assemble a program and to run and debug it with the
CodeWarrior simulator/debugger.

Prerequisites
You must know about the HCS12 instruction set and the memory addressing modes available. You
do not have to know the instruction set in detail. The following lab modules will help you learn that.

More Resources and Further Information

Cady, Fredrick M., Software and Hardware Engineering: Assembly and C Programming for the
Freescale HCS12 Microcontroller, 2nd edition. (New York: Oxford University Press, Inc., 2008).
Chapter 5 An Assembler Program, Chapter 6 The Linker, Chapter 7 The HCS12 Instruction Set.

Smart Linker, Metrowerks Corporation, Austin, TX, 2003.

Debug (DBG) Module V1 Block User Guide, S12DBGV1/D, Freescale Semiconductor, 2003.

MC9S12C128 Data Sheet: Covers MC9S12C Family and MC9S12GC Family, Freescale
Semiconductor, Austin, Texas, 2005.

Montañez, E. and Ruggles, S., MCUSLK_CSM12C32 - Getting Started with the Microcontroller
Student Learning Kit (MCUSLK), Freescale Semiconductor, Austin, Texas, 2005.

Sibigtroth, J. M., CPU12RM/AD rev. 3 – CPU12 Reference Manual, Freescale Semiconductor,

Austin, Texas, 2002.

Williams, J., AN2548SW1 – CodeWarrior Project Software files for AN2548/D, Freescale
Semiconductor, Austin, Texas, 2003.

Debugger HCS12 Onchip DBG Module User Interface, Metrowerks, 2003.

Using the CodeWarrior® Simulator

1. Launch the CodeWarrior IDE.

a. From the Windows desktop, click Start > Programs > Freescale CodeWarrior > CW for
HC12 Vx.x > CodeWarrior IDE.

2. In the Startup window select Create New Project.

3. In the HC(S)12(X) Microcontrollers New Project Wizard window:

Page 1: Select MC9S12C32 (or your derivative) as the derivative you want to use.

Check Full Chip Simulation and click Next.

Page 2: Check Relocatable Assembly. Uncheck C and C++.

Enter a Project Name that makes sense to you (like lab_x).

Enter a Location for the project. This should be on a drive or in a directory where you
want to keep your HCS12 projects.

Page 3: Click Next (no files will be added by now).

Page 4: Check None Rapid Application Development Options. Click Next.

Click Finish.

In the Project Manager Window

4. Verify that Full Chip Simulation is selected for debugging (This does not use the hardware for
debugging. If you want to actually use the HCS12 hardware, choose P&E Multilink Cyclone
Pro by clicking the pull down arrow and selecting P&E Multilink Cyclone Pro.)

5. Create listing files by opening the Simulator Settings panel by clicking the icon shown above.

a. Click on + next to Target in the Target Settings.

b. Highlight Assembler for HC12 and in that panel click on Options.

(i) Check Object File Format.

(ii) Generate a listing file.

(iii) Click OK.

c. Click OK.

6. Open the Sources folder (click on the + if it is not open).

7. Double click on main.asm

8. Substitute all the code below the following statement:

XREF __SEG_END_SSTACK

with the following code:

; data/variable section
CONSTANTS: SECTION
ConstData: DC.B $0a,$0b,$11,10
VARIABLES: SECTION
VarData: DS.B 2 ; Two bytes of storage

; code section
MyCode: SECTION
main:
_Startup:
Entry:

; DO
main_loop:
nop ; A "no operation" operation
ldx #ConstData ; Initialize X with an address
ldab #$02 ; Initialize a counter with data
; Load and store data in a loop
loop:
ldaa 0,x ; Get the data
staa VarData ; Store it in RAM
ldaa 2,x ; Get another byte
staa VarData+1 ; Store it
inx ; Increment the pointer
decb ; Decrement the counter
bne loop ; Loop until B = 0
nop
; Forever
bra main_loop
;**************************************************************

9. Save it to whatever name you want: File > Save As. (Make sure you give it an .asm filename, or
you can just use the main.asm file if you want.)

10. Check to make sure debugging information is going to be generated.

a. In the Project Manager Files window, check to see that there is a • in the rightmost column
under the bug icon.

11. Assemble the file to check for errors:

a. Click on Project > Compile.

b. Correct any errors.

12. Have a look at your list file.

a. File > Open and position to the bin folder in your project and open the .lst file.

1.
1. How many bytes are in the program and constant data?

27 Bytes in total, 23 in program and 4 bytes in constant data.

2. You cannot tell from this listing in what memory locations the VarData variable bytes will be
located. Why not?

Because it’s not yet assigned, since we select a relocatable memory mode.
3. What op code (in hexadecimal) is generated for a nop instruction?

A7

4. Do any of the labels in the program generate any code bytes?

No, because they are just labels for reference.

1.
1. Why does the instruction ldx ConstData assemble to CExx xx?

Because the code will be randomly located, since we select a relocatable memory mode.

2. What are the four bytes (in hexadecimal) assembled as constant data bytes by the assembler
directive DC.B?

0A0B 110A

3. In the ConstData why does DC.B produce different data bytes for $10 and 10?

Because the ‘$’ symbol implies that the data is in hexadecimal, and without the ‘$’symbol is a
data in decimal.

In future lab exercises you may wish to add other source files to your project. Here is how you do
that.

13. Add other source files to the relocatable files in the project:

a. Click on the Add New Text File icon:

b. Edit the file.

c. File > Save As (use .asm as the extension for assembler files).

d. Add it to the project: Project > Add *.asm to the project. In Add Files check both Full Chip
Simulation and P&E Multilink Cyclone Pro.

e. Assemble/Compile it: Project > Compile.

14. View the linker parameter file.

a. Click the + next to Prm and double click the Full_Chip_Simulation_linker.prm file to open
it in the editor.

2.

The linker parameter file allows us to locate the various parts of the program in the proper sort of
memory. For example, all code and constant data must be in ROM and variable data and the stack in
RAM.

1. Look at the SEGMENTS portion.

a. What memory locations are used for RAM?

0x0800 to 0x0FFF.z

b. Where memory locations are used for ROM?

0x4000 to 0x7FFF and 0xC000 to 0xFEFF.

2. Look at the PLACEMENT portion. A variety of default placement options are included. We are
interested in where the DEFAULT_ROM (code and constant data SECTIONS in our assembly
program) and the DEFAULT_RAM (variable data SECTION) will be located.

a. In what memory locations will the code and constants be located?

In ROM_C000

b. In what memory locations will the variable data be located?

In RAM_0800

2.

1. What change would you make to the linker parameter file if the target hardware had RAM in
memory locations $1000 - $1FFF (0x1000 – 0x1FFF)?

In the segment portion:

/* RAM */

RAM = READ_WRITE 0x1000 TO 0x1FFF;

2. What change would you make to the linker parameter file if you wanted to locate the code and
constants in memory starting at $4000 (0x4000)?

In the placement portion:

DEFAULT_ROM,

COPY /* copy down information: how to initialize variables */

/* in case you want to use ROM_4000 here as well, make sure

that all files (incl. library files) are compiled with the

option: -OnB=b */

INTO ROM_4000/*, ROM_C000*/;

15. Make the project.

a. Project > Make or click on the icon

b. Correct any linking errors.

16. Inspect the Linker Map file.

 a. Click the + on Linker Map and open Full_Chip_Simulation.map.

3.
STARTUP SECTION

1. What is the starting address of the program?

0xC000
SECTION-ALLOCATION SECTION

2. What number base is used to tell you the size of the various sections?

Decimal

3. How many bytes of ROM are used by this program?

23

4. How many bytes of RAM are used by this program?

253
OBJECT-ALLOCATION SECTION

5. What is the memory address of the label main_loop?

C000
6. What is the memory address of the label loop?

C006
7. In what memory locations would you find VarData?

8. 900

17. Run the program without the PBMCUSLK using the CodeWarrior True-Time Simulator.

a. Make sure Full_Chip_Simulation is shown in the Project Manager pull down window as
shown in step 4 above.

b. Launch the True-Time Simulator by Project > Debug, F5, or clicking on the icon

If a loader warning appears click OK.

c. If Simulator is not the debug target, click on Component > Set Target and chose
Simulator Target Interface and click OK.

d. If your program has not been loaded, or you want to reload it, click Simulator > Load and
load bin\simulator.abs.

e. You can use all the features of the simulator on the code.

4.

After the simulator has been launched, have a look at the display:

1. The Source window shows your source program.

2. The Assembly window shows the program as it looks in memory. Right Click in the Assembly
window and check Display Code to make your display show the code in the memory locations
 $C000 - $C01A. Right Click again and check Display Symbolic to show symbolic instead of
decimal addresses.

3. The Registers window shows the current status/contents of all registers.

4. The Data window will show the current value of constant and variable data in your program.
Click on the +ConstData to show the four constant data bytes. Right Click on ConstData and
select FORMAT ALL Hex. Click on the +VarData to show the two variable bytes.

5. The Procedure window shows what procedure you are currently in and the Command window
allows you to enter simulator/debugger commands.

6. The Memory window allows the display of memory contents. Right Click in the Memory
window and select Address . . . and in the Display Address window enter C000.

a. What is displayed here?

A7 CE C0 17 C6 02 A6 00 ……..

7. Try resizing any of the windows.

Run the Program in the Simulator

5.

1. In the Source window position the cursor pointer over the nop instruction and Right Click and
select Set Breakpoint.

2. Click the Green Start/Continue Arrow or click Run > Start/Continue. The program should run
to your breakpoint and stop. (Note: A breakpoint stops the program before it executes that
statement.)

3. Now, step through your program one assembly language statement at a time by clicking on the
single-step button or pressing F11 until
you reach the nop instruction at the
beginning of the program again. (We will
see what the LDS instruction is all about later.)

4. At each step inspect the Register window to see what is happening to the registers. Try to
predict what will happen at each step BEFORE you click on the step button.

3.

1. Under what circumstances does it make sense to run and debug your programs in the
simulator?

When the code is not running as we wish, step by step you will see at what point the program is
failing or doing anything that’s not wished.

2. When would you want to run and debug your programs using the hardware debugger?

3. When the hardware is not responding or is doing another thing different as planned or even
check logic and electric status.

1.

1. Double click on each of the register boxes in the Register window and enter a value of zero for
each register. You won't be able to change the CCR.

2. Press the Reset Target button (or type control-R) to return the program to the initial reset state.

3. Single-step through the program and complete a table showing the result of each instruction.
 The CCR (Condition Code Register) bits NZVC are shown bold when the bit is set.

Instruction D A B IX IY PC SP NZVC
Reset state 0000 00 00 0000 0000 C000 FFFE 0000
lds
#__SEG_END_SSTACK
nop A00 A 0 C019 0 C000 FFFE SXIZ
ldx #ConstData A00 A 0 C019 0 C001 FFFE SXIZ
ldab #$02 A00 A 0 C017 0 C004 FFFE SXIN
ldaa 0,x A02 A 2 C017 0 C006 FFFE SXI
staa VarData A02 A 2 C017 0 C008 FFFE SXI
ldaa 2,x A02 A 2 C017 0 C00B FFFE SXI
staa VarData+1 1102 11 2 C017 0 C00D FFFE SXI
inx 1102 11 2 C017 0 C010 FFFE SXI
decb 1102 11 2 C018 0 C011 FFFE SXI
bne loop 1101 11 1 C018 0 C012 FFFE SXI
ldaa 0,x 1101 11 1 C018 0 C006 FFFE SXI
staa VarData B01 B 1 C018 0 C008 FFFE SXI
ldaa 2,x B01 B 1 C018 0 C00B FFFE SXI
staa VarData+1 A01 A 1 C018 0 C00D FFFE SXI
inx A01 A 1 C018 0 C010 FFFE SXI
decb A01 A 1 C019 0 C011 FFFE SXI
bne loop A00 A 0 C019 0 C012 FFFE SXIZ
nop A00 A 0 C019 0 C014 FFFE SXIZ
bra main_loop A00 A 0 C019 0 C015 FFFE SXIZ

Communication
1. As you step through your program explain to your lab instructor what you see on the screen. In
particular, explain what is happening to each register and to the condition code register as you
step through your program. What questions do you have?

Reflection on Learning
1. For the program entered and stepped through, list any instructions that you are not sure how
they work. Compare your list with your lab partner's and if you understand something that he or
she does not, explain it so that they understand. If there are still instructions you are not sure of,
ask your laboratory instructor to explain them to you.