Tektronix 2465B oscilloscope teardown

[AMR Labs]

EDIT:  One more thought before starting down this path... With good data in the FRAM, you could do one power cycle, remove the FRAM, and read it to see if corruption occurred.

If it is of any help, yesterday I went manually through the Exer 02 procedure with the FRAM in place, and all cal data values where still spot on to what I programmed into it, nothing changed. As of today scope still booting up fine.

Is it possible there might be some kind of a Firmware difference in the 2445B that might be causing his corruption problem? I wonder if there are any documented 2445B scopes running FRAMs. As far as I can remember, all the writeups out there seem to refer to '65B scopes.

[MarkL]

EDIT:  One more thought before starting down this path... With good data in the FRAM, you could do one power cycle, remove the FRAM, and read it to see if corruption occurred.

If it is of any help, yesterday I went manually through the Exer 02 procedure with the FRAM in place, and all cal data values where still spot on to what I programmed into it, nothing changed. As of today scope still booting up fine.

Is it possible there might be some kind of a Firmware difference in the 2445B that might be causing his corruption problem? I wonder if there are any documented 2445B scopes running FRAMs. As far as I can remember, all the writeups out there seem to refer to '65B scopes.

That's a good question.  According to the two service manuals I have, the 2445B and 2465B have the same EPROM part numbers 160-5370 and 160-5371 for U2160 and U2260.  The 2445B lists versions -04, -08, and -09, and the 2465B lists versions -04, -05, -08, -09.

So, with the exception of -05 available for the 2465B, they run the same firmware.  The firmware of course discovers which scope it's running on, so it *could* do something different for power-down or other memory handling.  But I'm guessing probably not.

I also don't have the 2445B schematics to look for any hardware differences that would affect the FRAM.  All the on-line 2445B copies that I could find are missing the schematic section.

(If anyone has a copy or could point me to one that would be great.  And, no, I'm not buying one.  I don't have this scope.  Thx.)

[Miti]

Did your FRAM from Digikey arrive in a controlled humidity package like mine did? Maybe yours got a bit wet along the way!   

Yes, it did come in moisture barrier package but that is not important unless you do a reflow in an oven or you use the hot air station to solder it. Soldering one pin at a time cannot damage a part due to moisture and MSL does not affect operation, only reflow.
I just received a new replacement part from Digikey. If it doesn't work, I intend to write a short code on a PIC or Atmel board to test them all.

[Miti]

...
What I mean is, if I program properly the FRAM using the Xeltek programmer (that fully supports it), the first power up is ok, it runs well or at least I didn't see any issues in the short time that I ran it. But once I power cycle, two locations in the calibration constants area, the same locations that can't be programmed with TL866II Plus, are modified. Probably once it does the 0x55 then 0xAA, it cannot put back the original content. But why does it work for some people, that beats me.

So, you're saying the corruption shows up on the second boot.  It's possible the FRAM is getting corrupted during the scope's power-down sequence.  That would also explain why it passes the 0x55/0xAA test; the corruption has already happened.

You could use the PWR DN signal as a trigger and start looking at the behavior of the control signals into the FRAM, including the +5V power, during power down.  Maybe there's something marginal that the DS1225 tolerates.

If you have an MSO or a logic analyzer with enough inputs, you might also try setting up a trigger to capture when the corrupted address in the FRAM is accessed or written.  But keep in mind this could be an analog signal issue and a logic analyzer might not catch it.

EDIT:  One more thought before starting down this path... With good data in the FRAM, you could do one power cycle, remove the FRAM, and read it to see if corruption occurred.

The question is how does it test the integrity of the calibration constants? If it does a CRC, that mean the constants are correct at the first power up. What I will do first is an Exerciser 02 right after the first power up so if the self test corrupts the data, I will catch it.
I don't have a logic analyzer but I do have a Rigol DSO with 4 channels.

[Miti]

I'm trying to raise the unregulated +15V by few hundred mV. For that I want to replace the four diodes in the bridge CR1103 - CR1106 with Schottky diodes. The original diodes are 400V 1A but I don't see the need for 400V. I bought two type of diodes from Digikey and I would like to ask your opinion.
1. STPS1L60RL            60V 1A
2. SB1H100-E3/73       100V 1A

The first one has the lowest forward voltage drop of about 500mV at about 800mA.
I think 60V VRRM should be good enough, what do you think?

[MarkL]

...
The question is how does it test the integrity of the calibration constants? If it does a CRC, that mean the constants are correct at the first power up. What I will do first is an Exerciser 02 right after the first power up so if the self test corrupts the data, I will catch it.
I don't have a logic analyzer but I do have a Rigol DSO with 4 channels.

After the 0x55/0xAA test, which is considered part of the TEST 00 kernel test, it gets to TEST 04, which is a checksum procedure across all the constants (but not the entire 0x1E00 - 0x1FFF block).  It's a read-only test.

If you want to watch this area of the FRAM being accessed, you can run TEST 04 from the service menu, and you can also set the test to loop repeatedly until you stop it.  This is all detailed in the service manual, section 6.

[Miti]

In the end, I've chickened out and I installed the 100V diodes, just to be on the safe side. I still gained 360mV, +15V unregulated is now at 18.76V and U1371 +Vcc Pin 4 is now at 16.3V. The regulated +15V at Pin 2 U1260 is at 15.02V, 14.98V on Pin 6 J119 so is back to "normal", with the normal being too close to the edge for my taste due to crappy design. Interesting, the voltage drop over the R1400 is around 2.46V now, more in line with MarkL's measurements so the fact that the output has some more head room may help.
The FRAM now.
The only location that gets corrupted is 0x1F00, location 80 in EXER 02, validated through EXER 02 and with the programmer.
I ran TEST 04 multiple times after the first power up and passed with flying colours. Once it even passed the second power up but usually, after the second power up, location 80 changes from 0x11 to 0x20.

[MarkL]

I'm trying to raise the unregulated +15V by few hundred mV. For that I want to replace the four diodes in the bridge CR1103 - CR1106 with Schottky diodes. The original diodes are 400V 1A but I don't see the need for 400V. I bought two type of diodes from Digikey and I would like to ask your opinion.
1. STPS1L60RL            60V 1A
2. SB1H100-E3/73       100V 1A

The first one has the lowest forward voltage drop of about 500mV at about 800mA.
I think 60V VRRM should be good enough, what do you think?

I think either would be ok for substitution.  If it were me I'd probably use the 100V one.  The difference in the Vf @ 1A is only 0.06V.

But rather than substituting parts, I would recommend trying to figure out why the unregulated outputs are low in the first place and/or why the other side of R1400 is so low.  The feedback loop only keeps +5VD regulated (U1371C) so there could be excessive current on the unregulated rails and/or something wrong with anything connected to the other side of R1400.  I'm saying "and/or" because it could be two separate problems.  My $0.02.

EDIT: Posted this anyway since I just typed it up.  Glad the new diodes got you the extra margin but I think there's still a problem, albeit masked now.

[MarkL]

...
The only location that gets corrupted is 0x1F00, location 80 in EXER 02, validated through EXER 02 and with the programmer.
I ran TEST 04 multiple times after the first power up and passed with flying colours. Once it even passed the second power up but usually, after the second power up, location 80 changes from 0x11 to 0x20.

My primary suspicion is still that it's happening during power down.  I think something is happening with the FRAM control inputs while the +5 is fading.  They're not being controlled carefully enough for the FRAM while it's transitioning to power off, and it's trashing that location most of the time.

Something similar could be happening on power up, but you said it always works perfectly on the first power up after externally reprogramming the FRAM.


EDIT: The DS1225AB cuts off writes when Vcc reaches 4.62V (typ).  The FM16W08 remains active down to 2.7V, by the time the rest of the chips on that board have already lost their marbles.  The datasheet recommends a pullup from nCE to Vdd, but it's not clear to me that would work here.  FYI.

[Miti]

My primary suspicion is still that it's happening during power down.  I think something is happening with the FRAM control inputs while the +5 is fading.  They're not being controlled carefully enough for the FRAM while it's transitioning to power off, and it's trashing that location most of the time.

Something similar could be happening on power up, but you said it always works perfectly on the first power up after externally reprogramming the FRAM.

That was my suspicion as well but take a look at the power down sequence. The power down sequence happens between PWR_UP going down and RESET going down. +5V Digital is still stable at least 7ms after that. With the scope probes attached, it passed 3 power ups. What a .....

[MarkL]

My primary suspicion is still that it's happening during power down.  I think something is happening with the FRAM control inputs while the +5 is fading.  They're not being controlled carefully enough for the FRAM while it's transitioning to power off, and it's trashing that location most of the time.

Something similar could be happening on power up, but you said it always works perfectly on the first power up after externally reprogramming the FRAM.

That was my suspicion as well but take a look at the power down sequence. The power down sequence happens between PWR_UP going down and RESET going down. +5V Digital is still stable at least 7ms after that. With the scope probes attached, it passed 3 power ups. What a .....

What matters is what's happening on the nCE and nWE pins to the FRAM.  Follow the +5 all the way down to 2.7V while watching those pins.

Once the CPU and other chips get below their specified operating voltages, all bets are off and you best assume their outputs are random unless the power down characteristics are specified, which are for some chips.

[Miti]

Here you go. There are some glitches on nCE but nothing on nWE.

Edit: I guess the question is why does it works for everybody but me?

[MarkL]

Here you go. There are some glitches on nCE but nothing on nWE.

Interesting.  Did this cause a corruption event?  And tried it several times since it doesn't happen consistently?

Does your scope have a PEAK acquisition mode (just to make sure there's not a short pulse lurking in nWE)?

I'm not happy with the glitch on nCE, especially right when chip is transitioning to power down, but as long as nWE remains high I think it should be ok according to the datasheet.

Maybe it's also worth looking at the power-up cycle to make sure there's nothing odd with nWE or nCE there.

Edit: I guess the question is why does it works for everybody but me?

I don't why it would be inconsistent.  Maybe everyone else is getting away with it.  Or there's something wierd about the FRAM.

Have you tried your new FRAM from Digikey yet?  Your likely to get one from the same batch - check the date code.

You said your TL866II had an issue with a location.  Was it also 0x1F00?  Maybe don't let the new FRAM near the TL866II; just use the Xeltek.

[Miti]

Interesting.  Did this cause a corruption event?  And tried it several times since it doesn't happen consistently?

Does your scope have a PEAK acquisition mode (just to make sure there's not a short pulse lurking in nWE)?

I'm not happy with the glitch on nCE, especially right when chip is transitioning to power down, but as long as nWE remains high I think it should be ok according to the datasheet.

It is not the event that caused corruption, I tried multiple times to trigger exactly where I wanted, but it is very consistent. There's nothing on the WE, I acquired 12M points and then I zoomed in. I also tried to trigger on WE, there's nothing.

Maybe it's also worth looking at the power-up cycle to make sure there's nothing odd with nWE or nCE there.

In all my experiments, not once the first power up failed Test 04. I don't think power up is at fault.

I don't why it would be inconsistent.  Maybe everyone else is getting away with it.  Or there's something wierd about the FRAM.
Have you tried your new FRAM from Digikey yet?  Your likely to get one from the same batch - check the date code.
You said your TL866II had an issue with a location.  Was it also 0x1F00?  Maybe don't let the new FRAM near the TL866II; just use the Xeltek.

No, TL 866 can write 0x1F00. I tried both FRAMs, same date code, both fail the same. Xeltek is at work, it is a bit harder to experiment.
Interesting is that the first power up will work well forever....well for 15 min at least with no issues, with the FRAMs from Digikey, but will fail immediately with garbage in the readout with the FRAM from Ebay. That means the FRAMs from Digikey are OK. It is some external event that corrupts the data, most likely power down.

I also have a crazy theory that this is content dependent. My 0x1F00 always changes from 0x11, which is the correct value for that location in my case, to 0x20. Should the correct value be 0x20, probably I wouldn't see this issue until next calibration. I can't see how my scope can be different than others except for the content of the NVRAM

There is a solution though, a NAND gate on FRAM CE with inputs from CPU RESET and CE from the CPU inverted.

[Miti]

I found two easy ways to make it work. It is indeed that glitch that corrupts it.

1. Eliminate the glitch. Solder a 1K resistor series between the nCE pin of the FRAM and the driver U2250. Then connect the nCE pin to pin 6 of U2240. In this way, while the CPU is in reset, nCE cannot be pulled low anymore. Works like a charm even though it doesn't completely eliminate the glitch, it reduces it significantly, see the pictures.

2. Connect a 1K resistor between nWE and +VCC (pins 27, 28) Why didn't I try this from the beginning? After 10+ power cycles still going strong. We'll see for how long.

MarkL,

Apparently there is a glitch on nWE that I cannot catch (I doubt) or it is level that just needs a little pull up.

Edit: The FRAM from Ebay doesn't work with the pull up resistor, so it is a piece of .... Luckily I got a refund..

[MarkL]

Great - glad you came up with a couple of solutions!  The datasheet likes pullups on both nCE and nWE.

I was reading more about FRAM technology.  From the datasheet:

Internally, a F-RAM operates with a read and restore mechanism. Therefore, each read and write cycle involves a change of state. The memory architecture is based on an array of rows and columns. Each read or write access causes an endurance cycle for an entire row. In the FM16W08, a row is 64 bits wide. Every 8-byte boundary marks the beginning of a new row. Endurance can be optimized by ensuring frequently accessed data is located in different rows. Regardless, F-RAM offers substantially higher write endurance than other nonvolatile memories. The rated endurance limit of 10^14 cycles will allow 150,000 accesses per second to the same row for over 20 years.

So, the falling edge of nCE, even without a low nWE, initiates a read/restore cycle.  If it doesn't get a chance to complete the cycle because of power loss, I think it could lose the data.  The datasheet doesn't specify nCE low to power down minimum time, but it does specify a minimum nCE low of 70ns and a minimum cycle time of 130ns.  It's also pretty consistent about keeping nCE held to Vdd during the power down ramp.

This seems somewhat less likely to happen, but still possible.  Maybe it's that short spike on nCE.  But I think the newly found nWE glitch is more likely since the correuption is so consistent.

[Miti]

Thanks MarkL and everyone else who helped me!

After figuring out the FRAM, I recapped the A1 main board, did a CRT adjustment and I checked the horizontal calibration using my Feeltech FY6600. The Feeltech original oscillator has been replaced with a stable TCXO and tuned using the GPSDO so it is pretty accurate, short term.
What I want to say is ....WOOW.
After probably more than 10 years since the last calibration, the horizontal sweep is spot on.
The only issue that I found during the CRT adjustment was that the High Drive Focus was way off, that causing the readout to go out of focus at high intensity.
I could not believe my eyes how sharp this scope is now, at par with Hitachi V-1585, and that is one razor sharp tube.
The trade-off is that the readout best focus is not where the trace best focus is, or it may need some more fiddling with the adjustments.
Oh well, maybe one day when he weather is hot and the sky is blue....For now I'm done.....no, really.

[MarkL]

So the take away from all this is that the FM16W08 FRAM is NOT a reliable drop-in solution for the DS1225 NVRAM.

The Tek designers made sure that the memory control signals were stable up until they knew the DS1225 would be powered down and immune to changes when Vdd reached 4.62V (typ).  Below that, they didn't have to care what the signals did.

But with the FM16W08, it matters.  It's active down to at least 2.7V (there's no Vdd value in the spec for guaranteed off).  A proper solution would be to gate the nCE signal and turn off the gate below 4.62V.  There's plenty of circuit possibilities to do that, but it's more components than a simple drop-in.

It may work for the majority of other people because of differences in the +5 off ramp and how various gates handle under-voltage (non-operating) conditions.  It's possible they're also experiencing writes during power down, but by chance the writes aren't to any of the addresses in the cal data.  The majority of the FRAM is used as system RAM which is set before it's used by the firmware, so they would never know.

[cheeseit]

Maybe, or not a reliable drop-in in a 2445B, right? Are the 2445B/2465B similar in the relevant hardware and code (paths) that this goes for both? Perhaps one or more 2465B owners should take some measurements to determine the behavior upon power down and compare. I have a working 2465B with FRAM but no time for it at the moment. I haven't seen this problem mentioned before so it's worth investigating.

Edit: congrats on the fix and nice work Miti!

[Miti]

You're spot on MarkL. I also think that it depends on the content of that address, in my particular case 0x1F00. If that location happened to be 0x20 in my scope, I wouldn't have seen this issue until, eventually, I recalibrate the scope and if that location's content changes.

The voltage sense has the advantage of not needing any external connection to the FRAM module but I would prefer the reset line to block access to CE and WE when it is active.

[MarkL]

Maybe, or not a reliable drop-in in a 2445B, right?

I don't think so.  The basic problem is putting a FM16W08 in a circuit where the control inputs (nCE, nWE) are undefined during a power down because, in both scopes, the chips driving those inputs are way out of their operating range while the FM16W08 is still listening.

The chips driving on the 2445B are 74LS74 and PLDC20xx, and on the 2465B it's 74HCT74 and PLS153A.  So, that's different chips which could account for the different power down behavior.  There's also probably more revisions of the A5 cards floating around that may use other logic families and PLDs, adding to more behaviors.

But no matter if it works 99% of the time, it's still bad design to leave the power down behavior to chance when it's critical to data integrity.  Put another way, the FM16W08 datasheet is very specific about how to safely do power down, and the 2445B and 2465B circuits which were designed for the DS1225, do not adhere to that.

Are the 2445B/2465B similar in the relevant hardware and code (paths) that this goes for both?

I haven't looked at the NMI power down code.  But by the traces Miti obtained, the problem happens while nRESET is being asserted, so there's no code running at that time anyway.

Perhaps one or more 2465B owners should take some measurements to determine the behavior upon power down and compare. I have a working 2465B with FRAM but no time for it at the moment. I haven't seen this problem mentioned before so it's worth investigating.

I agree, it may be interesting to know exactly how bad it is.  I nominate AMR Labs if the lid is still off the 2465B.

[macboy]

Some time ago I built this Avalanche Picosecond Pulse Generator:

https://entangledwaves.wordpress.com/2013/07/15/avalanche-pulse-generator/

BTW the specified now obsolete 2N2369 transistor is still available at Mouser in TO-18 metal case for about $2, although a usable alternative seems to be a common 2N3904, but the former has a more desirable breakdown characteristic. I did not need to build the DC-DC converter part for the 90V avalanche bias supply, but instead used my Heathkit IG-4505 Scope Calibrator as a power source with the DC output set to the 100V position.

There is also another very well known website on the same subject:
http://www.kerrywong.com/2013/05/18/avalanche-pulse-generator-build-using-2n3904/

Wanted to share pictures of the pulse as shown on both my 2465B and the 2247A, and possibly hear opinions. Cursor time measurement are located between the 10% and 90% points of the rising edge. Thanks.

You can not measure rise time with an impulse. It can only be done with a step. The impulse can only show you the slew rate. The reason is simple: you never see the true "top" of the impulse before it begins decreasing in amplitude causing the scope response to follow. Therefore you can't set the 90% to anything meaningful. This is where the step is used; the top of the step eventually becomes clearly visible, so you can set the 90% mark against this 100% reference. Put another way, knowing that the trace is increasing is meaningless unless you know what point it is increasing toward.

My 2465A (350MHz) had a rise time to a very fast step (<50 ps rise time) of dead on 1.0 ns, and I had also measured the actual -3 dB point at about 375 MHz (using a leveled sine generator). It follows that a 400 MHz 2465B should be about 8.7 ns or so. The apparently significantly shorter response to your impulse generator is misleading and not accurate.

With that said, you can fairly easily convert an avalanche impulse generator to a step generator by substituting the capacitor for a short piece of 50 ohm coax, acting as a charge line. It needs only store a few ns of charge, so with 1 ns per 20 cm, you don't need much at all. (don't go too long, nor pulse too frequently as it stresses the transistor). A follow up Jim Williams app note builds upon his avalanche pulse (impulse) generator to make a step generator using coax as a charge line (AN94).

[g4wyz6]

Hello

What is the model for your earom burner?

As an EBay search came up blank.

73's

Mike G4WYZ

[guido]

The only thing i ever found was here (diy): http://ic-prog.com/index1.htm. ER1400.
Never used it myself yet (have a 2465 with earom).

[Miti]

Hello

What is the model for your earom burner?

As an EBay search came up blank.

73's

Mike G4WYZ

If this question is for me, the programmer that I have at work, and fully supports FM16W08 and many other FRAMs, is a Xeltek Superpro 5000.
The one that I have at home is TL866II Plus. This doesn't support parallel FRAM but if I select DS1225, it can program the majority of the FM16W08 except for few locations, one location being the first in the calibration constants area, 0x1E00. However, that location doesn't seem to trigger a TEST04 error, and the scope works well. There are few other locations that fail to program, but they are in the RAM area so it doesn't matter.