| Author |
Topic |
|
|
superiorcontrols
25 Posts |
 Posted - 11 Mar 2003 : 12:21:38
|
I'll post this under EVC because it is really only a debug issue, although it is a major pain.
In our development, we are using up to three COM ports and are intensively debugging. Occasionally, either because there is an error or just for convenience, we would like to abort the program without being able to programmatically close the COM ports.
After stopping the debug session, CE continues to hold those ports open and cannot be coaxed to close them without a boot. A boot, of course destroys the CEMGRC session and you start all over again.
Is there a tool we are overlooking to close those ports?
- - - - - - -
Later ... under Windows there are O/S tools to unscrew this problem. Typically, you can disable, then re-enable, the port and the situation will be cleared. I was curious if CE had any tool or mechanism to recover the situation. Saving the log files to flash, getting the registry entries into adsxxx.reg, saving the program to flash, rebooting, re-initializing cemgrc (even if you have put the string in the registry) ... these things make a long day even longer. As it is, we have the worst of both worlds -- the inconvenience of remote debugging -- and the obscurity of early Windows.
Surely there is a native API call that can access the internal tables and release the locked port. |
Edited by - superiorcontrols on 12 Mar 2003 19:13:08 |
|
|
ctacke
877 Posts |
Posted - 11 Mar 2003 : 16:01:42
|
This is an issue that isn't exclusive yourself - I'm dealing with it right now myself.
Unfortunately there isn't any way for an external process to get a valid handle to the port and close it (short of saving the handle somewhere like the registry when you open it) and when you stop the debugger, the port handle gets orphaned. The only "workaround" is to not stop debugging from eVC but instead always initiate the stop from the application and ensure that it can close the handle itself in all situations.
This is also an excellent example of a situation where exception handling is important. If your app gets an exception and shuts down without closing the port, again the port handle will be orphaned and the port left open until the device is reset. |
 |
|
|
superiorcontrols
25 Posts |
Posted - 13 Mar 2003 : 08:21:05
|
quote:
[i]Originally posted by ctacke[/i]
[br]This is also an excellent example of a situation where exception handling is important. If your app gets an exception and shuts down without closing the port, again the port handle will be orphaned and the port left open until the device is reset.
No kidding, he replied somewhat sarcastically. ;-) The original point was that, when debugging, you cannot always insure a clean close. Sometimes you want to stop at a breakpoint or at an exception -- before some physical event will occur. In our case we have other computers connected as well as smart ID devices and a PLC that controls shop floor equipment. When there is a debug error, you don't always want things to continue. |
|
|
|
ctacke
877 Posts |
Posted - 13 Mar 2003 : 08:37:25
|
| I fully understand. Using a UI control, like a menu item or button, that you enable only for debugging that gracefully shuts down the app and closes the port is the only thing I can think of offhand. |
|
|
|
superiorcontrols
25 Posts |
Posted - 13 Mar 2003 : 17:48:47
|
Thanks for your help.
As platform suppliers, you may have access to the bowels of CE in ways that I do not. Under Win32, I could use the native API and/or device driver functions to make a little utility to free the port. Under CE who knows ... |
|
|
| |
Topic |
|
|
|
All Forums
Microsoft Windows CE
COM Port held open after "Stop Debugging"
Forum Locked
Send Topic to a Friend
Printer Friendly