Author Topic: Just got a Tek 2465A, couple questions (how I screwed the calibration data)!!  (Read 13032 times)

0 Members and 1 Guest are viewing this topic.

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Thanks for the data usuthu65, and for transcribing it alpher.

I still can't get the checksum to match.  Maybe I'm looking at dead code in the EPROM and the firmware is using a different subroutine.

Although it's out of the block for the checksum (0B to AA), there is one error in the transcription that I found.  Exerciser location ED is 9186 (not 918F).

The parity on locations 01 to 6E is good.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Thanks Mark, appreciate you catching my mistake. :)
I will try to program the sram tonite, worse come to worst I'll just change it to dallas chip and be over with it.
I've edited my previous post with the correct ED value both in the listing and the included bin file.
Just a thought, maybe your firmware dump doesn't match the ram ( i.e. is from different revision or something) ?
Would you like me to post a firmware dump from my scope?
« Last Edit: March 29, 2018, 05:26:00 pm by alpher »
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
...
Just a thought, maybe your firmware dump doesn't match the ram ( i.e. is from different revision or something) ?
Would you like me to post a firmware dump from my scope?
That's always possible.  If you want to post it, I'll see if I can locate the checksum routine in it.  But without an actual 2465A and logic analyzer in front of me it's impossible to say what it's really doing.

Since you have an EPROM burner, it should also be possible to burn a little program in a spare EPROM that just writes the 512 bytes to the SRAM at 0x1E00.  Unplug the real EPROM, plug in the SRAM restorer, power it up for a moment, and then put the real EPROM back.

I can look at hacking together an EPROM image if you want to try it.  Or if you know 6800 assembly, go for it.  Just look out for the 2465A memory mapping.  It's bank switched.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
...
Just a thought, maybe your firmware dump doesn't match the ram ( i.e. is from different revision or something) ?
Would you like me to post a firmware dump from my scope?
That's always possible.  If you want to post it, I'll see if I can locate the checksum routine in it.  But without an actual 2465A and logic analyzer in front of me it's impossible to say what it's really doing.

Since you have an EPROM burner, it should also be possible to burn a little program in a spare EPROM that just writes the 512 bytes to the SRAM at 0x1E00.  Unplug the real EPROM, plug in the SRAM restorer, power it up for a moment, and then put the real EPROM back.

I can look at hacking together an EPROM image if you want to try it.  Or if you know 6800 assembly, go for it.  Just look out for the 2465A memory mapping.  It's bank switched.

Ilike the SRAM restorer idea quite a bit, unfortunately my assembly skills are, how should I put it, nex to nill.
Last time I coded anything was a looong time ago.  :) :) :)
If you wouldn't ming posting an image though I have plenty of spare EEPROMs.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
...
If you wouldn't ming posting an image though I have plenty of spare EEPROMs.
Ok, here you go.  It should be writing usuthu65's data.

I don't know if it should go in U2160 or U2260 because I don't know which EPROM is selected at boot time by PAL U2250.  I guess try U2160 first.

It won't blink lights or anything.  If I got at least some of it right U2310 pin 12 should go high since that enables the SRAM.

I'm flying totally blind here.  I can't test it.
 

Offline usuthu65

  • Newbie
  • Posts: 8
  • Country: us
Hi all,

Glad my data is of some use!

Regarding the inability to compute the checksum, is it useful for me to repeat the Exerciser 02 video to see whether something has changed in the data (i.e. to get a handle on where or what the checksum is doing)? Or do we not expect any changes?  I'm happy to repeat the process if you would like.  Just let me know.

Cheers.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Hi all,

Glad my data is of some use!

Regarding the inability to compute the checksum, is it useful for me to repeat the Exerciser 02 video to see whether something has changed in the data (i.e. to get a handle on where or what the checksum is doing)? Or do we not expect any changes?  I'm happy to repeat the process if you would like.  Just let me know.

Cheers.
I don't want to waste your time.  The checksum program failed on two different data sets, so it's probably something I'm doing wrong.

The data should be the same from run to run, but if you find yourself with some spare time and you want to verify it, it would be good to know.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
I've played with my programmer/ cable-clip a little tonight and quite frankly I lost confidence in this whole setup, let me elaborate.
First thing I noticed is that even though programer complains about mismatch after just a few bytes (like 1D), it actually programms the whole chip, just with almost every second byte being higher by 1 (like LSB being stuck high but only every second  or fourth location) ? :-//
Now is it happening during read or write is hard to determine, I know the programmer does work mostly fine using the zif socket, checked the cable/clip assembly a few times with a meter and they check out fine every time. I've programmed EEPROMS in circuit using this very clip mostly OK, (sometime it does error out).
I've jumped the CS2 to Vcc with 10 ohm resistor this time, the result is in the 2465A usuthu65 written-read zip file.
I've also tried Mark's test program in both locations 2160 and 2260, the resulting reads are the same as for direct writes with my programmer.
I've actually went full medieval with 2465a_test_1 , found an ancient 27512, erased with UV eraser that hasn't been used for ~10 years, programmed and voilla!! :) :) :) :) :)
Unfortunately when it was all said and done, still " TEST 04 FAIL 13>:(
I thing I'm going to wait fot the dallas chip that I've ordered, should be here after the weekend, at least I'll have a guarrantee that I'm reading the memory right.
Could be that the actual SRAM is defective? We'll see.
Attaching also firmware dump from my scope.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Actually, I will read the very U2160/2260 through the cable/clip assy.
See if it matches, this way I will know if at least reading works right.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Bummer that didn't work.

So... When you tried 2465a_test_1, did it write the usuthu65 data correctly?  Did you check it via your programmer or via the exerciser?  Maybe try a spot check on some of the values via the exerciser without the programmer attached.  Maybe it's interfering.

You can also use the exerciser to determine if the programmer is writing correctly.

It doesn't seem likely the SRAM is bad since you started with a working scope.

Another explanation is that there's more data somewhere besides this block that it's checking.

I will look at the firmware dump tomorrow.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Well, the verdict is in, guilty as charged!! See the attached zip file.
I actually read the very test file that Mark made, and I programmed into EPROM.
As you see the data read through the zif socket matches, through the clip doesn't (interestingly enough the actual program does match ).
In any case I cannot rely on the reading done with the clip/cable assy.
Will wait for a dallas chip, desolder the SRAM chip, solder a socket and play again.


« Last Edit: March 30, 2018, 03:26:25 am by alpher »
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Bummer that didn't work.

So... When you tried 2465a_test_1, did it write the usuthu65 data correctly?  Did you check it via your programmer or via the exerciser?  Maybe try a spot check on some of the values via the exerciser without the programmer attached.  Maybe it's interfering.

You can also use the exerciser to determine if the programmer is writing correctly.

It doesn't seem likely the SRAM is bad since you started with a working scope.

Another explanation is that there's more data somewhere besides this block that it's checking.

I will look at the firmware dump tomorrow.

I haven't thought about that, will do it tomorrow.
You're most likely right, which means that I just srewed it it up even more. Who knows what else was stored in the SRAM originally.
I've noticed that the area that doesn't change between powerups starts quite a bit before the calibration constants reside.
Anyway to confused now to continue, time for a beer and bed. :palm:
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
If you have the patience for it, it would be good to know if 2465a_test_1.bin was successful in writing usuthu65's data as verified by the exerciser.  No programmer connected.

You can check if 2465a_test_1 ran by seeing if U2310 pin 12 is high after you power up the scope with the 2465a_test_1 EPROM in U2160 or U2260 (again, I don't know which is the boot socket - might have to try both).  You should also remove both original EPROMs when doing this.

If U2310 pin 12 is not high, I got something wrong.  All bets are off.

If U2310 pin 12 is high, put the original EPROM back and look at the exerciser.  If the exerciser data matches usuthu65's data, and you still get TEST 04 FAIL 13, then we have a problem.  We've put back the 512 bytes and it's not sufficient.

Unless we can find something we've done wrong in the data, it also means all those people who have backed up their 2465A/B cal constants with a video capture don't actually have enough data to restore their scope in case of a battery failure.


Also, I looked at the firmware dump you posted.  Unfortunately, the checksum routine is the same as the one I've been looking at, just in a slightly different location (in U2260 at 0xa444 - 0xa469).  Again, I can't tell if this is even being used or if there's more SRAM outside this block it's looking at.


Attached is 2465a_test_2 which is the same as 2465a_test_1, except using z01z's data, if you want to try that.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Uff, this morning I've had some time to do more testing.
I did an exerciser 02 to check the calibration data writen to the SRAM after I tried MarkL's program burned to eprom.
The results are here:

https://youtu.be/XXkezTZN4Ik

Usuthu65's calib data looks like this :
Code: [Select]
Offset(h) 00   02   04   06   08   0A   0C   0E

00000000  00CD 06DC 26DB 06C1 268B 265A 06FD 270E
00000010  2702 06F8 06E3 21BA 01C5 21C4 21C1 01DB
00000020  01F3 0203 2204 2202 221A 2081 001C 001A
00000030  001F 201E 1BE3 3D44 1CAC 1D25 1FAC 1FC6
00000040  3FAD 3FA7 1FBD 0247 0247 2237 0242 3CB0
00000050  1E0D 1CF6 1000 3FAD 1FA6 3FB0 1F9F 3FB5
00000060  22E3 22E3 22E0 02DE 071B 084E 283B 282C
00000070  281F 083A 0828 205F 2849 2832 282A 281C
00000080  082E 281C 2060 2344 0331 2330 266C 0654
00000090  266A 0679 229E 22D0 1815 2ED0 0E9C 2726
000000A0  2725 020F 222F 214C 2132 0444 2633 03B3
000000B0  0331 049A 246E 236C 2514 27FE 27FE 27FE
000000C0  039E 059D 03A2 22F1 248A 06F8 0568 2770
000000D0  079F 26EE 27FE 02DD 00BC 00C1 20A5 005F
000000E0  5301 8CFA DC07 A720 5BE5 6556 FA65 188A
000000F0  FA00 40FF FF20 00DE FBC0 009E E620 18AF
00000100  EFC7 23CF B40E EDEA 7130 889E DC52 47DD
00000110  FF31 30FF DB00 86DE F7B2 5CF9 DF24 40F6
00000120  B24B 8E8C FAFC ED7B D91D 83E7 6D81 E1A0
00000130  EF10 6031 FC04 687A FF08 007E DB0A 04DD
00000140  BB24 82D7 EC33 0AD7 2E95 23EC 5F3F 44F1
00000150  B300 01FF 2501 A4F7 3D03 027F FD15 00DF
00000160  22C9 AB16 D60C 0A2B E525 84D5 D241 9E9D
00000170  FF04 00D9 6F1A D5FD 6302 70FD DB80 027D
00000180  86DA 4A9D F656 EED9 A40D 0EC9 BBE2 9CDF
00000190  7218 13FF 7D08 18BB E708 10FE 6D85 20F7
000001A0  EC2A 9C60 F443 0EDC BC6E C59A 873F A2A6
000001B0  FD80 6493 7F01 6963 FB86 0C3F E718 80DF
000001C0  C1A0 C4CF 2588 0553 7351 03FB DF23 A734
000001D0  FF42 44FF DF08 41FF DD80 9186 9F91 04B7
000001E0  E349 A5C4 C1AB 7D0B 3746 429D 7019 E5D3
000001F0  FF84 4EBF FF10 25FF FD04 81BF 1AFE 0000

So as you see the data is close but still differ . I tried the second bin provided by MarkL :
2465a_test_1, using z01z's data. This time I tried it monitoring pin 12 of U2310 , run it in both sockets U2160 and U2260.
Both times the pin didn't go high and nothing has changed as far as calibration constants go ( I just run the exercizer 02 each time).
So unfortunately the program doesn't write the SRAM, the values in exercizer must be a remnant of me playing with the flaky programmer/clip combo.
Wondering if there is some sort of hardware write protection to this memory area?
Maybe I should try MarkL program with the P501 in DIAG position and/or P503 in CAL ?
Somewhat reluctant to do it, but at this point I guess there's not much more to lose?
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Ok, I have a modification for you to try if you're still willing to be in the middle of the debug cycle for this little piece of code.

I didn't notice before how A15 was wired up on the EPROMs.  It is low at reset, which means Tek must have the lower half of the EPROM mapped to the high address space of the processor.  So, I don't think the processor is getting to the boot vector in the code I wrote to kick everything off.

I've taken the same code and replicated it verbatim in both 0x0000-0x7fff and 0x8000-0xffff.  So now it appears in both halves of the EPROM no matter what's going on with A15.

I still don't know exactly what the PAL is doing with the select lines, but this has a better chance of working since the PAL doesn't care what's happening in 2048 byte chunks (address lines A0 - A10).  I've attached 2465a_test_3.bin which is replicated from 2465a_test_1.bin (usuthu65), and 2465a_test_4.bin which is replicated from 2465a_test_2.bin (z01z).

You're right, you have nothing to lose, but the DIAG and CAL jumpers shouldn't make any difference.

I've also located a used 2465A processor board for cheap on ebay.  I should be able to figure out the whole boot sequence definitively once it gets here, but it's from overseas and may take a week or two.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
I've tried the 2465a_test_3.bin in both sockets U2160 and U2260 four times, once with jumper P503 in normal position and once in CAL, 4 times no-go.
Pin 12 of U2310 goes up to ~ 1V, looks like something is pulling it down?
Anyway I've tried it a few times pulling ROMs, putting them back between the trials, running excersiser 02 of course.
No matter what I did it did not write SRAM!! >:(  Decided in favour of "atomic" option, dumped the SRAM and installed the NVRAM, ST equivalent of Dallas 1225 chip, here are some pics:











Of course I programmed the NVRAM with an image with modified calib. constants, used usuthu65 values.
The result of the scope boot up is here:



So no more test 04 fail, looks like that was taken care of the calibration constants from usuthu65's scope.
Guess I have to readup on the options for the 2465A, mine is a CT version and that obviously is a problem.
Good news for people that backed up their calibration constants via excersiser 02 or othervise is that once properly written back to the memory you'll probably going to be god to go. For me not so much as I have yet to see an CT version of the calib. constants posted. Really appreciate if anyone with a 2465A CT is willing to run the exreciser 02 and post the footage, that would be great.
Anyway some progres finally. :)
« Last Edit: April 03, 2018, 01:24:29 am by alpher »
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
I've tried the 2465a_test_3.bin in both sockets U2160 and U2260 four times, once with jumper P503 in normal position and once in CAL, 4 times no-go.
Pin 12 of U2310 goes up to ~ 1V, looks like something is pulling it down?
Anyway I've tried it a few times pulling ROMs, putting them back between the trials, running excersiser 02 of course.
No matter what I did it did not write SRAM!! >:(  Decided if favour of "atomic" option, dumped the SRAM and installed the NVRAM, ST equivalent of Dallas 1225 chip, here are some pics:
Oh well,  I really thought I had it that time around.  I wish I had a way to test it.  Thanks for giving it a try.  I did find the programming info for the PAL, and U2160 is the boot socket, FWIW.  The remainder of the description in the service is consistent with the PAL programming.

I wonder if it's stuck in a loop and U2310 pin 12 actually has a pulse on it.

Maybe I'll figure it out when my 2465A controller board gets here.  I'm still interested in knowing what was wrong.  I'll post any results here for future 2465A users.

But I'm glad you were successful with the posted calibration constants (except for the CT, that is).

The CT is pretty easy to calibrate.  All you need is an accurate 1MHz 1Vp-p square wave.  I'm not sure about error code 81 03, however.   It's not listed in the manual I have.  Maybe my version from Jun 87 is outdated.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
I've tried the 2465a_test_3.bin in both sockets U2160 and U2260 four times, once with jumper P503 in normal position and once in CAL, 4 times no-go.
Pin 12 of U2310 goes up to ~ 1V, looks like something is pulling it down?
Anyway I've tried it a few times pulling ROMs, putting them back between the trials, running excersiser 02 of course.
No matter what I did it did not write SRAM!! >:(  Decided if favour of "atomic" option, dumped the SRAM and installed the NVRAM, ST equivalent of Dallas 1225 chip, here are some pics:
Oh well,  I really thought I had it that time around.  I wish I had a way to test it.  Thanks for giving it a try.  I did find the programming info for the PAL, and U2160 is the boot socket, FWIW.  The remainder of the description in the service is consistent with the PAL programming.

I wonder if it's stuck in a loop and U2310 pin 12 actually has a pulse on it.


Don't think so, I have a Rigol 1054Z and it was setup to single shoot at 2v on pin 12 of U2310, never did.
I'm on the opinion that there is some sort of write protection of the calib. data under normal operation.
It may involve the PAL, who knows. To me it makes sense, if I was the one developing the software for such a machine, I certainly would've want some sort of hardware protection against accidental writes to the calibration data memory area.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
Don't think so, I have a Rigol 1054Z and it was setup to single shoot at 2v on pin 12 of U2310, never did.
I'm on the opinion that there is some sort of write protection of the calib. data under normal operation.
It may involve the PAL, who knows. To me it makes sense, if I was the one developing the software for such a machine, I certainly would've want some sort of hardware protection against accidental writes to the calibration data memory area.
Ok, so much for the pulse theory on U2310 pin 12.

The CAL jumper is only a switch input to the processor, like a front panel button.  You can see it on schematic <2> location 7E.  It doesn't provide any hardware protection.


Here's some more detail on how the SRAM operates.

On the SRAM, CE2 is enabled whenever nRESET is high.  Other SRAM inputs are controlled by the PAL:

  nOE  = ~( nWFF )
  nWE  = ~( E & ~RD )
  nCE1 = ~OR( E & VMA & PAGE &  A15 & ~A14 & ~A13,
              E & VMA & ROM  &  A15 & ~A14 & ~A13,
              E & VMA &      & ~A15 & ~A14 & ~A13 & ~A12 & ~A11 )

  nWFF = U2440B.9 = delayed write, described in service manual theory under "Timing Logic".

And since I'm looking at the PAL...

The two EPROMS have their A15 input tied to PAGE.  So the PAGE signal selects either the lower or upper half of each EPROM address space.  The EPROMS are then enabled by outputs from the PAL (A15 below is the A15 output from the processor):

  U2160 nOE = ~OR( E & RD & VMA & ~ROM & ~PAGE & A15,
                   E & RD & VMA & ~ROM &  PAGE & A15 & A14,
                   E & RD & VMA & ~ROM &  PAGE & A15 & A13 )

  U2260 nOE = ~OR( E & RD & VMA &  ROM & ~PAGE & A15 & A14,
                   E & RD & VMA &  ROM & ~PAGE & A15 & A13,
                   E & RD & VMA &  ROM &  PAGE & A15 & A14,
                   E & RD & VMA &  ROM &  PAGE & A15 & A13 )

Here's what all this means.  The two 64k EPROMs are arranged in 4 banks of 32768 bytes.  ROM=0 selects U2160, and ROM=1 selects U2260.  PAGE=0 selects the lower half, PAGE=1 selects the upper half.  At reset PAGE and ROM are both 0.

A15 from the processor must always be 1 to enable the EPROMs.  So, to execute code out of the EPROMs the program counter must stay 8000 - ffff.

If either PAGE=1 or ROM=1, it creates a hole in the address space for the entire SRAM to drop in at 100x.xxxx.xxxx.xxx (8000 - 9fff).  The lower portion of SRAM is always accessible at 0000.0xxx.xxxx.xxxx (0000 - 07ff).

ROM and PAGE are controlled by writing to port 0x08c0.  ROM is bit 0x08 and PAGE is bit 0x10.  Bank switching is immediate in this system, so if you're executing from the EPROM and you change ROM or PAGE, you will suddenly be executing from a different section and/or different EPROM.  The addresses where the switching is occurring need to be coordinated.  It could also be done by writing a little bank switch routine into the SRAM and jumping to that.  I don't know which Tek is doing.

Attached is the JEDEC file for the PAL and my notes derived from that, if anyone is interested or wants to tell me what I got wrong in any of the above or the SRAM writer code (posted a few messages ago).

PAL datasheet here:

  http://datasheet.octopart.com/TIBPAL16L8-25CN-Texas-Instruments-datasheet-10254311.pdf
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
...
Pin 12 of U2310 goes up to ~ 1V, looks like something is pulling it down?
...
Just on this one point, that's odd because U2310 is an LS174 6-bit latch and pin 12 is one of the totem-pole outputs.  If it's not pulsing, it should be nailed to a low or high and not something in between (like 1V).

The only thing I can think of at the moment is if you had the unit in diag mode when you made the measurement.  The diag jumper removes power from U2310 (and U2350 and U2450).  If that's the case I could imagine pin 12 might have settled at some strange level.
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
...
Pin 12 of U2310 goes up to ~ 1V, looks like something is pulling it down?
...
Just on this one point, that's odd because U2310 is an LS174 6-bit latch and pin 12 is one of the totem-pole outputs.  If it's not pulsing, it should be nailed to a low or high and not something in between (like 1V).

The only thing I can think of at the moment is if you had the unit in diag mode when you made the measurement.  The diag jumper removes power from U2310 (and U2350 and U2450).  If that's the case I could imagine pin 12 might have settled at some strange level.

Wow, that's some detailed info about the memory operation, really impresive. :-+ :-+
Wonder how did you get the PAL info (can you actually read it from the chip) , I've allways thought that they are protected from reading after being burned?

Any way this is how I tried your code on my scope, as you can see there's a mini grabber connected to pin 12 of U2310.
At the back you can see the side of my rigol, unless I made some grave error setting up that scope (I must admit i's possible since I just got it and still learning how to use, but not likely) there was no pulse recorded on it even once.



On a different topic, here's a page from options service manual regarding calibrating CTT:



Do I read it correctly that this setup of 2 generators will produce what is essentialy 1MHz square wave 1V?
I'm I wrong here?
I must be. :-//

Here's a copy of the options service manual, it does have diagnostic error test 81  error 01 and 02 only listed.

https://drive.google.com/open?id=1XyZqO2u1x5B9Le-zL154XTEcoKKDVG4-

 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
...
Wow, that's some detailed info about the memory operation, really impresive. :-+ :-+
Wonder how did you get the PAL info (can you actually read it from the chip) , I've allways thought that they are protected from reading after being burned?
Yeah that was actually interesting.  I never decoded a PAL by hand before.  I got the JEDEC file from here:

  ftp://ftp.bluefeathertech.com/electronics/testgear/Tektronix/firmware/24x5/2465A-B/2465A.zip

No idea where they got it, but it seems to be right.  Only afterwards did I notice they also had the equation file, which would have saved me some time.

This PAL is pretty old and the datasheet doesn't mention any protection mechanism.  Then again, the whole "how to program this thing" is also not in the datahseet.  Who knows.

Quote
Any way this is how I tried your code on my scope, as you can see there's a mini grabber connected to pin 12 of U2310.
At the back you can see the side of my rigol, unless I made some grave error setting up that scope (I must admit i's possible since I just got it and still learning how to use, but not likely) there was no pulse recorded on it even once.
It's hard to tell, but it looks like the probe might be on pin 13?  The PAGE signal is also on pin 1 of both EPROMs, so I probably should have pointed to that as an easier place to look for it.  But even if it was pin 13, it still should not have been 1V.  It would have been good TTL logic levels and there would have been pulsing as the program ran.

If you probe it now with the scope running it will have random looking pulses on it.

Quote
On a different topic, here's a page from options service manual regarding calibrating CTT:
...
Do I read it correctly that this setup of 2 generators will produce what is essentialy 1MHz square wave 1V?
I'm I wrong here?
I must be. :-//
You're right.

The pulse generator can produce a 50% duty cycle at 1V pk-pk into 50ohms, but it's not very accurate.  So they use the time-mark generator as a stable time reference to drive the pulse generator.  What you get is a 1MHz ~50% duty cycle square wave that has an accurate frequency.  If you have an accurate 1MHz square wave generator that can do 1V pk-pk into 50ohms, you can use that.

Quote
Here's a copy of the options service manual, it does have diagnostic error test 81  error 01 and 02 only listed.
Yep.  Same one I have.

We're assuming the 81 03 error has something to do with calibration.
 

Online MarkL

  • Supporter
  • ****
  • Posts: 2120
  • Country: us
If it's any consolation, the service flowchart in the back says if there's any CTT error 81, the next step is to re-cal the CTT (PDF page 305).
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca


That's all I have, worth a try?  :-DD :-DD
 

Offline alpherTopic starter

  • Frequent Contributor
  • **
  • Posts: 347
  • Country: ca
Guess what, as incredible as it sounds, it worked!!! :-+ :-+
Here's the setup:




I just passed the signal through Rigol using it as a basicly frequency counter.
My cheeapass analog function generator turned out to be quite stable,  :-DD
Had to run the rutine a couple of times but as soon I went with the frequency a touch under 1MHz, bam! passed.
Scope boots without any errors now:

https://youtu.be/HCpPTXSqk0I

I realize that it should be calibrated anyway, but I guess have to wait till I get my hands on something slightly better than my FG8002.  :-DD :-DD


« Last Edit: April 04, 2018, 01:18:59 am by alpher »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf