HP Forum Archive 20

[ Return to Index | Top of Index ]

HP-15C LE Bug Reports Message #1 Posted by Katie Wasserman on 16 Sept 2011, 11:25 a.m. 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. -Katie

Re: HP-15C LE Bug Reports Message #2 Posted by John B. Smitherman on 16 Sept 2011, 12:37 p.m., in response to message #1 by Katie Wasserman 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? Regards, John

Re: HP-15C LE Bug Reports Message #3 Posted by gene wright on 16 Sept 2011, 12:57 p.m., in response to message #2 by John B. Smitherman 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. Really.

Re: HP-15C LE Bug Reports Message #4 Posted by John B. Smitherman on 16 Sept 2011, 2:31 p.m., in response to message #3 by gene wright Quote: 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. John

Re: HP-15C LE Bug Reports Message #5 Posted by Artur-Brazil on 16 Sept 2011, 2:51 p.m., in response to message #4 by John B. Smitherman 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? Artur

Re: HP-15C LE Bug Reports Message #6 Posted by Tim Wessman on 16 Sept 2011, 2:56 p.m., in response to message #4 by John B. Smitherman Is not. TW

Re: HP-15C LE Bug Reports Message #7 Posted by gene wright on 16 Sept 2011, 3:10 p.m., in response to message #6 by Tim Wessman 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! :-)

Re: HP-15C LE Bug Reports Message #8 Posted by Katie Wasserman on 16 Sept 2011, 3:29 p.m., in response to message #7 by gene wright 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. -Katie

Re: HP-15C LE Bug Reports Message #9 Posted by uhmgawa on 16 Sept 2011, 5:55 p.m., in response to message #8 by Katie Wasserman Quote: 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. -john

Re: HP-15C LE Bug Reports Message #10 Posted by bill platt on 16 Sept 2011, 3:30 p.m., in response to message #7 by gene wright REmember all that conjecture about the "lost" ROM? I guess the good news is, it was never lost after all!

Re: HP-15C LE Bug Reports Message #11 Posted by Martin Pinckney on 16 Sept 2011, 4:19 p.m., in response to message #10 by bill platt 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.

Re: HP-15C LE Bug Reports Message #12 Posted by Eric Smith on 16 Sept 2011, 3:48 p.m., in response to message #7 by gene wright 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.

Re: HP-15C LE Bug Reports Message #13 Posted by Artur-Brazil on 16 Sept 2011, 3:57 p.m., in response to message #12 by Eric Smith 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)...

Re: HP-15C LE Bug Reports Message #14 Posted by Dave Britten on 16 Sept 2011, 4:08 p.m., in response to message #13 by Artur-Brazil 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.

Re: HP-15C LE Bug Reports Message #15 Posted by Eric Smith on 16 Sept 2011, 4:41 p.m., in response to message #14 by Dave Britten 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.

Re: HP-15C LE Bug Reports Message #16 Posted by Gerry Schultz on 16 Sept 2011, 5:41 p.m., in response to message #12 by Eric Smith 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. Gerry

Re: HP-15C LE Bug Reports Message #17 Posted by Michael de Estrada on 16 Sept 2011, 12:38 p.m., in response to message #1 by Katie Wasserman 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.

Re: HP-15C LE Bug Reports Message #18 Posted by Katie Wasserman on 16 Sept 2011, 2:32 p.m., in response to message #17 by Michael de Estrada Quote: 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.

Re: HP-15C LE Bug Reports Message #19 Posted by Dan W on 16 Sept 2011, 4:53 p.m., in response to message #18 by Katie Wasserman Is there an alternative self-test that does work?

Re: HP-15C LE Bug Reports Message #20 Posted by Michael de Estrada on 16 Sept 2011, 4:58 p.m., in response to message #19 by Dan W Yes

Re: HP-15C LE Bug Reports Message #21 Posted by Mike Morrow on 16 Sept 2011, 7:24 p.m., in response to message #18 by Katie Wasserman 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!

Re: HP-15C LE Bug Reports Message #22 Posted by Lincoln R. on 16 Sept 2011, 7:49 p.m., in response to message #21 by Mike Morrow 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?

Re: HP-15C LE Bug Reports Message #23 Posted by Dave Britten on 16 Sept 2011, 8:56 p.m., in response to message #22 by Lincoln R. Maybe it isn't a checksum. Maybe the calculator is making rude noises because it's tired of running the self-tests.

Re: HP-15C LE Bug Reports Message #24 Posted by Mike Morrow on 16 Sept 2011, 10:56 p.m., in response to message #22 by Lincoln R. 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.

Re: HP-15C LE Bug Reports Message #25 Posted by Bart (UK) on 17 Sept 2011, 8:05 a.m., in response to message #24 by Mike Morrow Quote: 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)

Re: HP-15C LE Bug Reports Message #26 Posted by Mike Morrow on 18 Sept 2011, 12:01 p.m., in response to message #25 by Bart (UK) Quote: 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?"

Re: HP-15C LE Bug Reports Message #27 Posted by Eddie W. Shore on 18 Sept 2011, 3:56 p.m., in response to message #1 by Katie Wasserman 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.

Re: HP-15C LE Bug Reports Message #28 Posted by Katie Wasserman on 18 Sept 2011, 4:18 p.m., in response to message #27 by Eddie W. Shore This bug has been reported and documented here along with other bugs. Edited: 18 Sept 2011, 6:52 p.m.

Re: HP-15C LE Bug Reports Message #29 Posted by Mike Morrow on 18 Sept 2011, 4:44 p.m., in response to message #27 by Eddie W. Shore 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.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall