3478A cal RAM readout idea

[wolfalex]

Hello, good evening,

 I got a second used 3478A on ebay, and now I have to swap another lithium battery to make sure I do not loose the
 cal RAM data. I really dislike the whole procedure, and I am sure a lot of other people too. Trying to read the cal
 data without breaking the device seems to be a pain (especially because all parts are soldered directly onto the
 PCB), and therefore I guess pretty much all people just buy a new battery and go through the pain again.

 I was wondering if there is a way to safely read the contents of the cal RAM for backup. In my oppinion soldering wires
 to the pins of the uC or other devices is not safe enough... one slip or short and probably the RAM or another part is
 gone. Therefore I almost gave up on the idea again... but then I looked at a internal picture of my 3478a again, and I
 saw something interesting: one single devices seems to have a socket (at least in my meter): RP527. This part is
 kind of weird in the schematic: the schematic symbol looks like it is just a bunch of 0 ohm bridges...I thought
 probably it is there for helping during error search: it could be used to isolate both sides of the busses from each other by simply
 taking the part out. In a list which decodes old HP part numbers this part is listed as some sort of 100 ohms resistor network. I am actually not sure
 yet if this device is now a short or more a resistor..I would need to measure its resistance to know for sure.

 But seeing this part in a socket gave me the following idea: I should be able to take this part out of the socket and
 instead I slide a connector of a custom build PCB back into the same socket, which basically reconnects boths sides again, but
 at the same time allows easily to monitor the data lines D0 up to D7 (the ones were we will also see the CAL ram values
 go through during startup of the 3478A).

 But of course there is a problem: if I do not have the adress lines at the same time as the data I do not know where then
 cal RAM data byte came from initially during the readout. I gave almost up again thinking about that, before I saw the following:

 The data lines D0 up to D7 which I should already be able to sniff easily via RP527 socket do also transport the adress lines A0 up to A7.
 I just must know when the adress is transported and when a data byte which of course is the job of the ALE line. So my next thought was:
 Is there a easy and undangerous way to get ALE (again I do not want to solder in my unit)...and actually there is: thankfully there is a
 testheader/pinheader for debugging (TP3) -> so my idea would be the following: My custom made readout board has simply its own ALE latch on it.
 This latch then generates the adress lines A0 up to A7 for me at the same time as U513 on the original board by use ALE. This should give me the adress info
 I need.

 The last info I would need is when there is actually an read access from the CAL ram. Three signals should help me here: /OE1, OD and maybe CE2.
 R/W is not interesting I think, because until the CAL enable switch is enabled this line should never go to write access anyway.
 
 So from where do I get this signals without soldering? Again i found test pinheaders: OD is connected to /RD (TP5->easy).
 But /OE1 comes from another latch (U506) -> bad.... But on the input side of the latch on the same bit line is debugging jumper JM501...of course
 I would not want to change the setting of this jumper, but the third unused pin of the pinheader/jumper allows easy connection to this signal as well
 (without changing the position of this jumper).
 And this latch is also clocked by ALE again -> we should be able to reconstruct this signal also on our own board. The only signal I am not sure right
 now is CE2...maybe it is needed but I am not sure yet.

 So now my idea: the readout board has an onboard RAM device (maybe dual port RAM) which sniff the cal data from the bus in realtime during startup of the
 3578A via the testpoints I described above. Then after the 3478A is started up and running an onboard uC on the selfbuild readout board reads this captured CAL RAM data from
 the capture RAM and stores it into a FLASH or EEPROM device for eternity, or for later transfer to a PC via the same uC.

 What do you think about this idea? Any feedback? I know there is still a long way to go from a simple idea to the final working circuit, and I also know the problem is normally in the details... Could this idea work? Do all units have the weird device RP527 in a socket? If not then the idea does not help much.

 But if so then this could be a way to read and backup the CAL RAM data without risk and soldering from any 3478A out there.
 
 I added a part of the schematic to this post, and also the internal picture from my unit, as well as the datasheet of the used CAL RAM
  (at least I think this is the datasheet for this part, if not please tell me).
 
  Any feedback is very welcome, thank you very much,
 
    have a nice evening,day or morning
   
      Wolf Alexander
   

[wolfalex]

Sorry for the bad picture quality. I added a better version of the same picture.

[wolfalex]

And as a sidenote: I think I have a more old version of the 3478A, because I have the isolation via transformer. So I hope this socketed part was not removed on later revisions of the
 board.

[MarkL]

As posted recently in another thread, an easy way to get a copy of the cal data is to use a logic analyzer on the cal RAM to capture the nibbles as they are readout upon boot (or self-test).  The processor cycles through all the relevant cal locations so it can compute a checksum.  Not every single location is read out, but presumably the other locations are not important.  This will work with a lot of different test gear from that era.

You can also make the 3478A cycle through ALL cal RAM locations by putting it in the service mode described in 7-D-23, a through e.  This is really meant for signature analysis but can allow an analyzer to grab everything.

I have done both of the above with my 3478A.  No soldering necessary.


If you lose the cal data, getting it back in the RAM is more complicated and you may need to physically isolate some of the control signals as you describe and have an external processor re-write the data.

[wolfalex]

Thank you very much for your response, and the information. I completely forgot about the possibility to do the same with a logic analyzer. Does somebody know if there is also
 a newer USB PC based logic analyzer which would be able to do this? I mean to read out the Cal RAM during startup?

 Which signals have you used to trigger the logic analyzer? I guess the logical combination between /RD and /CE1, or? Because the /CE1 line is also connected to the LCD Sync
 pin I guess this signal is used also for other things, and therefore trigger on /CE1 alone would not be enough. Is this correct?

 Does somebody actually know how the meter firmware calculates the checksum? This would be very interesting

[MarkL]

In this case, you would use the processor /RD signal as the clock with the RAM /CE1 as a qualifier, plus of course the 4 data and 8 address lines.  The RAM R/W is always a read since the CAL switch is disabled, so that can be ignored.  And the RAM /CE2 can also be ignored since it's is always true.

For a USB based analyzer, I've used a Saleae 16-input analyzer to do this, but there are a ton of other makes/models that are equally capable.


EEVBlog user "Sailor" has disassembled and understands large portions of the 3468A and 3478A startup code.  You could try PM'ing him to see if he knows how it computes the checksum.

[wolfalex]

Unfortunately I do not have a logic analyzer right now, but thanks for the information which one you have used, and how it is done. Either I get a LA, or I try out a selfbuild circuit with
a RAM to capture the data. I guess as long as I do not make a short on an adress/data line (and damage an onboard component with it) the CAL data should be save in the RAM,
because the write access to the RAM is inactive anyway all the time (of course only if the CAL enable switch stays in the off position).

Today I thought it would be interesting to use a FRAM for the data capture... then the saved data would be even non-volatile, and can be easily transfered.

Knowing how to calculate the checksum would be a great thing... then at least one can check if the captured data is valid without writing it back to the device, and probably bricking
it during the validation.

How have you tested if your captured data  is valid?

[Sailor]

... and understands large portions of the 3468A and 3478A startup code.

I wish

Because my resurrected 3468A complains about the Cal RAM (Error 1) I need to get into the nitty-gritty of this also. Not only to stop mine complaining, but to understand the format of the cal data and how it is applied. The 8-bit ROM checksum is calculated in the normal manner except for one aspect - if an addition to the sum generates a carry, that carry is added back into the sum with the next byte value, and so on. Unusual, but there it is. The ROM checksum over the 4k 'half-ROM' is zero, so obviously there is a pre-computed byte stuffed somewhere to make it so. When we obtained the new ROM image I quickly ran it through my checksum script to verify that it was ok, but I didn't look anywhere for that byte - I should do so. I would expect it to be the last byte, but there is nothing that says it has to be.

I will look up how they handle the 4-bit RAM checksum - do they clear the top nibble of each value read, do they still do the add-carry thing, etc. I should be able to look at it tomorrow.

[MarkL]

How have you tested if your captured data  is valid?

I haven't.  But I've captured the data with 3 different logic analyzers at 3 different times and they all agree.  I'm confident I have the right data.  (Yeah, I know, famous last words...)

One other thought on restoring data.  As you pointed out, there's a data bus break jumper in the 3478A.  It should be possible to write a small program in an external EPROM or parallel flash that rewrites the RAM nibbles, and then substitute that for the real ROM in the unit.

You could do this by removing the jumper, putting the temporary EPROM in parallel with the address and control lines, and feed the EPROM data output directly into the processor.  When the processor booted, the temporary program would rewrite the RAM contents.  No soldering necessary.

It's too bad all equipment doesn't have a data bus break.


The FRAM idea is interesting.  It's like a removable logic state capture device.

EDIT: No, the temporary EPROM is not such a great idea.  The RAM inputs would be isolated from the processor databus too.  It could still be done but would need an additional tri-state driver to allow passage of data from the processor to the RAM only on writes.  Still no soldering, but more complicated than I had first thought.

[wolfalex]

Sorry for the late response, but during work I  try not to post in forums good thing that the weekend starts soon, and now I have much more time.

@Sailor: Thanks for your input and knowledge. It would be so beneficial to know the way the checksum is done. Then I would not need to risk the calibration of a 3478A during the first
 test of the idea in the future Maybe you find out how the do it. I have never seen the actual readout of the CAL RAM until now,...like I do not even know how much bytes the
 use. Maybe somebody can send me a file with some valid readout data.. would be very interesting.

@MarkL: I think after reading out the data in three different ways with always the same result I would also be more confident that the data is correct An easy way of course to test this
 would be to find an already uncalibrated 3478A (with invalid RAM), try to upload your data into its RAM, and then just switch it on. Then you should get Self test OK, even if it is not
 the cal values from this exact unit, or? Or does 3478A figure out itself in whatever way that the supplied cal values are bogus? (even if the checksum is OK).

I really like the idea of supplying the uC with your own program to do certain things. One way of uploading your data would maybe to open the bus breaker, give the uC your own
program for upload via the uC data lines (to trigger write strobes to the RAM), and at the same time force the correct information on the other side of the bus breaker to the RAM inputs).

wrong comment: (see edit2 below) /*But the main problem would be, that the onboard program ROM outputs have to be disabled in whatever way to prevent shorts on the bus. (and I am not sure if there is an easy way to do that).*/ end wrong comment

EDIT: i forgot to mention the biggest problem: I do not know until now how to program the 8039AH

EDIT2: I think I made a mistake. The ROM output drivers will not short with the RAM input data forced via the bus breaker lower side, because the ROM is only driving the BUS during
   program code fetch... so the own circuit just has to go high impedance during program fetch, and then after program fetch does drive the data to the RAM on the now usable lower
 bus.

[Sailor]

@MarkL

Mark, could you post (or PM me) a file with your cal RAM values?  Hex, bin, or intelhex would be fine.

I do not know until now how to program the 8039AH

@wolfalex  I've attached a couple of docs about the 8048. They won't teach you how to write assembler for the 8048, but they do tell you everything that you need to know (almost). The same as writing assembler for any processor, you need to read the manuals (a hundred times) until you totally understand every nuance, and then recognize what the manuals, datasheets etc haven't told you, and what implications those omissions may have.

EDIT: The file sizes are too large for eevblog. PM me your email address and I'll send them to you (three files, total size ~10MB)

[wolfalex]

I found a document which shows all the command codes for the 8048. The first one I was interested to find was NOP. And of course a NOP is available. Maybe this command will be
helpful. From the 8051 I know that if you simply apply NOP opcode all the time then the program counter will start at adr. 0 and simply count up one by one (like a counter) until the
PC overflows, and everything starts again from 0. I do not know if the 8048 is the same, but maybe applying a continious NOP opcode could be used too at least readout the program ROM (which I would also like to try at one point in time) as a whole, and store it in an FRAM.

I have to think about everything in detail first and learn more about the 3478A

EDIT: maybe the watchdog timer will not like a continious NOP opcode, but maybe it can also be disabled with the jumper

[wolfalex]

The 8048 emulator is already installed and running Now I should even be able to run the original 3478A firmware

[MarkL]

Mark, could you post (or PM me) a file with your cal RAM values?  Hex, bin, or intelhex would be fine.

Sure!

Attached; have at it...

[Sailor]

Thanks Mark. Interesting, yours look like about as much junk as mine - except that yours are ok and the 3468 spits the dummy at mine.

at least readout the program ROM

The ROM contents are already available on K04BB's site.

[wolfalex]

Attached is the cal RAM readout idea. Bus Break Device is removed and its socket allows easy access. I know it looks complicated, but still I would be interested if this works.
 I still have not checked the bus timings, and if this can even work (setup, hold times and so on).

 Because my own running firmware allows me now to only trigger an access to the cal RAM I think I do not need the signal /CE1anymore. The firmware can trigger an read event from
all of the cal RAM adresses and then just halt the uC.

The program could be something like that (i am sure the program is still missing some important things...like the watchdog reset), but just to give you an idea. If my program below is completely wrong please give me feedback At least in the emulator it seems to do the right thing. But it is also bascially my first assembler program.

.org 0
CLR A
MOV R0, A
loop:
 movx A,@R0
 INC R0
 MOV A, R0
 JNZ loop
 
end:
 JMP end

[wolfalex]

And here the cal RAM writeback scenario.

[Sailor]

Basically, that looks reasonable. Just a couple of points:

1.  While your program (specifically, the movx instruction) will generate the /RD signal, you will need to have both /CE1 and CE2 active at the same time. CE2 should be ok from the power-on circuit, but /CE1 comes from U506-6, which is the ALE-latched output of P23. The RESET signal to the processor sets the port outputs to the high state, so before entering your read-out loop, you will need to write a '0' to that port bit.

2.  U510 is a DM81LS95 which requires both enables (/G1 and /G2) to be low to enable its outputs (which would be in contention with the RAM outputs). The /RD signal drives /G1, but /G2 is another bit from U506, so you will need to be certain that when you write the '0' to P23, you also write a '1' to P22.

3.  Similarly, you will also need to be sure to write a '1' to P21, otherwise you will enable the HPIB chip, and the /RD would make it also in contention with the RAM.

I don't think I see anything else, but no guarantees.

Good luck.

[wolfalex]

@Sailor: Thank you very much for sharing your thoughts on the readout/writeback sketch. About P20 up to P23: If I am not wrong during a external program memory fetch this lines
are automatically controlled by the program counter to get the correct program data (therefore the are not a GPIO pin in this case). But to do bank switching during an external RAM access, do I have to set P20 up to P23 as a normal GPIO pin, and I have to care about their state myself? Or is there also some kind of automatic mechanism in place?

What my program is also yet missing is to reset the watchdog, and to make sure that all other GPIO pins are also in a state where nothing can go wrong.

[Sailor]

About P20 up to P23: If I am not wrong during a external program memory fetch this lines are automatically controlled by the program counter to get the correct program data (therefore the are not a GPIO pin in this case). But to do bank switching during an external RAM access, do I have to set P20 up to P23 as a normal GPIO pin, and I have to care about their state myself? Or is there also some kind of automatic mechanism in place?

A couple of things:

1.  The signals in question (/CE1 for the RAM, /G2 for the U510 driver, and /CS for the HPIB chip) are controlled by the latched values of P23 - P20 in U506, not by the port bits directly. The I/O values of P23 - P20 are latched into U506 on the leading edge of every ALE pulse, which occurs on every cycle of the 8039.

2.  The movx instruction is a 2-cycle instruction, and during the first cycle when it is fetching the instruction from program memory, the normal I/O values of P23 - P20 are replaced by address bits <11:8>. But that is only until the end of the /PSEN pulse. At that time the normal I/O values are restored and shortly after that the ALE pulse that starts the second cycle of the instruction once again latches the (same) port values into U506, and shortly after that the /RD signal is generated. Note that the 8039 was designed with only the intrinsic capability of addressing 256 bytes of external data RAM, and so it only needs to output 8 bits of address, which it does on the BUS lines. Port P23 - P20 are not designed to have any special function during a movx instruction.

3.  If you want to have the ability to address more than 256 bytes of external data RAM, then yes, you will need to set up and control your own bank-switching signals, using any port bits that are available in your design. There is nothing internal to the 8039 that will be related to your alternate bank access. As far as the 8039 is concerned it is simply addressing one of 256 locations.

The waveforms in the datasheet contained in the MCS-48 User Manual tell most of the story (remember what I said about 'what is not in the datasheets'). The datasheet produced by Fujitsu is minutely more illuminating (thanks, MarkL), and I'll send that to you also.

[wolfalex]

My plan would be right now to just program/handle the pins P21 up to P23 as GPIO pins, and set their level before I enter the readout loop as needed. (P21 = 1, P22 = 1, P23 = 0).
This would prevent the bus collisions as you have already noted.

For pin P20 I do not really know what level is needed because in the schematic it only goes to the LCD and I have not yet seen what the purpose of this signal is. But I assume that the reset pin level of P20 must be at least a safe condition for the hardware. And for the readout P20 does not matter anyway.

Thanks again for your very helpful information.

[wolfalex]

I have opened now the 2nd 3478A I got on Ebay lately. I am a little bit disappointed now, because it seems in the newer Revisions of the 3478A the bus breaker RP527 was removed (no socket), and seems to be replaced with some wire-jumpers on the PCB. Also some of the test points are not mounted/soldered onto the PCB, like in my other 3478A.

So opening the bus breaker will be a little bit more work on the newer revision.

I was happy to see that  my second 3478A also passes the Self Test, and it basically measures OK. The only problem I found with it is, that the display disappears randomly after some minutes of operation. So operation is intermittent, like somebody would switch it on and off all the time. Maybe the reset circuit triggers, or something is wrong with the display

So not really a complete winner.

[abyrvalg]

How do they write that cal data at factory? Why don't look for some serial port/service mode?

[dom0]

They just calibrate it as outlined in the manual. You can do that fully automated over GPIB ; just connect GPIB, four/five wires from your universal calibrator and run the calibration program.

[wolfalex]

Now I only need the universal calibrator