for Macintosh® II, IIx, IIcx, SE, SE/30, and Classic computers
rev. 9/21/92
______________________________________
______________________________________
TABLE OF CONTENTS
1. The Macintosh Test Manager
1.A- How to Recognize Test Manager Mode
1.B- How to Enter Test Manager Mode
2. Problems Entering Test Manager Mode
3. Basic (No Pain) Entry Method (“Manual TM Entry”)
4. Causes of Communication Path Failures
4.A- RAM SIMM Problems
4.B- NuBus™ Card Problems
4.C- SCSI Device Problems
______________________________________
______________________________________
1. THE MACINTOSH TEST MANAGER
The Macintosh Test Manager is a program that has been built into most Macintosh CPU ROMs since 1986. When a Macintosh is running the Test Manager, we say it is “in Test Manager mode” (or “in Test Mode,” for short). This mode allows Apple TechStep to communicate with a Macintosh CPU over the modem port. Test Mode requires only minimal functionality of the Macintosh CPU.
______________________________________
1.A- How to Recognize Test Manager Mode
Macintosh Classic and SE computers display the "Sad Mac" Icon when they have successfully entered Test Manager mode, provided the Macintosh is healthy enough to generate a video pattern.
Macintosh II-family machines play error tones (“Death Chimes”) to signal a successful entry into Test Manager mode.
______________________________________
1.B- How to Enter Test Manager Mode
There are several ways in which the Macintosh CPU can enter Test Mode. The most common are:
a) The Mac fails its own power-on self-tests. (This occurs automatically upon failure of any of the built-in Macintosh power-on self-tests.)
b) The user pushes the non-maskable interrupt (NMI) button (programmer’s switch) before the CPU "boots" the Macintosh operating system.
c) The user connects the correct cables and chooses "tstMd" key from the Apple TechStep menu.
Methods a) and b) will cause Test Manager entry whether an Apple TechStep unit is connected to the Macintosh or not.
Method c) was designed into the Apple TechStep ROM pack code for the convenience of the Service Technician. It eliminates the need for a programmer's switch and avoids the potential timing problems of method b) (pressing the switch too soon or too late).
______________________________________
______________________________________
2. PROBLEMS ENTERING TEST MANAGER MODE
Some types of failures prevent or obstruct the Test Manager from functioning properly. If the Test Manager is not functioning properly, many Apple TechStep™ tests will not run, because they will be unable to download test code to the Macintosh or to receive results from the Macintosh. When this happens, the test will display a screen that says “Lost comm w/UUT,” or “UUT timed out,” with the recommendation “Check prior UUT functions.”
These failures are almost always along the Apple TechStep / Macintosh communication path. The basic communication path consists of the Macintosh components and circuitry listed below. If even one of these seven items is non-functional, the Apple TechStep will be unable to communicate with the Macintosh Test Manager.
NOTE: The actual cause of the communications problem may be something other than the seven components and circuits listed here. Whatever the actual failed component, it disrupts communications by affecting one or more of the components listed below.
• System Crystal / timing clocks
• CPU (the Macintosh microprocessor)
• Address or data lines
• MMU
• ROM
• SCC
• Modem port
______________________________________
______________________________________
3. BASIC (NO PAIN) ENTRY METHOD (“MANUAL TM ENTRY”)
The "tstMd" choice on the Apple TechStep menu is a convenient way to enter Test Manager mode, provided the appropriate cables are connected. However, this method is not always the fastest or easiest way to enter Test Mode, especially if SCSI or ADB problems are suspected or if a minimum cable configuration is desired.
The following "manual" entry method uses only one serial cable (connecting the Apple TechStep modem port to the Macintosh modem port). This method also provides a quick way to check if the Macintosh has a Test Manager communications path problem.
1) Connect the serial cable “Modem to Modem” only. Make sure the stereo/audio cable is NOT connected.
(Note: You will not hear error tones if the stereo (audio) cable is connected, as connecting that cable disables the Macintosh speaker.)
2) Boot the CPU and listen for tones.
• If you hear the boot tone only:
Wait 10 seconds, then press the NMI switch to gain manual entry. Then go to step 3.
• If you hear error tones (or an attempt at error tones):
Go to step 3.
(Error tones (“Death Chimes”) mean that you have successfully entered Test Manager mode. If the Mac fails its own power-on self-tests, it will enter Test Manager automatically and will not require the user to push the NMI button. Note that error tones only occur on the Mac II family and that the Mac SE & Classic do not play error tones when entering the Test Manager mode.)
3) Choose your CPU from the Apple TechStep menu.
4) Choose “4+Logic” from the HOME menu.
5) Choose “2-ROMck” from the Logic menu.
• If the screen says “tstMd not found”:
Choose “2-Cancel.”
(This means the communications path is bad! A critical component or system affecting the Test Manager communication path has failed.)
• If the screen says “Test Passed,” you're in !!!
______________________________________
______________________________________
4. CAUSES OF COMMUNICATION PATH FAILURES
Since most replaceable modules share at least one of the seven components of the Test Manager communications path, almost any module can directly or indirectly cause a failure.
In troubleshooting for the failed module, it’s helpful to note all the symptoms of a Test Manager failure and to have some idea where the failure might be. Below are some descriptions of how specific modules can interfere with Test Manager entry, and methods to help isolate the problem module.
______________________________________
4.A- RAM SIMM Problems
A RAM SIMM can “lock up” the address or data bus, since it uses these buses to get information to and from the CPU. If the RAM SIMM fails so that it holds an address or data line “low,” no communication can take place in the system and therefore ...NO Test Manager. ("TstMd" will not be able to drop the Macintosh into Test Mode.)
•• Finding the “Failed” SIMM in a “NO Test Manager” Condition ••
The following method has two advantages over the SIMM swap described in the Technical Procedures:
• Fully booting the system is not necessary to find the bad SIMM.
• Replacing the SIMMs you remove is not necessary to find the bad SIMM.
(Remember: Test Manager can function with NO SIMMs or RAM—therefore, so can Apple TechStep.)
1. Use the Basic (No Pain) Entry Method to try to enter the Test Manager.
2. If Test Manager entry is successful, run the “SIMM” (or “RAM”) test to identify the bad SIMM(s).
3. If Test Manager entry is NOT successful:
3a) Power off the Mac and remove 1 SIMM.
3b) Repeat the above process, starting at step 1, until Test Manager entry is successful.
Once successful Test Manager entry is achieved, the last SIMM removed was the culprit.
______________________________________
4.B- NuBus Card Problems (Macintosh II Family Computers)
A NuBus Card can “lock up” the address or data bus, because NuBus design allows a card to become the system “Master” and “override” the system’s CPU. If the NuBus Card fails so that it interferes with or overrides the CPU, no communication can take place in the system and therefore … NO Test Manager. ("TstMd" will not be able to drop the Macintosh into Test Mode.)
•• Finding the “Failed” NuBus Card in a “NO Test Manager” Condition ••
The following method has an advantage over the NuBus Card swap described in the Technical Procedures, in that fully booting the system is not necessary to find the bad NuBus Card.
(Remember: Test Manager can function with or without a video card, video monitor or any other I/O device—therefore, so can Apple TechStep.)
1. Use the Basic (No Pain) Entry Method to try to enter the Test Manager.
2. If Test Manager entry is successful, run the “Video” test.
• If a “Check prior UUT functions” message appears, a NuBus card may be at fault.
• If an unexpected name or response from a video card appears in the menu, that card (slot) may be at fault.
• If no card appears in the menu where it is known that a video card is installed, that card (slot) may be at fault.
3. If Test Manager mode entry is NOT successful
3a) Power off the Mac and remove a NuBus card.
3b) Repeat the above process, starting at step 1, until Test Manager entry is successful.
Once successful Test Manager entry is achieved, the last NuBus Card removed was the culprit.
______________________________________
4.C- SCSI Device Problems
If a SCSI device fails in such a way that it puts the CPU into a mode (or endless loop) in which it is always responding to the SCSI device, it can “lock up” the CPU communications path. Constant interrupts or incomplete and/or repeated SCSI protocol requests from the SCSI device can prevent the CPU from responding to anything but that SCSI device, and therefore … NO Test Manager.
•• Finding the “Failed” SCSI Device in a “NO Test Manager” Condition ••
The following method has an advantage over the SCSI device swap described in the Technical Procedures, in that fully booting the system is not necessary to find the bad SCSI device.
(Remember: Test Manager can function with or without a SCSI device or any other I/O device—therefore, so can Apple TechStep.)
1. Connect the SCSI cable and use the Basic (No Pain) Entry Method to try to enter Test Manager mode.
2. If Test Manager entry is successful, run the “SCSI” test in the Logic menu.
If a “Check prior UUT functions” message appears, run all the tests under the “SCSI Functions” menu (in order):
2a) “SCSI Term Powr”: If this test fails:
* The system may have a “blown” SCSI fuse or diode on the Logic board.
2b) “SCSI Term Check”: If this test fails:
* If there is an external SCSI device, check or replace the SCSI terminator.
2c) “SCSI Bus Scan”:
* If a “Check prior UUT functions” message appears, a SCSI device may be at fault.
* If an unexpected name or response from a SCSI device appears on the Scan menu, that SCSI device may be at fault.
* If no SCSI device appears on the Scan menu where it is known that a SCSI device is installed, that SCSI device may be at fault.
2d) Choose each SCSI device number that appears on the “SCSI Bus Scan” menu:
* If a “Check prior UUT functions” message appears, a SCSI device may be at fault.
* If an unexpected name or response from a SCSI device appears, that SCSI device may be at fault.
* If no SCSI device info appears where it is known that a SCSI device is installed, that SCSI device may be at fault.
3. If Test Manager entry is NOT successful, run all the tests under the SCSI Functions menu (in order).
IF NONE OF THE SCSI FUNCTIONS FAILS, THE PROBLEM IS PROBABLY NOT CAUSED BY A SCSI DEVICE.
3a) “SCSI Term Powr”— If this test fails:
* The SCSI device may be at fault and may also have “blown” the Logic board SCSI fuse or diode.
* Logic board SCSI fuse or diode may be blown, causing a “healthy” SCSI device to act erratically.
3b) “SCSI Term Check”— If this test fails:
* If there is an external SCSI device, replace the SCSI terminator, as it may be shorted.
* Check terminating resistor packs on internal SCSI devices for damage or shorting.
* The SCSI device may be at fault and may be holding the SCSI signal lines “low.”
* If a “Check prior UUT functions” message appears, a SCSI device may be at fault.
3c) “SCSI Bus Scan”— Run the “SCSI Bus Scan”:
* If a “Check prior UUT functions” message appears, a SCSI device may be at fault.
* If an unexpected name or response from a SCSI device appears on the Scan menu, that SCSI device may be at fault.
* If no SCSI device appears on the Scan menu where it is known that a SCSI device is installed, that SCSI device may be at fault.
3d) Choose each SCSI device number that appears on the “SCSI Bus Scan” menu:
* If a “Check prior UUT functions” message appears, a SCSI device may be at fault.
* If an unexpected name or response from a SCSI device appears, that SCSI device may be at fault.
* If no SCSI device info appears where it is known that a SCSI device is installed, that SCSI device may be at fault.
IF ONE OF THE ABOVE TESTS INDICATES THAT A SCSI DEVICE MAY BE AT FAULT, REMOVE THE SCSI DEVICE.
4. Repeat this process, starting at step 1, until Test Manager mode entry is successful
Once successful Test Manager entry is achieved, the last SCSI device removed was the culprit.
