none
NEED HELP to Disable Windows CE Debug Serial port RRS feed

  • Question

  • Hi,

       I am running a Vortex 6350rde with an ICOP (thats the manufacturer of the board) BSP.  I have created a windows CE headless image (NO VIDEO, KEYBOARD or MOUSE) that has all of the functions I need.   Communication to the device is through Serial Ports and Network.  The problem is that  I want to disable the DEBUG serial port.  I use COM1 in my target application and the DEBUG output is interfering.   The OS is directing debug info and printf statements out COM1 which I am presently monitoring using a terminal.  

      I saw that in the registry there was a setting HKLM\DRIVERS\CONSOLE\OutPutto set to -1.   So I can set that to 0 and the printf statements will no longer be directed to COM1.   That still leaves the debug statements.

       Heres what I have tried so far:

       1.   Tried using LOADCEPC \C:0 NK.BIN (No Change)

       2.  In  WINCE\PUBLIC\COMMON\OAK\CSP\X86\OAL\Debug.c  used an IFDEF to essentially cut out all the code for all of the functions.  (No Change)

     

       3.   In WINCE\PLATFORM\VDX_63xx\Source\Bootloader\Debug.c used an IFDEF to essentially cut out all the code for all of the functions. (No Change)    VDX_63xx is the board support package.  

       4.  In  WINCE\PLATFORM\VDX_63xx\Source\Common\r6040\r6040.c found that it calls a macro OALMSGS
         4a.   Found the OALMSGS MACRO defined in WINCE\PLATFORM\VDX_63xx\Source\Common\inc\oal_log.h
         4b.   Found the OALMSGS macro returns FALSE if the SHIP_BUILD macro is defined and calls OALLOGSERIAL() if SHIP_BUILD is not defined

         4c    Defined the SHIP_BUILD macro in Platform Builder. Rebuild a clean OS

               (NO CHANGE) 

        **** I was not able to find the body of the OALLOGSERIAL() function!!!

         I dont understand what is causing the DEBUG output to be sent to COM1.   

         Please help

    Wednesday, September 4, 2013 3:41 PM

Answers

  • By following the "sources." files.

    Understanding the build system is very important when working with CE.

    In this specific case you would start in OALEXE, this sources. file will link to OALLIB. Check the sources file of OALLIB and see which libraries it links to. One of them will be debugserial or something similar. Do a search on your platform tree first to see which sources file produces debugserial.lib. If nothing, check your PLATFORM\COMMON\SOC folders and finally \PLATFORM\COMMON.

    Follow the breadcrumbs...

    You can find more information about understanding the build system on my blog (link below).


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Marked as answer by knk53 Thursday, September 5, 2013 12:56 PM
    Thursday, September 5, 2013 12:12 AM
    Moderator

All replies

  • Just tried the following:

       Comment out the code in the following 4 files.   

             WINCE\PUBLIC\COMMON\OAK\CSP\X86\BiosLoader\Loader\Debug.c
                  commented out all the code for all of the functions
             WINCE\PUBLIC\COMMON\OAK\CSP\X86\DOS\LoadCEPC\Debug.c
                  commented out all the code for all of the functions
             WINCE\PUBLIC\COMMON\OAK\CSP\X86\OAL\Debug.c
                  commented out all the code for all of the functions
       <x-tab></x-tab>     </x-tab><//x-tab>WINCE\PLATFORM\VDX_63xx\Source\Bootloader\Debug.c

                  commented out all the code for all of the functions

       No change.  

    KNK53

    Wednesday, September 4, 2013 3:47 PM
  • So this is a BSP question for the BSP vendor. How you do it will depend on the BSP. Often the BSP will have several variables set when DEBUG is set for the build. Maybe KITLSERIAL or something like that. I don't suppose you've simply built a RETAIL build rather than DEBUG?!

    Paul T.

    Wednesday, September 4, 2013 7:03 PM
  • Paul,

       Thanks for responding.    Yes it is basically something the Vendor should be able to help with.   Unfortunately, they arent always that much help.  

           It is a RETAIL build.     The only setting I have checked in the Platform Builder settings is Enable Full Kernel Mode.

       My understanding about the DEBUG SERIAL PORT is that some file implements OEMInitDebugSerial, OEMWriteDebugString, OEMWriteDebugByte, OEMReadDebugByte.    Since these functions are called before the OS really starts they use direct PORT_READ/PORT_WRITE to send rcv data to the COM Port.    There is no way to disable these functions except to recode them???   

      The question is which file are the real functions in??   I already tried 4 debug.c files to no avail.

       I have just found another one in

             WINCE\PLATFORM\COMMON\SRC\X86\COMMON\OTHER\debug.c  

       I just disabled the functions in that file and am rebuilding the OS.  Will post the results

    Thanks

    Ken

    Wednesday, September 4, 2013 7:32 PM
  • Paul,

       Well that did it.  I no longer get the messages when I comment out the functionallity in   

               1. WINCE\PLATFORM\COMMON\SRC\X86\COMMON\OTHER\debug.c  

     

       Out of curiosity, what could I have done to follow the code along in order to know that the file above(#1) is the one implementing the functions.   Again, I found 4 other debug.c files in locations that seem like they would be included in my project.

             2. WINCE\PUBLIC\COMMON\OAK\CSP\X86\BiosLoader\Loader\Debug.c
             3. WINCE\PUBLIC\COMMON\OAK\CSP\X86\DOS\LoadCEPC\Debug.c
             4. WINCE\PUBLIC\COMMON\OAK\CSP\X86\OAL\Debug.c

             5. WINCE\PLATFORM\VDX_63xx\Source\Bootloader\Debug.c

       How could I have sorted out which one is used for what??

    Thanks

    Ken

    Wednesday, September 4, 2013 7:46 PM
  • By following the "sources." files.

    Understanding the build system is very important when working with CE.

    In this specific case you would start in OALEXE, this sources. file will link to OALLIB. Check the sources file of OALLIB and see which libraries it links to. One of them will be debugserial or something similar. Do a search on your platform tree first to see which sources file produces debugserial.lib. If nothing, check your PLATFORM\COMMON\SOC folders and finally \PLATFORM\COMMON.

    Follow the breadcrumbs...

    You can find more information about understanding the build system on my blog (link below).


    Good luck,

    Michel Verhagen, eMVP
    Check out my blog: http://guruce.com/blog

    GuruCE
    Microsoft Embedded Partner
    http://guruce.com
    Consultancy, training and development services.

    • Marked as answer by knk53 Thursday, September 5, 2013 12:56 PM
    Thursday, September 5, 2013 12:12 AM
    Moderator
  • Thanks for the response,

        I will take a look at the sources files and see where they lead.

    Ken

    Thursday, September 5, 2013 12:55 PM
  • While you were commenting out the code, did you happen to notice that it uses variables to decide which serial port to use?  And that if the variable is set to 0 (zero) debug output is stopped?

    You can set the value in:

    1. if using BIOSLoader modify the boot.ini

    2. if using LoadCEPC, modify autoexec.ini

    So, no code change is actually needed.


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Tuesday, September 10, 2013 4:33 PM
    Moderator
  • Bruce,

       I am using LoadCEPC to start the OS

       I dont see any file named autoexec.ini.   I do see command line options for LoadCEPC()   Like \C:0 but this had no effect on my issue.

    knk53  

    Tuesday, September 10, 2013 8:09 PM
  • Right that should have been autoexec.bat - typed to quickly.

    But \C:0 should disable it, unless your LoadCEPC deviates from the original from Microsoft.


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    Wednesday, September 11, 2013 3:58 PM
    Moderator