> From: Danny Epstein
> Date: Fri, 27 Jul 2001 17:01:00
> > err = ExgPut(socketPtr);
> > if (!err) {
> > err = ExgDBWrite(WriteDBData, socketPtr, NULL, dbID, cardNo);
> > err = ExgDisconnect(socketPtr, err);
> > }
> >
> > Sometimes the LCD display gets corrupted after the ExgPut() call.
>
> After the ExgPut call or after the ExgDBWrite call? How do you know?
> Could your callback function be writing to screen memory? What
> device are you using? Which version of Palm OS are you using? Debug
> or release ROM?
After more investigation, I think I've isolated the problem. It happens
only on my PalmVIIx w/ 8MB RAM running OS 3.5. My apps allocates quite a
bit of memory, but still leaves about 118KB in the dynamic heap.
The screen corruption happens when the built-in "Beam" dialog displays
the animation, both during sending ("Searching ...") and durring
receiving ("Receiving: <appname>").
Also, the bug happens ONLY if my app sets the screen depth to 4-bit gray
scale. If I omit the call to scrDisplayMode(scrDisplayModeSet, ...),
then the bug never shows up.
So, to work around the problem, I just set the screen depth to 1 before
calling any of the beam operations (send or receive), and restore the
depth to 4-bit when the beaming is done. For beam receiving, I look for
vchrIrReceive events.
Strangely, the bug does not happen inside POSE (with debug or regular
ROM). It doesn't happen on my PalmVII (2MB RAM) either. However, the bug
DOES seem to be memory related. If I reduce the amount of memory
allocated by my app on the VIIx the bug goes away.
> If you can get your beaming code working in loopback mode
> (shortcut-dot-t), you can run it in Poser on a debug ROM. I'm
> guessing either you or the OS is writing using an invalid
> pointer. There's a good chance using Poser as I described will
> discover who's doing this when it first happens. Of course, the
> problem may go away when you run in loopback mode. This is likely if
> our IrDA stack is to blame.
>
> You could use the "ss" = "step spy" command in PalmDebugger to watch
> the appropriate area of screen memory, but you couldn't stay
> connected to the debugger while you're actually beaming. This isn't
> likely to be a problem because it sounds like the spurious write is
> occurring before you call ExgDisconnect. I don't think the serial
> port is needed until then.
Since the bug also occurs during receiving
(SysHandleEvent(vchrIrReceive)), I suspect the bug is either inside the
IrDA stack, or my app corrupts the dynamic heap for some reason.
However, POSE 3.1 doesn't complain any of my memory writes, even if I
turn on all the debug options. So I suspect that the culprit is inside
the IrDA stack. I don't have access to the IrDA source code. Could it be
doing some clever animation for the "Beam" dialog that doesn't work in
4-bit gray scale mode?
Any idea on how I can validate the state of the dynamic heap just before
I enter SysHandleEvent(vchrIrReceive)?
Thanks!
- Ioi
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
