Diagnostic Tests

1 MGD BLD Tests

These diagnostics allow individual testing of the DRF (1-4), TRF, SRF and , IRF Boards, and the AP Board(s) in the MGD Chassis. See Figure 1. Test options are provided on the right side of the screen. Refer to Table 1 for test descriptions.

Table 1. MGD BLD DIAGNOSTIC TESTS
TEST NAME	TEST DESCRIPTION
DRF 1 BLD	Tests the first DRF1 Board found. This is right-most board in slots 4-7. In an MGD Chassis configured for 4 receive channels this will be the DRF1 Board in slot 2. In an MGD Chassis configured for 8 receive channels this will be the DRF1 Board in slot 7. The APS tests the onboard memory and HPI interface. It also performs a test of the DMA.
DRF 2 BLD	Tests the second DRF1 Board found. This is the board directly to the left of the DRF1 Board designated DRF 1. The APS tests the onboard memory and HPI interface. It also performs a test of the DMA.
DRF 3 BLD	Tests the third DRF1 Board found. This is the board directly to the left of the DRF1 Board designated DRF 2. The APS tests the onboard memory and HPI interface. It also performs a test of the DMA.
DRF 4 BLD	Tests the fourth DRF1 Board found. This is the board directly to the left of the DRF1 Board designated DRF 3. Because there are only 4 slots for the DRF1 Boards and this is the fourth board DRF 4 should normally be located in slot 4. The APS tests the onboard memory and HPI interface. It also performs a test of the DMA.
TRF BLD	The APS or AGP tests functionality of the TRF hardware.
SRF BLD	The AGP tests the functionality of the onboard memory, and various registers.
IRF BLD	The AGP tests the functionality of the onboard memory, various registers, Xmit attenuation Look-Up Table, and the various board FIFOs.
AP RECON	The test sends a raw image test file through the image reconstruction process and compares the result to a known good processed image file. If the output “image” does not match the known good “image” bit-for-bit then the test fails. The “image” is not reconstructable and will not be displayed. The process is as follows: Read a 256 x 256 bit test raw image file from the hard disk. Load this file into AP memory. Run several image reconstruction routines on the raw image. Read the processed image back and compare it to a known good image file from the hard disk. Repeat the process with a 512 x 512 image.

2 MGD Datapath Tests

Refer to Figure 2. These diagnostics allow the testing of the communication paths between various boards in the MGD Chassis. Data paths diagnostics are tests, which transfer data from one FRU to another for the purpose of validating the hardware. This is accomplished where possible by utilizing the application code in a similar manner, as it would be used for patient scanning. This serves two purposes. The first is to detect the same errors as the application code does. The added advantage here is the canned data, which can be validated once it reaches its destination. The second advantage is the ability to validate the software as well as the hardware. The intensity at which the diagnostic works can speed up the detection of timing related problems. Test Results and Test Status are reported at the bottom of the window. Refer to Table 2 for test descriptions.

Table 2. MGD DATAPATH TESTS
TEST NAME	TEST DESCRIPTION
IRF -> DRF	Tests data path between the IRF and the DRF Boards. The test executes in these steps: AGP writes test data to a direct send port on the IRF Board. The IRF forwards the data to the receiver bus. The DRF decodes the receiver bus and stores the data internally. The APS reads this stored data. The APS sends the test data to the AGP through the Bridge Board.
IRF -> IRF I/O	Tests data path between the IRF Board and the IRF I/O (rear MGD). The test executes in these steps: The AGP writes test data to a direct send port on the IRF Board. The IRF sends the test data to the IRF I/O board. The IRF I/O Board loops the data back to the IRF. The IRF captures the data in a bypass FIFO queue. The AGP reads the test data out of the bypass FIFO and compares it to the original test data.
SRF -> DRF	Tests data path between the SRF and the DRF Boards. The test executes in these steps: The AGP configures the SRF to play out a Pulse Sequence Database (PSD) with a test data pattern. The SRF sends the test data out on to the sequence bus. The IRF captures the data and forwards it to the receiver bus. The DRF decodes the receiver bus and stores the data internally. The APS reads this data store. The APS sends the test data to the AGP through the Bridge Board.
SRF -> IRF	Tests data path between the SRF and the IRF Boards. The test executes in these steps: The AGP configures the SRF to play out a PSD with a test data pattern. The SRF sends the test data out on to the sequence bus. The IRF captures the data and stores it in a bypass FIFO queue. The AGP reads the data in the FIFO queue and compares it to the original data.
SRF -> TRF	Tests data path between the SRF and the TRF Boards. Note that the SRF and TRF Boards are physically included in one assembly and are one board (SRF/TRF Board). The test executes in these steps: The AGP configures SRF to play out a PSD with a test data pattern. The SRF sends the test data and the TRF recaptures it in a monitor FIFO. The AGP reads the monitor FIFO and compares the data to the original data.
APS -> Bridge	Tests communication path between the APS Board and the Bridge Board (rear MGD). This tests the ability of the Bridge Board to be accessed and configured and its ability to provide communications to/from the primary and secondary interfaces. The Bridge Boards 21554 scratchpad registers, which reside in the Control/Status Register map, are used for this test. These registers are non-invasive to the operation of the 21554. The master processor (AGP or APS) that is selected by the operator executes the diagnostic. The slave processor is not used for this diagnostic.
AGP -> Bridge	Tests communication path between the AGP Board and the Bridge Board (rear MGD). See test explanation above.
APS -> AP	Tests communication path between the APS Board and the AP Board.

3 RRF BLD Tests

Refer to Figure 3. These diagnostics allow individual testing of the DIF, Receiver, Exciter, and UTNS Boards. Options can be selected from the right side of the window as described earlier. Refer to Table 3 for test descriptions.

Table 3. DCB DIAGNOSTIC TESTS
TEST NAME	TEST DESCRIPTION
DIF BLD	The AGP sends data command to IRF queue. IRF forwards command via IRF I/O to RRF-DIF. RRF replies to IRF via IRF I/O and this is stored in IRF Board status memory. AGP waits 2 status memory cycles (about 512 usec) and then reads the IRF status memory.
Receiver BLD	The AGP sends data command to IRF queue. IRF forwards command via IRF I/O to RRF-DIF. RRF-DIF queries Receiver Board over bus. RRF replies to IRF via IRF I/O and this is stored in IRF Board status memory. AGP waits 2 status memory cycles (about 512 usec) and then reads the IRF status memory.
Exciter BLD	The AGP sends data command to IRF queue. IRF forwards command via IRF I/O to RRF-DIF. RRF-DIF queries Exciter Board over bus. RRF replies to IRF via IRF I/O and this is stored in IRF Board status memory. AGP waits 2 status memory cycles (about 512 usec) and then reads the IRF status memory.
UTNS BLD	The AGP sends data command to IRF queue. IRF forwards command via IRF I/O to RRF-DIF. RRF-DIF queries UTNS Board over bus. RRF replies to IRF via IRF I/O and this is stored in IRF Board status memory. AGP waits 2 status memory cycles (about 512 usec) and then reads the IRF status memory.

4 APS, AGP, and SCP Board Level Diagnostics

Refer to Figure 4. These diagnostics allow individual testing of the AGP, APS, and SCP Boards. Options can be selected from the right side of the window as described earlier. Refer to Table 4 for test descriptions.

Once the selections are made, the test is started by selecting the RUN button in the middle of the window. The tests can be ended by selecting the STOP button located to the right of the RUN button.

When selected, the ALL button enables testing on all 3 boards.
When selected, the Clear button disables testing on all 3 boards.

Table 4. DCB DIAGNOSTIC TESTS
TEST NAME	TEST DESCRIPTION
APS	Host resets APS Board to PPC diag mode (Motorola's proprietary debugger) through the serial port. Host sends diagnostic commands to the board to invoke the test. The test set exercises the SRAM, PCI Bridge, and the internal board register. Host parses the test status sent back from the boards and determines if the test passed/failed.
AGP	Functions for AGP the same way as APS test except AGP is tested. See description for APS above.
SCP	Functions for SCP the same way as APS test except SCP is tested. See description for APS above.

5 CAN Link Diagnostic

This diagnostic tests the functionality of the CAN Board daughter card that resides on the SCP Board in the MGD Chassis. This diagnostic first detects all the available nodes (in this case the Driver Control Module) on the CAN link by monitoring the Node Guarding messages. Once any nodes are detected, they are logged to the screen and then a data path test is run on each of them sequentially. The data path test consists of writing a walking one’s pattern on the Diagnostic Dictionary Index on the node and reading it back. The received data is checked to ensure its validity. The data path test is repeated three times on each node. Any errors will result in an error message logged and the information written to the screen. See Figure 5.

The Force Reset button will reset the CAN Link.
The Run button will start the execution of the diagnostic.
The Stop button will end execution of the diagnostic.

6 Driver Control Module BLD Tests

These diagnostics provide the ability to test the functionality of the Driver Control Module and components within this module. See Figure 6. Refer toTable 5 for test descriptions.

6.1 DCB Power Supply Data

Figure 7 provides a display of what results should normally be seen, when running this diag in Product Configuration (the default selection). Note that all passing results are displayed in blue. Failing results are displayed in red. Product Configuration does not display the results from parts of the Driver Module that are not yet utilized. All results should be displayed in blue.

Figure 8 provides a display of what results should be seen when running this in Full Configuration. Full Configuration tests all parts of the Driver Module, including those parts not yet used. Notice the failing items displayed in red (NEG Drive 15V, POS Drive 12V, MC2 POS 10V, and MC2 NEG 10V). Also notice that while the High Volt parameter is colored blue, the Value number is very low. This is due to the fact that the limits are set very wide. Obviously, the High Volt parameter is for future use. Since none of the functions indicated by the failing red parameters are currently performed by the Driver Module, it is normal and expected to see these failures.

6.2 DCB IO Status

Figure 9 provides an example display of what should be seen when running this diagnostic in Product Configuration. Again, normally all the results should be displayed in blue. Any failing results will be displayed in red. Don’t assume that failures reported here automatically mean that the Driver Module should be replaced. Try removing output cables to the Driver Module and run the diagnostic again. See if the results have changed. If they have, the problem may be external to the Driver Module.

Figure 9 provides an example display of what should be seen when running this diagnostic in Full Configuration. Notice the failing items displayed in red (High Speed Cable, MCD 2, TR/DD, and MCD 2 Cable). Again, these failures are normal in Full Configuration since these functions are for future use. Note the items in the Test Results window marked with an arrow. These items are detected on the Driver Module TR/DD Board. Since Driver Modules in systems with an SSM do not have a TR/DD Board (the SSM performs these functions), the status of these parameters is not valid. A failure of Fan 1 or Fan 2 on the front of a Driver Module without a TR/DD Board will not result in a change in the Fan 1 or Fan 2 parameter. The operation of these fans should be confirmed by visual inspection. The Head, Body, and MNS Overtemp parameters are determined from the temperature of the driver transistors on the Driver Module TR/DD Board. Again, if the system has an SSM, then the Driver Module will not have a TR/DD Board and these values are therefore not valid. Finally, be aware that if the CAN Communication Core (CCC) Board fails then a message indicating that the CAN Link has failed will be displayed in the Test Results window instead of the IO Data.

See a description of the remaining tests in Table 5.

Table 5. DCB DIAGNOSTIC TESTS
TEST NAME	TEST DESCRIPTION
Power Supply Data	This diagnostic reads the Power Supply information from the DCB board every 5 seconds for the specified Test Duration (max 300 secs). The values are checked against the tolerances listed in the DcbConfig.cfg file. Any failing values will be printed out in red. Passing values will be printed out in blue. No error messages will be logged for failing power supplies since the Applications Code will be logging these errors automatically. See sample screen and comments in Gradient Diagnostics.
I/O Status	This diagnostic reads the I/O Bit map information from the DCB board every 5 seconds for the specified Test Duration (max 300 secs). Each polled item and its status is printed in the window. Status messages displayed in red indicate an abnormal condition. See sample screen and comments in Gradient Diagnostics and descriptions in the table below.
	Test	Test Purpose	Nominal Result
	Multi-Coil Switch	Check position of Switch SW 4 MC ENABLE	FAULTS ENABLED
	Dynamic Drive Switch	Check position of Switch SW 3 DD ENABLE (not used on Driver Modules (DMs) in systems with an SSM)	FAULTS ENABLED
	T/R Switch	Check position of Switch SW 2 TR ENABLE (not used on DMs in systems with an SSM)	FAULTS ENABLED
	Power Status	Check incoming power to DCB Board	PRESENT
	High Speed Cable	Check for external cable connected to J4. Future use.	NOT PRESENT
	Front Panel Interface	Check internal ribbon cable to Front Panal I/F	PRESENT
	Un-Blank Cable	Check for external cable connected to J19	PRESENT
	Un-Blank Harness	Check connection of internal cable connection	PRESENT
	High Voltage Switch	Check position of Switch SW 1 HV ENABLE (not used on DMs in systems with an SSM)	FAULTS ENABLED
	Fan 1	Fan 1 operation status; monitored only in DMs equipped with a TR/DD Board. Not currently monitored.	OPERATIONAL
	Fan 2	Fan 2 operation status; monitored only in DMs equipped with a TR/DD Board. Not currently monitored.	OPERATIONAL
	MCD 1	Check for presence of MCD 1 Board.	PRESENT
	MCD 2	Check for presence of MCD 2 Board. Future use.	NOT PRESENT
	TR/DD	Check for presence of TR/DD Board. Future use.	NOT PRESENT
	MCD 1 Cable	Check for external cable connected to J5 (MC1).	PRESENT
	MCD 2 Cable	Check for external cable connected to J10 (MC2). Future use.	NOT PRESENT
	Head Overtemp	Check temp. of TR/DD Board transistors. Future use.	NORMAL
	Body Overtemp	Check temp. of TR/DD Board transistors. Future use.	NORMAL
	MNS Overtemp	Check temp. of TR/DD Board transistors. Future use.	NORMAL
	CCC Board	Check for presence of CCC Board.	PRESENT
	CCC ISO 5 Volts	Check for presence of CCC Board ISO 5 Volts.	PRESENT
	CCC Flash 5 Volts	Check for presence of CCC Flash 5 Volts.	PRESENT
	DCB Reset State	Report state of Digital Control Board inside DM.	NO RESET
Xpt Switch	This diagnostic runs the following patterns on the Cross Point Switch LED’s every 5 seconds for the specified Test Duration (max 300 secs): Walking one from 0 to 7. Walking one from 7 to 0.
MCD Volt Test	This diagnostic outputs the multicoil TR bias voltages listed below to the specified driver channels for measure at MC1 J5 and MC2 J10 (future use only) on the rear of the Driver Module. This test is helpful for dynamically checking the TR voltages using a DMM or oscilloscope. See Table 5 for J5 and J10 connection pinouts. The voltages will be present in the time interval specified in Test Delay and unblanked for the period of time specified in Un-blank Time. An Internal or External Un-blank signal can be specified for use. The Internal Un-blank is generated inside the DM but cannot be used outside the DM. The External Un-blank (RS-422 differential signal) can be supplied by the FE between pins 1 and 6 at the J19, 9-pin, sub-D port. : Disable all multi-coil channels Set all Driver channels to 3 Volts Set all Driver channels to 5 Volts Set all Driver channels to 7 Volts Set all channels to 5 volts Set each channel to 3 volts then back to 5 volts Set all channels to 7 volts Set each channel to 5 volts then back to 7 volts Set all channels to 3 volts Set each channel to 7 volts then back to 3 volts Enable all multi-coil channels Set all channels to 5 volts Set each channel to 3 volts then back to 5 volts Set all channels to 7 volts Set each channel to 5 volts then back to 7 volts Set all channels to 3 volts Set each channel to 7 volts then back to 3 volts At this point the test ends.
MCD Channel Disable Test	This diagnostic outputs a positive TR bias voltage to the specified driver channels for measure at MC1 J5 and MC2 J10 (future use only) on the rear of the Driver Module. This test is helpful for dynamically checking the disable TR voltage using a DMM or oscilloscope. See Table 5 for J5 and J10 connection pinouts. The voltage will be present in the time interval specified in Test Delay and unblanked for the period of time specified in Un-blank Time. An Internal or External Un-blank signal can be specified for use. The Internal Un-blank is generated inside the DM but cannot be used outside the DM. The External Un-blank (RS-422 differential signal) can be supplied by the FE between pins 1 and 6 at the J19, 9-pin, sub-D port.
MCD Channel Enable Test	This diagnostic outputs a negative TR bias voltage to the specified driver channels for measure at MC1 J5 and MC2 J10 (future use only) on the rear of the Driver Module. This test is helpful for dynamically checking the enable TR voltage using a DMM or oscilloscope. See Table 5 for J5 and J10 connection pinouts. The voltage will be present in the time interval specified in Test Delay and unblanked for the period of time specified in Un-blank Time. An Internal or External Un-blank signal can be specified for use. The Internal Un-blank is generated inside the DM but cannot be used outside the DM. The External Un-blank (RS-422 differential signal) can be supplied by the FE between pins 1 and 6 at the J19, 9-pin, sub-D port.
Gather Load Data	This test checks the current draw on the multicoil TR bias lines. It also has the capability to check the Dynamic Disable, Direct Drive Disable, head and body TR bias current draw, although the Driver Module does not yet support these functions. The data is sampled 5 times each for each line and then written to 3 separate text files in /usr/g/service/log. One can then use the more or cat commands to view the contents of these files. The data in each file is reported in Open (forward bias) and Short-circuit (reverse bias) modes. These modes refer to the fault conditions for which the Driver Module is always monitoring. Only the multicoil (mc) file will contain any useful data in EXCITE systems equipped with an SSM. In the multicoil data file the Open mode displays the current measured when reverse bias (always –5VDC irregardless of selected voltage) is applied to the LPCA circuitry and the circuitry of any coil attached to the LPCA. Short mode displays the current measured when forward bias (in this case the selected voltage of +3, +5, or +7VDC) is applied to the LPCA circuitry and the circuitry of any coil attached to the LPCA. The measured currents will vary based on the coil type and selected voltage. If no coils are connected to the LPCA and this test is run there are, however, typical measured currents that one can expect to see. In this state, as long as +5 VDC is the selected voltage, one should expect to see from –130ma to –150ma in the Short mode and between +155ma to +175ma in the Open mode. Values much greater than the typical values may indicate circuit damage or a short-circuit condition somewhere in the bias path while values much less than the typical values may indicate circuit damage or an open-circuit (maybe a disconnected cable?) condition somewhere in the bias path. Refer to the System Block Diagrams to help isolate the fault if troubleshooting one of these two scenarios. Run this test to troubleshoot intermittent problems and collect baseline data on any new surface coil. Stored surface coil data can be retrieved in the future and compared to current values for troubleshooting purposes. Connect any surface or phased-array coil to the LPCA adapter. Select the TR voltage normally used with the coil (5 Volts is typical but picking the wrong voltage won’t cause damage), specify a unique file name (if desired) in the Output File Name box that matches the name of the coil, and then run the test. The files are saved to /usr/g/service/log. The path and filenames are reported in the status window after the test is completed. An Internal or External Un-blank signal can be specified for use. The Internal Un-blank is generated inside the DM but cannot be used outside the DM. The External Un-blank (RS-422 differential signal) can be supplied by the FE between pins 1 and 6 at the J19, 9-pin, sub-D port. note: Please be aware that the test can only check as many multicoil lines as the site is equipped to support (typically 8; 0 - 7). The files report values for up to 32 channels but only the values that correspond to an actual line are valid. The remaining lines are for future use and the values listed for these are invalid. Also, be aware that, even with no coil connected, the multicoil switching hardware draws between –130ma to –150ma of current in Short mode and between +155ma to +175ma of current in Open mode when 5 volts is selected. The Short mode currents will not match the typical stated values if +3 or +7VDC is selected instead. Current flows (it is much greater than zero) during the Short mode (reverse bias) portion of the test due to the diode switching scheme used in the LPCA hardware. Remember that the measured current values will tend to vary from coil to coil. Baselining a new coil for future reference is a good practice. Individual coils in an array generally have current draws that are somewhat similar and usually, but not always, can be compared one to another.

7 SRI Datapath Tests

Refer to Figure 11. These diagnostics test the communication paths between the internal sections of the SRI. Refer to Table 6 for test descriptions.

Table 6. SRI TEST DESCRIPTIONS
TEST NAME	TEST DESCRIPTION
SRI PWM	This test verifies that the Pulse Width Modulator is converting pulses to analog voltages correctly.
SRI RAM	SRI RAM Test (Fatal) – On power up, the last 512 bytes of RAM, locations FE00H -FFFFH are tested without destroying the application contents of the RAM. The SRI interrupts are disabled for this test. These locations are tested one at a time. The contents of a location are read, inverted, and written back to the location. The location is read again and compared to the value written. The original contents of the location are then written back to the location that has been tested.
SRI Encoder	Encoder Voltage Test – This test verifies that the voltage across the encoder (measured at SRI) is >4.0V.
SRI Loopback	Test time is approximately 9 seconds. This test verifies the communication between the SPI and the SRI and the corresponding serial path. The SPI transfers a communication packet to the SRI (via the STIF Board) containing an Invert-and-Loopback opcode and 8-bit test patterns (55, AA, 33, 00, FF). The information returned by the SRI will be verified by the MGD.
SRI Streamed Loopback	This diagnostic runs the streamed loop back test with the SRI. The Streamed Loop Back Test opcode is sent to the SRI along with four bytes of data. The expected response is the one’s complement of each byte of data. The SCP will verify that the data is correct and log an error in the case of a data mismatch.
SRI Fiber LoopBack	Tests the loopback of data on the SCP board. The test executes in these steps: Sets the SCP board I/O path to the STIF in loopback on the board. Writes out a packet of data. Verifies receipt of the data.
SCP STIF LoopBack	Tests the loopback of data across the STIF board. The test executes in these steps: User must first connect the fiber optic loopback connector across the STIF SRI Tx/Rx connections Sends a packet of data out of the SRI Tx connection Verifies receipt of the data at the SRI Rx connection
SRI Register	This diagnostic runs the power up Register test resident on the SRI PROM. The Register Test opcode is sent to the SRI. The expected response is the error message opcode. A passing test will have an ermes of 0. Any other value indicates a failure in the test and causes an error to be logged.
SRI EEPROM	This diagnostic runs the power up EEPROM test resident on the SRI PROM. The EEPROM Test opcode is sent to the SRI. The expected response is the error message opcode. A passing test will have an ermes of 0. Any other value indicates a failure in the test and causes an error to be logged.

8 WIM Data Path Test

Refer to Figure 12. These diagnostics test the communication paths between the WIM and its peripheral’s (the Hard Key Processor inside the keyboard assembly and the PC). Refer to Table 7 for test descriptions.

Table 7. WIM DATA PATH TESTS
TEST NAME	TEST DESCRIPTION
WIM Loopback	This diagnostic runs a loop back between the SCP and the WIM processor. The loop back opcode is sent to the WIM with four bytes of data. The response opcode is then pended upon and the data is checked to ensure that the one’s complement of the sent data is received.
IWS Loopback	This diagnostic runs a loop back between the SCP and the PC. The loop back opcode is sent to the WIM with four bytes of data. The WIM will then send the opcode to the PC and wait for the response. Once the response is received, the WIM sends it on to the SCP. The SCP then waits for the return opcode and the data is checked to ensure that the one’s complement of the sent data is received.
HKP Loopback	This diagnostic runs a loop back between the SCP and the HKP processor. The SCP requests the button status from the HKP and checks the response to ensure that it is equal to zero. If any other value is received, then the test fails. note: If the test is run while any button is pressed, the test will fail.
WIM Reset	This diagnostic sends the reset opcode to the WIM processor and waits on the WIM to come back out of reset.
HKP Reset	This diagnostic sends the reset opcode to the HKP processor and waits on the HKP to come back out of reset.
HKP Audio	This diagnostic sends an audio command to the HKP processor commanding it to make a quick sound. The SCP will only check for a response to the command to check for pass or fail status. The operator will have to ensure that the sound is actually heard.

9 MGD Host Data Path Tests

Refer to Figure 13. These tests permit the Host to repeatedly “ping” the selected component(s) within the MGD with patterns of data via the individual 100 BaseT Ethernet link(s). Be aware that if the Ping -> APS test is passing then it is normal for the Ping -> 750 test to fail. Likewise, if the Ping -> AGP test is passing then it is normal for the Ping -> 750V test to fail. The Ping -> 750 and Ping -> 750V tests should only be run if the APS and AGP tests fail. Refer to Table 8 for test descriptions.

Table 8. WIM DATA PATH TESTS
TEST NAME	TEST DESCRIPTION
Ping -> APS	This checks that the host is able to successfully “ping” the APS via the Ethernet link.
Ping -> AGP	This checks that the host is able to successfully “ping” the AGP via the Ethernet link.
Ping -> SCP	This checks that the host is able to successfully “ping” the SCP via the Ethernet link.
Ping -> MCP750	This test should only be run if the Ping -> APS test fails. If the Bridge Board does not successfully initialize the APS then it will default to a 750 configuration. This test confirms that the APS is functional if it was not properly initialized by the Bridge Board. It is normal for this test to fail if the Ping -> APS test passes.
Ping -> MCP750V	This test should only be run if the Ping -> AGP test fails. If the Bridge Board does not successfully initialize the AGP then it will default to a 750V configuration. This test confirms that the AGP is functional if it was not properly initialized by the Bridge Board. It is normal for this test to fail if the Ping -> AGP test passes.

10 AP Board Level Diagnostics

These tests check the functionality of the AP Board(s). The AP Recon test reconstructs “canned” data from a file on the system. The data is not image data and so no image will be displayed after the reconstruction completes. See Figure 14. Notice that the tests are explained in the top of the screen. Refer to Table 9 for test descriptions.

Table 9. AP BOARD LEVEL DIAGNOSTICS DESCRIPTIONS
TEST NAME	TEST DESCRIPTION
APS -> AP Datapath	APS writes and reads data into AP memory and verifies that bits are not lost. APS also verifies that AP responds to simple memory data transformation commands.
AP Recon Test	The test sends a raw image test file through the image reconstruction process and compares the result to a known good processed image file. If the output “image” does not match the known good “image” bit-for-bit then the test fails. The “image” is not reconstructable and will not be displayed. The process is as follows: Read a 256 x 256 bit test raw image file from the hard disk. Load this file into AP memory. Run several image reconstruction routines on the raw image. Read the processed image back and compare it to a known good image file from the hard disk. Repeat the process with a 512 x 512 image.
Single Board AP Mem	The user must select the test that corresponds to the number of AP boards present. If the test sees a different number of boards, it logs an error. The test confirms that the correct number of CPUs and the memory length is correct. The memory is then run through a reasonably complete memory test. Allowing for Single versus Dual Board configurations was done in an attempt to cover the case where the system has 2 AP boards but one of them is unresponsive. An unresponsive board may be mistaken for an empty slot in a one-test scenario. Long memory tests are more thorough than short memory tests but execution time is also longer. The short selection is adequate for most testing.
Dual Board AP Mem

11 SSM Board Level Diagnostics

These diagnostics check various functions and registers on the CPD Board inside the SSM. These tests do not check hardware external to the SSM. Be aware that all multicoil functions are now controlled by the Driver Module. The system still writes to the SSM Multicoil Register and so this diagnostic is still provided. See Figure 15 below.

See Table 10 for an overview of each of the tests.

Table 10. SYSTEM SUPPORT MODULE DIAGNOSTICS DESCRIPTIONS
TEST NAME	TEST DESCRIPTION
RF Amp	Test time is ~6 seconds. This test verifies the operation of the MDS Link and the presence of the RFI and Analogic amplifiers. To verify the presence of these items, the Command Register is addressed and read by the SPI via the MDS. No additional tests are used.
Spectro RF Amp	note: This test is present only on systems with the spectroscopy option. Test time is ~6 seconds. This test verifies the operation of the MDS Fiber Optic Link and the presence and operation of the Spectro RF Amplifier Interface register on the SSM CPD Board. The Command Register is addressed and read by the SPI on the SCP Board via the MDS. The functionality of the Spectro RF Amplifier register is confirmed by reading the register for a specific pattern.
Multicoil	Test time is ~5 seconds. This test verifies the operation of the MDS Fiber Optic Link and the presence and operation of the Multicoil hardware on the CPD Board. To verify its presence, the Command Register of the CPD Board is read. To verify the functionality of the registers, a set of Multicoil Register tests are run simultaneously with patterns AA, 55, 33, 0F. Any errors are logged to indicate the failing register. Be aware that Multicoil driver signals and MC TR bias are now provided by the Driver Module. Except for data that the system writes to this register, the SSM does not perform any of the other multicoil functions. This test does not check the Driver Module Hardware.
TR Dynamic Disable & Power Supply	Test time is ~9 seconds. This test verifies that the CPD Board is attached to the MDS Fiber Optic Link and is in working order. This test is comprised of the following subtests: Presence Test The SPI on the SCP Board addresses the command register on the CPD Board. If the board is not present, an error is logged. Coil Configuration Register Test The coil configuration register is tested by writing/readback of patterns AAH, 55H, 33H, and 0FH. Fault Reporting Disable Register Test The Fault Reporting Disable Register is tested by writing/readback of patterns AAH, 55H, 33H, and 0FH. TR Command Register Test The TR Command Register is tested by writing/readback of bits 00 (Enable), 01 (Service), 02 (Reset), and 07 (Reset Status Registers). After each bit is read, the bit is checked to see if it has been reset. Register Reset Tests The CPD Board has two status registers: the TR/ID Status Register and the Dynamic Disable Status Register. These status registers are reset to 00H by setting bit 07 of the TR Command Register. After bit 07 of the TR Command Register is set, the Status Registers are checked to see if they are reset. Also, the Coil Configuration and Fault Reporting Disable Registers are each written with pattern FFH. Then, bit 02 of the TR Command Register is set, and these registers are checked to see if they have gone to 00H. The power supply tests verify the operation of the three power supplies (+15V, –15V, and +1000V) associated with the CPD Board. The status of these power supplies is indicated by the fault register bits 05 (+15V), 06 (–15V), and 07 (+1000V). These bits are each sampled five times (with approximately 65 milliseconds between each sample). A failure is displayed if one of the power supplies is indicated as having failed five times in a row.

Power Monitor	Test time is ~5 seconds. This test verifies the operation of the MDS Fiber Optic Link and the presence and operation of the CPD Board. To verify its presence, the Command Register of the CPD Board is read. To verify the functionality of the registers, a set of Multicoil Register tests are run simultaneously with patterns AA, 55, 33, 0F. Any errors are logged to indicate the failing register.

12 Gradient Diagnostics

The functionality of the Gradient hardware is directly exercised through running these diagnostics. Select Whole, Zoom, or Both for TwinSpeed Systems only. See Figure 16 below.

13 RRF-DIF Diagnostic

These tests, run from the SCP, verify features of the RRF through the CAN-Link. See Figure 17 below.

Table 11. RRF-DIF BOARD DIAGNOSTICS
TEST NAME	TEST DESCRIPTION
IO Status	Verifies various RRF values, states: RF Out switch state, 20Mhz clock, Rx Signal detect, Tx Ready, Link Ready, GB State, 3.3V present, 5.0V present, Feeder Diag state, Loopback DIag state, and FPGA reset state.
Reset FPGA	This tests that the FPGA can be reset.
Feeder Test	Mult-Coil Voltage test done in Driver Module.
Loop Back Test	This places the RRF-DIF Link FPGA into loopback mode. No data is transferred and nothing else is tested. This mechanism, in the future, will be used by another diagnostic to perform a loopback test.
Query A2D Values	Verifies the RRF-DIF Analog to Digital 3.3V and 5.0V levels.

14 RRF Datapath Diagnostics

These diagnostics will check the functionality and communication paths of the listed RRF components. See Figure 18 below.

Table 12. RRF-DIF BOARD DIAGNOSTICS
TEST NAME	TEST DESCRIPTION
RRF Calib	Actually perform ADC, ADC Offset, Exciter calibration, and receiver calibration.... just as though you were doing a Save Series. The difference is that the validation flags (more extensive validation) and logging flags (additional files are created which show the calibration results) are set.
Ex – Rx Signal	These are actually four related subtests. (1) Ex-Rx verifies the presence of the RF Out and LO signals to the receiver(s) from the exciter. (2) Exciter blanking verifies no signal is present when the exciter is blanked. (3) Receiver Blanking verifies no signal is present when the receiver is blanked. (4) Anti-Alias test verifies the Receiver filter range and "flatness".
IRF -> RRF	This test verifies the checksum feature of data returning from the RRF to the IRF.

15 MDS Diagnostics

This test provides a means for check the functionality of the Multi-Drop Serial (MDS) Link. See Figure 19 below. The MDS Link is currently the primary means of communication between the System Cabinet and the other cabinets in the MR system.

Table 13. RRF-DIF BOARD DIAGNOSTICS
TEST NAME	TEST DESCRIPTION
MDS Link & Polling Tests	Test time is ~17 seconds. These tests verify that the MDS fiber optic circuit is complete, and it checks the initial status of the peripherals presently on the link. The test first checks the serial port on the SPI processor by transmitting test patterns (AAH, 55H, 33H, 0fH) and verifying them as they return from the loopback. Next, the SPI sends out four data bytes in succession to ensure that the MDS link is complete. An error message is logged if either test fails. The polling test verifies the operation of the GP Board on the MDS Fiber Optic Link. The SPI addresses only two MDS Fiber Optic Link boards at a time. If the GP does not transmit an error packet back to the SPI within two seconds, the test fails, and an error is logged.
MDS STIF Loopback Test	Checks that the data received by the STIF from the MDS Link is the same data that was initially transmitted out on the MDS Link.

16 Image Transfer Bus Board Level Diagnostic

These diagnostics check the integrity of the Image Transfer fiber optic link. The diagnostics are explained as in the screen below in Figure 20.