Waveform generator PLL debugging - help with understanding.

[petemate]

Hi guys, I am working on repairing a waveform generator and I could use some help debugging the PLL.

The reason that I am suspecting the PLL to be the issue is because of an "unlocked" light(LED201B) and because of the clock circuit error message shown below. There is only one other clock that I can find(a 10MHz xtal, and that is supposedly running just fine.



Here is a schematic of the PLL - I have colored the trace names according to the scope channel colors of the ANALOG waveform below(not the digital one).



First step in debugging is looking at the control inputs of IC212B, which is an MC145170-2: https://www.nxp.com/docs/en/data-sheet/MC145170-2.pdf The control inputs are supposed to send a number of clock pulses to set the internal registers of the IC, which then compares the 10MHz clock with the clock from the LC filter. But the control inputs do not send anything but a short pulse on all channels:



This puzzles me a bit, as there is no description of the default behavior of the IC in the datasheet. I don't know if the "missing" programming pulses are caused by a different issue also causing the clockcircuit error and hence not trying to lock the PLL, or if whatever default output is missing from the PLL and hence triggering the error.

Anyway, the result of the MC145170-2 is a series of pull-up or pull-down pulses on pin 13(yellow). These are then fed to the integrator(IC214B), which then controls the voltage applied to the varactor diodes, changing the oscillator frequency until stable. At least, that is my understanding.

Probing the analog circuit reveals the following behavior.





At first, it is clear that the output of the integrator(blue) is acting until the input from pin 13(yellow) has reached the reference voltage of the non-inverting opamp input(thats about 1.6V). When that happens, the integrator output drops to zero. But as the integrator input dorps, so should the bias voltage on the varactor diodes(magenta).. Right? It stays at approx 2 diode drops, which makes sense if you consider D201B and D202B. But why isn't it pulled back down, as the integrator output drops to zero? Even stranger is what happens after ~15 seconds, as seen in the second waveform. YELLOW and BLUE drops to zero once MAGENTA has climbed all the way to 2 diode drops.

I am unsure of this behavior.. Am I missing something in my understanding of the PLL circuit? Is there something that comes to mind when you look at the waveforms that just screams "this isn't working"? Is there something on the schematic that you think I should look closer into?

Just to mention it: Yes, I verified all voltages. The 10 MHz reference waveform is injected to pin 1 of the MC145170-2. It is present and is good.

Thank you for your time!

Edit: Sorry, I am somehow unable to figure out how to insert the attachments as inline pictures! I hope you can deduce the order from the numbers

[Kim Christensen]

At first, it is clear that the output of the integrator(blue) is acting until the input from pin 13(yellow) has reached the reference voltage of the non-inverting opamp input(thats about 1.6V). When that happens, the integrator output drops to zero. But as the integrator input dorps, so should the bias voltage on the varactor diodes(magenta).. Right? It stays at approx 2 diode drops, which makes sense if you consider D201B and D202B. But why isn't it pulled back down, as the integrator output drops to zero? Even stranger is what happens after ~15 seconds, as seen in the second waveform. YELLOW and BLUE drops to zero once MAGENTA has climbed all the way to 2 diode drops.

Well, the integrator output (U214 pin6) should be able to go negative relative to ground. In fact, I would expect it to have a negative voltage on it's output during normal operation since varactor diodes are reversed biased in normal operation. Have you checked that there is -15V at pin 4 of U214? When the voltage on pin 2 (inverting input) exceeds the voltage on pin 3 (non-inverting input) of IC214, the output (pin 6) should swing negative towards the -15V rail. In an unlocked condition I would expect pin 6 of IC214 to be either apx -13V or +13V or so... (When the voltages on pins 2&3 are more than a few millivolts apart)

Also, is IC215B oscillating? There should be a waveform on pin 4 (I would guess around 1Vp-p). It should be amplified by IC313B, and appear on pin 4 of IC212B.

EDIT: Is channel 2 on your scope in AC coupling mode?... Chans 1, 3, & 4 appear to be DC coupled.

[petemate]

Well, the integrator output (U214 pin6) should be able to go negative relative to ground. In fact, I would expect it to have a negative voltage on it's output during normal operation since varactor diodes are reversed biased in normal operation. Have you checked that there is -15V at pin 4 of U214? When the voltage on pin 2 (inverting input) exceeds the voltage on pin 3 (non-inverting input) of IC214, the output (pin 6) should swing negative towards the -15V rail. In an unlocked condition I would expect pin 6 of IC214 to be either apx -13V or +13V or so... (When the voltages on pins 2&3 are more than a few millivolts apart)

Also, is IC215B oscillating? There should be a waveform on pin 4 (I would guess around 1Vp-p). It should be amplified by IC313B, and appear on pin 4 of IC212B.

EDIT: Is channel 2 on your scope in AC coupling mode?... Chans 1, 3, & 4 appear to be DC coupled.

Thank you very much for your reply! You are indeed correct that I had CH2 AC coupled. That was embarrassing! The voltage rises to max(approx 12V), after which CH1 starts dropping.



There is indeed +/- 15V on IC214B. The inverting input does indeed start out lower than the non-inverting input(which is just a voltage divider), so I guess the behavior is to be expected; a slowly rising output which saturates(integrator windup?). Only after saturation of the output does CH2 drop again.

Yes, the tank is oscillating at ~23.5MHz. The output of IC215B(which is actually an MC12148 and not MC100EL) measured at pin 6(again, its not the same IC) as ch1 and again at pin 4 of IC212B as CH2:



The service manual says that the PLL should produce an output of 25-50 MHz, so we are in the ball park. However, I am puzzled by the fact that I don't see the oscillator frequency change as pin 6 from the integrator rises. As seen in previous post, the magenta trace climbs to 2 diode drops almost immediately, and then takes a few seconds to stabilize. Would that mean that the oscillator frequency is maxed out? You need higher voltage for lower capacitance and thus higher oscillation frequency, right? And the 2-drop limit is to prevent the diodes from being forward biased?

Thanks again for your time!

[Kim Christensen]

The service manual says that the PLL should produce an output of 25-50 MHz, so we are in the ball park. However, I am puzzled by the fact that I don't see the oscillator frequency change as pin 6 from the integrator rises.

Having channel 3 (magenta) connected to the anodes of the varactor diodes (D203-D206) might be interfering with the oscillator. I would disconnect that test point since you're already monitoring PLLCTL-B which shouldn't really have a different DC voltage on it since no appreciable current should be flowing through R235 & R237 when the voltage there is between +1V and -15V.

 

As seen in previous post, the magenta trace climbs to 2 diode drops almost immediately, and then takes a few seconds to stabilize. Would that mean that the oscillator frequency is maxed out? You need higher voltage for lower capacitance and thus higher oscillation frequency, right? And the 2-drop limit is to prevent the diodes from being forward biased?

When the voltage at PLLCTL-B (And thus the voltage at the anodes of D203-D206) is up at +1.4V then the oscillator should be at it's lowest frequency.
When the voltage at PLLCTL-B (And thus the voltage at the anodes of D203-D206) is down at -15V then the oscillator should be at it's highest frequency.
If you wanted to, you could force the output of IC214B (pin 6) to swing negative, and thus raise the VCO frequency to it's max, by bridging IC214B pin 2 (inverting input) to the +3.3V rail (IC213 output pin 2). Use a resistor (330 ohms or so) to bridge it, and measure the voltages first just to be safe and not blow anything up accidentally.

Yes, the two diode drop limit is to prevent forward biasing the varactor diodes.

Rereading your original post, the problem might be that IC212B (MC145170) is not being programmed/setup properly and is trying to drive the VCO out of range. When the unit is commanded to change frequency or first turned on, it should send a bunch of serial data to pin 5 of IC212B and some clock pulses to pin 7 of IC212B. And while it's sending that data, it should have toggled pin 6 low, and then when done sending toggle pin 6 high again. (Trigger scope on IC212B pin 6 going low to see this clock and data)

[petemate]

Thanks again for taking the time to help me out!

I have tried without having the magenta channel connected directly to the probes. No change, unfortunately. I might try forcing a negative voltage, just to see if I can get a lock.

Rereading your original post, the problem might be that IC212B (MC145170) is not being programmed/setup properly and is trying to drive the VCO out of range. When the unit is commanded to change frequency or first turned on, it should send a bunch of serial data to pin 5 of IC212B and some clock pulses to pin 7 of IC212B. And while it's sending that data, it should have toggled pin 6 low, and then when done sending toggle pin 6 high again. (Trigger scope on IC212B pin 6 going low to see this clock and data)

I agree. There is nothing but a pulse on the three digital pins(very first waveform in the post). But the only other clock generator(the 10Mhz that is also a reference to the PLL) is present and fed to the FPGA responsible for controlling everything. So if it is indeed the question that there is no lock because of no data to IC212B, then it is caused by the FPGA not doing its job. And that is going to be hard to decode, as I have no knowledge of its internal workings.. But its doing everything else right, so far..

[Kim Christensen]

I agree. There is nothing but a pulse on the three digital pins(very first waveform in the post). But the only other clock generator(the 10Mhz that is also a reference to the PLL) is present and fed to the FPGA responsible for controlling everything. So if it is indeed the question that there is no lock because of no data to IC212B, then it is caused by the FPGA not doing its job. And that is going to be hard to decode, as I have no knowledge of its internal workings.. But its doing everything else right, so far..

The "clock" probably comes from the same CPU/MCU/controller, via one of it's peripheral chips, that is sending the ERROR 201 to the LCD driver chip. What you have there is basically one way SPI communication from the CPU/MCU to IC212B. (No CIPO line) The clock can be quite slow so try slowing the horizontal sweep down a bit more.

[petemate]

In case you want to dig deeper, I have attached the service manual schematics. I can't attach the entire manual, as it is too big.

As you can see, the FPGA on sheet 1 is responsible for communicating with the PLL through PLLD-B, ~PLLLD-B and PLLC-B. I would expect that the ARBCLOCK, which is the final output from the PLL and which is used in the FPGA(pin 213, called MCLK) to be the cause of the clock fault error. There are only two other clock signals going to the FPGA, which are the "2MHz" signal(generated by mcu timer) and the 10MHz "BUSCLK" signal which is produced by the 10 MHz xtal on top left of page 1. Bot the 2MHz and the 10MHz clocks are available to the FPGA. Hence, I believe that the "missing" CLK from the PLL is the cause of the critical clock error, as all other clocks appear to be there.

The FPGA is (as far as i can tell, since I can't decode the serial data) programmed correctly by the mcu through FPGACCLK, FPGAPROG and FPGADIN signals, and the LED "done" also changes state when programming is completed. The FPGA does also turn on/off a relay somewhere in the signal chain. However, the LED on pin 173, marked "LOCK" on the pcb silkscreen never changes state, meaning that something.. well, doesn't lock. Since the PLL LED doesn't lock either, I'd expect the PLL to be the culprit. But as you can see, its hard getting to the bottom of what is going on.

I think I should trace out the relay which changes state. Maybe the clock fault error(which is only described in the user manual: https://resources.aimtti.com/manuals/TGA12100_Series_Instruction_Manual-Iss10.pdf) is a generic hardware fault error that could be related to the circuit operated by the relay.

It could also be that the DAC doesn't generate a signal needed for internal calibration or something, but the DAC does indeed receive its clock. But no data to turn into analog values. Again, the FPGA isn't doing its thing.

Furthermore, there is some sort of lock-up going on with the mcu. Following the critical clock fault error, it throws errors about being uncalibrated and bat/ram/firmware update error, and then it locks up. I am expecting this to be the result of the FPGA/clock circuit not completing its job, but it could also be the other way around..

As you can see, still at lot to dig into! Let me know if you have any suggestions Thank you for your time!

[Kim Christensen]

I would expect that the ARBCLOCK, which is the final output from the PLL and which is used in the FPGA(pin 213, called MCLK) to be the cause of the clock fault error. There are only two other clock signals going to the FPGA, which are the "2MHz" signal(generated by mcu timer) and the 10MHz "BUSCLK" signal which is produced by the 10 MHz xtal on top left of page 1. Bot the 2MHz and the 10MHz clocks are available to the FPGA. Hence, I believe that the "missing" CLK from the PLL is the cause of the critical clock error, as all other clocks appear to be there.

Hmm... But ARBCLOCK is there isn't it? It's just the wrong frequency (~23.5MHz).. So I assume that 23.5MHz is getting to FPGA pin 213 (MCLK) correct? This is where the error message's (201 CRITICAL STOP! Fault in clock circuit of channel 1) true origin confuses me a bit... Because the PLL has no way of signaling to the rest of the circuitry that it's out of lock, since pin 11 of IC212 just goes to a LED.
Unless the FPGA can detect that the ARBCLOCK is out of range or something. Did you ever try to swing the PLL frequency a bit higher yet?

It could also be that the DAC doesn't generate a signal needed for internal calibration or something, but the DAC does indeed receive its clock.

Do you mean IC304B? Because that one receives it's clock from the FPGA. I would have guessed that this is the origin of the 201 error message on the LCD.

A puzzle indeed!

[petemate]

Hi again, sorry about the disconnect in our conversation! I had some pet emergencies over the weekend and just now got around to trying to tie the inverting input to 3.3V.

Hmm... But ARBCLOCK is there isn't it? It's just the wrong frequency (~23.5MHz).. So I assume that 23.5MHz is getting to FPGA pin 213 (MCLK) correct? This is where the error message's (201 CRITICAL STOP! Fault in clock circuit of channel 1) true origin confuses me a bit... Because the PLL has no way of signaling to the rest of the circuitry that it's out of lock, since pin 11 of IC212 just goes to a LED.
Unless the FPGA can detect that the ARBCLOCK is out of range or something. Did you ever try to swing the PLL frequency a bit higher yet?

Yeah, pulling inverting input of IC214B to 3.3v through a 330ohm resistor does indeed pull the PLLCTL-B line down and puts -13V on the anode side of the varactor diodes. This results in a frequency of approx 60MHz on the output of IC313B as well as ARBCLK. Still no lock.

Interesting part is that the frequency stays at 60MHz when the 330R resistor is removed. This indicates that there is actually no output from IC212B and its output is indeed supposed to be high-impedance when nothing is going on, doing only high/low pulses to correct the integrator. Probably, leakage causes the values I end up seeing when not applying the 3.3V. In my opinion, this clears the PLL system since it simply isn't turned on yet(we sort of knew that by the fact that it doesnt get programmed by the FPGA - but we didn't know if the FPGA was listening for some initial value)

It could also be that the DAC doesn't generate a signal needed for internal calibration or something, but the DAC does indeed receive its clock.

Do you mean IC304B? Because that one receives it's clock from the FPGA. I would have guessed that this is the origin of the 201 error message on the LCD.

Yeah, that would be my guess as well. There is a 47MHz clock(sounds like a doubling of the 23.5MHz PLL) present on the CLK inputs to the IC304B, but no data on its input, so output stays at zero. The FPGA does listen for zero-crossing and if that isn't there, who knows..

A puzzle indeed!

Indeed! And I am also now seeing some sort of lock-up during start, before all the error messages - probably from not having messed around with the device for a few days. I have to on-off-on-off it a few times before something appears on the LCD, though the relays are clicking.

[Kim Christensen]

Yeah, pulling inverting input of IC214B to 3.3v through a 330ohm resistor does indeed pull the PLLCTL-B line down and puts -13V on the anode side of the varactor diodes. This results in a frequency of approx 60MHz on the output of IC313B as well as ARBCLK. Still no lock.

I assume you mean no lock from pin 173 on the FPGA. I wouldn't expect a lock from the PLL ( IC212 pin 11) while doing that. But's good to see that the VCO and integrator appears to be OK.

Indeed! And I am also now seeing some sort of lock-up during start, before all the error messages - probably from not having messed around with the device for a few days. I have to on-off-on-off it a few times before something appears on the LCD, though the relays are clicking.

It's a bit of a long shot, but is the RAM backup battery dead? And/or is the circuitry switching the +3.3V to/from battery for the RAM (IC16-17) and the RAMSAVE line on reset working OK? If Q13/14 and associated circuitry wasn't working properly, I could see that causing intermittent issues. Low hanging fruit to check.