Electronics > Repair
HP 3478A: How to read/write cal SRAM
<< < (30/41) > >>
djrm:
The bad results are consistent and repeatable, I'm going to check my AR488 wiring again.
I'm tempted to fit the LA onto the ram pins but I'm afraid I'd mess up and lose the cal completely.
If I had full confidence in the GPIB cal reading then I'd try cal writing good checksums into the device (but I won't)

I saw some discussion about newline character translation in some older GPIB firmware, but it was for another GPIB driver.
MarkL:

--- Quote from: djrm on March 14, 2024, 09:03:10 pm ---...
I'm tempted to fit the LA onto the ram pins but I'm afraid I'd mess up and lose the cal completely.

--- End quote ---
Oooh... Back to basics.  There's always a risk poking at something that's working, but you can minimize the risk by not putting your probes directly on the RAM chip.  Probe the data and address lines, /RD, and the memory enable /OE1 on other chips, such as the processor and U506.  Also stay away from U515 since it is also powered by the battery when the unit is off (it holds the RAM write line high), and obviously leave the CAL switch off.

If you haven't seen it, here's some detail on how the SRAM readout was done previously:

  https://www.eevblog.com/forum/testgear/3478a-cal-ram-readout-idea/msg695908/#msg695908


--- Quote ---If I had full confidence in the GPIB cal reading then I'd try cal writing good checksums into the device (but I won't)

--- End quote ---
That's a wise choice.
djrm:

--- Quote from: MarkL on March 14, 2024, 10:46:49 pm ---
If you haven't seen it, here's some detail on how the SRAM readout was done previously:


--- End quote ---

Thanks, yes I spent all last night reading all the previous posts I could find including that one.

I tried another Arduino firmware with the same pin definitions but it doesn't want to read the config data at all and isn't very happy reading data from the PC programs but does at least manage it from a terminal.

I think the next step after a sleep will be to connect the LA to the GPIB lines and monitor the bus traffic

I have yet to try the special extended function GPIB firmware, I believe it is now capable of reading calibration.
D.
lmester:

You may want to try a different AR488 firmware version and see if this fixes your problem.

I recently had users of my software getting checksum errors when they tried to read the meter calibration. I found that this was caused by problems with specific AR488 firmware versions. My program works with AR488 0.49.14 but fails with AR488 0.51.18.

fenugrec:
Interesting...
+1 on trying different fw versions, although this is oddly specific behaviour for it to occur on the same 2 locations every time.


--- Quote --- I'm afraid I'd mess up and lose the cal completely.
--- End quote ---
Well clearly, not *completely* - only those two ranges with questionable content. You could test writing and reading back values to the unused rows, that should be fairly harmless (unless writing somehow fails due to a bad RAM and you can't restore it, in which case you'd be hosed anyway).


--- Quote ---diff showing checksum correction, found by guesswork!
--- End quote ---
If we're going to go that way, I'll add my own guesses :
- your correction to the 3V range (first char becomes a '@' e.g. 0x00 ) : that is probable, since it's the most significant digit. Also follows a pattern where the offset is shifted by one digit each range and very similar through those DCV ranges.
- On the 30mV range I'm not so sure that the checksum byte is corrupt.

If you're equipped to probe directly the RAM data and address lines, that will be interesting. It would be a very strange problem if the RAM is read properly on initial selftest, but not later when queried via GPIB. Have you tried triggering a selftest after a few minutes of being powered on ?
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod