++Processor error on TDS 754D on startup


pmoyle111
 

Last winter we had a power outage where the power co would turn power on for 15 min ever hour or so. The scope was soft turned off by the front button. Since then I have been getting the error message above. I ran SPC but that didn't change anything. Looking at the log there are lots of (loosely quoting) nvRam crcc errors. I am getting a gpib interface from Prologix that someone wrote a nice interface for that I found searching this topic. I also got a copy of the nvram file.

Should I be able to fix this by writing a new file, or will the nvRams need replacing? I assume that if I don't cycle power, the SPC should not have that error after uploading new image?

This seems to be a common problem. Anyone have any comments advice?


Harvey White
 

Looking at what I think is going on, it's possible that the processor was in the middle of writing to NVRAM and corrupted the process.  (it's write, and then write a checksum to validate the data).  *if* that happened, then the NVRAM should be electrically fine, but might have corrupted data.  In theory, the NVRAM itself is not likely bad, but the data could be corrupted.  A CRC is (one crude method), add all the data up to make a number, chop off part of it, then find a number that when added to what you have, makes the result zero.  Write that number into the last locations in the NVRAM.  When the processor checks it, the sum of all the data (corrected for the part you lopped off....) should be zero.  Not, and there are errors.

It's perhaps rare that this process could be interrupted, but it is possible.

Harvey

On 7/15/2021 6:22 PM, pmoyle111 via groups.io wrote:
Last winter we had a power outage where the power co would turn power on for 15 min ever hour or so. The scope was soft turned off by the front button. Since then I have been getting the error message above. I ran SPC but that didn't change anything. Looking at the log there are lots of (loosely quoting) nvRam crcc errors. I am getting a gpib interface from Prologix that someone wrote a nice interface for that I found searching this topic. I also got a copy of the nvram file.

Should I be able to fix this by writing a new file, or will the nvRams need replacing? I assume that if I don't cycle power, the SPC should not have that error after uploading new image?

This seems to be a common problem. Anyone have any comments advice?






pmoyle111
 

That sounds like a plausible theory, all though, what you described as a crc is really a checksum. A crc is similar but much more stringent. It is a polynomial with a characteristic divisor. In implementation is it is a bunch of shits and xors. None the less, that does not affect your theory, it works somewhat the same but the crc for target image must be calculated and then compared to the one in the last number of bytes depending on whether it is a crc8, crc16, or crc32. On the other hand the life time of those modules is 10 yr. About 30 yr ago I wrote a lot of 8051 code and designed a bunch of circuits to do all that. Back then 10 yr seemed like a lot of time. I think this scope is a mid nineties as its serial number is B4xxxx which is the later variety.

Anyhow I need to find out how up/download a new image. As I said above, I am getting an ieee 488 and I have an image I found posted. After that I can see if the same thing happens when power is removed, if so the module battery is bad. I would have thought running the SPC would have written a new freshly calculated crc. Seems like a flaw in the design. I always incorporated such features into my designs as I had an original IBM AT which used the original Mot chip the Dallas module was based on. The original design had a circuit bug that caused the battery to go dead regularly and so even though Dallas fixed the bug in the module, I always incorporated a convenient work around as sometime actions of users drained them. In the end the module was just a bad idea as can be seen now. Something custom that becomes obsolete changed out for something standard that will live seemingly forever.


pmoyle111
 

that was supposed to be shifts and xors


BobH
 

Which Dallas module are you needing? Is it one of the ones that are just battery backed RAM or does it have a clock in it as well? If it is just RAM, how large is the RAM?

BobH


pmoyle111
 

I believe the they are DS1486, and DS1250Y (from memory of reading recently) I guess maybe I should hunt the data sheets and re-familiarize myself with the beasts - I used to know something about everything Dallas had- but that was mid '90's. I started hoping I could find someone I could pay to do it and just outsource the problem, but it looks like I'm going to end up diving into the swamp.

I don't know which is the culprit but if one is replaced so should the other due to battery age, and pulling the board out and reworking one is not much less than reworking both.
I have seen on some threads, someone has designed a workalike using a non battery Dallas part allowing using an external battery
But at the moment I'm looking for assistance with how diagnose the problem further to prove that is the problem
I am getting in a Prologix IEE488 to usb adaptor in a week or so and I would like to get some instruction on how to download/upload the content
If it's one of those I should be able to clear the error at least long enough to do a self test to verify the hypothesis. I have a file someone posted for the DS1486 - I suppose that is where the error is

Anyhow just looking for some diagnostic steps I can go thru using 488 I/F. I have seen some using the floppy, but I don't have any of those and I guess you could find them online somewhere, but I think the 488 I/F will just be better, more user friendly, more robust


BobH
 

Thanks for the information. The reason that I was asking is that I have been working on a replacement for the battery backed SRAMs. I currently have an 8Kx8 board design that I am testing. It does not support timekeeping right now. B
ackup power is supplied by a socketed coin cell on top of the board.

I looked at the two part numbers you supplied, the DS1486 has RAM and a clock on board, and is obsolete with 0 stock at Mouser. The DS1250Y is a 512Kx8 SRAM which would be more approachable for a homebrew fix, but they are still available with Mouser having them in stock. They are expensive though.

On the boards that I am working on, they are using the DIP package. I have been looking at adding timekeeping to my design, but that is going to get a lot more complex, as it will require an FPGA to allow formatting the data to emulate the various module part numbers. Also, 5V tolerant FPGAs are getting scarce.

Good Luck with your 754D, those are nice scopes!
BobH


EricJ
 

Yes the 754s are really good scopes. I've got two, an A and a D. I am dreading the day when I need to get after this problem. I've already backed up the contents of the NVRAM via the floppy drive method, so I'm ready if I need to do it, but not looking forward to it.--EricSent from my Galaxy

-------- Original message --------From: BobH <wanderingmetalhead@dakotacom.net> Date: 7/19/21 9:03 AM (GMT-06:00) To: TekScopes@groups.io Subject: Re: [TekScopes] ++Processor error on TDS 754D on startup Thanks for the information. The reason that I was asking is that I have been working on a replacement for the battery backed SRAMs. I currently have an 8Kx8 board design that I am testing. It does not support timekeeping right now. Backup power is supplied by a socketed coin cell on top of the board.I looked at the two part numbers you supplied, the DS1486 has RAM and a clock on board, and is obsolete with 0 stock at Mouser. The DS1250Y is a 512Kx8 SRAM which would be more approachable for a homebrew fix, but they are still available with Mouser having them in stock. They are expensive though.On the boards that I am working on, they are using the DIP package. I have been looking at adding timekeeping to my design, but that is going to get a lot more complex, as it will require an FPGA to allow formatting the data to emulate the various module part numbers. Also, 5V tolerant FPGAs are getting scarce.Good Luck with your 754D, those are nice scopes!BobH


pmoyle111
 

Thanks for the response. If endeavoring to do this (rtc + ram), there are already a number of folks that claim to have working solutions, so I would search out their progress and find the flaws and try to find elegant workarounds. The easiest way is to find compatible no-batt rtc, and add logic around that to extend the ram. Maybe easiest is to used the latest version of the original MC148616 and i/f logic and add an fram if the are any parallel i/f available - the original has muxed a/d so that would have to be demuxed. Goal would be to try to get away with a bunch of glue logic in an XC9536 or 72. To try to recreate the ds1486 from scratch would take a tremendous verification/validation effort with no payback. Seems like a lot of nuances present. Mot's original MC14xx had battery discharge bugs which was one of the Dallas popularities. Mot fixed it in the b version.

Most modern designs use an i2c rtc and an fram. So, other than legacy sockets, not much market.

pmoyle