HP Forums
HP-15C LE -- endless loop in SOLVER - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: HP-15C LE -- endless loop in SOLVER (/thread-203023.html)



HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011

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
.
.
.




Re: HP-15C LE -- endless loop in SOLVER - Jeroen Van Nieuwenhove - 10-27-2011

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.


Re: HP-15C LE -- endless loop in SOLVER - Thomas Radtke - 10-27-2011

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

Why does it blink in the first place?


Re: HP-15C LE -- endless loop in SOLVER - Kiyoshi Akima - 10-27-2011

The HHC2010 15C+ just stops with Error 0.


Re: HP-15C LE -- endless loop in SOLVER - uhmgawa - 10-27-2011

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.




Re: HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011

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


Re: HP-15C LE -- endless loop in SOLVER - Marcus von Cube, Germany - 10-27-2011

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


Re: HP-15C LE -- endless loop in SOLVER - Gerson W. Barbosa - 10-27-2011

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


Re: HP-15C LE -- endless loop in SOLVER - uhmgawa - 10-28-2011

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.




Re: HP-15C LE -- endless loop in SOLVER - Marcus von Cube, Germany - 10-28-2011

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.