Electronics > Repair

LeCroy Waverunner 6200 Repair

(1/7) > >>

I recently acquired a Lecroy Waverunner 6200 in non-working condition and have been working on it on and off for a couple months with no luck. I've included screenshots of relevant areas of the service manual and schematics in the post but full service manual and schematics can be found on KO4BB. Any help would be greatly appreciated!

Initial Symptoms:
When I first got it, it still had Windows 2000 which started but refused to boot. My initial thoughts was that it was probably just a corrupt windows installation so I saved an image of the original hard drive (including all the calibration data) and upgraded it to Windows XP with an SSD. When it came to installing all the scope software it would crash near the end of the software installation (entire PC would freeze and become unresponsive, requiring a hard power restart). After some software trouble-shooting I found that it crashed specifically when it went to install drivers for the LeCroy S65 PCI device, which is the PCI card that links the PC portion of the scope to the acquisition portion. I could reliably replicate the crash by trying to install the drivers manually using either LeCroy's provided driver installation in the software directories or Windows automatic driver detection and installation that now appears on startup.

The X-Stream software starts but raises the error of "No hardware detected, not authorised to run on this system" (exact wording might be different, writing this from the top of my head). I suspect that this is primarily just caused by the lack of the PCI card driver meaning that the software has no way to communicate to the acquisition board.

Initial troubleshooting of checking all the voltages (were done at either output of regulators or main power supply connectors) and various clocks were done (except the 10Ghz clock as I have no equipment to test that).

The debugging guide in the service manual point towards replacing the PCI card and the entire acquisition system but I think we can do a bit better than that. The theory operation in the service manual points out that on startup there should be two beeps which indicate a good "connection" between the PCI card and the acquisition system (denoted by MB, not the computer MB), I don't get any beeps with my scope so indeed there is a problem with the LVDS connection between the PCI card and the MB. I confirmed that there is indeed a problem with the LVDS communication by probing the LVDS lines and there is indeed no communication between PCI and the MB, on startup all the data lines and the reset error line (almost) immediately go high, with only the sync and clock lines actually having any signal. More on probing and JTAG later.

The entire architecture of the PCI card and the MB is composed of 3 Xilinx XC2S200E's, a PQ208 quad flat pack on the PCI card and 2 BGA FG456's on the MB. From the service manual, the one on the PCI card acts as a transaction repeater for the PCI interface. On the MB there is one FPGA which acts as the main control FPGA and the other FPGA doing something to do with the timebase. The FPGA on the PCI card communicates with the control FPGA via LVDS which is connected using 2 forty pin special ribbon cables. (Note: these can be easily probed at from the PCI card connector which is TH). See various block diagrams below:
System block diagram:

MB block Diagram:

Given these were FPGA's I chased a red herring checking if they were configured correctly with proper bitstreams. From the schematic and probing they all operate in Slave Serial mode and are configured externally by an Infineon C161PI microcontroller on the MB. The FGPA on the PCI card is configured first using a separate CCLK line with a shared DIN line, then the two on the MB are configures in a serial chain. From what I can tell by directly probing the DIN and various CCLK lines as well as looking at the DONE signals by the FPGA's, they are all configured correctly. This is also indicated by a red LED on the MB which goes off after the FPGA's have been configured (released DONE from a low state).

I managed to get JTAG access to all the PCI card FPGA and the control FPGA, the other devices on the MB had some weird JTAG configuration with certain populated and unpopulated zero ohm jumper resistors which I couldn't figure out. From the JTAG access I performed boundary scans on both FPGA's and indeed there is no LVDS communication at all as confirmed by directly probing the LVDS lines from the PCI Card connector. From probing directly I can see that the FPGA's initialise the LVDS data pins in that they drop down from the main supply voltage to a low LVDS level for 400ns before going to a high LVDS level with no further activity or data at all. This is the part which confuses me a bit, I would have expected that they try to do some sort of handshake or something like that but from what I can see, they don't "attempt" to transfer any data at all, just immediately going high. The LVDS clock and sync signals are always present though. See the schematics below.

PCI card Troubleshooting:
From the boundary scan of the PCI FPGA, I can see all the relevant PCI activity when windows communicates during startup and driver installation (when it crashes). So in the below schematic, the left hand side with the PCI interface looks to be working, but there is no activity on the right hand side with the LVDS interface.
As a note I thought RX_TXSTABLE, RX_RXSTABLE, TX_TXSTABLE, TX_RXSTABLE (pins 38,40) on J1, J2 of the LVDS interface, might have something to do with a handshake of some sort but I couldn't figure anything out. They all have pullup resistors to 3V3 (some on PCI card and some on MB) and RX_RXSTABLE and TX_RXSTABLE are high while the other two are low. But I couldn't figure anything further than that out.
PCI Card Schematic:

Control FPGA Troubleshooting:
Also, from the boundary scan of the control FPGA, I can see the relevant activity on the MAM_IN and MAM_OUT buses (8B/10B Gigabit Ethernet) which goes to and from the actual acquisition devices (ADC and acquisition memory readout) as well as the UC_D and UC_A (Parallel interface) which is communication to and from the C161PI microcontroller. However, there is also a number of devices for which there is seemingly no activity to and from the control FPGA. There is no activity for all of the following items.
- As mentioned previously, there is no activity on the LVDS lines, LVDS_IN and LVDS_OUT. Apart from the LVDS clock and sync lines.
- There is also no activity in the SDRAM interface. According to the theory of operation the SDRAM is used for timestamp in sequence mode. Which given that the scope hasn't triggered might be correct that there is no activity??
- JTAG interface to timebase FPGA and acquisition system, according to theory of operation, the control FPGA uses JTAG as a "serial interface to communicate" with the devices. Might not be an issue as we aren't receiving any commands to relay on to the timebase or acquisition system??
- SPI interface for control of DAC's and Front End. Again might not be an issue that there is no activity as we aren't changing any of the FE settings??
- some interface to the timebase FPGA, no clue what type of interface this is but also not present. Could this be the issue??
See schematic below for control FPGA section:
Control FPGA Schematic:

Anybody have any pointers on what might be wrong or where to look next? Or if anybody with a working scope can probe the start of the LVDS lines or the RX/TX_STABLE lines that would be great. Any commentary or help at all would be greatly appreciated!

Hello, if I can help you with an image of a working XP device, I would create it for you.

Thank you for the offer! But I don’t think it’s a software issue unfortunately. I think I’ve already got the correct drivers and software from the LeCroy website.

On PCI card 1.8V supply is spot-on ?
What does the FPGA fetch from U11 - DS2433 ?
I once had a DSO dead to windows because the PCI board couldn't load configuration from a defective I²C EEPROM. It wasn't a LeCroy.

PCI Card 1.8V rail is spot on.
Forgot to mention in the initial post but one of my initial suspects was the EEPROM as well. I ended up pulling it from the board and was able to read the Scope ID and options so I assume it's fine as well. Additionally, I read from the LeCroy "options" thread on the forum that others who had messed with the EEPROM to enable certain options just cause the scope to enter some sort of demo mode and not the no hardware authorised error.

Also, I hooked up a UART adapter to the RS232 port of the C161PI microcontroller (according to service manual it's used to program flash storage) and got the following output:

Seems like the microcontroller can't get the various ID's of the FPGA's? But could this just be related to the lack of communication with certain things on the control FPGA?


[0] Message Index

[#] Next page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod