none
CreateFile does not return when opening COM1 RRS feed

  • Question

  • Hi,

        I have a Windows CE 5.0 OS built for a terminal application.   There are 3 COM ports, hard drive and video defined and no network interface.

        When my application starts it opens COM1: and COM2:.   In some instances, the application just hangs, the mouse wont move, the screen and keyboard become non-functional and I have to reboot.     I put some debug crumbs in and was finally able to determine that the call to CreateFile(COM1) was never returning.   Here is the sample code:

         MessageBox(_T("Before"));

         comm1handle =  CreateFile(_T("COM1:"),GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL);  

         if(comm1handle == INVALID_HANDLE_VALUE)

              MessageBox(_T("Invalid Handle"));

               return;

         else

             MessageBox(_T("After");

       If the COM port is not attached to another device when the OS starts I receive the "BEFORE" and "AFTER" message boxes and my application runs fine.

       If the COM port is attached to another serial device whent the OS starts, I receive the messagebox "BEFORE",    Then the whole system freezes. 

    I have only been able to come up with 3 guesses for possible reasons

         1. There is an electrical / grounding issue on the CPU board that causes this.   

                  We tested this theory multiple different ways and it doesnt appear to be the case.

        2.  The debug serial port has COM1 held up somehow.   My last question on the forum was in regard to the Debug Port, and I have tried to disable it everywhere???    If I put a lightbox on the COM1 hardware while the OS starts up I do see the lights flash as though the port is being initialized.     I do not see the same flash on COM2.    Any ideas where this might be occurring???

        3.  Createfile is hung on a call to EnterCriticalSection either within the driver or the kernel?   

    Any hints or ideas would be greately appreciated.

    Thanks

    KNK53

         

    Tuesday, September 10, 2013 8:32 PM

Answers

  • There are a lot of things that could be happening.  Do you have the source code for the BSP that you are running on or did you get it from another vendor.  Is the device that the COM ports internal to the Processor or an External device?  I am assuming that you are using a USART for the rest of this post.

    If you got it from another vendor I would contact them and get their support / help.

    My first step would be to see how far into the Open call (in the driver) everything gets.  What you are looking for is to determine if the system itself is deadlocking or if it another thing going wrong.  From your description it sounds pretty easy to reproduce so I would probably just setup a build with KITL + Kernel Debugger and step through the Open call.

    If it seems to be something else other than a deadlock you can check to make sure that the Open function in the driver driver does not create any (or wake up any) higher priority threads that are starving out other threads in the system.

    I've seen code bugs around the code for USARTs before that utilize level-sensitive (not edge) interrupts for their data especially when sharing the interrupt that resulted in a continuous interrupt being tripped and not being handled properly.  Perhaps you are seeing something similar in your system.  What I might do is take a look and see what the Interrupt lines are doing between your Processor USART if the USART is external to your processor.  You will need to check to see if the interrupt is level or edge based as well to understand what it all means (I don't know of any USARTs without level-sensitive interrupts but that does not mean that there are not any.)

    Good luck,

    Brad.

    • Marked as answer by knk53 Wednesday, September 11, 2013 5:29 PM
    Tuesday, September 10, 2013 10:51 PM

All replies

  • There are a lot of things that could be happening.  Do you have the source code for the BSP that you are running on or did you get it from another vendor.  Is the device that the COM ports internal to the Processor or an External device?  I am assuming that you are using a USART for the rest of this post.

    If you got it from another vendor I would contact them and get their support / help.

    My first step would be to see how far into the Open call (in the driver) everything gets.  What you are looking for is to determine if the system itself is deadlocking or if it another thing going wrong.  From your description it sounds pretty easy to reproduce so I would probably just setup a build with KITL + Kernel Debugger and step through the Open call.

    If it seems to be something else other than a deadlock you can check to make sure that the Open function in the driver driver does not create any (or wake up any) higher priority threads that are starving out other threads in the system.

    I've seen code bugs around the code for USARTs before that utilize level-sensitive (not edge) interrupts for their data especially when sharing the interrupt that resulted in a continuous interrupt being tripped and not being handled properly.  Perhaps you are seeing something similar in your system.  What I might do is take a look and see what the Interrupt lines are doing between your Processor USART if the USART is external to your processor.  You will need to check to see if the interrupt is level or edge based as well to understand what it all means (I don't know of any USARTs without level-sensitive interrupts but that does not mean that there are not any.)

    Good luck,

    Brad.

    • Marked as answer by knk53 Wednesday, September 11, 2013 5:29 PM
    Tuesday, September 10, 2013 10:51 PM
  • Brad,

       Thanks for responding!   I recompiled the OS with KITL, EBOOT space, Event Tracking, Kernel Debugging, target control support and profiling enabled.     I am now able to run the debug utilities on my os.

       So I started the platform with EBOOT.BIN, 

           COM1 connected to a laptop with procomm

           Set a static IP Address, and subnet and hit enter to start EBOOT.BIN

           Remove COM1 from the laptop and plug it back to the other device that causes my issue

           Go back to the DEV Workstation and attach to the device with platform builder.   All of that works fine.

           My OS then boots, and I can start my target program.

           Unfortunately, with this debug build the problem disappeared???????   No Idea why??

          

           I did put 2 breakpoints in the serial driver COMMON\OAK\DRIVER\SERIAL

                   1 in COM_MDD2\COM_MDD.C  at the top of the procedure COM_OPEN

                   2 at COM_16550\com_16550.c at the top of the procedure CREATE_SERIAL_OBJECT.

          I expected Create_serial_object to get called since the device enumerator should find the serial ports, but why would COM_OPEN get hit.    My target application has to be started manually, so is COM_OPEN called during the driver initialization???   I thought it would be called when I try to open the port using CREATEFILE???

         I still think in my Release Build that COM1 may be in use somehow and when I call CreateFile it cant

    use the resources????

    Any ideas???

    KNK53

    Wednesday, September 11, 2013 2:45 PM
  • All,

      I must apologize.   There actually is a startup task that I have been using forever in Windows CE OSes that is called right when the OS beigns.   This task uses COM1 to display some boot messages.   When I stop this task from opening COM1 the problem goes away.      COM1 must not be getting closed properly in the startup task, although I am not sure why.

       Again, sorry for adding any clutter to the board.

    KNK53

    Wednesday, September 11, 2013 5:27 PM