HP Forums

An incomplete program I was developing, still buggy, becomes stuck in a loop - this happens sometimes in software development.

What should NOT happen (but does) is for the hardware to become so locked in its loop so that user intervention becomes impossible. One cannot even switch the calculator off. The only way we have found of breaking the loop is to use a pin in the reset hole but this erases all memory and destroys all on's work.

A calculator with no possible means of saving programs except in volatile memory must, must, MUST have extremely robust firmware. For it to let us down like this, and force us to erase everything, is appalling. It means we cannot trust it not to wipe out all our work when we develop any new software.

I am hoping fervently that HP can tell us how to solve this (eg some keystroke combination to break the loop).

Serial numbers known thus far to be prone to this aberrant behaviour :
- CNA 72100255
- CNA 72100299
- CNA 72101944
- 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 the above 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.
--
John

Hi John:

If I were you, I'd send the 35s back, and get a 50g and move on. You won't have this sort of problem, and you'll have a machine that is truly capable of advanced programming, i/o etc.

Quote:

---

If I were you, I'd send the 35s back, and get a 50g and move on. You won't have this sort of problem, and you'll have a machine that is truly capable of advanced programming, i/o etc.

---

1. Too big piece of hardware - dimensions, weight. I take my calc nearly everywhere so these parameters are important. However, I admit that the HP35S in it's comfortable (but large) case has practically the same dimensions as HP50G.

2. Very high consumption of batteries. I want my calc to run for months if not years on a set of batteries. The 48GII needed new batteries after several weeks. Is the new 50G better in this? How long it takes to drain a new set of batteries?

3. In general, the 48GII et al is an overkill for my style of work. I need a calc for quite simple but quick and effective hand calculations (with some short user defined functions, invoked by 1 or 2 key press, like normal functions). For anything more complicated, a PC or notebook is always available. I absolutely don't need such miracles like CAS and the whole lot of fantastic powerfull functions of the 'G' series.

However, after the bitter experience with HP35S, I may test a 'G' series calc again in short future. What an irony - HP, after delivering a buggy HP35S calc, may get a new 50G customer! What a marketing success! I would really hate to do it this way, though.

Vaclav

Hello John,

I also had this problem: calculator was locked in a (probably endless) loop while writing a Sudoku solver program.
Program length at this time was several 100 lines.

Only way-out: reset-pin and - of course - total memory loss ...

Serial no. of my 35S is CNA 72102148.

Since then I'm not keen on programming something on this gadget any more.

Regards,
Robert

Quote:

---

2. Very high consumption of batteries. I want my calc to run for months if not years on a set of batteries. The 48GII needed new batteries after several weeks. Is the new 50G better in this? How long it takes to drain a new set of batteries?

---

All my C code starts with:

sys_slowOff();

I think you'll get months with the 50g, but not years. The first time you restore your 50g RAM from SD or PC you'll be glad you switched.

BTW, the C programmers kit for the 50g includes HPGCC and a .033 gauge paper clip. I have reset my 50g countless times using the RESET hole. All I have ever lost was the contents of the stack. Everything else was intact.

The 48Gii is a crippled version of the 49G+ which was replaced by the 50G. It is a price-point machine, not the fully capable top of the heap. At the time of the 48GII, you had to make the fasutian decision as to whether you needed any sort of RS232support, and if yes, then the 48GII was a must.

Also more to the point, John is doing *much* more with his 35s than you are...and from his descriptions, he is squarely in the territory of an I/O machine--whether a new 50G, or an old boat anchor 9815:-)

Quote:

---

This runs the 50g at full speed and is measurably faster. I am surprised with all my testing lately that I have not needed to replace the batteries soone

---

Is your hp 50g connected via USB? If so, it's drawing power from an external source, saving you money on AAA's

:) Pal

Hi, Egan;

I am about to search for information regarding the C Programming for the HP50G, but I decided to ask first (maybe it is faster). The basic set o'questions: documentation, where to find, how to get, etc. Should I go straight to hpcalc.org?

Thaks.

Luiz (Brazil)

Nope. Go here: http://hpgcc.org/

TW

I am working on a tutorial that should be ready in a few weeks.

Quote:

---

Is your hp 50g connected via USB? If so, it's drawing power from an external source, saving you money on AAA's

---

Hi, Egan;

I'm inspecting the HPGCC.ORG (thanks, Tim) and I see there's a bunch of documents to download. I'll be visiting the site till I have the files, and will be waiting for your tutorial. Please, let us know. If you have a mailing list for such purpose, please, feel free to add mine: lcvieira {at} quantica [dot] com (dot) br

Best regards and thanks.

Luiz (Brazil)

Quote:

---

Rarely. It only draws from USB if USB is connected before power on. Usually I have it on before I connect.

---

Or, for that matter, with the 50g off and disconnected from USB,
remove a AAA cell, plug in the USB, and turn the 50g on and run
it.

As far as I've been able to determine, as long as it's connected
to a powered USB port, it's powered from the USB connection,
regardless of whether it was on or off when the connection was
made.

A 5V adapter ("USB charger"), designed for charging the battery in
some USB-capable devices, works as well, as does an externally
powered USB hub, even without being connected to the PC's USB
port. The 50g requests only 50mA from USB, and I expect that any
of these sources should be able to supply more than that.

I'm rather surprised to find that the USB connection even supplies
"battery+" power to the serial port.

I don't know why your 50g should behave any differently. Try this:
With the USB disconnected, press ON and F together to get to a
test display, and then press the 8 key to start the "POWER" test.
One of the lines should be "BATTERY NORMAL" (or, I suppose, maybe
"BATTERY LOW" or something similar); now connect the USB cable and
it should change to "USB POWER WORK", and disconnecting the USB
should change it back to "BATTERY NORMAL".

But the 50g may very well do a warmstart instead of cleanly
switching back to battery power in cases where the USB voltage
"fades out" gradually, such as when the AC adapter is unplugged or
the PC is powered down while the 50g is still connected. I suppose
that similarly, the 50g might fail to properly switch to USB power
in a situation where the USB voltage "ramps up" gradually, such as
powering up the PC with the 50g already connected.

Regards,
James

Hello Robert,

Do you still have the partial program somewhere convenient for sharing, like a text file or MS Word file? If you do, I would like to see if I could repeat the problem. (Of course, if you don't already have it, I won't ask you to type in a several-hundred line program all over again!)

I want to find a short, repeatable test case, and analyzing your program along side John's program might help.

Regards,

Seth

I'll post it here.

I have a small utility that reports the battery voltage. If I power up then connect the cable, it can still read the batteries, if I attach then power up, it reports v0.00. I assumed that if it can read the voltage from the batteries that it is running from battery.

I tried the ON-F-8 tests. You are correct it reports USB POWER when connected/reconnected.

If I power up, attach cable, remove battery, I am still up and the batt util still reports voltage. It must be reading old sensor data.

I stand corrected, my unusual battery life my have been extended by USB. Since I connect to copy C binaries, I usually do not disconnect until done for the day.

Here is a list of serial numbers known thus far to be prone to the aberrant behaviour described below:

- CNA 72100255

- CNA 72100299

- CNA 72101944

- CNA 72102148

- CNA 72102361

With no possible means of saving programs except in volatile memory, extremely robust firmware is fundamentally important. In breach of this crucial principle, certain code fragments (not yet identified precisely) cause HP35s calculators to become so locked in a loop that user intervention becomes impossible. One cannot even switch the calculator off. The only way we have found of breaking the loop is to use a pin in the reset hole but this erases all memory and destroys all one's work stored on the machine (i.e. ALL PROGRAMS ERASED).

This is appalling because we cannot trust it not to wipe out all our work when we develop any new software so we cannot risk developing new programs when something we need is in memory.

I hope HP can tell us how to solve this (eg some keystroke combination to break the loop).

I hope we narrow down which code sequences/memory settings/conditions cause this, so that we can avoid them.

It would be good to know for sure whether anyone has a serial number for which the calculator WILL ACCEPT user intervention when it enters an endless loop with the code that has caused the above effects. 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. We need someone who can get the program into the endless loop that the above 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.

--

John

We do have one report of your program running without the lockup:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=126163#126163

Mark, if you're reading this message, could you (re-)confirm that you ran John's program as he described, and you did NOT encounter an unbreakable infinite loop? Could you describe what you did, and what the program behavior was?

Mark reports his serial number is CNA 72600768.

Can anyone else with a serial number that does NOT start with CNA 721- try the program?

Its important when testing for a loop lockup from the errant program to enter a combination of H and B that are around 20% smaller than the values suggested by the program and to enter a single value (eg 20) after the prompt for the steel "C,T BAR SIZES". Only after this does the program enter the vortex.

Anyone not familiar with reinforced concrete beam design might not realise that the program data entry is not finished until after this point. There is no "X=?" type of prompt for the steel, just the text shown above.

My concern is to be sure that people reporting good behaviour and a loop that they CAN break really do get into the loop. If you don't get into the endless loop then probably either there is an error in your program code entry or you haven't got to the end of the data entry part of teh program.

We do really really need to know if any calculators with more recent serial numbers exhibit correct controllable behaviour and allow the endless loop to be interrupted.

--

John

The plot thickens!

I have run the program many more times, and discovered that after entering a value for C,T BAR SIZES, if you step through the code even a little bit before pressing R/S, you can later break out of the infinite loop!! If you do NOT step through the program, you can not later break out of the infinite loop.

Here is exactly what I did, in the following order.

1. Keyed in the program. I got LN=1616,CK=D170 [but these figures will probably not be useful to anyone, because of a known and acknowledged bug in checksum calculation]. I have no other programs in memory.

2. Before each run, I performed the following operations, in order:

   a) CLEAR VARS

   b) CLEAR STACK

   c) DISPLAY FIX 4

   c) GTO ..

3. Start the program with XEQ B ENTER

4. I used the following inputs when prompted.

   M?= 150,000,000

   Y?= 460

   F?= 35

   C?= 40

   H?= 332   [suggested value was 443. 332 is 75% of suggested.]

   B?= 275   [suggested value was 366. 275 is 75% of suggested.]

5. When prompted by C,T BAR SIZES, I pressed ENTER

6. I entered 20, then pressed DOWN ARROW to step.

7. I stepped through the code a few times. Some of the lines I stepped through...

    B265 STO O

    B266 Rv

    B267 STO Q

    B268 STO L

    B269 RCL H

    B270 RCL C

    B271 -

    B272 RCL O

    B273 2

    B274 /

    B275 -

    ...

8. I took a deep breath and pressed R/S

9. The program got stuck in an infinite loop, displaying "NEXT BAR" and "RUNNING" over and over.

10. I pressed R/S again, and this time the program halted!

I was able to repeat these ten steps many times. Each time I was able to break out of the loop just by pressing R/S.

Alas, for the final try, instead of stepping through the program in step (7), I just pressed R/S. As expected, this time I was NOT able to break out of the infinite loop.

There seems to be some problem caused by fetching and executing the program steps. Possibly entering into the debugging environment by pressing the down arrow sets up or clears some environment that is not otherwise set up, and allows R/S to break out of the program.

Very frustrating. But I'm entranced by this problem, so I'll keep looking.

Edited: 15 Oct 2007, 4:23 p.m.

Congratulation Seth. What a detective work!

This is the kind of thriller I like to read. :-) So at least, following your procedure, John is maybe able to debug his program. Also, I hope that this is really a batch problem. I would like to hear from other people with higher S/Ns doing this test.

Miguel

Hi Seth,

unfortunatelly I do not have reasonable documentation, only some fragmentary flowcharts.

The problem occured in a nested loop.
Due to using a wrong variable one of the loops didn't terminate.
As far as I remember I interrupted the program with R/S, executed a few single steps and started program again with R/S.
I wonder if I switched the calc into PRGM mode and did some BST and SST - I can't remember.
After a while I realized that the calculator got stuck.

I don't know if it is important in this context: flag 10 was set all the time for displaying EQN messages.

BTW: meanwhile I'm convinced that writing a Sudoku solver program on the 35S is not the best idea, even if there are no crashes. Speed is way too slow.

Regards,
Robert

On comp.sys.hp48 I just found this:

Quote:

---

Joel Koltner

View profile

Newsgroups: comp.sys.hp48

From: "Joel Koltner" <JKolstad71HatesS...@yahoo.com>

Date: Mon, 15 Oct 2007 11:33:12 -0700

Local: Mon, Oct 15 2007 8:33 pm

Subject: Bug in HP-35S?

I've run the following program on a couple of HP-35S machines, and both of

them indicate that something Very Strange is happening in how equations are

being evaluated. Anyone else want to try this out?

Enter the following program:

LBL A

156.25

STO X

208.333333334 ;There are eight 'threes' in there

STO R

1.77951304201

STO Q

-R*X/(X*Q-R) ;Should evaluate to roughly -467, and it does

-R*X/(X*Q-R) ;Should (still) evaluate to roughly -467, but calculator outputs 31.323 instead!

RTN

It's important that the program is entered exactly as shown. Note that the

"-" in the expressions are entered with the "+/-" (change sign) key, not the

"-" (subtract) key. Changing the numerical constants will (often) make the

expressions evalulate correctly. Some minor changes (e.g., changing -R to +R)

in the expressions still demonstrates the error, but making significant

changes (such as changing X*Q-R to just X*Q) no longer does. Changing the

expressions to R*-X/(X*Q-R) fixes the problem. Removing the initial "-" in

the first expression causes the second expression to fail, although the output

is then -52.287 rather than 31.323!

I discovered this while creating a real program, which is rather alarming...!

Anyone have any ideas? Is this a well-known bug somehow?

---

Who knows, maybe it's got something to do with your bug...

Edited: 16 Oct 2007, 4:48 a.m. after one or more responses were posted

He may be able to debug his program, true... but even so, he can't trust that running the debugged program won't still cause a lock-up, and he'll lose all of his data again. Most upsetting!

My goal out of this is to find a small (< 75 line) repeatable test case that we can send to HP for their testing purposes. If anyone at HP can confirm a way to break out of the loop that we don't know about, then the current 35s might still be a suitable environment for complex programming. Otherwise, we'll have to wait for a new ROM revision before there's hope that the 35s will be trustworthy, I'm afraid.

It's a real shame, because I do love the 35s. It's my day-to-day calculator. The display is nice, the keyboard is nice, it's comfortable in the hand (I've become quite good at two-handed entry), and best of all I can get new ones if I drop mine (unlike the 41C or 42S!). But alas, I won't be doing much programming on it, I don't trust it not to erase all of my programs.

Edited: 15 Oct 2007, 8:30 p.m.

Flag 10 is set all the time in John's program as well. It may not be related, but at least it's a clue to add to our collection.

Brilliant piece of work, Seth.
Also very helpful to me because I now now not to trust it when the prob seems to have gone away during debugging.

I have been cleaning up the code using a debug version with R/S breakpoints in it. To my surprise, I got the (corrected) program fully working on the way home from work this evening. I have been removing breakpoints one at a time, hoping it won't lock up on me.

I will continue, even more carefully. I'll send you the latest code tomorrow.

I don't have an infinite loop to need to break out of at the moment but I d not know whetehr this is because of bits of code I corrected or because the calculator hardware is behaving itself whilst I have all these breakpoints still in it.

Needless to say I am keeping a careful written record of code changes.

Goodnight for now

---

John

FYI.

This "bug" (the one reported by Joel on comp.sys.hp48 --- not John's interminable loop bug) is also present in the 33s. Apparently, no one ever found this one on the 33s in over 3 years of use.

On a 33s...(edited to correct a thing or two)

A0001 LBL A

A0002 156.25

A0003 STO X

A0004 208.333333334    ;There are eight 'threes' in there

A0005 STO R

A0006 1.77951304201

A0007 STO Q

B0001 LBL B

B0002 -R*X/(X*Q-R)  

B0003 STOP        

B0004 GTO B

Gene

P.S. I checked this on an old HP32S2 - works fine on that machine.

Edited: 15 Oct 2007, 8:38 p.m.

Corrected and updated post:

My original-version HP-33s (S/N CNA413xxxxx) (mis-)performs as Gene's example states.

The HP-35s I bought in July (S/N CNA721xxxxx), as well as the HP-35s I got at the HHC conference (C/N CNA 734xxxxx) both exhibit the bug posted by Joel on comp.sys.hp48 -- the second equation result is incorrect.

-- KS

Edited: 18 Oct 2007, 12:49 a.m. after one or more responses were posted

On my HP35s (CNA726*****) it behaves oddly, too. Even if I change the variable name from X to K or R to S it's still the same wrong value.

But: if I change -R to -1*R it works correctly. Two times -466.927.


Tadahhhh! So maybe there is some register arithmetic going on if you apply the +/- sign directly to the variable.



Also, if I change back to Joel's original code and than put, say, 1 in the line between the two equations like:

-R*X/(X*Q-R)

1

-R*X/(X*Q-R)

the answers on the stack are

-466.927

1

-466.927

But if I only put R/S after every EQN, the result is buggy.

Edited: 16 Oct 2007, 5:42 a.m.

deleted: obsolete

Edited: 16 Oct 2007, 5:51 a.m. after one or more responses were posted

Quote:

---

are you saying you tested Joel's bug on both and one failed and the other 35s was correct?

---

I figured that there'd be some implied ambiguity in my incomplete specification, and it was called out. The truth was, I hadn't even opened my free HP-35s, which I received in late September.

So, this time I laboriously cut through the blister pack and tested the free one. It has a later S/N, CNA734xxxxx. (It also misses entry of "0" on the keyboard frequently!)

It also turns out that I misentered one line on the first HP-35s, adding an extra "3" in the long constant, making it 13 digits (208.3333333334). The constant actually used in calculations then became 208.333333333, not 208.333333334, and the second answer inexplicably turned out correct. Upon correction of the program and retesting, I found that both units have the bug. My earlier post is now corrected and updated.

This, of course, doesn't mathematically justify the vastly-different results of the two equations, but does help to illustrate the unsoundness of accepting -- then effectively discarding -- extra digits. No previous RPN calc -- not even the HP-33s -- handled input in this manner.

-- KS

Edited: 16 Oct 2007, 5:41 a.m.

This problem seems to occur very often even with simple coeffiecients.

A001 LBL A

A002 1.1

A003 STO X

A004 1

A005 STO R

A006 3

A007 STO Q

A008 ~R*X/(X*Q-R)

A009 ~R*X/(X*Q-R)

A010 x=y?

A011 GTO A014

A012 RCL R

A013 STOP

A014 1e~9

A015 STO+ R

A016 GTO A008

An error occurs when R =

1.000,000,006

1.000,000,014

1.000,000,022

1.000,000,035

1.000,000,043

..and so on..

Regards, Lyuka

It goes on to be weird:

The same odd behaviour can be found in EQN-Mode (not in a program!). You can type in "-R*X/(X*Q-R)" as an EQN, then evaluate it be keying in the appropriate numbers. First time you do this, -466.927 is the result. When you now evaluate the EQN a second time and key in the numbers again, you will obtain -466.927.

BUT, if you evaluate the EQN and only R/S the numbers that the HP 35s has already stored, you will get the same wrong result 31.323 EVERY SECOND TIME, alternated with the correct one.

BTW, I tested the program both in ALG and RPN - same weird result.

Edited: 16 Oct 2007, 9:40 a.m.

I am not sure what I am doing wrong, but if I use '+/-' for both minus signs then I get the obvious Syntax Error in the subtraction. If I enter the '+/-' as the first character and the subtraction operator for the second, I don't get the oscillating results, neither in Joel's version nor in Gene's equivalent with the LBL and GTO bracketing the equation.

However, if I enter this as an equation and do repeated evaluations, then the oscillating result appears.

My 35s is also from HHC2007, i.e., CNA73400XXX.

What am I missing?

Pavneet,

Your results are a little surprising. My CNA734 unit gets the oscillating results with the following program:

A001 LBL A

A002 156.25

A003 STO X

A004 208.333333334    ;There are eight 'threes' in there

A005 STO R

A006 1.77951304201

A007 STO Q

A008 -R*X/(X*Q-R)

A009 -R*X/(X*Q-R)  

A010 STOP        

A011 GTO A008

Jeff

Quote:

---

Running the above produces the wrong answer in the x register and the right answer in the y register. Pressing R/S will cycle through again.

---

My CNA725* also produced the correct answer in y and incorrect in x after every R/S.

I modified the two equation lines to be -1*R... (using +/- for the -) and then both results were correct.

Strange stuff.

sdb