Electronics > Repair
Series defect on agilent 167xx boards?
MarkL:
Here's something that may or may not help...
On the 16700 HPUX-running chassis, you can turn on debugging when invoking the top level GUI, /usr/sprockets/bin/vp:
usage: vp [-debugqfxa]
[-debug level]
[-all] (load all shared library groups)
[-q] (don't show intro screen, don't prebuild instrument menus)
[-f cfgfile] (load this config file at powerup)
[-x] (exit after powerup, typically used w/ -f option)
[-a address]
address < 0: don't load instruments
address > 5: search all scsi addresses (the default)
address = 0-5: search only this scsi address
Setting -debug to something greater than 1 (well, I tried 1, 2 and 255; try others if you like), makes a "Debug" option appear under the main "Select" menu for some models of analyzer cards. I tried this on 16752A and 16756A cards, and I think it should would work on a 16760A since it appears to share some of the same code. See screen captures below.
Perhaps you can use this to characterize the problem further by reading registers, or maybe by verifying chip select lines are working. The "Chip Dump" button causes a file to be created in whatever directory you started "vp". The file created contains a series of register dumps.
Setting "vp -debug 255" causes more stuff to be printed, but seems mostly related to the various widget settings for the GUI. There's also some interesting commands if you run /usr/sprockets/bin/starhw. I think it's the CLI equivalent to what's visible with vp -debug.
The above usage output from vp also implies the cards are accessed through some kind of emulated SCSI interface? I really haven't looked at it in detail.
As is par for the course in more recent Agilent/Keysight equipment, there's no documentation for any of this. Good luck, and if you discover anything useful, like for other values of -debug, please share.
There's lots of opportunity for "infinite monkey" hacking...
DocBen:
Wow that SCSI bit is realy interesting. In the documentation they write something like propriatary multiplexed 16-bit bus.
The LA connector has 72 pins, SCSI 50 or 68 if I remember correctly, but definitly close enough.
Would really be quite ingenious to do it that way because all the ip for the fpgas would already been there and tested.
Also quite impressed with the debug options, havent had time to see if the 16902a has something like that as well, would be really helpful.
NickAmes:
--- Quote from: MarkL on November 26, 2017, 08:48:08 pm ---On the 16700 HPUX-running chassis, you can turn on debugging when invoking the top level GUI, /usr/sprockets/bin/vp:
usage: vp [-debugqfxa]
[-debug level]
[-all] (load all shared library groups)
[-q] (don't show intro screen, don't prebuild instrument menus)
[-f cfgfile] (load this config file at powerup)
[-x] (exit after powerup, typically used w/ -f option)
[-a address]
address < 0: don't load instruments
address > 5: search all scsi addresses (the default)
address = 0-5: search only this scsi address
--- End quote ---
That's really interesting. Using
--- Code: ---vp -debug 255
--- End code ---
yields a debug menu on the 16760A. (Screenshots attached. The comparator window has a few more options than the 16756A.) I was incorrect earlier when I wrote about the app locking up when capturing from the card. It runs just fine, but locks up when trying to view the data. When trying to capture and view pod 1, the following message is printed to the console:
--- Code: ---KatanaHardware::ramSearchStart()
startSample:33554026, stopSample:33554824
startRow.port:0x142550.a, endRow.port:0x1425b4.8
maskSize:6, relative:1, mode:1, type:0
search master = Chip9, FPGA0
chip9: level:0x0,00009838 care:0x0,ffff0045
--- End code ---
For pod 2:
--- Code: ---chip 8: fineToCoarseRatio = 16
KatanaHardware::ramSearchStart()
startSample:33554018, stopSample:33554816
startRow.port:0x3fffce.2, endRow.port:0x400032.0
maskSize:6, relative:1, mode:1, type:0
search master = Chip9, FPGA0
chip8: level:0x0,00009838 care:0x0,ffff5a44
--- End code ---
Also, some of the bits are oscillating with no cables attached. (Third screenshot.) They looking like they might be physically adjacent on the card.
I can't mess with the threshold settings since I don't have a probe to go on the end of the cable. According to the service manual, the LA communicates with the probe over I2C to identify which type it is. Does anyone have information on what the LA expects to find there? (Perhaps a small EEPROM?) This would also be helpful for people who can't afford the 90-pin probe prices.
MarkL:
--- Quote from: DocBen on November 26, 2017, 10:41:26 pm ---Wow that SCSI bit is realy interesting. In the documentation they write something like propriatary multiplexed 16-bit bus.
The LA connector has 72 pins, SCSI 50 or 68 if I remember correctly, but definitly close enough.
Would really be quite ingenious to do it that way because all the ip for the fpgas would already been there and tested.
Also quite impressed with the debug options, havent had time to see if the 16902a has something like that as well, would be really helpful.
--- End quote ---
I think now my guess about using SCSI is probably wrong. I wasn't able to make the "vp -a" option do anything different, plus I also found some utilities that look like they're using PCI to talk to the cards. "pciinfo", for one:
# pciinfo
Starship PCI Device Configuration Header
0x00: 1650103c 0x10: 0000ff01 0x20: f0f00000 0x30: 00000000
0x04: 00000007 0x14: f0dfe000 0x24: 00000000 0x34: 00000000
0x08: 06800000 0x18: f0dff000 0x28: 00000000 0x38: 00000000
0x0c: 0000f800 0x1c: f0e00000 0x2c: 00000000 0x3c: 00ff0104
Starship PCI Device Non-Volatile Serial ROM Contents
0x00-0x0f: 3c 10 50 16 00 e0 00 00 00 00 80 06 00 f8 00 00
0x10-0x1f: c1 ff e8 10 00 f0 ff 7f 00 f0 ff 7f 00 00 f0 7f
0x20-0x2f: 00 00 f0 bf 00 00 00 00 00 00 00 00 00 00 00 00
0x30-0x3f: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 ff 00
Starship PCI Base Addresses
Base Start Size Mapping Width Description
---- ----- ---- ------- ----- -----------
0 0000ff01 40 Kernel Map 32 bits AMCC Internal Registers
1 f0dfe000 1000 User Map 8 bits PassThru0-Bus FPGA
2 f0dff000 1000 User Map 8 bits PassThru1-Bus Registers
3 f0e00000 100000 User Map 8 bits PassThru2-8 Bit Memory-Mapped Bus
4 f0f00000 100000 User Map 16 bits PassThru3-16 Bit Memory-Mapped Bus
Starship PCI AMCC Register Contents
00=00000000 Outgoing Mailbox 1
04=00000000 Outgoing Mailbox 2
08=00000000 Outgoing Mailbox 3
0c=00000000 Outgoing Mailbox 4
10=00000000 Incoming Mailbox 1
14=00000000 Incoming Mailbox 2
18=00000000 Incoming Mailbox 3
1c=00000000 Incoming Mailbox 4
20=00000000 FIFO port
24=00000000 Master Write Address
28=00000000 Master Write Transfer Count
2c=00000000 Master Read Address
30=00000000 Master Read Transfer Count
34=00000000 Mailbox Empty/Full Status
38=00000000 Interrupt Control/Status Register
3c=000000e6 Bus Master Control/Status Register
Backplane State
connectCount=1, fpgaLoaded=TRUE, fpgaVersion=1
PCIInterruptMask=0x0000 (0000000000000000)
Interrupt Setup
Interrupts are not being used
And "pcipeek":
# pcipeek
Startouch Backplane Found! (frameID=1)
PCI addresses: PAL=f0dfe000
Bus control registers=f0dff000
Backplane 8 bit bus=f0e00000
Backplane 16 bit bus=f0f00000
rockyII> ?
RockyII peekpoke Commands: all numbers are hex
t - toggle between 8 and 16 bit backplane bus r / w access
r XX - read 8/16 bit backplane address XX
w XX YY - write 8/16 bit backplane address XX with value YY
R XXXX - read FPGA/PAL address XXXX
W XXXX YY - write FPGA/PAL address XXXX with value YY
T - toggle between FPGA and PAL for R / W access
a X - set access size to 1, 2, or 4 bytes
c NNNN - set repeat count for read/write operations
d filename - download raw bits (.rbt or .tek) file to PCI FPGA
m filename - download Altera (.ttf) file to Marinade FPGA
s n - select slot n (a..j, 1..4) in cardcage. 0 ==> no slot
D msec - delay time between I/O accesses
v n - set verbosity level to n
i - show PCI configuration info
l - load backplane FPGA and list cage contents
h, ? - this help screen
q - quit
rockyII> l
A: id=0x38 Unknown hardware ID
B: id=0x38 Unknown hardware ID
C: id=0x35 Unknown hardware ID
D: id=0x34 Unknown hardware ID
E: id=0x1b Unknown hardware ID
F: id=0xff Empty Slot
G: id=0xff Empty Slot
H: id=0xff Empty Slot
I: id=0xff Empty Slot
J: id=0xff Empty Slot
1: id=0xff Empty Slot
2: id=0xff Empty Slot
3: id=0xff Empty Slot
4: id=0xff Empty Slot
rockyII>
Those id's above map back to the card product IDs in pv and other utilities. Contents of /usr/sprockets/tools/instrument/16700/productMap (IDs are in decimal):
--- Code: ---# This is a table of product ID codes and their corresponding HP
# product numbers. When we invent a new product (LAX for example), we'll
# need to add it to this lookup table. Until we have time to spend
# truly eliminating the code dependence cycle, this will have to do.
#
# NOTE: the directory name and lib name must be the same, since they're
# pulled from this file as a single name.
#
4 16517 # Roadrunner
5 -1 # Roadrunner expander
13 16532 # Epitaph
14 16534 # Franz
15 16535 # Talons
21 -1 # Old Pattern Generator
22 -1 # Old Pattern Generator Expander
24 -1 # Phaser expander
25 16522 # Phaser
26 -1 # Deep Phaser expander
27 16720 # Deep Phaser
31 -1 # Elan
32 16550 # Socrates
33 -1 # Socrates Expander
34 16555 # Marianas
35 -1 # Marianas Expander
36 marinade # Marinade
37 16710 # Kazon
38 -1 # Kazon Expander
40 -1 # Omega
41 -1 # Omega Expander
42 -1 # Chronicle
44 16715 # LAX
45 -1 # LAX Expander
46 ont # ONT
47 -1 # ONT Expander
48 sfo # SFO
49 -1 # SFO Expander
50 yakitori # YAKITORI
51 kabob # KABOB
52 16718 # Katana
53 -1 # Katana Expander
226 multi # Multiframe
54 16760 # Daytona
55 -1 # Daytona Expander
56 16754 # Wildcat
57 -1 # Wildcat Expander
60 16718 # Yari/Supercharger Rev. 2
61 -1 # Yari/Supercharger Rev. 2 Expander
logic#
--- End code ---
More stuff to play with!
Sorry I can't be more helpful with your 16902A, but I don't think Agilent would delete all this debugging when porting the code. I found clues for most of it by running "strings" on the executables and shared libraries, and then started trying things. Perhaps a similar scan through the windows bits would be enlightening.
EDIT: Fixed couple of minor typos.
MarkL:
--- Quote from: NickAmes on November 27, 2017, 01:07:16 am ---...
Also, some of the bits are oscillating with no cables attached. (Third screenshot.) They looking like they might be physically adjacent on the card.
I can't mess with the threshold settings since I don't have a probe to go on the end of the cable. According to the service manual, the LA communicates with the probe over I2C to identify which type it is. Does anyone have information on what the LA expects to find there? (Perhaps a small EEPROM?) This would also be helpful for people who can't afford the 90-pin probe prices.
--- End quote ---
One thing you can do is buy E5378A adapters (about $20 on ebay) and some Samtec ASP-65067-01 (also on ebay or Digikey) and make your own single-ended probes. Or with a fair amount of trouble, differential probes. The E5378A has a resistor for the probe ID.
Unless you need the speed, extra memory, or differential probing, it might be easier in the end to go with a 16750A/16751A/16752A card with the much cheaper and ubiquitous single ended probes. As per my other post, you can turn any of those into the maxed out 16752A.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version