Endless 35S loop, continued ...


I have tested the John Wasilewski's code on my HP35S and found the same problem - more on this in http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=126378#126378.

I want to ask more people to run the test so we can better understand whether it's a general problem or just a specific batch problem. Thanks in advance.




My S/N is CNA 72100299, I have written that in my entry here
So we have 2 calcs from (probably) the same day showing the same problem. Are there more?


Hi, Václav; (at least I hope this post is from you...)

about the endless loop and program structure. I know some programs may find an endless loop because of code OR argument error, i.e., either the code causes endless loops or the arguments force the code to do so. Of course, this would not lead the device itself to enter in a no-interruptible loop, i.e., a loop that could not be broken by some reset/restart key sequence. This is, surely, a bug and must be investigated.

Appart of that, I wrote John an e-mail mentioning another fact I noticed is related to data input. His original listing has the
following steps, step # included:

262. RCL Q
263. RCL O
265. STO O
266. R|
267. STO Q

Based on John´s explanations, one can either enter tension steel only or both compression stell and tension steel. John wrote:

20 R/S for tension steel only


16 ENTER 20 R/S for sizes of both compression steel (top) and tension steel (btm).

If we observe his listing, there is another problem there. Register Q contains compression steel value and register O contains tension steel value, both may also be already stored in calculator memory. A copy of both is brought back to the stack and if they are already there, one may simply keep them by pressing [R/S] and they will be stored back (steps B265 to B267). If we enter both new values, it will happen the same: the new values will override the old ones (again, steps B265 to B267). But if we enter only the tension steel and press [R/S], as John suggests, we will have the new tension value correctly stored in register O and
the previous tension steel value wrongly stored in register Q, overriding the one you actually want tokeep. For example, consider that you already have hipothetical values for tension stell and compression steel as follows: 12 and 18 (cannot tell if these are acceptable, just hipothetical). Let´s consider that you want to enter only the new value for tension steel, so the stack contents would be:

262. RCL Q 18 a b c a,b,c are placeholders
263. RCL O 12 18 a b Hipothetical values
264. C,T BAR SIZES 16 12 18 a You enter 16 only
265. STO O 16 12 18 a 16 correctly stored in O
266. R| 12 18 a 16 rolls down stk contents
267. STO Q 12 18 a 16 12 wrongly stored in Q

I am not sure about how would this affect program control, but it would surely disturb data organization. My suggestion would be a double stop: one for compression (press [R/S] to keep existing or key in new value then [R/S]) and another for tension (same thing: [R/S] to keep existing or key in new value then [R/S]).

I have already loaded the program and tested it step-by-step to a certain point, but I intend to add some modifications prior to run it straight. I'd not like to have the calculator stuck as it had already happened with some of you and have to key the program in, head to tail...

Also, I tested the VIEW(I) and VIEW(J) followed by PSE. The display always shows the contents of register (I+27) and returns INVALID (I) (or (J)), even when they are valid. If we remove the PSE and let the program to stop, it shows the correct register contents.

HP has definitely lost its way to design calculators... Bring AOC back, pleeeessss...


Luiz (Brazil)

Edited: 12 Oct 2007, 4:44 p.m.



There are numerous errors in the code.

I will fix them all.

I value greatly your comments and suggestions for error correction and optimisation. However, I want to get a working version before I start to polish up the code. See below for more about what I propose.

One of the errors, for example, appears many times in the subroutine befinning at line B020. I forgot to insert a ROLL-DOWN step after each bar diameter is tried. THis mistake happened because, after my first lockup failure, I had a written record of only 90% of my code and when working from memory, I forgot the ROLL-DOWN step in this subroutine.

I plan to key it all in again and try to get it working correctly even with the hardware fault. I will have to put in a lot of temporary R/S steps and not take them out until I know that there are no endless loops left after I finish debugging.

When I get a working version I will send it to you (and others) and look out for your suggested improvements.




Hi, John;

I value greatly your comments and suggestions for error correction and optimisation.
Thank you, I appreciate. Just would like to add that I am not actually trying to optimize the code so far, just doing some 'witch hunting' (error correction). Many programs have coding errors, none is completely free of them, and errors appear as code lines are added. What I mostly care is for the fact that it is somehow hard to test a program if errors prevail. My own way of dealing with programs is to 'purge' coding errors, then to hunt structure erros (GTO's, XEQ's, indexed operations, etc.) and then the cosmetics, the final product. If, and only if, applicable, the code optimization and shortening. But this is just the way I prefer dealing with my programs.

The picture below shows how did I deal with your program.

(click to enlarge)

Although you cannot see easily, your program is completely listed there. You can also identify my handwriting. The functions marked in red are XEQ (subroutine calls), and the subroutines themselves have their starting and ending points market wiht a thick, red line (vertical). Functions in blue are GTO's and their corresponding jumps are marked with thick, blue lines, ended with a small arrow. This way I could follow program logics. Some marks in yellow and blue are related to some possible problems.

However, I want to get a working version before I start to polish up the code. See below for more about what I propose.
I think I get it.

This is a sample of a program form for the HP35S I wrote in MS Word format. The specific TTF is the one I created sometime ago for the HP33S sometime ago with a few modifications (new characters) for the HP35S. I think I'll rename it after the HP35. The final document was then converted to PDF. The program in the listing was taken from an HP35S and typed in, I had no time to study it.

Anyway, I have my spare time spent somehow.

Hope you succeed.


Luiz (Brazil)

Edited: 13 Oct 2007, 11:14 p.m.


You have worked hard on it Luiz! I do very much the same as you when analysing code. I also like very much your HP35s programming proforma.

The "never executed" steps in subroutine 020 are because that particular subroutine was lost without a copy during one of my crashes. I thjought I could remember it but I got it wrong. There should be some ROLL DOWN instructions in it.

I am working on the program again now and I'm correcting mistakes like this. I do want to know what is wrong with teh calculator to lock it into a loop but I also want to make my program work.

I'll send you a copy of the next draft of the code.



Good work -- I'm only sorry the code is so long to replicate this hardware error. I have tried to create some shorter code to produce teh same effect. No luck yet. John


Good work -- I'm only sorry the code is so long to replicate this hardware error. I have tried to create some shorter code to produce teh same effect. No luck yet. John

Maybe it's not your code as such but its length/memory consumption or a combination of these that lead to the crash. That at least would explain why you couldn't reproduce the crash with smaller bits of code...


My own theory is that the processor interprets code as it runs and has to search for each GTO or XEQ address from the top of the code, and that it is this searching that blocks user intervention. With short code it finds addresses faster so spends more time executing. Long code it spends more time searching for the address of each jump than executing. Just a guess. I tried a 400 line program of rubbish with a few GTOs back and forth from to to bottom in an endless loop. This was difficult to iterrupt, but not impossible. John



I tried your code and I get the same result. The calculator enters an endless loop that cannot be interrupted and after a reset, all the data is lost. Well, I have to enter all my programs again. It was fun, though!!!!

My HP 35s is a CNA 72102361.

When the program enters in the loop, it shows RUNNING and then NEXT BAR SIZE again and again. Pressing the ON/OFF/C and others combinations does not interrupt the program. Just doing reset works but making the calculator to loose the data.

Thanks Luiz for sending me the code.



Edited: 13 Oct 2007, 12:08 p.m.


This is not good news Miguel, but thank you for your test result.

That is three serial numbers giving this aberrant behaviour :

- CNA 72100255

- CNA 72100299

- CNA 72102361

It would be good if we could find out for sure whether anyone has a serial number for which the calculator WILL ACCEPT user intervention when it enters an endless loop with this code. One or two people have reported that the program seems to behave normally, but I am a little unsure whether they took the test far enough, because I might not have explained sufficiently how to enter the data.

We need someone who can get the program into the endless loop that you, Vaclav and I have all experienced, and can then report successfully breaking out of it without having to erase all memory.

When we have this we will know that there is a hardware/firmware fault on early batch(es) of this calculator and we will know that it was fixed by HP on later production runs.




You may add my calculator to the list.

I typed in the full program and verified my entry before proceeding. I then followed the example inputs you provided at the beginning of this saga, and let the program run.

I entered an unbreakable infinite loop alternating between displaying "RUNNING" and "NEXT BAR". No key combinations were able to break out of it. I resorted to the Reset hole on the back of the calculator, which cleared its memory.

My SN is: CNA 72101944

I think the only useful thing to do now is narrow down on a single, small, repeatable test case to demonstrate the lock-up which we can submit to HP.


The "NEXT BAR" instruction was just a debug temp. breakpoint to help me keep track of progress through program loops. It isn't a data entry point. It will be taken out when the program works. I made the mistake of putting a PSE after it, so it did just that. It paused but then continued, stuck in its loop! I also forgot to put in a VIEW instruction to let me see what value of Q had accumulated in the loops.

I have now re-entered the whole program again and I'll try to debug more carefully, with extra breakpoints and with stepwise execution.

We must all try not to lose sight of the fact that the problem here is not how to get my program right. The problem is to find out what is wrong with the HP35s and whether it is just one production run or all of them that can sometimes lock themselves into a loop that users cannot break.

Thank you again for your help, Seth. Anything else you can discover from your investigation will be useful.



I will try the program one more time, but this time, when the program stops to ask for comp bar and tension bar diameters (C,T BAR SIZES), I will single-step through the program with the down arrow cursor key instead of hitting R/S. Perhaps I can get you some useful information that way.



I've single-stepped through the troublesome part of the program several times now, and I'm pleased to report that it is very effective at avoiding the infinite loop.

I let the program run until it gets to the point where it asks for C,T BAR SIZES. I then enter "16 ENTER 20". Instead of pressing R/S, I pressed and held the down-arrow cursor key. This is very important! Holding the down-arrow displays the line currently being executed. When you release it, the results are displayed in the stack. Press and hold again to see the next line, release the key to see the results, etc. You may press and release the button very rapidly if you want to work through each bar's inputs more quickly. It takes a while to step through, but it is much quicker than re-entering the entire program after losing your memory!

Oddly, when stepping through the program, it behaved the way it is supposed to. It pauses after displaying "NEXT BAR" and waits for input. It does not lock up.

I hope this will help you debug your program without losing your data yet again. It may also help locate the looping bug, but more importantly it will help you get back to developing with a little more confidence that you won't end up in another infinite loop.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime: Long integers (continued) Helge Gabert 2 1,113 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  WP34s integration trapped in infinite loop Bernd Grubert 25 4,798 10-17-2013, 08:50 AM
Last Post: Dieter
  HP15c continued fraction for Ln(Gamma) Tom Grydeland 0 836 09-30-2013, 05:48 AM
Last Post: Tom Grydeland
  New community-maintained version of "Calculators benchmark: add loop" Pier Aiello 20 4,606 09-12-2013, 02:42 AM
Last Post: Pier Aiello
  Calculator Speed Benchmark (Add Loop) Thomas Chrapkiewicz 2 1,073 01-20-2013, 11:24 AM
Last Post: Thomas Chrapkiewicz
  HP-IL: Using 82162A Printer and PIL-Box in Same Loop Les Wright 12 2,784 05-17-2012, 11:58 PM
Last Post: Les Wright
  HP-15C LE -- endless loop in SOLVER Gerson W. Barbosa 9 1,974 10-27-2011, 02:20 PM
Last Post: Kiyoshi Akima
  HP-15C LE Error 5 in simple loop Eric Zoob 4 1,028 10-14-2011, 12:05 AM
Last Post: Eric Zoob
  Symbolic Integration, Continued Austin W. 6 1,636 04-20-2011, 12:17 PM
Last Post: Austin W.
  HP-35S hung in "Memory Clear" loop? Scott Newell 2 2,024 02-18-2011, 12:34 PM
Last Post: Scott Newell

Forum Jump: