| 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 |
| Message Index |
| Next page |
| Previous page |