WP34S: "Domain error" when running a program



#2

I just entered a short program on my 34s, freshly updated. The program ends with a RTN and then an END.
After entering it, I went to the CAT, saw it there, and pressed XEQ to run it, and I got a "Domain error". I cleared the error, went to CAT again, pressed XEQ again and now it worked.

Now comes the weirder part. Executing it again, it returned the result "plus one". I tried single-stepping it, and in the single-stepping it got stuck in a loop: where it encountered the RTN, it skipped one step back, thus executing the previous command (which happened to be a INC X); after the INC it executed the RTN again, and so on, always adding 1 to the displayed number.

I have no idea why the single-stepping looped while normal execution only "skipped back" once, but I think neither is the intended behaviour... The manual says that RTN, if in a program and not a subroutine, should stop execution and set the pointer to 000.

The same happened in the emulator.

In case it matters, here's what is in the memory:

001   LBL'D'
002 DATE
003 YEAR
004 # 1
005 # 1
006 ->DATE
007 DATE
008 (Delta)DAYS
009 INC X
010 RTN
011 END

Cristian

Edited: 30 Jan 2012, 11:59 a.m.


#3

I think I can explain the SST issue: A top level RTN sets the PC back to where it was when the program was started. In the case of SST this is the step before the RTN. I agree that this is a little strange and worth reconsideration.

I can't reproduce the strange CAT behaviour. What is your version? I'm running 3.0/2347.

BTW, END serves as a RTN. So RTN is not needed in your case.


#4

The version I'm using is 2347. It's reproducible here, I'm writing down a list of operations to do to show the problem. I'll report it here when I have it.

Cristian


#5

Can't reproduce the strange CAT behaviour either. Emulator V3.0/2348.

And I count the SST looping being a bug.

Edited: 30 Jan 2012, 1:48 p.m.


#6

Quote:
And I count the SST looping being a bug.

I concur. I've uploaded a new build.

#7

I updated the emulator, and the loop bug is gone, but the "domain error" and hang-up are still there, as described in my post below...

I also have a .dat file from before the crash... with that dat file, you just go to program mode, move to step 008, exit program mode, and run the program, and here comes the crash. Do you want it to test it?

Cristian

Edited: 30 Jan 2012, 3:16 p.m.


#8

I was able to reproduce a loop in the error handler. Pauli has recently converted more stuff to XROM which made the error apparent. The "Domain Error" is thrown inside the [delta]DAYS routine by some bogus input.

I have not tested the weird CAT behaviour. There is most probably still something wrong.

#9

I have problems here. I'm able to consistently get weird results (sometimes the program gives the correct result but also displays the day's name; sometimes I get totally wrong results like 735628; and so on) but I have problems in finding the exact order of commands to induce them. But it seems (though I can't believe it) that unexpected results are triggered when exiting the program edit mode at different locations. If when I exit program mode I was at location 000 I get different results than if I was at 001 or, say 008...
I have to experiment some more. I'll report back.

#10

OK, the exact errors aren't exactly reproducible, but a weird behaviour is. Here are the exact steps I take (it seems that every individual keystroke counts...)

0) Hard reset, using the cable's "reset" button
1) Contrast- three times, to make display more readable
2) DATE (to verify reset) - it shows 1.012007
3) Back arrow twice to clear display
4) P/R (to enter program mode), it enters at step 000
5) Enter above program, without inserting the ending END because it's already there
6) Right after entering RTN, press P/R (to exit program mode)
7) CAT (it shows Lbl'D' RAM)
8) XEQ (it shows Monday 2007)

At this last step, sometimes it shows "Monday 2007", sometimes just 2007, sometimes "Monday 0", sometimes just 2, sometimes "Monday 732679" and so on... and doing CAT and XEQ again and again always gives different results (though sometimes you get the same result 3 or 4 times in a row). I have reflashed the calc, just in case, but it still does the same thing.

On the emulator instead, these following steps:

1) Total reset by removing wp34s.dat
2) DATE (shows today's date, taken from system clock)
3) P/R to enter program mode
4) Enter program as above, without ending END
5) Right after entering RTN, press P/R to exit program mode
6) CAT
7) XEQ (it seems to work right, even after several tries)
8) P/R
9) move to step 000
10) P/R
11) CAT
12) XEQ (it displays the correct result but also the weekday)
13) P/R
14) move to step 008
15) P/R
16) CAT
17) XEQ (it says Domain Error)

The emulator seems more consistent in that the results are always the same. I was wondering if maybe I had faulty hardware but the emulator does similar (though not identical) things...
After the Domain error, sometimes the emulator is left in a locked state. After forcing a quit, and reopening the emulator, it shows garbage on the screen. I have a .dat file from this state if needed...

Cristian


Edited: 30 Jan 2012, 2:35 p.m.


#11

I think I can explain why a message is shown: The date functions set an internal message to be shown on the next display event. This only occurs when the program has come to an end. I think it's better not to set the message when a program is running.

Can you try the latest build please? (It still sets the message.)


#12

Quote:
I think I can explain why a message is shown: The date functions set an internal message to be shown on the next display event. This only occurs when the program has come to an end. I think it's better not to set the message when a program is running.

The day of week command probably should set the message either way. I agree the rest can not. Or we should be clearing the message a bit more often than we do perhaps.


- Pauli


#13

I've made it dependent on the Running flag.

#14

On the emulator, I consistently get 30 if calling the program via CAT XEQ - and Monday 30 if calling it via XEQ'D' without using CAT.


#15

Quote:
On the emulator, I consistently get 30 if calling the program via CAT XEQ - and Monday 30 if calling it via XEQ'D' without using CAT.

Walter, the emulator is more consistent, did you try on the real hardware? Also, did you try on the emulator to enter program mode, go to step 008, exit program mode without changing anything, then run the program wia the CAT? Doesn't it give you the Domain error if you do that?

Cristian


#16

I'm getting no stack change from the console build executing this via CAT when I start with the PC at step 008.

I suspect we might be executing stuff after we return or at least not quite executing properly from the CAT display.


- Pauli


Edited: 30 Jan 2012, 5:08 p.m.

#17

Quote:
A top level RTN sets the PC back to where it was when the program was started. In the case of SST this is the step before the RTN. I agree that this is a little strange and worth reconsideration.

I'm still in favor of resetting the PC to the start of the current program instead of leaving it where it was. I've been caught out by this behaviour more than a few times -- it is both unnatural and annoying.


- Pauli


#18

There was a bug which led to the repositioning of the PC to the INC X statement. There is a problem with resetting the PC to the begin of the current program when we hit a top level RTN: Technically, executing a command that is implemented as XROM is just an ordinary XEQ to a routine which ends in a RTN statement. This would affect the user's PC which is undesirable.


#19

if (top level and not xrom)
pc = 0;


???

Okay not 0 but the start of the current program :-)


- Pauli


#20

All issues should be fixed by now. I've implemented something similar to what Pauli has suggested.


#21

After preliminary testing, both on emulator and real calc, everything seems to be ok. Thank you! :)

Cristian


Possibly Related Threads...
Thread Author Replies Views Last Post
  MS advert shows spreadsheet with obvious error BruceH 3 764 11-14-2013, 09:50 AM
Last Post: Bill (Smithville, NJ)
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 855 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  HP Prime: Rounding error in determinant Stephan Matthys 3 587 10-25-2013, 09:29 PM
Last Post: Walter B
  Prime Error or Mine? toml_12953 12 1,352 10-22-2013, 10:35 AM
Last Post: toml_12953
  Explaination on How to Reset Caculator in Users guie: error Harold A Climer 5 844 10-15-2013, 02:11 AM
Last Post: cyrille de Brébisson
  Repair of HP-34C - Error 0 and Error 9 Jeff Kearns 3 601 10-11-2013, 12:29 PM
Last Post: Randy
  Do You Think a Listing Error Was Made? Jim Johnson 13 1,302 09-04-2013, 09:23 AM
Last Post: Eddie W. Shore
  HP Prime: Error reports : Here Patrice 111 6,023 07-24-2013, 05:52 PM
Last Post: Thomas Klemm
  program print in wp34s Andrew Nikitin 13 1,341 07-22-2013, 10:11 PM
Last Post: Andrew Nikitin
  PARTFRAC error. Romeu Medeiros 2 501 06-23-2013, 10:27 PM
Last Post: Romeu Medeiros

Forum Jump: