| Electronics > Repair |
| Series defect on agilent 167xx boards? |
| << < (4/50) > >> |
| 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 |
| Message Index |
| Next page |
| Previous page |