Electronics > Repair
HP 3478A: How to read/write cal SRAM
WaveyDipole:
I have been keeping an eye on this problem with interest ever since lmester reported it to me on thew AR488 thread. Someone else has now linked this one so I have just been reading up and it is indeed a curious problem. Initially it was suggested this might be related to a code change that resulted in a change to EOI timing. EOI should be signalled with the last character sent and not after it. I am uncertain why that change was made, but this should have been fixed in version 0.51.28. Logic analyzer traces seemed to indicate that the EOI signal is now being generated concurrently with the last character being sent. However, it seems that the problem is still present in 0.51.28 (according to djrm's comment in #150 and lmesters comment on the AR488 thread) so it seems there is something else going on. I also hadn't quite grasped that the problem consistently affects the first and third lines of the output and consistently affects multiple users in exactly the same two lines. That is certainly very odd.
Unfortunately I haven't had a HP3478A to test with for some time, although I appreciate the comparison posted by lmester in post #153. I will investigate further but since I cannot conclusively test, I will have to rely on others being able to do so. I will obviously keep 0.49.14 available in the archive.
David, your observations in #152 are also appreciated. I had noticed however, that in your #136, the wrong character is in position 13. It just so happens that in lmerster's example that the 10th and 13th character are the same but a noteworthy pattern nonetheless. The attnRequired, lonmode and tonmode functions do not come into play in controller mode, but certainly sendToInstrument and read_h will.
I have been trying to refresh my memory on how the dump is generated and found a note that says a W<addr> command is sent to the instrument where <addr> runs from 0 to 255, presumably in a loop. I am assuming that a ++read has to be sent to read each byte in turn? From the dump it would see that a checksum is calculated for every 13 bytes received?
djrm:
--- Quote from: WaveyDipole on March 17, 2024, 11:58:02 am ---David, your observations in #152 are also appreciated. I had noticed however, that in your #136, the wrong character is in position 13. It just so happens that in lmerster's example that the 10th and 13th character are the same but a noteworthy pattern nonetheless.
--- End quote ---
My post #150 has an attachment image showing the bad and good transfers, the data in post #136 has the bad and manually 'corrected' values, I later realised that the error positions were not what I had guessed. clear now? relevant section of image inline below:
I could setup a LA trace on the GPIB lines if it would be any help fixing the problem.
I have now made an additional board to run HP3478ext software, that too is working well now.
pqass:
--- Quote from: WaveyDipole on March 17, 2024, 11:58:02 am ---I have been trying to refresh my memory on how the dump is generated and found a note that says a W<addr> command is sent to the instrument where <addr> runs from 0 to 255, presumably in a loop. I am assuming that a ++read has to be sent to read each byte in turn? From the dump it would see that a checksum is calculated for every 13 bytes received?
--- End quote ---
A checksum byte is saved into the cal SRAM when the calibration is saved for each type (DCV,ACV,DCA,ACA,ohms)+range. The W command just reads any addressed byte from that SRAM. The cal SRAM is organzied as 19 records of 13 bytes (11+checksum word). The first record begins at address 01 hex; first byte of the SRAM is ignored. Three records are unused and there is 8 bytes padding at the end. The checksum word is used to validate the previous 11 bytes of a given record.
What the control program should be doing is issuing the following command for each SRAM byte requested at the given address:
W\e\xHH\r++read\r
Where:
\xHH = byte representing a hex address into a 256 nibble SRAM
\e = ASCII escape
\r = ASCII carriage return
Same command as hex: (hh is the address byte)
57 1B hh 0D 2B 2B 72 65 61 64 0D
But these are the problem commands:
57 1b 0a 0d 2b 2b 72 65 61 64 0d
57 1b 1b 0d 2b 2b 72 65 61 64 0d
It's interesting that the 3rd byte, what should be an unmolested address, happens to be a control code. Hmmm.... Check the escape logic Wavey.
m k:
My first thought was a corrupted memory where variable width is too narrow.
But maybe it has something to do with values under 0x20.
djrm:
I have now run a pulseview gpib trace and can see missing address bytes in the read commands.
trace is taken when running read cal with HP3478A Control with AR488 V0.51.28
Maybe easier to see in this view:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version