Access Denied on serial port

I am trying to figure out why I am getting an "Access Denied" error when I try to open a serial port. It happens when I try to recreate an instance of a serial port. The first time is okay. (Overlapped read/write done in a thread.)

It suggests that when I close the object I don't shut down the serial port correctly. At the end of the thread I reset the port with the original configuration and timeout values and then call that purge routine. Then I close the handle of the port.

This problem only happens on my laptop...not my desktop.

Heres the code at the end of the thread.

Code:

---

    CloseHandle(overlappedread.hEvent);
    CloseHandle(overlappedevent.hEvent);
    CloseHandle(overlappedwrite.hEvent);
        CloseHandle(quitthread);

        PurgeComm(commhandle,
                  PURGE_TXABORT | PURGE_RXABORT | PURGE_TXCLEAR | PURGE_RXCLEAR);

//--- RESTORE OLD TIMELIMITS:---------------------------------------------------
    if(SetCommTimeouts(commhandle, &original_timeouts) == FALSE)
        {
                error = GetLastError();
                return(FALSE);
        }
//--- RESTORE OLD CONFIGURATION:------------------------------------------------
    if(SetCommConfig(commhandle, &original_config, sizeof(COMMCONFIG)) == FALSE)
        {
                error = GetLastError();
                return(FALSE);
        }

        CloseHandle(commhandle);
        commhandle = NULL;
        commthread = NULL;
    return(1);

---

Any ideas?

Thanks,

Brian

Can it be that you posted only half of the code? :confused:

The code is after an infinite "while" loop. The thread is terminated by the typical "WaitonMultipleObjects()" function and the code I display is how I restore the comm port to its original settings, purge it, and close the handle.

Yet when I try to reopen the port with "CreateFile()", I get an access denied. Thhe only thing I can think of which would cuse that is that the system still believes I am using it.

By the way, what's the difference between

"SetCommState()" and
"SetCommConfig()". The structure passed to the former is contained in the structure passed to the latter. Then there always is the
"SetDefaultCommConfig()"

I should try the last for laughs.

Brian

I found an obscure piece of documentation on the MSDN which says that after one calls 'CloseHandle(commhandle)' that there is a two second delay for the system to close resources. Unfortunately it's not in the documentation that comes with VC++ in the description of the serial port functions.

In any case, with a Sleep(2000) function placed after the CloseHandle() function, the problem is solved. Who would have guessed it was 2 seconds!

Brian

Hmmm...indeed interesting...

Now I am wondering about the following:

Can I change the baudrate, databits, stopbits, and parity on the fly, that is without closing down the port and recreating it? I have my comm port handling routines in a thread and I am wondering what would happen if I kept the thread going, port opened, and just called SetCommState()?

Anyways, I am going to try...on my laptop...where the system limits seem to be the weakest.

Clearly, changing the comm port from COM1 to COM2 or anything else like that is changing the physical device, so that one can't do on the fly.

Quote:

---

Originally Posted by Gyannea

Can I change the baudrate, databits, stopbits, and parity on the fly, that is without closing down the port and recreating it? I have my comm port handling routines in a thread and I am wondering what would happen if I kept the thread going, port opened, and just called SetCommState()?

---

Yes, should not be any problem....do a combination of 'GetCommState()' and 'SetCommState()' (first retrieve the actual parameters, change the ones you need and set them back...

It worked. At least on my two computers, and the laptop uses a USB to serial converter.