Another 12C+ Bug


This is a tiny bug, but disturbing in an emulator-based calculator just the same. This simple program will blank the screen and lock up 12C+ in a such way that you need to turn off the calculator to recover from:

01 1
03 GTO 01

I'm running firmware dated 7/31/2009, can anyone confirm that this problem existed in earlier firmware 12C+ calculators? (press [ON]+[G]+[ENTER] then [2], [any key] to see the date) On all other 12C calculators that I've tested pressing any key will abort the program, as it should.



The program terminates when a key is pressed but only after some seconds (sometimes five seconds, sometimes up to 15 seconds). Firmware date: 2008-06-28.



I have the same firmware date as Gerson (2008-6-28), but no key press on my unit will terminate the program, even after 30 seconds or so. Only turning it off will work.


Oh, I forgot to add, it continues to display "running", but it doesn't flash, just kind of sits there until you turn the calc off to get rid of it.


I forgot to mention the program would not terminate upon the first key presses, I had to keep trying until I found one that stopped the program.

Edited: 27 Aug 2009, 7:34 p.m.


Try rapidly toggling a key, then hold.


Katie, based upon these bugs that you have found in this ARM-based 12c, I'll bet the financial and real estate firms that buy these for their new employees will want to buy the older (slower) 12c's, because they are dependable. It seems that only the members of this forum are particularly interested in getting the newer units.



You might be right, but I don't think that there will be a choice in short order since, only the new (12C+) machines are in production I believe. Isn't that why HP did a silent roll-out of this model?

Given the results reported above, I think that the faster the emulator is the less opportunity it has for program interruption. The firmware dated 7/31/2009 is 2.5 times faster than previous versions allowing little or no time for keyboard interrupts.


Edited: 28 Aug 2009, 5:12 a.m. after one or more responses were posted


If the keyboard handling was done the way I recommended, it wouldn't matter how much faster the simulation was than the original. There's no fundamental reason why speeding it up makes it hard for it to be responsive to the keyboard; that's just the effect of a bad decision in how the keyboard scanner code is designed and how it interacts with the simulation, possible as a result of having more concern for speeding it up than making the simulation accurate.


Could it be that the speed is causing the processor to scan through the keyboard latches/mux/buffer (whatever) too fast, not allowing the signals to settle on the uP I/O lines causing it to "miss" the keypress?

Just speculating as I have no clue of the ARM & 12C architecture.


No. The scanning is done by software, and the software can do it at any rate the programmer wants (within reason).


So my question is not how often the programmer calls the kbd scanning routine - but that, with Katie's short program, the routine now executes too fast, reading the port register before the signal has established itself and the port's register is updated. This is what could be associated with "speeding things up", no measures are put in place to accommodate the latency of the H/W when we merely increase clock speeds or plug in fast processors on existing H/W designs.

If increased speed is achieved by reducing the frequency by which the kbd scanning routine is called, a longer keypress would solve the problem.

If however due to the "shortness" of Katie's program the kbd scanning routine is skipped, then we have a different type of bug - something is wrong in the software and that has nothing to do with speed.



the keyboard scanner is under interrupt, so when you press a key, it toggles an interrupt and scans the keypad immediately.

Since there is then no way to detect directly further key presses on the same column or all key releases cases, a timer is set that scans the keyboard every 10ms until all keys are released...

The problem does not stem from there...

The problem stems from the fact that the original 12C WAITED for all keys to be released before going in 'IDLE' mode. This is not a problem for eric's windows based emulator who can just ignore that wait loop.

However, on the real hardware, where a typical keypress last around 250ms but executes in <10ms, this would lead to a lot of wasted battery power...

So, the emulator attempts to detect when the old ROM is entering this 'wait for all key released mode' and tells the old ROM that all keys have been released (even if they have not), but there is a need to program a lot of special cases to handle this (problems with SST for example, or the PREFIX and MEMORY functions are examples)... and I guess that there is still something wrong with the way the key detection is done in the AMORT function...

regards, cyrille


Hi Cyrille,

I've done some reading up on the AT91 ARM (assuming the 12C+ uses the same as the 20B). I guess you're using a similar structure to their 4x4 keypad example.

From the datasheets the interrupt seems edge triggered, also the "de-bounce" is implemented by delay rather than circuit. I just was wondering if somehow the trigger was missed or the de-bounce not long enough (maybe because of the short routine (??)) - hence my other post advising to try rapid key toggles followed by a hold, to generate multiple interrupts hoping at least one would be caught.

Another avenue of thought I had was that if the AMORT routine used an FIQ, it could mask an IRQ of the keyboard matrix, because Katie's routine pretty much keeps it permanently in the AMORT routine.

Again, just some thoughts.




the debounce is done 100% in software and is done by taking a time stamp when the key is pressed. If it later detects the same key pressed without another keypress inbetween within less than 100ms, it considers the 2nd key as a bounce... so there is no time wasted in doing the debouncing...

the 12C rom does not have any IRQ/FIQ or other...

the problem is that the emulator lies to the ROM when it request information on the keyboard from the emulator. the emulator lies in order to protect battery life... I tried to remove/hide/patch all the side effects caused by this 'lie', but that one, I do not know how to fix.

regards, cyrille..



the 12C rom does not have any IRQ/FIQ or other...

I thought maybe the emulator takes the keyboard interrupt & key data and passes it on the rom via an interrupt. The FIQ idea was just a stab in the dark.

I think I understand how the emulator's lie about the "key still pressed" works when in calc mode (and you definetly do not want the processor running full blast >25x longer than it needs to). However, when executing a program, would the rom not look for a key press, rather than a key release, to stall execution? Or does the rom have a "glitch catcher" that when it sees a key press followed by a quick release (now due to the lie) it assumes that no key was pressed and continues execution? OK, perhaps this is a bit far fetched, right now I just can't think of another reason why a lie about key release can cause a problem for something that requires interruption via a key press.

I wish you luck with solving this.

regards, bart

The code I use on real hardware doesn't ignore the wait loops. In addition to my PC version, I've got simulation code running on three different embedded hardware platform (but not yet on the AT91SAM7L128), and on these platforms it does one of three things:

  • drop the clock to 32 kHz and continues polling
  • go to sleep with CPU clock stopped but 32 kHz timer clock active, for a periodic wakeup to continue polling.
  • go to sleep with all clocks stopped, for a wake on port change when the keyboard input changes

Once the condition of the wait loop is met, it resumes full speed.

Have a simulation ignore ANYTHING that the original did is a recipe for disaster, unless you understand exactly why it did it. Unfortunately neither of us is in the position of knowing exactly why the 12C firmware does a lot of the things it does, without spending a lot more time on reverse-engineering than either of us can likely afford.


No, I've got my code running on real hardware, and it does sleep while it's waiting for a key to be released. It's not that hard to do it properly. Just use a timer interrupt to wake it up periodically, check whether the key is still pressed, and go back to sleep if it is. It's really not that difficult.

However, I don't see what that has to do with failing to detect a key press during a running program.

Maybe I should port my own simulator to the 12C+ hardware.


Maybe I should port my own simulator to the 12C+ hardware.

Have you considered porting your 15C simulator to it? It would be awesome, even if the keys and faceplace didn't match the actual functions.


Have you considered porting your 15C simulator to [the 12c+]?

No need for that. There have been some strong indications on this forum that HP will issue a 15C+ sometime in the not too distant future. See this recent thread in particular.



Please note that I'm using coulds & woulds. As I said before I am not familiar with ARM & 12C architecture. I just like to speculate & discuss things - maybe trigger some thoughts.


Does the memory stay intact? The 35s has a deadlier form of the bug which requires removal of the batteries & results in "memory lost".


Yes, memory is intact. I haven't seen any memory-related problems with the 12C+. This is strictly a timing issue given that the slower version of the firmware has the same problem but not quite as bad. The other timing issue I mentioned recently is that the keyboard self-test times out in about 2 seconds giving an error message. The original 12C does this too, but it takes several minutes so it's gone unnoticed.


I remember your previous thread on the keyboard test time-out. I tried some Pioneers, and they timed out after around 1 to 3 minutes. These bugs raise some concern as to whether the I/O and man-machine interface received due consideration when the ARM upgrade was implemented.


On the original 12C, when this program is run does "running" flash, or stay on constantly? I expect that you'll say that it flashes, but that the way that both Cyrille's and my simulators work, it won't flash in simulation. If so, I know why, and can fix it in mine fairly easily. Mine doesn't have any problem with recognizing keystrokes instantly, though, even when I crank up the simulation speed to over 500x original.


On the original 12C and the 25th Anniversary edition, "running" flashes when this program is run.


Thanks. I'll apply the fix to my simulation code.


Out of curiousity may I ask if the simulation is purely S/W or some sort of ICE on original 12C H/W?


My simulation code is purely software.


Which, as i'm sure you'll agree, is not quite the same as real H/W. Besides, an ICE does not cover it all either.

... without spending a lot more time on reverse-engineering than either of us can likely afford.
I understand this time problem and thank you & Cyrille for allowing me to indulge my thoughts. I always have a desire to get to the root cause of a problem, but -reality check- this is not a critical problem. It is easily solved by switching the unit off & on again and without memory loss.


Cyrille's code running in the 12C+ is pure software too. And I've run my code on real hardware (though not the 12C+ hardware).

ICE doesn't enter into this *anywhere*.


Hi Eric,

Yes, sorry, I kind of gathered that. My ICE comment was to say that ICE does *not* solve all problems.

Let me just add I am thankful to you & Cyrille for the efforts put into the 12C+.

I currently don't have any 12C H/W (or S/W) to play with, but hope to get a 12C+ soon.

regards, B


My ICE comment was to say that ICE does *not* solve all problems.

Oh. You're absolutely right about that.

Let me just add I am thankful to you & Cyrille for the efforts put into the 12C+.

99.999% Cyrille, but I've tried to help him with it when he's needed it.

Possibly Related Threads...
Thread Author Replies Views Last Post
  38E/C, 12C, 12CP date arithmetic bug Katie Wasserman 26 2,546 10-19-2011, 08:57 PM
Last Post: Miguel Toro
  HP 12C Platinum CHS bug? M. Joury 23 2,503 08-11-2011, 06:45 PM
Last Post: Gerson W. Barbosa
  HP 12C, 12C Platinum & 15C iOS App Walter Lam 2 664 06-02-2011, 01:25 PM
Last Post: Andrés C. Rodríguez (Argentina)
  Bug in 12C iPhone App Andrew H. 1 427 11-03-2010, 09:01 AM
Last Post: Namir
  12C vs 12C Platinum Cash Flows Katie Wasserman 10 1,392 12-28-2005, 10:12 PM
Last Post: tony(nz)
  HP-12C bug Kalevipoeg 4 592 10-08-2004, 02:05 AM
Last Post: Kalevipoeg
  12c/12c Platinum programming differences Don Shepherd 6 1,020 08-11-2003, 10:11 AM
Last Post: Gene
  12C or 12C Platinum...that is the question Joe 3 666 06-21-2003, 11:39 PM
Last Post: Don Nguyen
  Hi !! Gene, HP 12C vs 12C Platinum Luc Chanh Truong 0 428 06-09-2003, 10:28 PM
Last Post: Luc Chanh Truong
  Another 12c platinum bug from c.s.hp48 Gene 2 476 06-05-2003, 09:01 PM
Last Post: Scuba Diver

Forum Jump: