HP Forums

Full Version: unknown (?) error message HP48G
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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?

"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

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.

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.


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.

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.