Electronics > Repair

HP 3478A: How to read/write cal SRAM

<< < (3/41) > >>

Armadillo:

--- Quote from: dfrederickson on April 06, 2017, 06:57:44 pm ---http://hpmuseum.org/forum/thread-8061-post-71213.html#pid71213

--- End quote ---

Now those are interesting investigation. thanks

dfrederickson:

--- Quote from: Armadillo on April 06, 2017, 07:02:30 pm ---There are so many uncertainties with claims as yet to be demonstrated, and for all you know, the undocumented command "W" may be returning an error bytes from Global Variables Iberr or ibsta and yes the logic analyser will be reading the same bytes returned. That, I am afraid cannot be taken as an affirmation of correctness.

In the other post, dfrederickson wrote;

Quote "Now I need to calibrate one parameter at a time and see which data changes, then figure out how the constants and parity/checksum  are encoded. Unfortunately the 3478 responds to the B2 command with the B1 command status. Dave"


unless you know the location of each parameter and the exact representation taking into account any of the endians, example enter 41.2 represented at location X as 0x34, 0x31, 0x2E, 0x32, "yy" checksum, otherwise is doubtful the application and usability of it.



--- End quote ---

I do know the location of each parameter, at least for the 3468 and 3421.  Knowing that there are 5 ranges for DCV, 2 for DCI, 1 each for VAC and ACI, and 7 for resistance I can pretty much figure out which function-range is in each row, above.  Now I just need to figure out the encoding.

Dave

Armadillo:

--- Quote from: dfrederickson on April 06, 2017, 07:18:24 pm ---
I do know the location of each parameter.  Now I just need to figure out the encoding.

Dave

--- End quote ---

+1;  :-+

MarkL:

--- Quote from: Armadillo on April 06, 2017, 07:02:30 pm ---There are so many uncertainties with claims as yet to be demonstrated, and for all you know, the undocumented command "W" may be returning an error bytes from Global Variables Iberr or ibsta and yes the logic analyser will be reading the same bytes returned. That, I am afraid cannot be taken as an affirmation of correctness.

--- End quote ---
The logic analyzer was attached to the data, address, and control lines of the SRAM (U512) and captured each nibble stored at each address.  How to set up the logic analyzer capture was discussed in a different thread a couple of years ago:

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

The SRAM would not be storing iberr or ibsta anyway since the SRAM is read-only during normal operation.  It's only used for calibration data.  The internal SRAM of the 8039 processor (128 bytes) is what's used for volatile storage while the unit is running.

I have no doubt that "W" returns the nibble at each specified address in the SRAM (and that would be the calibration external SRAM U512, to be specific).

Try it for yourself if you don't believe me.  Or try reading the service manual theory section 7-F-60, or look at how the SRAM is controlled in the schematic.  Verification is always encouraged.

MarkL:

--- Quote from: dfrederickson on April 06, 2017, 06:57:44 pm ---
--- Quote from: MarkL on April 06, 2017, 06:22:32 pm ---The breakdown of the SRAM makes sense.

But even if you could figure out the encoding and the checksum, how do you know what the factory default values should be?

--- End quote ---

Hmm, let's see.  The input response is linear and the equation for a line is y=mx+b.  Constants are stored for Zero and Gain, so, from the HP Journal article for the 3468:
...

--- End quote ---
Ok, read your thread at hpmuseum.

One way to tackle this would be to figure out the ECC algorithm so you can poke values into the cal locations to see how they affect readings.  (Maybe that's what you had in mind; sorry if I'm stating the obvious...)

I'm not familiar with the 3468A or 3421A, but on the 3478A it would be possible to use a logic analyzer to watch the fetch and execution of instructions as it computed the ECC.

It should be possible to do a calibration and trigger on a write to any of the associated addresses in the cal SRAM.  I'll take a guess that the firmware will write the new cal nibbles, compute the ECC by perhaps re-reading those nibbles, and then write the new ECC, in that order.  If true, it's an easy way to bracket the code you want.


Well, and then there's always the brute force method.  If you're right that there's only 16 bits of ECC, how long will it take to write and test all the possible ECC values (or half, on average)?  No finesse points for that approach.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod