Self tests: what do they actually do?


Hey all,

I was performing the "ON"-"x" self test for my HP 15c lately and it caused me wonder just what is going on behind the "Running" message.

The keyboard/display tests on modern HP calculators are pretty self-explanatory, but what about the other (ROM/RAM) tests? I suppose the actions taken by the test will vary by model, but for ROM/"circuitry" tests: does it do a checksum on the ROM to make sure it isn't corrupt? Or perform a battery of operations and make sure the results are as expected? For RAM tests, does it read/write to all/some addresses/registers to make sure they work?

Just curious.



self test for the rom check typically the checksum of the content of the memory. They do not check the correctness of the software. This must be tested during the developement and in going to production, but not later anymore.

For testing RAM certain patterns are written into the memory and read back. If you read the same as you have writtem the memory is assumed to be ok. The releability of this test depends on the patterns used.

What a definit calculator does in its self test only HP can say. The above is how we are doing it for comparable systems.

Best regards,




the big question might also be:

In case a self-test procedure returns an error/faulty message, could it be an error in the self-test routine itself, hence the circuit/routine under test is OK?

I have seen, and I guess many others here too, such circumstance in regular, hardware-based supervisory circuits. I worked in a switching network system (telephony) about 15 years ago (Siemens ESK), and from time to time we needed to change the contacts of some relays. I remember once in a while having to replace contacts in relays signaling false errors: it happened that they were the error themselves.

But this is something I saw in a 'hardwired' switching network. Never found such event in solid state, software controlled systems.

Have any of you?


Luiz (Brazil)

Edited: 8 July 2010, 8:08 a.m.



As a personal story, I remember back in the 80s some systems which at power-up ran BISTs (Built-in Self-Tests) during hours ! before booting -Intel systems running iRMX.

Besides that, I read an HP Journal issue related to some "big" HP processors in HP 9000 systems; they gave a very interesting description of a thorough self-test for a microcoded CPU :

1- a hardwired sequencer triggers CPU functional blocks while a hardware check is done on various output signals. Then the microcode ROM is checked the same way.

2- using as few instructions as possible, a first routine tests register banks or caches, then some RAM and so on...

3- if everything is still OK, extensive tests are done on the whole RAM array.

A funny note : If I remember well, in some systems of that era the first test was done using an on-board microcontroller -which of course had to run, first of all, its own BIST... eh ? who said "matrioshka ?"

As you can see it's a hierarchical process in the way that you can only rely on already-tested devices. And if you really want to test everything, it can take forever to complete.

Returning to our calculators, Eric Smith (please Eric, correct me if I'm wrong) told that the Spice series added new instructions to their CPU, devoted to the ROM test, and even a hardware CRC checker I think. I suppose that the goal was to use as few CPU hardware as possible at this stage of testing.

By the way, it means also that if the CPU is defective, the calculator won't even start, as you already guessed.

Luiz : I worked with people who did maintenance on relay-based switching telephone equipment, they all said it quickly could become a real nightmare, crowded with false errors :-)

Regards from France,


Edited: 8 July 2010, 12:20 p.m.


The self-test code in the Spice and Voyager series mainly check the ROM and the RAM. In the Spice, they added a special instruction to the CPU which causes it to compute the CRC10 of a 1Kx10 "quad" of ROM. The Nut CPU used in Voyager does not have a comparable instruction, so it uses a loop that computes a checksum of the ROM.

The RAM test is very cursory. It really just makes sure that each RAM location can be written and read back, but does not test all the bits of a word independently nor does it test for pattern sensitivity.


If you like I may log the trace in my emulator/CPU-simulator. I will do it this WE and could send it on Monday. But I have only a copy of the ROM at hand Eric Smith removed 2008 from his Nonpareil distribution and which is most probably modified.

Just an other story: The Service ROM for the HP-41 made my emulator/simulator display "CPU OK" but the Time Module calculated the 1-Jan-1900 to be a Sunday, it was a Monday (I am told). So you may only be sure that there _is_ something wrong if it displays "CPU BAD" but not that everythings fine if you see "CPU OK".

Nice WE.....Mike


That anomaly may be attributed to the fact that 1900 was not a Leap year. That would offset all days before Feb 28th by one day.

Just an FYI and my $0.02


No-no, it was an error in my emulator/CPU-simulator. But even with this error the Service ROM testet the CPU OK.



To megarat: if you are interested (if yes I need your mail address) I have a 10k-ZIP with two trace logs for sending you. The first is just the ON/OFF sequence (from deep sleep back to deep sleep) and the second one is the ON+* sequence. Alas it is without contents of the CPU registers, it shows only the address and command.

As I assumed, I have only a modified ROM at hand where the checksum is not corrected. So the selftest ends with "Error 9" in the display and the number 2 in register X. In contrast Nonpareil 0.77 shows the same message but has the number 3 in the regsiter X. So my question to Eric Smith is if his Nonpareil allows log tracing.



To megarat: if you are interested (if yes I need your mail address) I have a 10k-ZIP with two trace logs for sending you.

Thanks, a personal message will be sent shortly.


Hello Craig!
Did you get the log files?



Yes, Nonpareil can generate trace logs when it is compiled with HAS_GUI_DEBUGGER=1.


Thank you for the hint. BTW, do you have a list about the meaning of the number in the X-register after the error in the self test?



No, sorry.


Someone else here in the community has a clue?


Possibly Related Threads...
Thread Author Replies Views Last Post
  An old trick rediscovered: combining conditional tests Dieter 2 503 08-12-2012, 03:42 PM
Last Post: Dieter
  HP-15C LE torture tests ckelley2 11 1,338 07-25-2012, 09:36 AM
Last Post: Gerson W. Barbosa
  HP48SX seems fully functional won't run SELF TESTS? Bruce Larrabee 5 849 07-16-2012, 11:04 PM
Last Post: Luiz C. Vieira (Brazil)
  15C LE self tests / how? db (martinez, ca.) 1 366 04-22-2012, 12:55 AM
Last Post: Ethan Conner
  Calculators on Standard Tests Norman Dziedzic 18 1,748 02-14-2012, 10:26 PM
Last Post: bill platt
  OT: AA Lithium Battery Tests Bill (Smithville, NJ) 5 758 12-08-2011, 10:01 AM
Last Post: Jim Yohe
  Another couple of practical speed tests for the 15c Jose Gonzalez Divasson 16 1,491 10-14-2011, 11:39 PM
Last Post: Reth
  The *REAL* Self Tests For the 15C LE Mike Morrow 15 1,610 09-12-2011, 02:14 PM
Last Post: Mike Morrow
  Self tests in the HP12C Platinum+ Jose Ernesto 3 610 02-08-2011, 02:31 PM
Last Post: Lyuka
  Standard Tests for Calculator Accuracy? Steve S 10 973 04-25-2006, 08:29 AM
Last Post: Steve S

Forum Jump: