11/22/2000

CPSC483 - Group 4

Infant Medical Device
Bi-weekly Report

November 8, 2000 – November 22, 2000

3

CPSC 483 – Fall 2000 (Group 4) Biweekly Report

Jack Followay, Jr.

Bret Hodge

David Schmidt

Thomas Supercinski

Kerey Tassin

Infant Medical Device

Fourth Two-week Report

Progress Update

Followay has been working on the IMD application. Using the basic model determined previously, he has been implementing the methods for the basic objects. (See previous biweekly report 3 for more details). The application is still full of “loose ends” while the serial API for the LCD, keypad, and sensors are being developed.

Schmidt has complete the report on using VxWorks and the Tornado environment with the PowerPC-403GCX Evaluation board. (See attached). He has been working with Supercinski to troubleshoot the network problems we have been having with the evaluation board. The major problem was traced to a bad Ethernet card.

Hodge has completed his design for the LCD display. With the corresponding completion of VxWorks on the PowerPC, we can now test the circuit. Through some initial testing with Supercinski and Hodge have found that there is a framing problem. They have not been able to determine if it is because of the circuit or because of the serial transmission from the PowerPC.

Supercinski has been working on the VxWorks serial drivers and interfaces as well as developing an API for the LCD and keypad. He has successfully created a test routine and has output via the serial port. He has been working with Hodge to interface with the LCD/keypad hardware. Supercinski also assisted Schmidt in troubleshooting, identifying, and fixing the Ethernet connectivity problems with the evaluation board.

Tassin has been reviewing the ReadyMedic group report from last semester regarding how they set up the serial port in LabVIEW. She has also worked to create a heart beat signal in LabVIEW that she can pass through the serial port. At this stage, she has been able to use the arbitrary wave function to create a signal that looks like a heart beat, but she is having difficulty in relating the signal to time.

Two-week schedule

·  Followay will complete the IMD Application for VxWorks and develop a prototype for the hospital application.

·  Schmidt will be working with Followay in developing the hospital application prototype.

·  Supercinski will continue work on the serial communications and LCD API development. Additionally, he will help write the network routines necessary for IMD internet connectivity.

·  Hodge will finish the keypad circuitry and get the LCD functioning properly.

·  Tassin will continue to work on test signals. Once she has overcome the current difficulties, she will create waveforms for both normal and alarm conditions. When done, she will connect the signals to the IMD through the serial port.

·  The entire team will be wrapping items up and working towards the final presentation and demonstration.

Updated Project Timeline:

3

CPSC 483 – Fall 2000 (Group 4)

VxWorks and the IBM PowerPC 403GCX Evaluation Board

Introduction

This manual is intended to aid students of CPSC 483 who wish to use the VxWorks real-time operating system with the IBM PowerPC 403 GCX board. It is a supplement to the documentation provided with the PPC board and the Tornado software package, and should not replace these materials. Before reading this manual, it is important to be familiar with the 403 board, RISC Watch, and the basic development environment found in Tornado. This information can be found in [1] and [3].

The documentation included with the Tornado development package is centered around a professional embedded systems environment. It makes assumptions about the user's skill level, the resources available, and the intended purpose of VxWorks. However, the 483 lab is not a professional lab, and the students have little or no experience with embedded systems. This means that students need to work around the framework of information provided by WindRiver and IBM and use it to adapt to their own unique environment. Fortunately, several students have already discovered many of the adjustments necessary to run a VxWorks image on the 403 board. The "tips and tricks" documented within this manual will save a group weeks (perhaps months) of guesswork and frustration.

Overview

VxWorks is a real-time OS that conforms to several POSIX 1003.1b standards [2]. This means the OS implements several of the same features that a Unix (or Linux) machine does, like pipes, sockets, and I/O. The Tornado development system (explained below) allows a VxWorks image to be custom configured with different features. For example, a user may choose to include or exclude network capabilities, or, as is the case for the PPC board, exclude disk I/O.

The Tornado development system is intended to provide all the support needed for developing VxWorks systems and applications. The user can include their own code and include different OS features, and Tornado comes with GNU compiler tools and uses them for all its compilation and linking. Basically, a project contains all the information and files for a particular board, or target, and Tornado allows the user to change different aspects of the OS to suit the needs of the target.

VxWorks and Tornado can include board support packages (BSPs) that contain board-specific code. This allows a VxWorks image to be custom configured for the particular system. The Tornado systems in the 483 lab have the 403 BSP installed. It contains all the hardware-specific information for the 403 series boards.

There are several different methods for compiling and downloading a VxWorks image to the PPC board. Tornado will build a ROM-resident image, a RAM-based image, or a compressed ROM image. Once the image is built, it is downloaded to the board and executed. To assist with application development and debugging, VxWorks and Tornado communicate through a target server and target agent. The target server runs on the host machine and the target agent runs on the target. This is where much of Tornado features are implemented. For instance, the WindSh shell can run inside Tornado, allowing users to execute commands on the target OS from the host environment.

With the introduction of RAM/ROM images, target agents and servers, and OS features, a whole wealth of issues surrounding the PPC 403GCX arise. Each of these (and their solution) will be discussed separately. If you have not read the Tornado getting started guide, it is a good idea to do so before reading the following information. It is important to be as familiar with Tornado as possible before diving into these issues.

The Proper Configuration

The development environment for the 483 lab should consist of a host PC, the target board, and RISC Watch. The target board should communicate with the host through a serial cable. RISC Watch should connect to the target board and the host PC, and all three should be connected through a 10base2 Ethernet connection. Consult the diagram below.

Loading Images to the PPC Board

For some reason, the Tornado documentation only discusses downloading images from one viewpoint. It assumes that the developer already has a working image on the board that is capable of communicating with Tornado (through the agent) and downloading a new image. Since the PPC board contains only a ROM monitor, there is obviously no way to download a new image from Tornado. RISC Watch can be used to load a new image onto the board and execute it. There are a few simple steps that must be followed.

  1. Open RISC Watch and make sure it connects to the board.
  2. Connect the HyperTerminal to the board and establish communication with the ROM monitor. From the ROM monitor menu, choose "0" to exit (make sure the debugger is toggled on).
  3. When the monitor prints "Waiting for debug command…Press any key to exit", type "stop" in the RISC Watch command menu. This halts execution of the processor.
  4. Type "srchpath set <path>" where <path> is the fully qualified path to your VxWorks image.
  5. Execute any command files necessary (see "RAM and ROM Images" below).
  6. Type "load file vxworks". This will begin downloading the image to the board and linking the instruction register to 0x10000 (thanks to the BSP, the VxWorks image is linked to begin executing at 0x10000, so this works perfectly).
  7. When the image is finished, type "run" and switch to the HyperTerminal. The VxWorks OS should be running.

Once the OS is running, Tornado can connect to the target agent (which is now running as a process on VxWorks) through its target server. For information on how to configure the target server, consult [3] or [4].

RAM and ROM Images

The Power PC boards in the 483 lab are all equipped with 128 KB Flash ROM's, but a ROM-based VxWorks image requires 512 KB at the very least. As soon as the larger ROM chips become available (as of 11/00 none were in stock), one will be purchased to allow VxWorks ROM development. However, until that happens, development is limited to RAM images for the PPC boards. This introduces another issue with the 403 board. The VxWorks operating system is designed to be loaded by a ROM-based program that provides boot parameters to the OS. Among these parameters are the network device to use, the IP address of the target, the IP of the host, etc. For example, the following boot parameter string specifies the "nicEvb" device as the network interface (this is the chip on the 403 board), a target IP of 7.1.1.4, a host IP of 7.1.1.5, and lists the directory for the VxWorks image:

nicEvb(0,0)host:/vw/config/evb403/vxWorks h=7.1.1.5 e=7.1.1.4 u=target

The default boot line is defined in “config.h”. A further explanation of these parameters can be found in [2].

Since we are loading the RAM image without the help of a VxWorks ROM program, we must supply this boot parameter string manually. The source code for VxWorks indicates that this string is stored at 0x4200 in memory. To properly write the string to this location, it must be converted to ASCII and written to RAM using the "write" command in RISC watch. Since this command only writes four bytes at a time, it is wise to create a batch file with the necessary number of commands (see [1] for more details). Here is an example of the commands used:

write dmem 0x4200 0x6e696345 [nicE]
write dmem 0x4204 0x76622830 [vb(0]
write dmem 0x4208 0x2c302968 [,0)h]
write dmem 0x420c 0x6f73743a [ost:]
write dmem 0x4210 0x643a2f69 [d:/I]
write dmem 0x4214 0x6d642d64 [md-d]
write dmem 0x4218 0x65762f64 [ev/d]
write dmem 0x421c 0x65666175 [efau]
…etc…

Obviously, it takes time to write the command file, but it's a nice review of ASCII conversion.

Parting Thoughts

Hopefully, this provides a little more insight into VxWorks and Tornado. The best way to become familiar with everything is to take a week and read as much as possible. The documents referenced in this manual are the most helpful out of the WindRiver library. The tips outlined here will make more sense as you learn more about Tornado.

References

[1]  PowerPC Embedded Processors, Cores, and Tools. Product Documentation CD. IBM, 2000.

[2]  VxWorks Programmer's Guide. WindRiver Systems.

[3]  Tornado 2.0 Getting Started Guide. WindRiver Systems.

[4]  Tornado 2.0 User's Guide (Windows Version). WindRiver Systems.

A-2