EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: alpher on February 26, 2018, 02:48:04 am
-
Hi, just got the 2465A CT in rackmount adapter quite cheaply . :)
Unit works, I;m reluctant to do much with it before changing the battery backup for the RAM chip, affraid to lose the calibration data.
I;m I right though? The dreadded test 4 fail on 2465B does it applies to 2465A as well?
Looking breiefly through service manual looks like the auto calibration procedure may
"populate" the RAM with the correct values somehow?
Anyway as I said so far there are no startup errors displayed, I measured the battery voltage to be a healthy 3.5+ V on cr2770.
Should I be worried and replace the battery first (date code from 87) ?
Also since it came in rackmount adapter I'm missing the handle, looks though that to get the handle I may have to get a donor scope, hoped that maybe handle from my TDS340 will somehow fit, but 2465 is ~2" narrower :(
So any one knows if other series (beside 24xx) will fit?
Maybe 22xx?
(http://)
Thanks.
-
The battery backs up the SRAM holding the calibration constants, so yes, you can get those errors if the battery is depleted.
The tricky part with this kind of battery is that you cannot really know how much juice is left, according to the datasheet the output voltage is flat then it drops suddenly.
-
So you're sayi'n that the RAM data is "unrecovearable", so to speak ?
Also, I removed the cooling fan to lubricate the bearing as it was pretty noisy.
Just to make sure, the fan should suck the air out of the case?
Thanks.
-
using this thread to ask about my own 2465a, as well (hope its ok).
I bought a new battery for the cal data ram board; I have not opened the scope yet and the scope seems to work right now, so I assume the cal data is still intact.
just checking before I start, to make sure I understand fully: is it true that I don't need to keep the scope plugged in, power on, while doing the work on this board for the battery swap?
I've read about avoiding grounded soldering irons and all that - but my plan is to remove the board from the powered-down scope, have the board sit on my workbench, tack wire some temp connections to a holding battery of some kind, clip out the old battery and solder the new one in its place.
if the board is NOT grounded at all, just floating - and sitting on my bench - there's no need to worry about having a grounded soldering iron, right? I can't see any reason to worry as long as I don't short the battery while I'm doing the work.
I've also read about people using a small series R on the new battery so that it will limit how much current it might push out (if the old one is low-z; but I'm not sure an old battery would be low-z anymore!). is this being overly cautious? same about a series anti-backfeed diode. so I really need to worry about such things, given that the swap will take a minute or less, with the other battery in parallel?
before I start, wanted to be fully sure so that I don't make any mistakes.
-
I don't get it. :-//
What's wrong with this thread:
https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/ (https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/)
You'll each get a wider audience that can assist you with these great scopes.
Is the A really that much different ?
-
Unfortunately as far as memory backup goes A it's a very different animal than B or plain 2465.
I don't have good advice at this point, preparing a longer post about it.
Long story short, I did lose the calibration constants data!!!!
Even though I thought I have a foolprof method of changing a battery, sheet did happen >:( >:(
If you're willing to wait a day or so I will post a longer post with pictures of what and how I did it.
Maybe i't will help you avoid the disaster.
-
I don't get it. :-//
What's wrong with this thread:
https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/ (https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/)
You'll each get a wider audience that can assist you with these great scopes.
Is the A really that much different ?
Unfortunately as far as memory backup goes A it's a very different animal than B or plain 2465.
...
That thread started as a tear down, but it seems to have become a catch-all for many of the 2445, 2465 (plain/A/B), and 2467 discussions. The models share many of the same problems and approaches for fixing.
One suggestion in there is to use Exerciser 02 to flip through all the calibration entries that are in the cal NVRAM and take a video of it. Getting the numbers back in the RAM is a different problem, but at least you have them should the NVRAM replacement go wrong.
Sounds like it's too late in your case, alpher, but maybe not for linux-works.
If you have the GPIB interface, user korlatos recently reported in that thread you can dump the cal values via GPIB. They didn't say, but you can probably put them back via GPIB too.
-
So you're sayi'n that the RAM data is "unrecovearable", so to speak ?
Also, I removed the cooling fan to lubricate the bearing as it was pretty noisy.
Just to make sure, the fan should suck the air out of the case?
Thanks.
If the NVRAM data is gone the scope will need a calibration. I have seen posts of people using NVRAM contents from other scopes of the same model, but I can't agree it's a good approach.
Yes, the fan sucks air out of the case and blows it out the back.
-
Again, thread in question(is it somehow a sacred thread ?), doesn't do much for the 2465A users.
I guess it's all in the numbers, thre were simply many more B's made, even plain 2465's.
-
No, not a sacred thread at all. (Is any thread?) Just information and various repairs on different models of that series piled in one place. It just grew that way.
The title is misleading, so sometimes it helps to point people to it. Might help, or might not.
-
I have a 2465b and I went thru the dallas chip copy and replace exercise. it was not under stress since you can easily read the data, and then just copy it to a new chip that was $25 or less. so, yeah, I'm familiar with the 'b' thread but I don't see a lot of 'a' talk and the 'a' is quite diff on that battery stuff.
its also WAY too long and unpractical to read thru, so its not worth more posts there (unless its very clearly a 'b' post).
anyway, I can wait a few more days. I have a battery that came from mouser but have not touched it yet. the stuff I read is scary, about it wanting to explode if your short the terms and that its for military use only, these days, and almost never civilian. really makes me feel comfortable handling such a thing, lol..
I'll wait for your post on your method and what I should avoid. thx.
-
oh, and while I'm at it, anyone have the part # from mouser/digikey/etc for a proper 'a' replacement fan? I think it will take the same as a 'b' and I remember ordering one from either of those 2 places, but it was several years ago. if you have the part # handy, that would be appreciated. might as well do the fan while I do the battery, at least on first look.
-
I don't get it. :-//
What's wrong with this thread:
https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/ (https://www.eevblog.com/forum/testgear/tektronix-2465b-oscilloscope-teardown/)
You'll each get a wider audience that can assist you with these great scopes.
Is the A really that much different ?
Unfortunately as far as memory backup goes A it's a very different animal than B or plain 2465.
...
That thread started as a tear down, but it seems to have become a catch-all for many of the 2445, 2465 (plain/A/B), and 2467 discussions. The models share many of the same problems and approaches for fixing.
Exactly.
IMHO posters here are doing a disservice by not keeping all the info about these great scopes together and not scattered and lost deep in forum archives.
its also WAY too long and unpractical to read thru, so its not worth more posts there (unless its very clearly a 'b' post).
:o
What's up with you guys ? :-//
Shit, I've read it and studied it a couple of times over the years just for interests sake and have never even owned one.
This and that thread should be merged by the moderators to keep all the good info in one place IHMO. :horse:
-
its also WAY too long and unpractical to read thru, so its not worth more posts there (unless its very clearly a 'b' post).
Translation: my time[1] is more valuable than your time[2].
That's not a way to get people to help you, nor a way for you to learn (unless, I suppose, you think stackexchange's "which button should I press" ethos is good).
[1] reading and researching
[2] writing and repeating
-
[/quote]
That thread started as a tear down, but it seems to have become a catch-all for many of the 2445, 2465 (plain/A/B), and 2467 discussions. The models share many of the same problems and approaches for fixing.
[/quote]
Unfortunately this is not true in this case, simply put, battery backup of the calibration constants is done very differently in the A model.
In the B, provided that the dallas chip still works you can just pull it of the board, read the data using any cheap eprom reader and voilla!!
On the A it's just a touch more convoluted.
I did read the sram memory, too bad it was only after it went scramble |O |O
Anyway I edited the title of the thread, preparing the pics that I took to post how I did it.
-
some of us disagree that long thread become useless due to their length and chat nature.
if it was pure tech and no chit-chat, that would help, but this is a FORUM and not a wiki site, so its to be expected of course.
still, those that enjoy pouring thru hundreds of pages of chat text to find the gems, more power to you, but I don't have THAT kind of time on my hands, these days; it can take hours to go thru a thread like that.
(on many forums, once a thread reaches a certain size, its locked.)
hey, if that thread could get distilled into a simple FAQ, that would be a true service. but to blame people for not wanting to spend hours going thru it, seems a bit much. its not a 10 page thread we're talking about, folks, remember that. its just too friggin long and unwieldly as a REFERENCE thread.
-
some of us disagree that long thread become useless due to their length and chat nature.
if it was pure tech and no chit-chat, that would help, but this is a FORUM and not a wiki site, so its to be expected of course.
still, those that enjoy pouring thru hundreds of pages of chat text to find the gems, more power to you, but I don't have THAT kind of time on my hands, these days; it can take hours to go thru a thread like that.
(on many forums, once a thread reaches a certain size, its locked.)
hey, if that thread could get distilled into a simple FAQ, that would be a true service. but to blame people for not wanting to spend hours going thru it, seems a bit much. its not a 10 page thread we're talking about, folks, remember that. its just too friggin long and unwieldly as a REFERENCE thread.
That doesn't change the basic point that the "my time is more valuable than your time" attitude is very irritating for many people.
When I was young it was necessary to learn how to glean all the information possible from the meagre available sources.
Nowadays the key skill for young people is how to speedily disregard most of the available "data", thus allowing you to concentrate on the "information".
Hence "speedreading" is a key skill.
-
...
On the A it's just a touch more convoluted.
I did read the sram memory, too bad it was only after it went scramble |O |O
Anyway I edited the title of the thread, preparing the pics that I took to post how I did it.
Well, there were a couple of postings specifically on 2465A NVRAM battery replacement in that thread (Jan 8, 2016). Using the "Print" format of the thread and then the browser search tools is one way to find stuff.
But it doesn't really matter at this point. I for one am interested in hearing about your procedure and how you figured out how to read the SRAM. Thanks for sharing your information and experience.
-
That doesn't change the basic point that the "my time is more valuable than your time" attitude is very irritating for many people.
I just don't see it that way and we'll have to disagree and leave it at that.
I checked to see if I could find the part # for the fan I ordered years ago, maybe still in my email from mouser or something, but could not find it. but when I read forum posts asking for info, if I happen to have that info handy, I post it and don't give the poster a hard time about it, either... its how we help each other online, rather than just beat each other with a stick and tell them to RTFM (which is really what you are saying).
if you don't want to help, don't help; but its uncalled for to criticize other members for not wanting to spend hours in a chatty thread. if you don't want to supply the info or help, don't. commenting in a thread just adds noise (like this, sad to say) and just makes extracting info even harder for the next guy...
-
OK, here's the scoop:
Allways wanted to have a good analog Tek scope, was looking for a 2465B but they are a little pricey for my taste.
So I bought an A instead and quite cheaply I may add, took a gamble really because of blurry pic and the usual description "removed from a working environment" ;).
To my pleasant surprise when it arrived not only it worked just fine (it did |O ) but looked really clean both outside and inside, I mean not a speck of dust ! Here's a pic of the A5 control board before removal:
(https://i.imgur.com/0ZhcVfV.jpg)
I did not clean it in any way, cause it looks mint to me.
I meassured the battery voltage and it was very healthy 3.6V despite battery date code from 1987 !
Decided to change that damn battery anyway >:( , ordered one from Allied and waited.
When I got it I just removed the A5 board from the scope, carefully not to short the battery or sram pins to the standoffs. I had this 18650 laying arround charged, prfect voltage 3.6V so I used it as a temporary backup during battery replacement. Here you can see it attached by soldered ! leads to one of the standoff grounds and cathode of CR2770 . There is also an 1N4007 in series with the positive lead ( just in case) .
(https://i.imgur.com/u538FlE.jpg)
(https://i.imgur.com/kYI5jvY.jpg)
Measured voltage, everything was fine so desoldered the original battery using my hakko 808, checked voltage again, and again no problems at all. Soldered a new battery, check the voltage, desolder temporary leads, check the voltage, everything seemed peachy, here's a pic of the new battery on the A5 board:
(https://i.imgur.com/6EnXpzH.jpg)
Very well, here's what I saw when I turned the machine on:
(https://i.imgur.com/1phAUUO.jpg)
:'( :'( :'( :'( :'(
Did I deserve it?
-
That doesn't change the basic point that the "my time is more valuable than your time" attitude is very irritating for many people.
I just don't see it that way and we'll have to disagree and leave it at that.
I doubt we will agree, but others do share my weltanschauung - including some in this thread!
... and tell them to RTFM (which is really what you are saying).
No, that is not what I am saying.
I am saying that if you know what you could do but can't be bothered to do the legwork, what make you think we can be bothered to do legwork helping you?
-
...
Here you can see it attached by soldered ! leads to one of the standoff grounds and cathode of CR2770 . There is also an 1N4007 in series with the positive lead ( just in case) .
...
Are you sure that screw pad you soldered to is connected to the ground of the board? Some of those pads could be floating.
-
When I saw what I've done was quite upset >:(, so much so that I let it sit for a couple of weeks or so.
You must know that this is a purelly hobby for me, and not only I lack the equipment necessary to calibrate such a scope but probably also skills to do it. :(
Then I came up with an idea that if the sram got scrambled by me momentarily shorteing somehow the vcc pin during the whole procedure it may be scrambled only by a couple of bits or so and by reading it I may be able to figure out what was there originally.
Rigged something like this:
(https://i.imgur.com/V2Ts6j8.jpg)
(https://i.imgur.com/uKg7RK4.jpg)
Read the memory no problems at all, actually I read it mor than 10 times switching on/off between the reads changing settings ETC.
Just to have a general feeling what's going on inside. Found out that the las 512 bytes or so never change and probably there the cal constants are stored.
When I figure out how to properly paste HEX data I'll post the listing.
T.B.C.
-
OK, here's the last 512 bytes of the SRAM:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00001E00 EF 22 00 FD FE 02 85 FA 7F A0 04 DE EB 80 00 7F ï".ýþ.…ú. .Þë€..
00001E10 7F 04 41 DF 9F 02 10 BD 15 A0 04 BF D5 88 00 DF ..Aߟ..½. .¿Õˆ.ß
00001E20 FD 20 00 FD FF 34 13 7B BE 84 48 FB 7D 00 01 FD ý .ýÿ4.{¾„Hû}..ý
00001E30 F2 C0 40 EF FF 03 40 D9 FB 00 02 BB 7D 00 04 9F òÀ@ïÿ.@Ùû..»}..Ÿ
00001E40 BE 90 90 F7 FB 08 83 3F 9F 40 0C FF BF 00 88 FF ¾..÷û.ƒ?Ÿ@.ÿ¿.ˆÿ
00001E50 FF 08 22 EF FF 42 42 AF 5F 01 00 59 FF 0A 40 F6 ÿ."ïÿBB¯_..Yÿ.@ö
00001E60 BF 0A 24 FD 7F 18 28 B7 FE 84 80 FF 7F 00 40 FF ¿.$ý..(·þ„€ÿ..@ÿ
00001E70 FB 18 00 4F 97 13 02 BF FA 8A 23 FF F7 02 05 F7 û..O—..¿úŠ#ÿ÷..÷
00001E80 D7 00 61 7F DD 01 88 B7 3C 20 21 FE DD 01 A8 FF ×.a.Ý.ˆ·< !þÝ.¨ÿ
00001E90 BF A1 00 BA FF 40 48 3F FF 04 00 9B DF E1 92 FB ¿¡.ºÿ@H?ÿ..›ßá’û
00001EA0 FF 00 06 7F FD C4 20 FD FE 26 10 79 FE 32 84 8F ÿ...ýÄ ýþ&.yþ2„.
00001EB0 EB 00 30 FF EE 00 05 7F DF 80 81 B7 BD CA 40 DF ë.0ÿî...߀.·½Ê@ß
00001EC0 AE 26 04 D7 F6 06 82 F7 76 10 02 DC F7 E1 10 7F ®&.×ö.‚÷v..Ü÷á..
00001ED0 DD 31 04 EB D7 2A 41 FB DE 06 20 DD BE 00 20 7F Ý1.ë×*AûÞ. ݾ. .
00001EE0 FD 01 14 F5 7F 04 60 FF FF 90 0C FF EE 80 8C BF ý..õ..`ÿÿ..ÿ¿
00001EF0 DB 00 91 57 BF 10 4A FF DF 52 A0 DF 7E 08 40 3E Û.‘W¿.JÿßR ß~.@>
00001F00 FF 00 00 B7 FF 00 02 FF DF 84 08 FB F7 30 14 FF ÿ..·ÿ..ÿß„.û÷0.ÿ
00001F10 FF 0A 10 7B FC 0A 00 DF C7 A1 C2 FF EF 20 00 FF ÿ..{ü..ßÇ¡Âÿï .ÿ
00001F20 FD 62 00 7F 7F 44 20 AF F7 80 80 B5 FF 41 20 DD ýb...D ¯÷€€µÿA Ý
00001F30 FF 30 00 FF E7 03 10 FB B7 00 10 DF F5 40 61 FF ÿ0.ÿç..û·..ßõ@aÿ
00001F40 FA 00 21 3F FF 40 50 BF 8F 05 B0 9F CF 00 00 DB ú.!?ÿ@P¿..°ŸÏ..Û
00001F50 7E 0A B0 37 FE A0 08 7F 7F 90 38 ED FF 49 32 FB ~.°7þ ....8íÿI2û
00001F60 EF 00 20 EB 3F 03 10 FF 7D 00 31 6F FB 10 1A FF ï. ë?..ÿ}.1oû..ÿ
00001F70 F7 10 C1 D7 FF 50 11 FD FE 50 02 BD FE 22 00 EF ÷.Á×ÿP.ýþP.½þ".ï
00001F80 FF 40 08 DF EB 04 00 DF 3F 80 08 AD 9F 01 00 DE ÿ@.ßë..ß?€..Ÿ..Þ
00001F90 F7 10 89 7E FF E4 40 E3 FC 22 00 FF FF 00 80 5F ÷.‰~ÿä@ãü".ÿÿ.€_
00001FA0 E3 C2 00 EA DF 40 01 BF 7D 10 18 7D FF 00 80 FE ãÂ.êß@.¿}..}ÿ.€þ
00001FB0 EF 02 00 BF DF 00 0A FF F7 08 D0 FF FE 80 00 5F ï..¿ß..ÿ÷.Ðÿþ€._
00001FC0 FB 01 50 5D F7 10 01 7F 3F 00 14 EF D7 00 08 6F û.P]÷...?..ï×..o
00001FD0 F7 50 02 BD FE 80 08 FF F6 60 14 ED AF A4 06 EF ÷P.½þ€.ÿö`.í¯¤.ï
00001FE0 7F 02 00 E7 FF 82 08 FF FE 04 21 3F FD 00 44 F7 ...çÿ‚.ÿþ.!?ý.D÷
00001FF0 FF 20 00 7D FF 10 20 FD BE 24 10 F4 BF A0 0A FB ÿ .}ÿ. ý¾$.ô¿ .û
These are the calibration constants for the scope, I verified it by doing calibration ram exerciser 02 :
https://youtu.be/-Upu0b4jBlA
As you can see it matches, from the service manual I know that the data is 14 bits (including parity), that's a maximum 3FFF in hex !
As you can see lots of it is way higher that that :-// also parity is all over the place.
I'm at loss how it got scrambled so badly?
Attached a ful 8K image of the memory, maybe someone will be able to figure it out?
-
It looks like you have a diode to power up the SRAM. Did you read the SRAM while the scope was powered off?
If so, that's interesting that it worked given that the programmer was driving all those off components through their I/O pins.
What are the resistors doing?
-
...
I'm at loss how it got scrambled so badly?
...
SRAM contents are random after being powered up. The value is dependent on tiny process variations for each bit cell.
-
I added a diode in series with vcc pin just in case programmer does something silly, like grounding the pin before reading, just being extra careful here.
One resistor pulls the WE pin high also as a precaution, the other is needed because I'm reading it as a plain 27C64 eprom, and pin 26 is not connected there, but on uPD4464 pin 26 is a second chip select CE2 ant it must be high for reading.
Somehow my programmer doesn't have an option to read 4464 it can only write!!
-
...
I'm at loss how it got scrambled so badly?
...
SRAM contents are random after being powered up. The value is dependent on tiny process variations for each bit cell.
I beg to differ here, static ram sometimes can retain their data even after complete power loss, especialy in low temperature. We're talking relatively short periods of time here, seconds.
-
Perhaps you missed this question...
Are you sure that screw pad you soldered to is connected to the ground of the board? Some of those pads could be floating.
-
I've checked the resistance, dead short to GND.
Something else must have happened, my best guess is that I may accidently somehow touched the vcc pin or anode of the CR2770 to the aluminum standoff while mounting the board back.
I was trying to be extra carefull, but who knows.
Other than that maybe some sort of static discharge while soldering/desoldering ?, it is pretty dry here in winter.
I don't really know.
Was hoping somehow that I be able to figure it out from the memory dump (it would be doable if perhaps one byte was bad), but with so many bytes evidently wrong I'm at loss, I think it's hopeless. :'(
Anybody knows the way to calibrate these "on a cheap" ?
-
I've checked the resistance, dead short to GND.
Oh well, I thought I had a good guess. Those top two screw pads are floating on my 2465 board, but it's obviously a different design.
-
If it helps, these are the constants from a 2465A, written down from the screen (so there may be some errors).
-
If it helps, these are the constants from a 2465A, written down from the screen (so there may be some errors).
Wow, thanks man !! :) :)
Much appreciated, will try them over the weekeend, now I have to figure out how to calculate "spiral" checksum.
-
Much appreciated, will try them over the weekeend, now I have to figure out how to calculate "spiral" checksum.
Here's a starter for you. I already figured out the "spiral-add" for the 2465. With any luck it's not too different from the 2465A:
https://www.eevblog.com/forum/testgear/tektronix-2445-2465-cal-settings-earom-er1400/msg927144/#msg927144 (https://www.eevblog.com/forum/testgear/tektronix-2445-2465-cal-settings-earom-er1400/msg927144/#msg927144)
It's just the assembly code that does the spiral-add translated into C. No points for efficiency.
-
Thank you Mark, now I remember I read your thread awhile ago, if I remember right you were having a similiar issue
only with a plain 2465, how did it end up for you?
Must reread your thread.
-
A "spiral-add" checksum for all the cal data is stored at location 0x00. So, if we know the checksum and we know there's only one bad word, it might be possible to reconstruct the bad word. I don't know exactly what algorithm they mean by "spiral-add", but it could be figured out. But then the problem is how to write the correct word back to the EAROM at 0x4C. That could be done too, but it's not trivial.
Mark this is a quote from you on the older thread on 2465 earom, there checksum is located at 0x00 could you elaborate a little what it means?
What I'm driving at is, the location 0x00 is it somehow relative to the location of constants within the earom or is it an "absolute" first location in the chip?
I'd like to know, cause in my case memory dump at 0x00 changes from read to read, in case of 2465A would make more sense to dedicate the whole last 512 Bytes of ram to storage of constants and checksume this area only storing checksum at the end or the beginning.
Do you think that's the case here?
Why it matters ? Cause if that's the case the values that z01z posted should contain the checksum allready since there are a full 512 bytes there.
Here's the z01z data in different form, I marked the first AA constants in red since manual says that many there are,
my guess is that the remainder is for the differnt options perhaps?
Offset(h) 00 02 04 06 08 0A 0C 0E 10 12 14 16 18 1A 1C 1E
[color=red]
00000000 005B 0675 266A 264D 0637 2627 082E 0822 280B 27FB 0830 0218 221A 221A 2216 2229
00000020 21F7 21FE 01FF 01FC 0212 0068 001F 0020 0023 0020 1C18 3CA8 1D1C 1D94 1FAC 3FA8
00000040 3FA1 3F79 1FB4 0236 0236 2232 2231 1E13 3CA1 3CDA 1000 3FAB 3FA2 3FAB 3FA2 3FAE
00000060 02E4 02E4 02E1 22E0 075C 2834 083C 082B 081B 0839 2823 2065 0836 283B 282F 2820
00000080 2834 081E 2063 2344 0334 2335 2672 2660 2672 065E 02F9 22DC 186B 0E8D 0E90 0724
000000A0 071E 0214 220D 015F 2146 23A9 040F 239A 0326 03D0 0345 230F 0456 0370 02FC 23A6
000000C0 2249 0531 250A 23D4 2596 04B2 04AA 06EC 04D7 03A1 2563 2297 00BF 00C4 20A9 AA66
000000E0 7DA2 032D 851B E8FD 2D47 919F 0440 A1AB 6B25 38B7 DA04 07D6 C003 0484 E87E 6C70
00000100 C76B 9550 6A81 537B F911 3038 D00C 442E 8508 12CE C57E EA21 1421 22FA 3CD5 9DE9
00000120 D8AC 2106 B052 36F9 3FD0 30EB F44E E5AD CB25 08EE E154 0859 BB11 5C93 98CA 844C
00000140 763E F08F 00E8 80C5 764A F152 6E0A 1F6D FA63 7CFD[/color] 4190 E2BA 7B01 30F5 F78E C63F
00000160 F7A8 A479 A4D8 0C53 DE26 14DA 1930 0156 C844 15EC F706 076F A7C8 68DE 6630 FE3F
00000180 FC5B 25B6 6F5B 09F9 0B3B 2D47 2AB8 DC9A 7C29 19FB 93B1 C0F6 03C5 6C9F FF19 1CB1
000001A0 B3C4 9973 FF40 3291 9A10 DACF F98C 88CF BE02 47D7 BE10 089A D46C 0EFB D752 D0FC
000001C0 C73D 28A7 8473 A467 3042 3BCC 9F2A 28FB 838A 148A 9F88 88F8 7F86 F07D 5936 AB8F
000001E0 A7AF C67C 7F64 003E DD5A 2422 322A F7D4 F238 8821 3311 D43B E804 AE72 00CB 0000
-
Thank you Mark, now I remember I read your thread awhile ago, if I remember right you were having a similiar issue
only with a plain 2465, how did it end up for you?
Must reread your thread.
In that thread there was a user who had one bad value in their 2465 earom (maybe it was a 2445?). We managed to find which value it was, and further what that calibration constant did (something to do with delta-V cursors).
We then tried to work backwards to replace the bad value by computing trial values with the right parity that would also match the spiral-add checksum for the whole earom. But because Tek truncated the checksum to 8 bits before storing it, it left many possible combinations for correct solutions. There was no way to know which match was the original value.
In short, it was a fun exercise but it didn't end up solving the user's issue. And before anyone says it, yes, a re-cal would have been easier. But you're missing the word "fun".
-
A "spiral-add" checksum for all the cal data is stored at location 0x00. So, if we know the checksum and we know there's only one bad word, it might be possible to reconstruct the bad word. I don't know exactly what algorithm they mean by "spiral-add", but it could be figured out. But then the problem is how to write the correct word back to the EAROM at 0x4C. That could be done too, but it's not trivial.
Mark this is a quote from you on the older thread on 2465 earom, there checksum is located at 0x00 could you elaborate a little what it means?
What I'm driving at is, the location 0x00 is it somehow relative to the location of constants within the earom or is it an "absolute" first location in the chip?
For the 2465, the checksum is stored at an absolute location of 0 in the EAROM. The EAROM (ER1400) is a bit of an odd thing. It has 100 locations of 14 bits each and is addressed serially with BCD digits. It's not in the processor's address space like on the 2465A.
I'd like to know, cause in my case memory dump at 0x00 changes from read to read, in case of 2465A would make more sense to dedicate the whole last 512 Bytes of ram to storage of constants and checksume this area only storing checksum at the end or the beginning.
Do you think that's the case here?
Why it matters ? Cause if that's the case the values that z01z posted should contain the checksum allready since there are a full 512 bytes there.
I think that's inconsistent with the 2465, assuming location 0 is the checksum on the 2465A. As I recall, the checksum on the 2465 was static.
But you might be right that all you need to do is copy z01z's data to 0x1E00. Caveats: There has to be no mistakes in the data, and also that a single capture is consistent with itself (e.g., location 0x00 is not changing while you're capturing everything else, assuming that 0x00 is either the actual checksum, or 0x00 is included in the checksum it if it lives somewhere else).
Here's the z01z data in different form, I marked the first AA constants in red since manual says that many there are,
my guess is that the remainder is for the differnt options perhaps?
...
It could also be settings for the scope that need to be remembered between power ups. Maybe they're not included in the checksum because if a knob setting is not restored it's not as important, and it's annoying to recompute the checksum every time someone tweaks a knob. Just a guess.
-
Reacalibration easier? :o Gues if I had necessary gear, maybe.
Anyway here's the z01z's calibration data in a differnt format, (guess you cannot color within code brackets).
I marked the firts AA contants, according to the service manual there shoul be AA 14bit constants in the 2465A ram CMOS memory.
What worries me is that starting from 6F there are some bigger that that ? :-//
Should I worry or the manual is wrong here?
Offset(h) 00 02 04 06 08 0A 0C 0E 10 12 14 16 18 1A 1C 1E
00000000 005B 0675 266A 264D 0637 2627 082E 0822 280B 27FB 0830 0218 221A 221A 2216 2229
00000020 21F7 21FE 01FF 01FC 0212 0068 001F 0020 0023 0020 1C18 3CA8 1D1C 1D94 1FAC 3FA8
00000040 3FA1 3F79 1FB4 0236 0236 2232 2231 1E13 3CA1 3CDA 1000 3FAB 3FA2 3FAB 3FA2 3FAE
00000060 02E4 02E4 02E1 22E0 075C 2834 083C 082B 081B 0839 2823 2065 0836 283B 282F 2820
00000080 2834 081E 2063 2344 0334 2335 2672 2660 2672 065E 02F9 22DC 186B 0E8D 0E90 0724
000000A0 071E 0214 220D 015F 2146 23A9 040F 239A 0326 03D0 0345 230F 0456 0370 02FC 23A6
000000C0 2249 0531 250A 23D4 2596 04B2 04AA 06EC 04D7 03A1 2563 2297 00BF 00C4 20A9 AA66
000000E0 7DA2 032D 851B E8FD 2D47 919F 0440 A1AB 6B25 38B7 DA04 07D6 C003 0484 E87E 6C70
00000100 C76B 9550 6A81 537B F911 3038 D00C 442E 8508 12CE C57E EA21 1421 22FA 3CD5 9DE9
00000120 D8AC 2106 B052 36F9 3FD0 30EB F44E E5AD CB25 08EE E154 0859 BB11 5C93 98CA 844C
00000140 763E F08F 00E8 80C5 764A F152 6E0A 1F6D FA63 7CFD 4190 E2BA 7B01 30F5 F78E C63F
00000160 F7A8 A479 A4D8 0C53 DE26 14DA 1930 0156 C844 15EC F706 076F A7C8 68DE 6630 FE3F
00000180 FC5B 25B6 6F5B 09F9 0B3B 2D47 2AB8 DC9A 7C29 19FB 93B1 C0F6 03C5 6C9F FF19 1CB1
000001A0 B3C4 9973 FF40 3291 9A10 DACF F98C 88CF BE02 47D7 BE10 089A D46C 0EFB D752 D0FC
000001C0 C73D 28A7 8473 A467 3042 3BCC 9F2A 28FB 838A 148A 9F88 88F8 7F86 F07D 5936 AB8F
000001E0 A7AF C67C 7F64 003E DD5A 2422 322A F7D4 F238 8821 3311 D43B E804 AE72 00CB 0000
-
Here's the z01z data in different form, I marked the first AA constants in red since manual says that many there are,
my guess is that the remainder is for the differnt options perhaps?
...
It could also be settings for the scope that need to be remembered between power ups. Maybe they're not included in the checksum because if a knob setting is not restored it's not as important, and it's annoying to recompute the checksum every time someone tweaks a knob. Just a guess.
I don't think these are settings of the scope as read the memory many times after I changed the settings, powered it up and down and the last 512 bytes never change.
There's a lot of changes in the lower memory locations though.
I've included a few of the reads in the attached zip file.
-
Reacalibration easier? :o Gues if I had necessary gear, maybe.
Anyway here's the z01z's calibration data in a differnt format, (guess you cannot color within code brackets).
I marked the firts AA contants, according to the service manual there shoul be AA 14bit constants in the 2465A ram CMOS memory.
What worries me is that starting from 6F there are some bigger that that ? :-//
Should I worry or the manual is wrong here?
It wouldn't be the first time the service manual was wrong, and in that paragraph in particular.
At least all the data from 0x01 to 0x6E is within range, which is where the manual says parity is computed.
I would say try z01z's data and see what happens. It might be good to check the parity on 0x01 to 0x6E for a little bit of a verification on the data.
-
I don't think these are settings of the scope as read the memory many times after I changed the settings, powered it up and down and the last 512 bytes never change.
There's a lot of changes in the lower memory locations though.
I've included a few of the reads in the attached zip file.
Ok, so it's storing the settings elsewhere.
It doesn't surprise me that other parts of memory are changing. Other than the 128 bytes in the 6808, this is the THE memory for the system, so the processor is doing whatever the processor usually does in the SRAM. I agree with your suspicion that the last 512 bytes have been reserved for NVRAM functions, but since the whole memory is battery-backed, the firmware could stick non-volatile values anywhere it wants.
In these dumps, location 0x1e00 is always 0xef. I thought you said it was changing? Or is there some specific action that makes it change? Also note that it's an 8-bit value, which is consistent with Tek's checksum algorithm.
Let me rephrase that... Of course it's 8-bit because that's all I'm looking at. Duh. But it's still a consistent 0xef 0x22 in all of the dumps.
-
...
I would say try z01z's data and see what happens. It might be good to check the parity on 0x01 to 0x6E for a little bit of a verification on the data.
Just wrote a quick check. The parity is good on 0x01 to 0x6E. FYI.
I can't seem to derive the checksum, though. It may take disassembling the code for the 2465A.
-
0x1e00 is where the calibration constants start, from there on to the very end 512 bytes or 256 words (14bit words if to believe the manual ;D ).
I'm going to try z01z data mybe even today, anxious to see the outcome .
-
I did a little disassembly of a 2465A EPROM (160-3303-06) and found checksum code similar to the 2465. It appears to be checksumming the calibration values from 0x11 to 0xAA, with special processing for locations up to and including 0x6E. The special processing would be the parity checking.
Unfortunately, I still can't get the computed checksum to match. Without an actual 2465A to watch with a logic analyzer, it's getting too much in the weeds to figure out.
It could be something I'm doing wrong (very likely), or there's an error in the data (possible). If anyone else has a second set of Exerciser 02 data from a 2465A I could look at, please post.
Good luck with z01z's data. Let us know what happens...
-
Hello,
I happen to have a still functioning 2465A. A safety-copy video with the Exerciser 02 data is here:
https://photos.app.goo.gl/g5OUIetQAZVJYZfs2
Sorry that I don't have time to transcribe it but you can pick it off the video.
By the way, I don't have any illusions this scope is still even close to being in calibration so I'm planning in the future to get one done. I suggest you budget for one as well. Chuck Harris would be a go-to person for the task and he has all the right gear.
Good luck!
-
Thanks Phil, much appreciated. I will transcribe your data and post it later.
For most of the evening I've been fighting my programmer (wellon vp480) trying to program the SRAM in the scope, so far no-go. :(
It errors out after only a dozen bytes or so, I suspect that the loading on CE2 and/or OE maybe even vcc is too high, may have to cut some traces to isolate the chip.
Have to dig into uPD4464 datasheet. :(
Anybody has a good suggestion as to what chip to use as a template during write?
I've trried dallas ds1225Y, no go even if I slow down the cycle to 1mS, in desperation I even tried to program it as a 28C64 EEPROM :) .
Somehoe the geniuses at wellon didn't think that writing and reading SRAM can be useful.
The chip is listed as supported but the read button is grayed out and the write button
doesn't actually write the buffer data but performs a test of some sort, damn. >:(
-
Hello,
I happen to have a still functioning 2465A. A safety-copy video with the Exerciser 02 data is here:
https://photos.app.goo.gl/g5OUIetQAZVJYZfs2
Sorry that I don't have time to transcribe it but you can pick it off the video.
By the way, I don't have any illusions this scope is still even close to being in calibration so I'm planning in the future to get one done. I suggest you budget for one as well. Chuck Harris would be a go-to person for the task and he has all the right gear.
Good luck!
Thanks again usuthu65, here's your data copied to hex.
Hope there are no errors there, it took me a couple of hours.
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
And here's a full image with your constants inserted.
-
OK, I read the 4464 datasheet again, didn't discover anything unusual.
Except maybe a small detail, under "Low Vcc Data Retention " heading noticed that they somehow insist that
"CE2 must be equal to or higher that Vcc-0.2V, or less that 0.2V " while the "normal" Vih calls for just over half of Vcc.
I also noticed that there are 2 resistors 680omhs each in series pulling CE2 to the ground, since I'm feeding it to the Vcc
through 1K no wonder that CE2 stays just below 4 Volts.
Wonder, should I just short the CE2 to Vcc or cut the trace?
-
...
Wonder, should I just short the CE2 to Vcc or cut the trace?
It looks like shorting CE2 to Vcc should be ok. I don't see anything pulling it down except R2470 and R2471. Maybe go to 100 ohms or whatever value gets you above Vcc-0.2V. I'm not a fan of shorting stuff.
-
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.
-
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?
-
...
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.
-
...
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.
-
...
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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:
-
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.
-
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 :
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?
-
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.
-
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:
(https://i.imgur.com/vfefMfT.jpg)
(https://i.imgur.com/gtbYCbs.jpg)
(https://i.imgur.com/9P8PXHH.jpg)
(https://i.imgur.com/aQBT8bf.jpg)
(https://i.imgur.com/PNIBk7G.jpg)
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:
(https://i.imgur.com/nOw4ooF.jpg)
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. :)
-
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.
-
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.
-
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 (http://datasheet.octopart.com/TIBPAL16L8-25CN-Texas-Instruments-datasheet-10254311.pdf)
-
...
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.
-
...
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.
(https://i.imgur.com/fctpNP6.jpg)
On a different topic, here's a page from options service manual regarding calibrating CTT:
(https://i.imgur.com/rxEhvh4.jpg)
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- (https://drive.google.com/open?id=1XyZqO2u1x5B9Le-zL154XTEcoKKDVG4-)
-
...
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.
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.
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.
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.
-
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).
-
(https://i.imgur.com/pjSSNnD.jpg)
That's all I have, worth a try? :-DD :-DD
-
Guess what, as incredible as it sounds, it worked!!! :-+ :-+
Here's the setup:
(https://i.imgur.com/55CXsOU.jpg)
(https://i.imgur.com/W5FcJl5.jpg)
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
-
That's all I have, worth a try? :-DD :-DD
An analog function generator? Yikes. I suppose any calibration is better than no calibration.
Try it, but the 2465A may not like any minute drift or instability the frequency is bound to have while the calibration is in progress, and the rise/fall time may not be sufficient. If it doesn't like the signal, it will just fail the calibration, so no harm done.
Since your Rigol has a crystal timebase in it, I would at least set the frequency to 1MHz by measuring on the Rigol.
If it works you can compare 2465A CTT readings with the Rigol and repeat until it's as close as you can get it. But it's always going to be "approximately right". By comparison, the TG501 recommended by the service manual for calibration has a timebase accuracy of 0.00005%. The CTT is specified for 0.0005% accuracy when calibrated with that timebase.
-
Posted as I was typing my answer.
Great - glad it worked!
-
Actually I just realized that I've never thanked those that helped me with the whole affair.
So thanks to everyone involved especialy usuthu65, z01z and ofcourse MarkL :-+ :-+ if you're ever in Mississauga beer's on me! :) :)
I will probably try to calibrate the scope anyway but don't know when.
Will start another thread as I want to document the whole proces, reading the cal data of the ram as I proceed so we know what is what.
-
You're welcome! Although at times I felt I was distracting you from your original plan which, in the end, worked fine. I might end up passing through Mississauga at some point. We've always wanted to go camping in Canada.
But I'm not done yet. I'm waiting for that used A5 board to get here and I hope it's working enough to boot. I intend to strap it to a logic analyzer and make it give up its secrets. I still want to know why the checksum wasn't matching and why the SRAM copy thing didn't work.
I do not like to end with unsolved mysteries.
-
Actually I put a step towards the calibration proces allready, here are a few pics:
(https://i.imgur.com/ktIznDt.jpg)
(https://i.imgur.com/S8WXfpt.jpg)
(https://i.imgur.com/obC7Rta.jpg)
(https://i.imgur.com/vt9mYVp.jpg)
(https://i.imgur.com/dMg3ITc.jpg)
Basicly what I did is I used the empty spot on the A5 board that Tek probably reserved for some sort memory expansion, never used it anyway (at least I haven't heard of it ever bein used).
Unfortunatelly Textronix in their wisdom thought of only 16kbits memory here, 24pin chip like 6116 or such.
So I had to improvise a few mods using kynar wire, anyway the idea was to have a zif socket there, so I can make a simple patch cable using 2 28pin sockets to connect it to programmer.
I didn't feel at all comfortable pulling the eproms and nvram constantly during the "testing" phase.
The wear on the sockets an possibly the chip pins was a risk I did not like to take.
After I put the NVRAM chip I couldn't use the simple clip/cable (that was unreliable in the extreme anyway), I had to devise a way to read the RAM without pulling it everytime from the machined socket, risking a broken pin or such.
So we will see how it will work, I'm planning to do a quite a bit of memory reading during calibration procedure( at least once every step), we'll see how that goes.
As far as gear goes, so far I got his:
(https://i.imgur.com/ehLMKC7.jpg)
That does this:
(https://i.imgur.com/eCUlgFt.jpg)
That's a 50nS pulse, just look how sharp are the edges!, isn't that amazing. :) :)
500pS timebase :
(https://i.imgur.com/THhfeMW.jpg)
As far as other stuff I may need I'm thinking of getting a new FY6800 or even older 6600 if it gets to be cheap enough.
May be enough to calibrate the scope.
PS MarkL , funny that you mentioned camping in Canada, the reason that I wont be doing the calibration anytime soon is this:
(https://i.imgur.com/gg43L2P.jpg)
Bought this puppy before the winter and have to get it ready for the season, (lots of work), it's going to be the first season for me and my wife.
Cheers.
-
Archer,
What a mess was created by replacing the battery. I am thinking of doing just that to my 2465A CT but this is exactly my worry with doing it. My scope works well, only has 5000 hours, and the battery reads 4v. Could the points you chose to connect the backup battery have been the problem?
I'm thinking of following this process and points:
https://jestineyong.com/tektronix-2465a-dv-oscilloscope-memory-backup-battery-replacement/
I already took an EXER 02 video and I'm seriously considering backing up the SRAM with an GPIB interface adapter. I hope that GPIB can read and write the entire SRAM and not just the calibration area just in case it gets corrupted like it did for you. Great job getting the whole mess fixed!
-
Worry not! :) I ended up calibrating the scope anyway, not to dificult in the end. Since your battery reads 4V i wouldn't worry at all.
Leave it alone.
:)
-
Like you, I'm just a hobbyist and don't have any of the fancy calibration equipment and couldn't afford it even if I wanted it. What equipment did you use to calibrate?
-
Like you, I'm just a hobbyist and don't have any of the fancy calibration equipment and couldn't afford it even if I wanted it. What equipment did you use to calibrate?
Vertical deflection is easy: just use a power supply and voltmeter.
Horizontal deflection is easy: just use any modern signal generator (or an old one with a frequency counter).
The trickier and more important adjustment is the step response. For that you need something with a risetime less than the scope's risetime with no overshoot and with a flat top. Hence the long running "show us your square wave" thread :) No, a simple pulse from an avalanche generator isn't sufficient, because the visible trace is the convolution of the (undefined) input pulse and the scope's response.
-
Like you, I'm just a hobbyist and don't have any of the fancy calibration equipment and couldn't afford it even if I wanted it. What equipment did you use to calibrate?
Vertical deflection is easy: just use a power supply and voltmeter.
Horizontal deflection is easy: just use any modern signal generator (or an old one with a frequency counter).
The trickier and more important adjustment is the step response. For that you need something with a risetime less than the scope's risetime with no overshoot and with a flat top. Hence the long running "show us your square wave" thread :) No, a simple pulse from an avalanche generator isn't sufficient, because the visible trace is the convolution of the (undefined) input pulse and the scope's response.
To restore lost calibration constants you don't need any pulse generator.
I used the Tek prescribed stuff, all you really need is TG501 and PG506.
[attach=1]
If you interested I'll sell it cheap.