So I'm using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
have the following problem:
When I try opening any COM port on the devices, i get an IOException
(obviously, there is no message on the exception). However, the most
interesting (as in odd) thing is that putting the .Open method alone in a
try/catch, I was able to use the .Write method on the serialPort object AND
connecting a display to the COM port, I could see that:
1. the port was open
2. i can write on the port crrectly

Did anyone ever had such a problem?
The oddest thing is that the exact same application works perfectly on
another image, same devices (indeed, as far as i remember, the other image is
a R2 image!).

Best regards,
Alex

Your explanation doesn't really give much to go on, but my guess is that you
tried to open the port twice. The second time fails, but the port is still
open because you opened it the first time, so reads and writes work fine.

Paul T.

"Alex Mang" wrote:

> So I'm using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
> have the following problem:
> When I try opening any COM port on the devices, i get an IOException
> (obviously, there is no message on the exception). However, the most
> interesting (as in odd) thing is that putting the .Open method alone in a
> try/catch, I was able to use the .Write method on the serialPort object AND
> connecting a display to the COM port, I could see that:
> 1. the port was open
> 2. i can write on the port crrectly
>
> Did anyone ever had such a problem?
> The oddest thing is that the exact same application works perfectly on
> another image, same devices (indeed, as far as i remember, the other image is
> a R2 image!).
>
> Best regards,
> Alex

I think I agree with Paul. I've not seen this, so without code to view, we
are playing a guessing game.

Perhaps you can simply test the .IsOpen() method to see if, in fact, the
port has been opened and not closed, earlier?

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

Sorry, but I can only strongly disagree.

If you'd like, I could even share a code snippet of the app, since it's a
test app only.
Anyway, to sum everything up, the code is something like:
1. void Form_Load(object sender, EventArgs e)
2. {
3. serialPort.Open();
4. serialPort.WriteLine("test");
5. serialPort.Close();
6. }

The code above, would raise the IOException. However, if i write the
following code instead, everuthing works fine (which is odd).

1. void Form_Load(object sender, EventArgs e)
2. {
3. try{
4. serialPort.Open();
5. }catch{}
6. serialPort.WriteLine("test");
7. serialPort.Close();
8. }

Again, I repeat from the last thread: the application works perfectly on an
older R2 image (so there is no extra-opening on the port; otherwise, the app
wouldn't work on the second image either). Surely, there are several
differences between the two images I'm nentioning. But my question is wether
I am forgetting a component, or maybe an environment variable?

"Paul G. Tobey [eMVP]" wrote:

> Your explanation doesn't really give much to go on, but my guess is that you
> tried to open the port twice. The second time fails, but the port is still
> open because you opened it the first time, so reads and writes work fine.
>
> Paul T.
>
> "Alex Mang" wrote:
>
> > So I'm using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
> > have the following problem:
> > When I try opening any COM port on the devices, i get an IOException
> > (obviously, there is no message on the exception). However, the most
> > interesting (as in odd) thing is that putting the .Open method alone in a
> > try/catch, I was able to use the .Write method on the serialPort object AND
> > connecting a display to the COM port, I could see that:
> > 1. the port was open
> > 2. i can write on the port crrectly
> >
> > Did anyone ever had such a problem?
> > The oddest thing is that the exact same application works perfectly on
> > another image, same devices (indeed, as far as i remember, the other image is
> > a R2 image!).
> >
> > Best regards,
> > Alex

No, you're not forgetting an environment variable. The code is a much better
way to show what's going on. We need to see the contents of the exception
that you are, presumably, catching in the second case shown. So, don't just
do:

catch {}

actually catch it and examine it in the debugger. At worst, you should be
able to get an HResult that corresponds to what the exception is trying to
tell you went wrong. That should be a good hint.

It's possible that you've built things wrong in some way, of course, but I
think that it's more-likely to be some improvement in the error checking of
framework or some change in the serial driver behavior causing the problem.
You're doing this with a *very* simple set of serial port parameters? 9600,
n, 8, 1, no handshake, no time-outs?

Paul T.

"Alex Mang" wrote:

> Sorry, but I can only strongly disagree.
>
> If you'd like, I could even share a code snippet of the app, since it's a
> test app only.
> Anyway, to sum everything up, the code is something like:
> 1. void Form_Load(object sender, EventArgs e)
> 2. {
> 3. serialPort.Open();
> 4. serialPort.WriteLine("test");
> 5. serialPort.Close();
> 6. }
>
> The code above, would raise the IOException. However, if i write the
> following code instead, everuthing works fine (which is odd).
>
> 1. void Form_Load(object sender, EventArgs e)
> 2. {
> 3. try{
> 4. serialPort.Open();
> 5. }catch{}
> 6. serialPort.WriteLine("test");
> 7. serialPort.Close();
> 8. }
>
> Again, I repeat from the last thread: the application works perfectly on an
> older R2 image (so there is no extra-opening on the port; otherwise, the app
> wouldn't work on the second image either). Surely, there are several
> differences between the two images I'm nentioning. But my question is wether
> I am forgetting a component, or maybe an environment variable?
>
> "Paul G. Tobey [eMVP]" wrote:
>
> > Your explanation doesn't really give much to go on, but my guess is that you
> > tried to open the port twice. The second time fails, but the port is still
> > open because you opened it the first time, so reads and writes work fine.
> >
> > Paul T.
> >
> > "Alex Mang" wrote:
> >
> > > So I'm using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
> > > have the following problem:
> > > When I try opening any COM port on the devices, i get an IOException
> > > (obviously, there is no message on the exception). However, the most
> > > interesting (as in odd) thing is that putting the .Open method alone in a
> > > try/catch, I was able to use the .Write method on the serialPort object AND
> > > connecting a display to the COM port, I could see that:
> > > 1. the port was open
> > > 2. i can write on the port crrectly
> > >
> > > Did anyone ever had such a problem?
> > > The oddest thing is that the exact same application works perfectly on
> > > another image, same devices (indeed, as far as i remember, the other image is
> > > a R2 image!).
> > >
> > > Best regards,
> > > Alex

This is the way I'm initializing the serial port object (actually, calling
the constrctor):
System.IO.Ports.SerialPort _sp = new System.IO.Ports.SerialPort("COM", 9600,
System.IO.Ports.Parity.None, 8, System.IO.Ports.StopBits.One);

I did have a Exception class in the catch defined, but as stated previously,
there is very little information on the IOException (almost nothing on the
stacktrace - e.g.: even the message is IOException). I don't recall wether it
had a HResult inf. Once I'll get back home, I'll check it again.

Thanks for your support!

If anyone had a similar problem before, please don't hesitate to let me know!

"Paul G. Tobey [eMVP]" wrote:

> No, you're not forgetting an environment variable. The code is a much better
> way to show what's going on. We need to see the contents of the exception
> that you are, presumably, catching in the second case shown. So, don't just
> do:
>
> catch {}
>
> actually catch it and examine it in the debugger. At worst, you should be
> able to get an HResult that corresponds to what the exception is trying to
> tell you went wrong. That should be a good hint.
>
> It's possible that you've built things wrong in some way, of course, but I
> think that it's more-likely to be some improvement in the error checking of
> framework or some change in the serial driver behavior causing the problem.
> You're doing this with a *very* simple set of serial port parameters? 9600,
> n, 8, 1, no handshake, no time-outs?
>
> Paul T.
>
> "Alex Mang" wrote:
>
> > Sorry, but I can only strongly disagree.
> >
> > If you'd like, I could even share a code snippet of the app, since it's a
> > test app only.
> > Anyway, to sum everything up, the code is something like:
> > 1. void Form_Load(object sender, EventArgs e)
> > 2. {
> > 3. serialPort.Open();
> > 4. serialPort.WriteLine("test");
> > 5. serialPort.Close();
> > 6. }
> >
> > The code above, would raise the IOException. However, if i write the
> > following code instead, everuthing works fine (which is odd).
> >
> > 1. void Form_Load(object sender, EventArgs e)
> > 2. {
> > 3. try{
> > 4. serialPort.Open();
> > 5. }catch{}
> > 6. serialPort.WriteLine("test");
> > 7. serialPort.Close();
> > 8. }
> >
> > Again, I repeat from the last thread: the application works perfectly on an
> > older R2 image (so there is no extra-opening on the port; otherwise, the app
> > wouldn't work on the second image either). Surely, there are several
> > differences between the two images I'm nentioning. But my question is wether
> > I am forgetting a component, or maybe an environment variable?
> >
> > "Paul G. Tobey [eMVP]" wrote:
> >
> > > Your explanation doesn't really give much to go on, but my guess is that you
> > > tried to open the port twice. The second time fails, but the port is still
> > > open because you opened it the first time, so reads and writes work fine.
> > >
> > > Paul T.
> > >
> > > "Alex Mang" wrote:
> > >
> > > > So I'm using Compact Framework 2.0 on a WinCE 6.0 R3 embedded device, and I
> > > > have the following problem:
> > > > When I try opening any COM port on the devices, i get an IOException
> > > > (obviously, there is no message on the exception). However, the most
> > > > interesting (as in odd) thing is that putting the .Open method alone in a
> > > > try/catch, I was able to use the .Write method on the serialPort object AND
> > > > connecting a display to the COM port, I could see that:
> > > > 1. the port was open
> > > > 2. i can write on the port crrectly
> > > >
> > > > Did anyone ever had such a problem?
> > > > The oddest thing is that the exact same application works perfectly on
> > > > another image, same devices (indeed, as far as i remember, the other image is
> > > > a R2 image!).
> > > >
> > > > Best regards,
> > > > Alex

Try it without the call to Close(). It (IMO) always good practice to close
the port, only after all data have been sent.
This may, or may not, be the case -- here. That is, is the Open() causing
the exception?

BTW, exceptions that do not report details, usually, are caused by the
driver, not by code in the framework.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

The exception is caused by the .Open method.

I had indeed once another problem where the exception was just like this
one, with very little information regarding it, cause by a driver. However,
it's strange how (theoretically) having used the same BSP for the other
image, on which there isn't any exception thrown...

Any suggestions?

Alex

"DickGrier" wrote:

> Try it without the call to Close(). It (IMO) always good practice to close
> the port, only after all data have been sent.
> This may, or may not, be the case -- here. That is, is the Open() causing
> the exception?
>
> BTW, exceptions that do not report details, usually, are caused by the
> driver, not by code in the framework.
>
> Dick
>
> --
> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
> Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
> Author of Visual Basic Programmer's Guide to Serial Communications, 4th
> Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
> 2006.
>
> .
>

Sorry, I don't have any suggestion. Open should not throw an error, unless
the port selected is unavailable. So, my best guess (still) is a driver
failure. I suppose that this might actually be caused by a hardware fault,
but I've not seen it.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

I have the same problem.
Hardware - PNA (JJ-connect2100wide) atlas4 with WinCE 6 (r2).
What I see is that most of GPS applications i tested on it are able to
detect GPS port as COM1
and work ok.

I'm trying to build my own tiny GPS application with compact framework
3.5
And when I try to call
serialPort.open()
I have absolutely same exception. I make a lot of attempts opening
port as "COM1" as "COM1:" and "\\.\COM1:" e.t.c
No success.. Exception is the same..At least when port name is valid.
Attempts to open port with wrong name rise other exception.

More.. I found some other C# projects most of which are proven to work
ok on other devices..
All of them fail with the same exception.
Doesn't matter I got binary and run it on my PNA or I comple it
myself and run it in debug mode.
Always I get exception.
My conclusion was that problem is related to using .NETCF
As other software can work on the same port.

My guess is that .NET CF opens COM1 as debugging port
so it becomes unavailable for application.
I was able to find in registry some key defining
COM1 as "Debugging port for atlas4 board"

So I guess this is a reason..
The question is how to disable using COM1 as debugging port for .NET
CF applications?















On 14 дек, 23:54, "DickGrier" <dick_grierNOS...@msn.com> wrote:
> Sorry, I don't have any suggestion. Â*Open should not throw an error,unless
> the port selected is unavailable. Â*So, my best guess (still) is a driver
> failure. Â*I suppose that this might actually be caused by a hardwarefault,
> but I've not seen it.
>
> Dick
>
> --
> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
> Lakewood, CO 80228 303-986-2179 (voice) Homepage:www.hardandsoftware.net
> Author of Visual Basic Programmer's Guide to Serial Communications, 4th
> Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
> 2006.