HP-15C LE -- endless loop in SOLVER

[Gerson W. Barbosa]

The HP-15C LE will alternate forever between "running" and "Error 0" in this example:

001- f LBL A

002- g LN 

003-   /

004- g pi

005-   -

006- g RTN

1 ENTER f SOLVE A    ->  running

                         Error  0

                         running 

                         Error  0

                            .

                            .

                            .

[Jeroen Van Nieuwenhove]

Interesting. The 15C emulator in Nonpareil gets stuck at the first error message, as would be expected. I suppose the original 15C behaves the same. This is strange, since the 15C LE is based on the same firmware. The error handling seems to be influenced in some way.

[uhmgawa]

Quote:

---

Interesting. The 15C emulator in Nonpareil gets stuck at the first error message, as would be expected. I suppose the original 15C behaves the same. This is strange, since the 15C LE is based on the same firmware. The error handling seems to be influenced in some way.

---

I'd be quite surprised if this was due to a change in the
firmware error handling behaviour peculiar to the 15c le.

Gerson, is the alternating between "running" and "Error 0"
occurring at the same rate of the display blink frequency?
[I don't have a 15c le handy ATM.] If so I'd make a wild
guess this is somehow due to the display update minimization
logic along with an interaction of exiting the emulator driven
display blink mode. Although I can't really think of a reason
a shadow of the prior display contents would be needed.

Running this on KEMU I find the expected behaviour. The display
update sequence preceding this point looks quite vanilla as well
so I don't have a better guess.

[Gerson W. Barbosa]

Yes, exactly the same rate of the display blinking frequency (according to my measurement).

[Marcus von Cube, Germany]

You can stop it with any key. It looks like a display problem.

[Gerson W. Barbosa]

No big issue like the PSE bug, I agree, but worth taking into account in a future firmware upgrade.

[uhmgawa]

Quote:

---

Although I can't really think of a reason
a shadow of the prior display contents would be needed.

---

Ah, I suspected it may be rooted in the lcd controller as it
does provide a hardware timed blink. See section 34.5.6 Buffer
Swap Mode (pg 502)
here for details. There is a two level data
buffering scheme allowing update to a yet-to-be-displayed buffer
which is subsequently transferred to the lcd display (multiplex
scan) buffer. If the lcd controller is placed in "Buffer Swap Mode"
the data driven to the display will alternate between both buffers
at the hardware blink frequency. Seems like the controller is
unintentionally winding up in this mode vs. (presumably)
Normal Mode.

[Marcus von Cube, Germany]

You need to wait long enough after you have written to display memory before you can safely change the mode. The docs say it takes 2 refresh cycles but my experience is that waiting even longer is a good idea. WP 34S does not do a busy wait, the display refresh triggers an interrupt (at roughly 50 Hz) and the number of interrupts is counted. The logic is in the sources in main.c under LCD_interrupt():

	/*

	 *  Wait for LCD controller to copy the user buffer to the display buffer.

	 *  Then turn off the automatic update.

	 *  WaitForLcd is set to 1 by finish_display()

	 */

	if ( WaitForLcd ) {

		if ( ++WaitForLcd == 3 ) {

			SLCDC_SetDisplayMode( AT91C_SLCDC_DISPMODE_LOAD_ONLY );

		}

		else if ( WaitForLcd == 4 ) {

			WaitForLcd = 0;

		}

	}

I'm not using the blink option but I need the display memory for storing intermediate data. If I remove the 'else' part and clear the variable directly after mode switching, display memory gets corrupted. The trick is to wait for another cycle after switching to 'load only' mode.

[Thomas Radtke]

The emulator just blinks w/o showing 'running'.

Why does it blink in the first place?

[Kiyoshi Akima]

The HHC2010 15C+ just stops with Error 0.