HP-48GX version P hanging

[rui.c.sousa.99]

Hello
I bought recently a HP-48GX version P and it happens that this calculator sometimes hangs. Only have it for three days.
I have other HP-48GX version R and it almost never hanged (while normaling using it in UserRPL).
When the P version calculator hanged the first time, on the first day, I knew I was doing "strange" things, like passing whole directories from the version R calculator to the version P, in ascii, and the P version errored while parsing the ascii result. I thought it could be due to differences in the calculator versions.
Then I transfered the directories in binary and the transfer was ok. But after a while the calculator start hanging, and I thought it could be some memory corruption due to the transfer. I have checked the bug list for version P, and there are bugs in the transfer commands.

I reset the calculator, passed again lot of programs, and libraries, and it worked very well for a couple of days
but now, after a couple of days, it hanged again in the editor, while writing a user rpl program.

Is there any stability problem with version P? Or is this device malfunction?
I made all the ROM tests and they are all OK


Regards

[Han]

Here is some information on the ROM differences/bugs that may be relevant to your use case:

http://www.hpcalc.org/hp48/docs/faq/48faq-3.html

[rui.c.sousa.99]

Hello
I had already checked that information.

The calculator crashes when it appears to be busy (perhaps during garbage collection), for example when exiting the editor, or debugging a program. But not always. Sometimes it hangs, sometimes giberish appears on the screen. But after a reset, the calculator seems ok, and the memory is also ok.
It hanged with the internal editor but never with for ex string writer editor that I downloaded and use.
I realize this happens when the clock is ticking on the screen. Now I disabled the clock, and it seem stable, didnt crash anymore.

But I never have see this reported. I know that some versions have bugs related to the overflow of the return stack registers.
But the clock on the screen seem to be a such "banal" situation for this to happen

Thanks anyway