HP / Agilent 34401A hidden menu

[Hydron]

Yeah the hope was that it is something that can be enabled via an undocumented poke like the 10mA AC range.

Seeing as I had a memory dump and the thing all wired up already to allow EEPROM access (for both write and monitoring), I thought I'd have a crack with some other POKE commands. I tried everything up to the mid 30s at least with x,0,0 without result other than what I wrote in my notes. This post suggests that other poke commands can be used to do some other tricks though, but annoyingly HPAK didn't elaborate any further: https://www.eevblog.com/forum/testgear/agilent-34401a-hidden-10ma-ac-current-range/msg400451/#msg400451

Edit:
A little more info - I tried again with dimmog's .BIN, but only writing up to 0x30 (the first checksum). Gave errors 740 747 and 748, i.e. Cal secure, GPIB addr. and "internal data" checksum errors, no other errors suggest that the other calibration info is stored after that point (as suspected). After changing a setting (triggering a re-write of at least the checksum) it's reset all the stuff I wrote from the .BIN to nearly what was originally there, suggesting it's back to defaults. No hidden menu enable still 

Edit 2:
...just realised this might be a little/big endian issue with the byte order, which would explain the total lack of success with dimmog's .BIN. Will try again with the bytes in each word swapped!

[dimmog]

I'm not a programmer but I think 11-05-02 has a different EEPROM structure. The 07-05-02 and 10-05-02 have almost the same data up to 0x60 and 11-05-02 looks completely different.

[Hydron]

Success!

Looks like the EEPROM structure is still compatible between versions 07 10 and 11.

Fixing the byte order worked, and I was able to load your .BIN up to word 0x30 (i.e. up to byte 0x61), which is the section that contains the magic incantation to enable the hidden menus.

It looks like my calibration (and count, message etc) is untouched, and I have the new save/recall/power-on menus, though I have not tested them in anger yet. Applying the AC 10mA range tweak also works - while the value at the address it changes is now non-zero to begin with, it only modifies one bit from 0 to 1, leaving the rest the same (via a read-modify-write cycle I guess).

Edit:
A quick test with the saved state resulted in being able to set the default number of digits on boot to 6

Edit2:
- Found the byte that does it, by changing the second byte at word 0x09 (i.e. byte 0x13) from 0x98 to 0x8C (and updating the checksum at word 0x30 by subtracting the difference, i.e. 0x0C, from it) it enables the hidden menu. There aren't that many changed bytes between my original and dimmog's file (at least before the 0x30 checksum word), so it only took 2 attempts to find it!
* Update: 0x9C works too, so it's just the 4s bit in the second nibble

Also see attached the byte swapped version of the .bin that dimmog originally posted.

Anyone want to have a crack at guessing bytes to get the temperature menu working?

[tv84]

I'm not a programmer but I think 11-05-02 has a different EEPROM structure. The 07-05-02 and 10-05-02 have almost the same data up to 0x60 and 11-05-02 looks completely different.

As Hydron mentioned the endianness of the 11-05-02 version is wrong (probably a mistake from the dumper).

[Hydron]

...and more notes:
Using the save settings option with fast 6-digit mode selected (otherwise power-on-defaults) changes words:
- 0x0C from C0D1 to C0E1
- 0x1D from 0000 to 8000
- 0x1E from 0000 to 0232
- 0x2A from 0000 to FC00
- 0x2B from 0000 to 0001
- the checksum at 0x30

This accounts for all but three bytes of the differences between my firmware dump and dimmog's (remaining differences are at words 0x08 and 0x20)

Turning on the option to recall settings on boot modifies word 0x08 from 1000 to 3000 (probably would be 0000 to 2000 without the bit being set for AC 10mA range enable)

If anyone has a 34401A with a temperature menu present, please pipe up (and even better still, supply an EEPROM dump!)

[tv84]

Based on @meandeev C program  , here is a tiny contribution.

His program can be reduced to this C# snippet (others can put it in Python):

Code: [Select]

            int start = 0x64;
            for (int j = start, s = 0; j < buffer.Length - 1; )
            {
                ushort b = BitConverter.ToUInt16(buffer, j);
                Console.Write("{0}", Convert.ToChar((b >> s) & 0x7F));
                s += 7;
                if (s > 8)
                { s -= 8; j++; }
            }
This is already adapted to extract the 7-bit text from 34401a_11-05-02-EEPROM.bin (corrected version) and should work on other versions (just adjust initial start and s values if necessary).

As you can see, starting at offset 0x64 (bytes), there are these strings:
HP034401     23 JUN 2005 25.9C

34401a-save-state-menu.BIN file at offset 0x64 (bytes):
HP034401     HUBEQUIP.NET

34401a_05-01-01_eeprom.bin at offset 0x18 (bytes):
HP034401    18 APR 1995 21.3C

calrom_orig.bin at offset 0x18 (bytes):
HP900000    ZERO CAL: 35.7C; 3 Mar 1992;09:33:58

So, @Hydron, you cannot swap all the bytes as you did. That requires further investigation.

[Hydron]

Hmm, curious. I've attached my original (well, after enabling 10mA AC range) bin from before I opened up my unit and started messing around too much, could you check that one too?

I'm pretty sure I have the right byte order, as it's what I get by sniffing MISO or by using a tool to read the chip, and also when I have updated the checksum it has worked in the order that I have. It's also the only order that works when flashing a .bin to it.

[tv84]

That explains it! Your dump has incorrect endianness BUT it's in sync with your programmer. So that's why you should invert endiannes to flash BUT we can only proper analyze the dump if we correct the endianness.

So with endianness corrected, your dump shows at offset 0x64 (bytes):

HP034401      2 MAR 2007 24.5C

[Hydron]

...and finally (well, other than endinness adjustment), I took another stab in the dark and tried flipping more bits to get the temperature menu.

Second try lucky (first try was turning on all the bits in the word which enabled the save menu) and it's the same byte as the DIAG:POKE 25,0,1 command changes - this time the high bit instead of the low bit. Word 0x08 (byte 0x10 in the endianness I'm using) is the one to tweak, along with the checksum of course.

Have attached the final EEPROM with both extra menus enabled (note endianness may not match for everyone, I can do a swapped version too but not tonight), and also a couple of pics of the patient under surgery and a PT100 temperature measurement.

[dimmog]

...and finally (well, other than endinness adjustment), I took another stab in the dark and tried flipping more bits to get the temperature menu.

  Way to go!

[coromonadalix]

hi
noob question,  is it the mainboard eeprom or the cpu eeprom

[dimmog]

hi
noob question,  is it the mainboard eeprom or the cpu eeprom

This is U505 EEPROM IC.

[dimmog]

Now I'm wondering if it's possible to make a DIAG:POKE command to activate those menus..

I found some info about DIAG:POKE.

[tv84]

Second try lucky (first try was turning on all the bits in the word which enabled the save menu) and it's the same byte as the DIAG:POKE 25,0,1 command changes - this time the high bit instead of the low bit. Word 0x08 (byte 0x10 in the endianness I'm using) is the one to tweak, along with the checksum of course.

I went to bed with the feeling that you would solve it very soon.  Great job!

Now I'm wondering if it's possible to make a DIAG:POKE command to activate those menus..

I found some info about DIAG:POKE.

I think so. Just a matter of processing all the knowledge gained in these last hours.

I think the cal string packing is an indicator of how all the binary structures are packed. The cal string is basically a concatenation of 7-bit chars (instead of the usual 8-bit). So, I've a feeling that all other structures are also tightly packed and don't obey to the usual byte boundaries.

[Hydron]

dimmog, sadly I don't think the PEEK and POKE commands work like that on the 34401A, at least the ones which modify the eeprom. Though it might help to look at the post I linked earlier for some more examples.

Would be very useful to be able to turn the bits on via SCPI though, so not gonna discourage more testing!

[tv84]

The attached picture is the map of all the blocks (and their Checksum positions) of the EEPROM dump. This should allow (one day) a more precise understanding of the initial blocks.

I used the 34401a_11-05-02-EEPROM.bin (posted above).

This was done based on the info collected by Hydron yesterday.

In order to verify and calculate the checksums of all the blocks in a dump, I leave here a C# code that does that (should be self-explanatory):

Code: [Select]

            byte[] block_sizes = { 0x02, 0x02, 0x2A, 0x1A, 0x18, 0x12, 0x1A, 0x1C, 0x22 };
            if (BitConverter.ToUInt16(buffer, 0x14) != 0)  // to accommodate older FWs (below version 07-05-02)
            {
                block_sizes[2] = 4;
                if (BitConverter.ToUInt16(buffer, 0x06) != 0x16)
                    block_sizes[3] = 0x18;
            }

            for (int j = 0, i = 0; j < block_sizes.Length; j++, i += 2)
            {
                ushort sum = 0;
                for (int end = i + block_sizes[j] * 2; i < end; i += 2)
                    sum += (ushort)(BitConverter.ToUInt16(buffer, i) + 1);               
                Console.Write("Offset: {0:X4}  Checksum_Calc: {1:X4}  ", i, sum);
                if (BitConverter.ToUInt16(buffer, i) - sum == 0)
                    Console.WriteLine("OK");
                else
                    Console.WriteLine("ERROR!");
            }
(This source code can be used to verify if your EEPROM dump is OK.)

The output for 34401a_11-05-02-EEPROM:

Code: [Select]

Offset: 0004  Checksum_Calc: 0002  OK
Offset: 000A  Checksum_Calc: 0018  OK
Offset: 0060  Checksum_Calc: 9147  OK
Offset: 0096  Checksum_Calc: 9B7D  OK
Offset: 00C8  Checksum_Calc: 7336  OK
Offset: 00EE  Checksum_Calc: 1F61  OK
Offset: 0124  Checksum_Calc: 8093  OK
Offset: 015E  Checksum_Calc: 1EB3  OK
Offset: 01A4  Checksum_Calc: 3B72  OK

The output for 34401a_hydrons_ebay_unit_with_save_temp_menus_enabled_by_bit_changes_EEPROM:

Code: [Select]

Offset: 0004  Checksum_Calc: 8663  OK
Offset: 000A  Checksum_Calc: 0018  OK
Offset: 0060  Checksum_Calc: 215C  OK
Offset: 0096  Checksum_Calc: 0101  OK
Offset: 00C8  Checksum_Calc: 99A5  OK
Offset: 00EE  Checksum_Calc: 3ADC  OK
Offset: 0124  Checksum_Calc: CE20  OK
Offset: 015E  Checksum_Calc: DEC0  OK
Offset: 01A4  Checksum_Calc: EFE5  OK

The output for calrom_orig.bin (floating around in the web). This old dump contains checksum errors (in my opinion):

Code: [Select]

Offset: 0004  Checksum_Calc: 8663  OK
Offset: 000A  Checksum_Calc: 000A  OK
Offset: 0014  Checksum_Calc: 1A66  ERROR!
Offset: 0046  Checksum_Calc: 25D4  OK
Offset: 0078  Checksum_Calc: A3A5  ERROR!
Offset: 009E  Checksum_Calc: B3D6  ERROR!
Offset: 00D4  Checksum_Calc: 4359  OK
Offset: 010E  Checksum_Calc: 2C46  ERROR!
Offset: 0154  Checksum_Calc: 2B1B  OK

The checksum calculation has a little twist: they also sum the number of Words that are used in the calculation.

Edit: The green area contains the additional bytes that were added with the introduction of FW 07-05-02.
The red area is where the option bits reside. As we can see, this area already existed in FW 07-05-02.

[Hydron]

Interesting - never found the first couple of checksums as I didn't manage to trigger anything that would mess with that area. I wonder what those first two small blocks do - my unit and dimmog's both came with different info in the first word than the 0000 I've seen from other dumps.

Good insight into the extra twist of the word number being added to the sum - I didn't manage to figure out where the offset came from when I tried (though I was also probably looking at the wrong range of words).

I guess the main questions now are a) are there any more useful hidden features to find and enable and b) can we flip the magic bits via SCPI without an eeprom programmer

On my end I had a bit more of a play this morning, but I think I'll put my unit back together soon - does anyone have further tests they want done while I still have my programmer connected?

[tv84]

On my end I had a bit more of a play this morning, but I think I'll put my unit back together soon - does anyone have further tests they want done while I still have my programmer connected?

If I understand correctly what you tested, these are the option bits:

Offsets: 0x11+0x12

Code: [Select]

00 00 98 06 - Default
00 90 9C 06 - Store State + Temp + 10mA AC
00 10 98 06 - 10 mA AC
   |   |
   |   0001 - SCALE options in math menu
   |   0010 - ???
   |   0100 - Store State
   |   1000 - Default (?)
   |
   0001 - 10 mA AC
   0010 - Recall saved settings on power-up (set via SAVE menu item)
   0100 - ???
   1000 - Temp
Did you test the other combinations? Can you do it?

BTW, If we look at those 2 bytes as a little-endian word, the middle nibbles become:

Code: [Select]

9800
9C90
9810
 |
 +---+
 |   |
 00000001 - 10 mA AC
 00000010 - Recall saved settings on power-up (set via SAVE menu item)
 00000100 - ???
 00001000 - Temp
 00010000 - SCALE options in math menu
 00100000 - ???
 01000000 - Store State
 10000000 - Default (?)
By crossing this info with the command to enable 10 mA Option:

DIAG:POKE 25,0,1

I could imagine this scenario:   

0 is the bit position of the above table (that we want to change)
1 is turning ON that bit position

Can you test POKE 25 with other combinations, with this theory in mind?

(not much hope but worth a try...)

[Hydron]

OK so PEEK/POKE do NOT work like that doc. However I have found:

DIAG:PEEK? -1,x,0 where x is a decimal number will read the EEPROM word at address x, answer comes back in decimal again. This is a closed-case EEPROM backup enabler

Trying to do the same with POKE (e.g. diag:poke -1,8,45056) doesn't seem to write anything.

As for the option bits, I have tried setting them all on, didn't notice any changes beyond what we've already found with TEMP and SAVE menus, didn't search exhaustively though. I can add a little to the table though:

Code: [Select]

   0001 - 10 mA AC
   0010 - Recall saved settings on power-up (set via SAVE menu item)
   0100
   1000 - Temp

[tv84]

OK so PEEK/POKE do NOT work like that doc.

Sure, forget the doc.

Can you try to disable the Temp by using the POKE 25 as I hint above:

POKE 25, 3, 0

[robert.rozee]

i'm afraid i'm a little late to the party here. i do have a 34401A, but not one that i can tinker with. nonetheless...

regarding the two HP poke commands to enable/disable the 10mA AC range:
"DIAG:POKE 25,0,1"
and
"DIAG:POKE 25,0,0"
can someone post screen dumps (before and after) of what the EEPROM looks like, like the one TV48 posted in reply #65 above? preferably with any changed values highlighted?

if the 10mA AC pokes change one bit, then it seems that either the necessary checksums are automatically updated, or TWO bit locations are updated, so that one change cancels out the other when calculating any checksums.


cheers,
rob   :-)

[Hydron]

Can you try to disable the Temp by using the POKE 25 as I hint above:

POKE 25, 3, 0

Still only changes the 10mA AC range (turns it off). TEMP stays on.

@robert.rozee:
The POKE 25 commands only seem to change the bit for 10mA AC range (a single bit), but as you assumed, the checksum is then automatically updated (so I guess you could say it changes more than just the single bit, but the checksum only determines whether the meter throws an error).

[robert.rozee]

so we can change the parameters to "DIAG:POKE ..." and observe how they change the EEPROM dump? ie, instead of the two we know: "25,0,1" and "25,0,0", we could try (for instance) "25,0,2", "26,0,1", and other minor variants - although initially at each step changing just a single parameter.

in a sense, we know the outcome we seek. now we just need to reverse-engineer the behavior of "DIAG:POKE ..." to figure out how it affects the pattern saved to the EEPROM.


cheers,
rob   :-)

[Hydron]

so we can change the parameters to "DIAG:POKE ..." and observe how they change the EEPROM dump? ie, instead of the two we know: "25,0,1" and "25,0,0", we could try (for instance) "25,0,2", "26,0,1", and other minor variants - although initially at each step changing just a single parameter.

in a sense, we know the outcome we seek. now we just need to reverse-engineer the behavior of "DIAG:POKE ..." to figure out how it affects the pattern saved to the EEPROM.


cheers,
rob   :-)

I had a crack at this already - see my first post in this topic (probably on page 2). Didn't have much luck with this, and it was time consuming, as I had to go back through the logic analyser output after each test to look for write commands.

If you have the ability to write an EEPROM in case of disaster (seeing as we don't have the command for arbitrary write yet) then feel free to write a script to dump yours with the PEEK command I just discovered (or just using the programmer), and have a play.

[tv84]

The 3rd param of POKE 25 looks like it's ON (1) and OFF (0).

IMHO that should not be necessary to brute force anymore.

Assuming that this POKE 25 is the one for all options, I would bet on testing plenty of 2nd params to see if they are responsible for other bit positions (in the options bytes).

BUT AFTER HAVING A BACKUP DUMP.

As Hydron has tested, I don't thing other POKE numbers (26,, 27, etc) will do the trick...