Tool provides code for testing prototype
Hardware engineers have a hard time writing test code because they are not, after all, software engineers. Even though they may know their hardware components inside out, they must learn how to operate the CPU and use software development tools with which they are unfamiliar.
As a result, this step in the hardware debugging process can cause major delays. Developing the test code typically takes anywhere from 10 to 25 weeks. And as microprocessors become more complex, so does the software required to test them.
The objective was to reduce both the cost and the size of the cell site controller. The design called for integrating several different circuit boards into one card, code-named Eclipse, that was to contain all the function ality that had previously been implemented on four separate boards: a PowerPC embedded-controller motherboard; a network interface card (NIC) that provided a T1/E1 interface; an Ethernet card to interface to the transmitters and receivers, and a site time and frequency reference card that contained a high-stability oscillator trained by an onboard GPS receiver.
We chose the Motorola MPC-860 PowerQuicc processor as the engine for our board. The PowerQuicc itself is an integrated microprocessor and communications controller and is, therefore, very complex. This complexity increases the difficulty of writing software to test it. Major components featured on the Eclipse include DRAM, on-board flash and a removable flash card, a PCI bus bridge, T1/E1 framer and line driver, Ethernet transceiver, FPGA and a dual universal asynchronous receiver transmitter (DUART). The board was so complex that we had four engineers working on it, each one responsible for a different section.
We needed software code to test all the different functionality on the board. There were two requirements: to get the board up and running and to actually send messages on Ethernet, transmit data on the T1 line and so on. The manual for the PowerQuicc is hundreds of pages long, and we were faced with a steep learning curve to be able to understand the parameters needed simply to get the processor to boot up and run.
For a test tool we picked the DriveWay-MPC860 because it could generate boot and test code for the MPC860 as well as drivers (in C) for the processor's on-chip peripherals. Its graphical user interface would allow us to generate code simply by pointing and clicking, without having to know about all the bits and registers in the data book. In addition, there are several multipurpose pins on the MPC860 and DriveWay cross-checks use of the pins so that the same one is not used for more than one function. This was particularly helpful, especially since we had several developers laying out different sections of the board.
Though DriveWay could not provide all of the code required to test our board, we decided it would, nonetheless, save significant time in software development. We combined it with a Diab Data compiler and the SDS SingleStep debugger. In addition, the PowerQuicc's built-in emulator was included in our test strategy.
In some cases, this tool provided all the drivers and test code needed to implement the test plan; in others, it provided initialization code or drivers that were integrated with internally generated code.
For iteration of the cell site controller, the BSP for only the embedded-controller motherboard took 12 staff weeks to develop. It took another eight staff weeks to develop the driver to bring up the NIC and its HDLC controllers used in the audio routing function. We developed the BSP for the Eclipse card in only one week.
The test setup
The DRAM test setup connected a cable between the parallel port of a Windows NT computer and the background debug mode (BDM) port of the MPC860. In addition, the DUART on the Eclipse board was connected into a regular serial port on the computer. We were able to use DriveWay-generated memory test code to complete all the DRAM tests outlined in our test plan: data and address bus walking-bit test; linear tests; pattern tests; memory walking-bit test, and wipe test.
An additional piece of internally developed software was inserted to feed information back to the computer, providing a "memory test passed" message on the screen. SingleStep debugger software was used to actually start and stop the test.
Normally, it would have taken us about three weeks to get a software person up to speed on the microprocessor and to write the test code for the DRAM controller. Using DriveWay, we were able to generate test code in one day.
The PowerQuicc features built-in Ethernet, which we chose to implement on serial communication controller (SCC) No. 1. There are four SCCs on the PowerQuicc, and No. 1 is optimized for Ethernet. We modified DriveWay's built-in internal loopback Ethernet test to make it an external loopback. We also wrote C code to expand on DriveWay's test so that received Ethernet messages were sent out a serial port where they could be viewed on a monitor. In three days the Ethernet portion was fully tested and working. We would never have known it was operational without the software to test it.
The DUART is external to the MPC860 on the Eclipse board and we needed to write a driver to test this device. While DriveWay does not directly support the DUART, we used it to provide an interrupt handler structure. Internally, we developed the initialization and interrupt routines along with character and string functions. Using one of the entry points in DriveWay's C code, we put our DUART driver into the DriveWay BSP, compiled it with the compiler and were able to run it on the board.
DriveWay code is well documented, so we could easily plug in our own code and make changes. Because Aisys has great knowledge and experience with the MPC860, its code is better documented than what we would have produced internally. By using the DriveWay interrupt handler, we were able to trim about two weeks off development of the DUART driver and the overall DUART test process.
The DriveWay HDLC transmit test message program was beefed up to create a continuous message program that transmitted over and over again. DriveWay does not provide a receive test, so we wrote our own code to perform one. We were able to integrate the DriveWay HDLC driver into our receive test, which saved development time.
Peek into memory
As part of the test, we wrote information into memory and then, by putting a breakpoint into the debugger, were able to look into memory and see if we actually received what we thought we had. We then wrote a program that could take something received and spit it out on a serial port to a terminal that would display it on screen. Again, this process used the DriveWay HDLC driver.
The third piece of the communications processor testing was the Level 1 T1/E1 chip. We used the DriveWay BSP to communicate with the chip, then wrote our own driver to initialize and test it. It took five staff weeks to run the full communications testing.
The Eclipse board features two TDM buses, A and B, each with an LXT370 T1/E1 framer and line driver. To test the functionality of these buses, we developed code to send data packets out one bus and to receive them in the other. We used DriveWay's built-in test of the TDM channel, Time Slot Assigner, to test these features and also devised our own test based on the DriveWay driver for the TDM bus.
Though DriveWay is actually designed to provide the BSP for use in the final product, it proved an invaluable tool in testing our prototype board while saving internal software resources. We got the board up and running and fully functional in weeks instead of months and, most important, had first-pass success with the board.