You will be provided with the parts that make up the multimedia board development platform. You should have:
The following steps will guide you through assembling the StrongARM system. Before starting anything that involves touching electronic parts make sure you have on a grounding wrist-band so that static charges do not harm these sensitive boards. Once the system is assembled you will be asked to identify some of the key features of the development board.
System (also
labeled J4). Remove your SA-1100 development board from the box and
insert (CAREFULLY!) the board in the System slot.
Now that the board is setup, use the SA-1100 Multimedia Development Board with Companion SA-1101 Development Board User's Guide and board schematics to locate the following parts and hookups on the board.
What are the chips from Lattice Semiconductor used for on the development board?
The TA's may question you on this material during checkout, so be sure that you are familiar with the above material.
In this section you will learn how to connect your development board to the computer at your bench, load programs to the board, and debug programs running on your board using the built-in Angel firmware. Read section 12.1 and 13.1 of the ARM SDT User's Guide to find out more about debugging and Angel. Your TA's may ask you questions about Angel during check out.
For this part you will need to download some projects files which will be used with the ARM SDT, the development environment for the StrongARM board. Click here to download the necessary files. You will need to unzip these files into your home directory for this lab.
Start the ARM Project Manager by selecting it from the Start menu. It is located under Programs->ARM SDT v2.50->ARM Project Manager. Open lab1.apj from the area in which you extracted the files. You want to build the Debug version of the project, rather than the DebugRel or Release versions. Once you have done this, start the ARM Debugger by clicking on the Debug button in the toolbar.
The debugger has two modes, armulate and remote_a. The bottom right corner of the debugger window has a cell which indicates the mode that you are running in. For the purposes of all of our labs, you will want to be running in remote_a mode. Switch to this mode by selecting Configure Debugger... from the Options menu. A dialog box will appear in which you want to select your target debug environment to be remote_a. Click the Configure... button in the dialog to configure this mode. You will want to select a baud rate of 115200 and turn off the Heartbeat. Be sure that your board is on before clicking OK in the dialog boxes. If your board is off or in an unknown state, the debugger will crash. Resetting the board while the debugger is connected will also cause it to crash. Experiment with this if you wish... Killing the debugger with the task manager and resetting the board using the push switch at S2 should be sufficient to return your system and development board to a workable state.
Once you've returned to the main debugger window (by clicking OK twice in the dialogs that have been opened) you should see a message window pop up which shows the progress made at loading the program onto the development board. Once this has finished, you may press the Go button in the toolbar to start your program. You should see the debugger proceed to the start of the main function and stop. You may then press Go again to run the program. You should see the LEDs in block D1 blink and the phrase "Hello World!" appear in the Console Window.
If you wish to run the program again, reload it by clicking the appropriate button in the toolbar. You should again see the load progress message box appear again. You may execute the program as before or step through it. You should note that using the step buttons may be somewhat unreliable with functions that cause external state to change. For example, if you do step through the current project code, you will note that the LEDs do not turn on when you step over the instruction that does this. This is an unfortunate side effect of using the Angel firmware for debugging.
Be sure to go through the code for this project and understand what each of the lines do. What memory address is mapped to the block of LEDs? Can you make only one LED flash (instead of the entire block)?
Feel free get comfortable with the development environment by altering the program and running it via the debugger.
In this section you will learn two different methods of making the LEDs flash with a period of one second: the busy wait and timer interrupts. You may continue to use your project from the last part or you may download a fresh copy from the location noted in Part 2.
Code has been provided for you in the project that implements a simple busy wait. You should look through the sa1100.c file provided with the project and examine the Wait function. Be sure to understand how this function works as your TA will question you on it during check out.
Use this function to write a loop in which the wait function is called and an LED in alternately turned on and off with a period of two seconds.
Demonstrate this to your TA and be prepared to answer questions about how it works.
Code has been provided for you in the project that installs an interrupt handler function. Look at the Install_Handler routine in the sa1100.c file. You will also want to read section 9.5 of the ARM SDT User's Guide to learn how to write interrupt handlers using the C++ development environment.
Code has also been provided to setup and start a timer interrupt. Look at the initTimer function in sa1100.c. Be sure to understand this function, the Install_Handler function, and interrupts in general. The TAs will be questioning you about this during check out.
Using the functions provided, install an interrupt handler which alternately turns the LED on and off and setup the timer to trigger an interrupt every second.
Demonstrate this to your TA and be prepared to answer questions about how it works.