Products > Test Equipment

Just got a Tek 2465A, couple questions (how I screwed the calibration data)!!

<< < (13/17) > >>

alpher:
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.


alpher:

--- Quote from: MarkL on March 30, 2018, 03:10:08 am ---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.

--- End quote ---

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:

MarkL:
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.

alpher:
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: ---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
--- End code ---

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?

MarkL:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

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