HP-15C LE Bug Reports


I've started a bug report article for the 15C LE. I'll try my best to keep this current but please let me know if I miss something or have any inaccuracies.



Thanks Katie. Have you had a chance to look at the 15cle trig functions to see if there are any improvements over the 33s and 35s?




The 15c LE trig functions are the 15c trig functions. The ONLY bugs really ought to be limited to handling the placement of an emulator running 150-175X faster than the original into the 15c LE shell.

Display updates fall into that category.

Computing sine, cosine, LN, etc. should not be affected in any way, since the code to computer those is the 15c code. Period.



Computing sine, cosine, LN, etc. should not be affected in any way, since the code to computer those is the 15c code. Period

Did you mean "should not" or "is not" affected... Not knowing how the 15cle was created puts me in the "Trust but verify" mindset.



Hi, John

Please, as I didn't receive my HP 15C yet, couldn't you make some simple tests on Complex numbers and matrices?
By the way, are the labels Cx,y and Px,y printed on + key or face plate?


Is not.



Verify all anyone wants. IS NOT is the proper response.

The 15c rom is inside this thing. Only the links in or out to the new hardware are different as well as the chip the code is running on.

I am not aware of ANY bug ever found in beta testing that was not somehow related to the speed differential...which is almost certainly the cause of the display craziness.

So, 99.9999999% sure all can relax. Test away! :-)


I'll agree. It's very unlikely that any math error exists in the 15C LE that does not exist in the 15C. However it's not impossible as there could be a bug in the emulator, the compiler used to generate the object code for the emulator, or the ARM chip itself.

I would not agree with Gene's nine 9's of certainty, I'd only give it 5 nines.



I'll agree. It's very unlikely that any math error exists in the 15C LE that does not exist in the 15C. However it's not impossible as there could be a bug in the emulator..

Guess what? That's where most, if not all, of my KEMU bugs
existed. Although there were some bugs in AVR gcc I needed
to work around -- but admittedly I'm surprised that toolchain
works as well as it does in the first place. Anyway being
hosted on several platforms helped knock out such issues.

There is a deceptive amount of functionality which can perform
correctly as some instructions appear infrequently, see little
coverage, and may only be exposed on some rom versions. One
weird problem I only found on the 16c was of the window
scroll indicator (left "." in the ".b" radix indicator) not
being enabled. I traced this to a bug in the NUT "C=-C-1"
instruction where effectively the carry bit is always set
as a result of the operation, but wasn't due to my interpretation
of the HP documentation.

Many other NUT instruction semantic dark corners exist in the
original HP docs. And regrettably I keep forgetting to credit
Monte Dalrymple's NEWT specification as an excellent reference
which helped disambiguate numerous points. Monte himself
was also quite helpful and always responsive to my questions.



REmember all that conjecture about the "lost" ROM? I guess the good news is, it was never lost after all!


If the discussion you refer to, Bill, is the same one I remember, I think Tim stated that it was the "source code" (high level, I suppose) he did not have, rather than "binaries" (ROM image, I imagine).

I am definitely out of school on this; I just remember the discussion because I had made some incorrect assumptions about what was meant by "missing" code.


Actually I'm fairly certain that the display blinking problem is totally unrelated to the speed increase. In the original 15C the display blink was done in hardware using a clock completely asynchronous to the instruction execution. If the microcode told the display to blink, it didn't affect the blink phase. In the new 12C and 15C LE, it appears that the simulation of the instruction to make the display blink effectively resets the blink phase. This would cause "display craziness" even at normal speed.

However, I haven't studied the actual code used in the new 12C and 15C LE, so I could be entirely mistaken.

Also, there definitely were other bugs found in beta testing that were unrelated to the speed differential. I provided instruction traces to Cyrille to help track down some of them.

IMNSHO, "is not" is too strong a statement. It definitely was the case during testing that there were bugs that affected computations in subtle ways. The known bugs have been resolved, but it is not impossible that there are others still lurking. I'll concede that it is somewhat unlikely that a serious computational bug remains at this point.

Edited: 16 Sept 2011, 3:51 p.m.


My concern is that a simple Cx,y was causing troubles, so, I can imagin when Complex stacks or complex matrices were created in programs or directly from keyboard.
Another important point to test: the i addresser (i)...


The results I was getting from Cy,x were never incorrect, numerically. Just for some reason, if my program received parameters that would cause it to loop through the Cy,x instruction exactly three times, the screen would flash as though there had been an error. The results were always correct, though. It's probably some silly race condition.

I've been doing a few little programs with matrices and indirection, and haven't found any issues with those yet.


Actually that does sound like an outright bug in the simulation code rather than just a race condition. It sounds like something in the code is setting the internal CPU flag (not user flag 9) that tells the main microcode loop to use flash mode. While it didn't give incorrect numeric results in this case, a bug that results in an incorrect CPU flag setting could cause all manner of other problems.

I'll try your code on my own simulator, which is unrelated to HPs, and see what I get.


To add to Eric's comments; the bugs reported, so far, are not in the 15C+ issued last October at HHC2010. So they are probably not related to the speed increase but induced by patches made to the firmware since last October.



Perhaps you can add related documentation errors, e.g.:

1) Back label shows ERROR 9 ON / X self test, which does not work. This should be blanked out on the label or replaced with N/A.


1) Back label shows ERROR 9 ON / X self test, which does not work. This should be blanked out on the label or replaced with N/A.

I'll mention this, thanks.


Is there an alternative self-test that does work?




I cited this several days ago. However, rather than locking out the buggy old tests that can generate Error 9, it would be much more desirable to make them work on the 15C-LE, without always generating the Error 9 condition, and without corrupting memory.

The original self tests appear to actually test some things. The program memory corruption that I noted last week when ON plus * or ON plus + tests are performed seem to occur as memory is tested. It's not obvious why the old tests should be corrupting program memory. The problem could be potentially serious and it could still lurk, if the only solution to correct the problems with the old self tests is to prevent their initiation.

The new tests don't appear to test anything except:

1. All LCD segments can be activated, and

2. The firmware date, checksum, and copyright texts can be read from the firmware, and

3. The keyboard contacts can be tested.

With respect to the checksum shown in new self test 2, I wonder if that is a result of the test, or just a value stored in the firmware? What is shown for the 2011-04-15 firmware is FFFFh. (How likely is that?) It seems to be a number stored in firmware that has no real significance as a test. Especially when the checksum is a bogus and arbitrary FFFFh!


1 in 2^16, so still better than your chances of winning the lottery. Including a fake checksum display wouldn't make sense, why would someone bother coding that?


Maybe it isn't a checksum. Maybe the calculator is making rude noises because it's tired of running the self-tests.


I don't believe that performing new self "test" 2 initiates a firmware memory scan that generates a checksum each time the self test is performed. I believe that self "test" 2 does nothing more than look at some pre-loaded text with the pre-stored checksum, the pre-stored firmware date, and the pre-stored copyright date, without actually testing anything. It appears that a checksum is supposed to be determined in the firmware generation process, then stored for recall whenever new self "test" 2 is performed.

It is not very probable that the real firmware checksum is FFFFh. That looks more like a dummy value that never got changed to reflect the real checksum of the firmware installed.

Now with respect to why there would be a fake checksum, just answer the question "What difference would it make?"

I certainly wish that self test 2 actually performed a checksum of the firmware image...but I doubt that's what is taking place. I will be happy to learn differently from knowledgeable people from the 15C-LE design team.

Edited: 16 Sept 2011, 11:07 p.m.


Now with respect to why there would be a fake checksum, just answer the question "What difference would it make?"

A lot! The checksum is *usually* used to determine if a bit (or bits) has changed in the ROM/Flash. So it should be calculated on what's actually there every time the test run. If it is not the expected value, you know that what's in the ROM/Flash is not what is supposed to be.

BUT now if it just always returns the same value, irrespective of what's actually calculated on the ROM/Flash image, you would never know if there was an error in your firmware. This is even more inportant now with Flash than with ROM.

So how do they know if the production line flashing was successful? (Not that production checks it anyway given that a 15C LE has benn shipped with 12C+ code!! - in my company there'd be hell raised, I for one would be crapping all over my MD)



A lot! The checksum is *usually* used to determine if a bit (or bits) has changed in the ROM/Flash.

There are people who read this list that know the answer to the question:

"Does new self test 2 actually calculate a checksum of the stored firmware image, or does test 2 simply report a stored checksum that was calculated when the firmware image was compiled externally?"

A second question would be:

"Is FFFFh the checksum of the existing 15C-LE firmware, or some dummy value?"


The PSE is acting weird. When I programmed the sample program on page 93 and tried the sample problem on page 94, I only got the final answer displayed without any of the intermediate steps.


This bug has been reported and documented here along with other bugs.

Edited: 18 Sept 2011, 6:52 p.m.


You can examine the postings to this forum since September 9, when the first 15C-LE units reached the gamma testers, to see if particular issues have already been identified.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime graphing bug BruceH 1 1,045 11-19-2013, 08:14 AM
Last Post: Joe Horn
  HP Prime - another cosmetic bug BruceH 3 1,370 11-12-2013, 02:18 PM
Last Post: Ken Shaw
  HP Prime Bug bluesun08 19 4,095 10-14-2013, 10:48 PM
Last Post: Han
  HP Prime bug in EDITMAT Han 7 2,075 09-27-2013, 10:15 AM
Last Post: Han
  OT - A lucky find - Busicom Handy-LE LE-120A Cristian Arezzini 2 1,346 09-26-2013, 04:43 AM
Last Post: Cristian Arezzini
  Low power warning for HP-15C LE and batteries Nick_S 1 1,109 09-16-2013, 09:34 AM
Last Post: Hans Brueggemann
  [HP 39Gii] - Bug report Jean-Michel 1 1,306 08-28-2013, 10:53 AM
Last Post: Tim Wessman
  HP 15C-LE replacement still available? Borja 16 4,001 08-22-2013, 11:16 AM
Last Post: Michael de Estrada
  HP Prime: Error reports : Here Patrice 111 16,405 07-24-2013, 05:52 PM
Last Post: Thomas Klemm
  JTAG on HP-12C and HP-15C LE Ingo 5 1,960 07-01-2013, 06:37 PM
Last Post: Paul Dale

Forum Jump: