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
The following warnings occurred: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Warning [2] Undefined array key 195557 - Line: 275 - File: inc/plugins/threaded_mode.php PHP 8.1.2-1ubuntu2.14 (Linux)
|
HP-15C LE Bug Reports
|
|
« Next Oldest | Next Newest »
|
▼
09-16-2011, 11:25 AM
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 ▼
09-16-2011, 12:37 PM
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 ▼
09-16-2011, 12:57 PM
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. ▼
09-16-2011, 02:31 PM
Quote: 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 ▼
09-16-2011, 02:51 PM
Hi, John
Please, as I didn't receive my HP 15C yet, couldn't you make some simple tests on Complex numbers and matrices?
09-16-2011, 02:56 PM
Is not. TW ▼
09-16-2011, 03:10 PM
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! :-) ▼
09-16-2011, 03:29 PM
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
▼
09-16-2011, 05:55 PM
Quote:
Guess what? That's where most, if not all, of my KEMU bugs
There is a deceptive amount of functionality which can perform
Many other NUT instruction semantic dark corners exist in the
09-16-2011, 03:30 PM
REmember all that conjecture about the "lost" ROM? I guess the good news is, it was never lost after all! ▼
09-16-2011, 04:19 PM
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.
09-16-2011, 03:48 PM
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. ▼
09-16-2011, 03:57 PM
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. ▼
09-16-2011, 04:08 PM
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. ▼
09-16-2011, 04:41 PM
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.
09-16-2011, 05:41 PM
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
09-16-2011, 12:38 PM
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. ▼
09-16-2011, 02:32 PM
Quote: I'll mention this, thanks. ▼
09-16-2011, 04:53 PM
Is there an alternative self-test that does work?
09-16-2011, 07:24 PM
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: 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! ▼
09-16-2011, 07:49 PM
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? ▼
09-16-2011, 08:56 PM
Maybe it isn't a checksum. Maybe the calculator is making rude noises because it's tired of running the self-tests.
09-16-2011, 10:56 PM
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. ▼
09-17-2011, 08:05 AM
Quote: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) ▼
09-18-2011, 12:01 PM
Quote:
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?"
09-18-2011, 03:56 PM
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. ▼
09-18-2011, 04:18 PM
This bug has been reported and documented here along with other bugs. Edited: 18 Sept 2011, 6:52 p.m.
09-18-2011, 04:44 PM
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,457 |
11-19-2013, 08:14 AM Last Post: Joe Horn |
|
HP Prime - another cosmetic bug | BruceH | 3 | 1,678 |
11-12-2013, 02:18 PM Last Post: Ken Shaw |
|
HP Prime Bug | bluesun08 | 19 | 5,289 |
10-14-2013, 10:48 PM Last Post: Han |
|
HP Prime bug in EDITMAT | Han | 7 | 2,547 |
09-27-2013, 10:15 AM Last Post: Han |
|
OT - A lucky find - Busicom Handy-LE LE-120A | Cristian Arezzini | 2 | 1,783 |
09-26-2013, 04:43 AM Last Post: Cristian Arezzini |
|
Low power warning for HP-15C LE and batteries | Nick_S | 1 | 1,381 |
09-16-2013, 09:34 AM Last Post: Hans Brueggemann |
|
[HP 39Gii] - Bug report | Jean-Michel | 1 | 1,590 |
08-28-2013, 10:53 AM Last Post: Tim Wessman |
|
HP 15C-LE replacement still available? | Borja | 16 | 5,384 |
08-22-2013, 11:16 AM Last Post: Michael de Estrada |
|
HP Prime: Error reports : Here | Patrice | 111 | 22,335 |
07-24-2013, 05:52 PM Last Post: Thomas Klemm |
|
JTAG on HP-12C and HP-15C LE | Ingo | 5 | 2,386 |
07-01-2013, 06:37 PM Last Post: Paul Dale |