This morning I would have said, "Bring it on!", but since the problem I was working on went away (moved out of my stuff and into our script based stuff), I don't really need it fixed at the moment.
Still, I can't believe that other people aren't running into this on a daily basis - maybe it's just our application and the fact that we do put the device to sleep most of the time that makes my experience different - but boy is it annoying to be all ready to catch a bug and go into CW to set the breakpoint and weeeerrr, dead POSER.... Is there a similar explanation for the fact that if, while asleep, one clicks in the graffiti area, POSER dies in that state too? Thanks for the explanations though! Kevin -----Original Message----- From: Keith Rollin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 2:53 PM To: Palm Developer Forum Subject: Re: General problem with POSE At 12:54 PM -0500 8/28/02, Ben Combee wrote: >I didn't think POSE would let the device go to sleep. Yes, Poser lets the device go to sleep. Just try pressing the Power button. :-) One thing that Poser does in this area is set the auto-sleep timeout value to <never> when it boots a device. However, it lets that value be changed (for example, with the General preferences panel). >Unfortunately, the debug protocol between CodeWarrior's debugger and >POSE doesn't allow complicated retries. The TCP/IP channel they use >is open all the time, and I think it is POSE that is hanging when it >tries to modify memory on the device. Yes, I'm pretty sure it's Poser that's hanging, too. The problem is that in order to handle the incoming debugger packet, Poser needs to synchronize the thread handling the packet with the thread performing the CPU emulation. With the CPU thread "sleeping", the synchronization process hangs. This problem is not insoluble, but occurs so infrequently (Kevin's experience aside) that I never got around to fixing it. Fixing the problem may be tricky. Some debugger packets have different requirements from others. For instance, handling a "set breakpoint" packet should be pretty simple to handle, and doesn't require much synchronization with the sleeping CPU thread. However, other packets (such as RCP packets) require a fully awake and running CPU thread. Either that second problem would have to be solved in order to even handle "set breakpoint" packets, or the packets would have to be classified according to which could be handled when the device was asleep or not. If anyone wants to take this on, I can lead them around the source code. -- Keith Rollin -- Palm OS Emulator engineer -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ ------------------------------------------ The information in this transmittal and any attachments is privileged and confidential and is intended only for the recipient(s) listed above. You are hereby notified that any unauthorized distribution or copying of this transmittal or its attachments is prohibited. If you have received this transmittal in error, please notify Invivodata immediately at (831) 438-9550. ------------------------------------------ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
