ECE 4510/5910 Lab Manual: Programming Microcontrollers with DBUG12 and NOICE - Prof. Janos, Lab Reports of Microcomputers

Download ECE 4510/5910 Lab Manual: Programming Microcontrollers with DBUG12 and NOICE - Prof. Janos and more Lab Reports Microcomputers in PDF only on Docsity!

ECE 4510/

Lab Reference Manual

Dustin Spicuzza, 4/15/

Table of Contents

1. Terminal Programs a. Default Settings b. ICC c. HyperTerminal d. Common Questions and Answers
2. Flash Burning a. Introduction b. Setting up your program c. Project Settings d. Programming using the DBUG12 bootloader e. Programming using NOICE and a BDM

f. Steps to Reprogram the DBUG12 into the Flash

g. Advanced Performance Tips

3. Background Debug Module (BDM) and NOICE a. Debugging b. Using NOICE and the PLL

4. Source Level Debugging (BDM Only)

a. ICC12 Project Settings b. NOICE Settings c. Debugging

5. Interrupt Service Routines

a. General Notes about Interrupts b. Interrupt Handlers in RAM using DBUG c. Interrupt Handlers in Flash

Introduction

This lab manual is intended to serve as a reference on a lot of different topics. If you want minimal trouble in this lab, you should read this manual all the way through at least twice before the labs. We have tried to make sure the best way to do things are shown in this manual, so you don’t have as much trouble using this hardware as we did at first. One thing you should remember is that there is almost always more than one way to do something.

Prerequisites

You should be using an Adapt9S12DP256 microcontroller board for these labs. I assume you are using ImageCraft ICC12 as your compiler and Integrated Development Environment (IDE). Optionally, you may be using a BDM pod using NOICE 8.4 or greater.

This lab reference manual is intended for educational use only. It was produced for the express purpose of providing documentation for the ECE 4510 labs at Western Michigan University. If you fry something by following the procedures in this manual, it’s your fault, not ours. Good luck.

Note: These instructions may vary depending on your version of windows. However, the ‘spirit’ of the instructions should remain consistent. HyperTerminal is a terminal program that is bundled with Windows. To use HyperTerminal, you need to first figure out where it is on your system. If you do not have the default windows setup, it’s possible that it may not even exist on your system.

For most people, HyperTerminal will be located in the start menu. Within the start menu, it should be located at this location:

Programs -> Accessories -> Communications

When you first start HyperTerminal, it may ask you about your modem settings. Enter in whatever you feel will work – it won’t affect the way HyperTerminal works. If you use dial-up internet, then it will affect that, so make sure the settings are correct.

At this point, it will ask you if you want to create a new connection. If you haven’t already created (and saved) a connection, then enter in a name for the new connection and hit “OK”.

Next, it will ask you where it needs to connect to. Change “Connect Using” to the serial port you have the BDM/Microcontroller connected to. In most cases, this will be COM1. Select OK.

HyperTerminal will ask you now about your connection settings. Use the appropriate settings for your BDM or Microcontroller. Typical settings are given above. After you do this, select “OK” and you’re done.

Changing the connection speed

If you need to change the connection speed/settings in HyperTerminal, you can either setup a new connection, or you can do this:

1. On the menu, Call -> Disconnect
2. Next, go to File -> Properties
3. In the dialog box, click on “Configure”
4. Change the settings, and click “OK”, and click “OK” again.
5. Select Call -> Call to reconnect to your device again.

Common Questions and Answers

Q: I can’t see anything in the terminal window, help! A: First, reset your microcontroller, or the serial device you are trying to connect to. If nothing shows up, try hitting the ENTER button a few times. Otherwise, change the baud rate in the terminal program until you find one that works. Use 112500 or 9600 first.

Q: It says something about not being able to access the port! A: Close NOICE, ICC12, HyperTerminal, and any other programs that may access the serial port. If that doesn’t work, reboot.

Q: I see gibberish! A: Check the baud rate settings on the terminal program. Make sure they match the settings on your controller/device. Try resetting your controller. If that doesn’t work, set your baud rate to 9600 or 112500

• since these are the two rates we recommend, chances are that it will be set to one of them. This is especially true for the BDM. Generally, the BDM keeps the baud rate setting from the previous user. DBUG12 does not, and resets itself upon powering the unit down.

2. Flash Programming

Introduction

In a production environment, finished programs are programmed to the flash memory of a microcontroller – or they are permanently embedded into a ROM memory on the controller. There are a number of advantages and disadvantages of burning your program into the flash memory.

There are two ways to download your program into the flash. One method requires NOICE and a BDM, and the other method requires that DBUG12 be present on your microcontroller.

For information on terminal programs and how to use them, please refer to section one. Of course, you already read that, right?

When you program your program to the flash memory, then your program is given total control of the Microcontroller when it starts up. So, if you make a program to blink a LED every second, and burn it to flash – then when you turn the power off and turn it back on, then your program will immediately execute and blink that LED. Or, whatever you told the program to do.

Because a program in flash memory is supposed to be executed automatically when the microcontroller powers on, we need to ensure that the controller knows where your program is – otherwise, it’s not going to be able to find it.

Note: If you are using interrupt service routines, then see the section “Interrupt Service Routines” for additional information to make sure those work properly.

Setting up your program

First, you should COPY the “vectors_dp256.c” file into your project directory. The file should be located at c:\icc\example.s12, or possibly c:\icc\example.

You need to add the file to your project in ICC12. In the ICC12 IDE, you can do this by pressing SHIFT-F11. Alternatively, you can use the menu and go to Project -> Add Files_._ Of course, there are other ways to do this.

If you are using NOICE and a BDM

You should ensure that the #pragma directive before the interrupt vector array looks like this:

#pragma abs_address:0xFF

This is should already be present by default in the vectors_dp256.c file. 0xFF80 is the address of the real interrupt vector table.

If you are using the DBUG12 bootloader

You should change the #pragma directive in the vectors file to look like this:

#pragma abs_address:0xEE

If you are not sure of the operation of your program, or if you have equipment attached to the controller that could pose a risk to anyone, you should disconnect any external hardware (ie, breadboards, etc) from the microcontroller before attempting this.

1. Open Hyper Terminal. The Settings should be the following:
2. Set BAUD = 9600, 8, N, 1 Xon/Xoff = enabled
3. Move jumper JB3 to the position PAD00: PAD01 = 1:
4. Power up the Board.

D-Bug12 Boot Loader v1.0. 1a. Erase Flash 2b. Program Flash 3c. Set Baud Rate 4d. Erase EEPROM

5. Choose “a” to erase
6. Choose “b” to program

Now you must send the program to the microcontroller. In your work directory, there should be two files with an s19 extension. One should be [programname].s19, and the other one should be [programname]cvt.s19. The file that you need to send to the DBUG bootloader is the [programname]cvt.s19 file. If you send the wrong file, it will not work properly! Do NOT send any .dbg files to the bootloader – these can only be used with NOICE.

In ICC12:

In the terminal window, click the “Browse” button to browse for the program you want to download to the controller.

In HyperTerminal:

On the top menu, go to Transfer -> Send Text File. On the bottom of the file dialog, change the file type to ‘All Files (.)’. Browse to your work directory, and select the proper .s19 file.

The controller may output a lot of * characters while it is programming. Once you see the prompt again, then the flash programming is complete. You should then disconnect the board from power, and move jumper three back to its original position: PAD00: PAD01 = 0:0. Reconnect the power to the board, and press the reset button.

Programming Using NOICE and a BDM

For this method, you need to remove power from the microcontroller board. Next, connect the BDM to the BDM connector on the microcontroller board. Finally, connect the serial cable to the serial port on the BDM.

If you are not sure of the operation of your program, or if you have equipment attached to the controller that could pose a risk to anyone, you should disconnect any external hardware (ie, breadboards, etc) from the microcontroller before attempting this.

Next, you should open NOICE and check the following settings so it is ready to program the flash. If you get an error saying that NOICE cannot synchronize with the BDM, then you will definitely need to check these settings.

1. On the menu, go to Options -> Target Communications
2. Check these settings:

Interface: Technological Arts microBDM12SX (or your BDM) Port: The serial port your BDM is connected to, usually COM Baud rate: 9600 is default, some pods may be set to 115200 Bus frequency: 8Mhz (If you enable the PLL in your code, do not select a different speed until NOICE prompts you) Target Chip/Environment: MC9S12x256 Flash Use 24-bit hardware breakpoints: This should be checked Use Flash/EEPROM Burner: This should be checked

Now you must send the program to the microcontroller.

If you are using source-level debugging

1. On the top menu, select File -> Load
2. In the dialog box, change “Files of Type” to “ImageCraft DBG Format”
3. Browse to your work directory, and select the dbg file that was compiled. Click “Open”.

Otherwise

1. On the top menu, select File -> Load
2. In the dialog box, change “Files of Type” to “Hex Files”
3. Browse to your work directory, and select the proper file Note: In your work directory, there may be two files with an s extension. One should be [programName].s19, and the other one should be [programName]cvt.s19. The file that you need to load with NOICE is the [programName].s19 file. If you send the wrong file, it will not work properly! Do NOT send the other file, as it will load improperly.

After you complete these steps, NOICE will show a progress bar until it has finished downloading your program to flash memory. NOICE will then jump to the startup location of the controller. If DBUG12 is not resident on the controller, it should jump to location 4000, which is where ICC12 places your startup code. If you are using source level debugging, and you have “Run until Main” enabled, NOICE will automatically jump to the first instruction in your main() function.

Steps to Reprogram the DBUG12 into the Flash

Actually, programming DBUG12 back onto the microcontroller is exactly the same as any other program. DBUG12 is distributed in an .s19 file (which you can obtain from the class website), and when you select a file to load onto the controller – use that file instead of your program.

NOTE: The DBUG12 file does not end with *cvt.s19 – it is whatever you named it after downloading it from the website.

Advanced Performance Tips

3. Background Debug Module (BDM) and NOICE

The Background Debug Module (BDM) is a very powerful and useful tool. The BDM allows you to take complete control of your hardware, without interfering with the operation of it.

Debugging

The developer of NOICE has produced some decent tutorials and help files for NOICE. To save time with creating this manual, I refer you to those resources. Refer to http://www.noicedebugger.com/tour/index.html for a comprehensive and user-friendly tour about using NOICE. The NOICE help file (located at http://www.noicedebugger.com/help/help.htm) also contains helpful information about how to use NOICE.

Using NOICE and the PLL

From the NOICE website:

“ Unfortunately, some types of HCS12 (including the A, Dx, and H) contain a bug, described in Motorola/Freescale errata, that causes BDM to stop working when the PLL is enabled and BDM is operating in the default mode .”

Basically, this means that for labs asking you to set the system clock speed to something different using the PLL, it may be difficult or impossible to get NOICE to work correctly with the project. This may change in the future, however.

Please refer to http://www.noicedebugger.com/help/bdm12.htm#PLL for more information.

4. Source Level Debugging (BDM Only)

“Source level debugging” means that you can run a program, and debug while looking at the source code of the program. So instead of looking at lots of assembly language code and registers and pointers to absolute locations, you can see the C code and use the variable names and symbols while debugging! Additionally, NOICE has a lot of other useful debugging things in it, which you should learn how to use if you want to debug your programs effectively.

Most of the time (unless it crashes because you missed a semicolon or comma somewhere ☺) ICC12 compiles C and assembly code into .s19 files that can be downloaded onto your microcontroller. However, this downloads the file to the controller in binary, which (most) humans don’t generally read very well.

ICC12 has a debug format available, which burns the same binary to the controller, except it preserves references to the source code. This allows a program such NOICE to interpret the program in terms of your C code (including comments) – very similar to the way you can debug C++/VB/C#/etc programs in Visual Studio! If you’ve never programmed using Visual studio… well, I’m sorry.

I will assume you already have a project ready to be downloaded/flashed onto the microcontroller. Here are a number of settings you need to change to make this work correctly:

ICC12 Project Settings

Note: These settings must be changed for each project that you create. It may or may not keep the settings for the next project… hard to say.

In the ICC12 IDE:

1. In the menu, go to Project -> Options
2. In the dialog box, select the “Compiler” tab

3) Change “Output Format” to “S19 with ASM/Source Level Debugging”

When you compile your project, then ICC12 will generate a file in the work directory with an extension of .dbg. This is the file you will want to load using NOICE onto the microcontroller.

If you are burning your program to flash

NOICE must use the built-in hardware provided by Motorola to use breakpoints. Source-level debugging is practically useless without breakpoints. To tell NOICE to do this:

1. Select Options -> Target Communications
2. In the dialog box that pops up, ensure that “Use 24-bit Hardware breakpoints at 28” is checked

IMPORTANT! Because of hardware limitations, you can only set two breakpoints in flash memory. You can remove previous breakpoints in NOICE by going to Breakpoint->List/Delete, or pressing F6. Alternatively, you can right-click on the code where the breakpoint is and select “remove breakpoint”.

Other NOICE Settings

5. Interrupt Service Routines

Interrupt service routines (also called Interrupt Handlers) are a central part of many of our lab assignments, and you should know how to implement them properly in C and Assembly language.

General Notes about Interrupts

Each C function used as an interrupt handler should be preceded by a directive such as this:

#pragma interrupt_handler myISR

This will tell ICC12 to end your function with an ‘rti’ instruction, so that it can return from interrupt instead of returning from a subroutine as usual.

To actually have your routine called when an interrupt occurs, refer to the following sections. Just declaring an interrupt handler is NOT sufficient to make this happen.

For more specific notes, please refer to the instructors notes as posted on the course website.

Interrupt Handlers in RAM using DBUG

FIXME!

Interrupt Handlers in Flash

First, you should COPY the “vectors_dp256.c” file into your project directory. The file should be located at c:\icc\example.s12, or possibly c:\icc\example.

You need to add the file to your project in ICC12. In the ICC12 IDE, you can do this by pressing SHIFT-F11. Alternatively, you can use the menu and go to Project -> Add Files_._ Of course, there are other ways to do this.

To ensure that your handler gets called when the interrupt occurs, you must put a reference to your function in the interrupt table. In vectors_dp256.c, the vector table is implemented using an array of function pointers.

1. Add an external reference to the ISR in the vector_dp256.c file

by using the following syntax:

extern void myISR();

2. Change the appropriate DUMMY_ENTRY to your ISR name. Each

DUMMY_ENTRY has a comment next to it that describes which interrupt it is associated with. Ensure that you REPLACE the DUMMY_ENTRY, and that you do NOT add an extra entry to the table. If you do this, then unfortunately ICC12 is too stupid to realize that you have done this. The processor will behave strangely if you mess this up. So don’t do it.

You should repeat this for each ISR that you need to implement. You will also need to ensure that the interrupt vector table is located at the proper location for your setup.

If you are using NOICE and a BDM to program the flash

You should ensure that the #pragma directive before the interrupt vector array looks like this:

#pragma abs_address:0xFF

This is should already be present by default in the vectors_dp256.c file. 0xFF80 is the address of the real interrupt vector table.

If you are using the DBUG12 bootloader to program the flash

You should change the #pragma directive in the vectors file to look like this:

#pragma abs_address:0xEE

0xEE80 is the address of the ‘fake’ interrupt table that is provided by DBUG-12. The reason for this is to allow DBUG12 to run in the background using the real interrupt table – but, it will call your interrupts using this fake table.