unknown (?) error message HP48G



#2

While trying to get an answer to the S&SMC#14/1 for which I had written an RPL program, my HP48G finally asked *me* a question: "Try to recover memory?"

Of course I replied YES, but it reasked the question, so I couldn't do anything but reply NO and after a while the calc cleared itself and went into virgin status.

I cannot find this message in the manual, but I may have overlooked it. Does anyone have additional information on this behavior?


#3

"Try to recover memory?" indicates a reset condition and should appear if the calculator has reset itself. You probably ran out of memory in a way that the caclulator couldn't recover.

Marcus


#4

Due to a program error I may have filled the stack to its limits. I would have expected the program to just halt with a 'stack full' message, but in extreme cases apparently things don't always go as expected.

I think you're right with your answer. Thank you.


#5

When the HP48 uses up all available memory, it will go into a mode that will attempt to free up some of the used memory. In this mode, the calculator will prompt the user if it can delete various parts of memory, beginning with the least important section (e.g. last stack, last arguments, last commands, etc). Once "enough" memory is freed up, the calculator exits this mode. If more memory is required, it will restart and you may possibly have to purge more objects from memory. This is normal, and should never corrupt memory. This is completely different from the "Recover Memory?" mode. Unless your program was written in SysRPL or assembly, memory should always stay in tact.

Is your program written in SysRPL or assembly? Buggy programs in SysRPL or assembly can often result in memory corruption.

Quote:
Due to a program error I may have filled the stack to its limits. I would have expected the program to just halt with a 'stack full' message, but in extreme cases apparently things don't always go as expected.

I think you're right with your answer. Thank you.



#6

Quote:
Is your program written in SysRPL or assembly? Buggy programs in SysRPL or assembly can often result in memory corruption.

It was just a novice's little program between << and >>. To my knowledge that's neither SysRPL nor assembler and hence should only halt in stead of crash.

I was trying some things and cannot replay the exact program for I don't have it anymore, but it must have something to do with stack growth. I tried to clean it up between calculations, but I must have made an error there.

Anyway, your explanation is clear to me. I'll have to keep track of stack operations carefully (well, anyhow, I guess;-)

Thanks.


#7

Well, nothing done in "pure UserRPL" (excluding SYSEVAL, LIBEVAL, FLASHEVAL, and 49 series "hacker's library" commands, that is) should cause a "Try To Recover Memory?" (TTRM), including attempting to make the stack grow beyond available memory. However, there are some bugs (depending on the ROM version) that will cause a TTRM; maybe see the most recent 48 series FAQs at http://www.hpcalc.org/hp48/docs/faq/. Of course, it's also a possibility that you've stumbled upon a previously unreported bug.

Regarding programs or libraries written in SysRPL or assembly language, there's a possibility that a bug won't be immediately apparent, but willl cause memory corruption that will later cause a TTRM during UserRPL operations.

Too bad that the TTRM didn't successfully recover memory; it would be interesting to see what your program did.

Note the "Try" in "Try To Recover Memory"; sometimes it fails or is only partially successful. In particular, Bill Wickes's Insights says that a library shouldn't be left in a global variable after it's been copied to a port, as the TTRM will take the library as the start of port 0, thus any global variables or subdirectories following it will be lost.

Of course, if your calculator has anything that you really can't bear to lose, it's wise to have a backup of it on another device, either by transferring selected variables or using the ARCHIVE command.

Regards,
James

Edited: 14 Mar 2006, 3:56 p.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  MS advert shows spreadsheet with obvious error BruceH 3 320 11-14-2013, 09:50 AM
Last Post: Bill (Smithville, NJ)
  HP Prime: Rounding error in determinant Stephan Matthys 3 237 10-25-2013, 09:29 PM
Last Post: Walter B
  Prime Error or Mine? toml_12953 12 628 10-22-2013, 10:35 AM
Last Post: toml_12953
  Explaination on How to Reset Caculator in Users guie: error Harold A Climer 5 343 10-15-2013, 02:11 AM
Last Post: cyrille de Brébisson
  Formatting the app view message with bullets (dots) Geoff Quickfall 4 232 10-14-2013, 06:22 PM
Last Post: Geoff Quickfall
  Repair of HP-34C - Error 0 and Error 9 Jeff Kearns 3 248 10-11-2013, 12:29 PM
Last Post: Randy
  message for Andreas Grund Don Shepherd 0 114 09-26-2013, 03:56 AM
Last Post: Don Shepherd
  Message to Eric Rechlin Etienne Victoria 3 238 09-24-2013, 07:50 PM
Last Post: john mantooth
  Do You Think a Listing Error Was Made? Jim Johnson 13 598 09-04-2013, 09:23 AM
Last Post: Eddie W. Shore
  HP Prime: Error reports : Here Patrice 111 2,770 07-24-2013, 05:52 PM
Last Post: Thomas Klemm

Forum Jump: