Re: CreateFile() Hangs for serial port in Release by Dean
Dean
Tue Aug 21 10:20:23 CDT 2007
Order is up to the BSP. But typically the serial driver will be first
because it is loaded by device.exe, and the display driver is later because
it is loaded by gwes.
--
Dean Ramsier - eMVP
BSQUARE Corporation
"Doug Allender" <doug.allender@nht.co.uk> wrote in message
news:BC8D5222-850A-46D6-B341-1B23CFD728E7@microsoft.com...
> Looks like I have a hardware issue which causes this.We use a GPIO which
> is
> attached normally to the LCD Driver. This is still active when we have
> called
> CreateFile(), and I assume this is what caused the problem. I've proved
> this
> by cutting the track, and my problem goes away, remake track and the
> problem
> returns.
> I would like to know how to find out the order in which the drivers start
> (Display, Serial) so I can decide if I need to just modify the Serial, or
> wether I need to modify the Display driver as well.
> --
> Snr. Des. Eng.
> Northern Hi-Tec
>
>
> "Paul G. Tobey [eMVP]" wrote:
>
>> CreateFile doens't really care. The serial port driver could care, of
>> course, but I wouldn't expect that to be a problem unless you have a very
>> slow processor and/or a very high priority on the interrupt event for the
>> driver or something.
>>
>> Paul T.
>>
>> "Doug Allender" <doug.allender@nht.co.uk> wrote in message
>> news:787C949B-DC5F-4B68-B0AD-4EFB32D2FD2C@microsoft.com...
>> > Could CreateFile have a problem, if for instance the RX line had data
>> > present
>> > before the CreateFile happened. (this could be a lot of transitions)?
>> > --
>> > Snr. Des. Eng.
>> > Northern Hi-Tec
>> >
>> >
>> > "Paul G. Tobey [eMVP]" wrote:
>> >
>> >> Maybe COM3: isn't what you think it is. It's frequently a problem to
>> >> decide
>> >> which port is going to be assigned which COMn number, particularly
>> >> when
>> >> switching from DEBUG to RETAIL build, as one of the actual COM ports
>> >> is
>> >> often reserved in DEBUG for debug log messages. If that port is the
>> >> usual
>> >> COM1 (remember that Windows CE doesn't care whether, in DOS, you'd
>> >> call a
>> >> given port COM1, COM2, or COM3; it just assigns COM port numbers in
>> >> the
>> >> order it finds entries in the registry), you can get a weird shift of
>> >> which
>> >> port is which when you switch to retail.
>> >>
>> >> Modify your serial port driver to create a log file in the filesystem
>> >> when
>> >> it's loaded and have it record log information about where it's
>> >> executing,
>> >> what it's doing, and so on. When you get a hang, go back to the log
>> >> file
>> >> and see what was happening when the hang occurred. It's probably some
>> >> call
>> >> that can potentially block, but which you're more or less counting on
>> >> completing immediately, or maybe you're polling a hardware register
>> >> for
>> >> some
>> >> bit to have a particular value and it never does.
>> >>
>> >> Paul T.
>> >>
>> >> "Doug Allender" <doug.allender@nht.co.uk> wrote in message
>> >> news:E3A98F3A-F7B5-466A-AAFA-51465E767293@microsoft.com...
>> >> > HI All
>> >> > This is a follow on to an earlier post. We now have CE5 - I have an
>> >> > App
>> >> > which uses COM1,2,&3. This App works in release mode on my
>> >> > development
>> >> > Kit,
>> >> > and the end hardware. The App works in release mode only on the dev
>> >> > kit,
>> >> > as
>> >> > COM3 causes a hang when CreateFile(_T("COM3:"), GENERIC_READ |
>> >> > GENERIC_WRITE,0,NULL,OPENEXISTING,0,NULL) is issued on my end
>> >> > hardware.
>> >> > Then end hardware should not be causing problems as we have this
>> >> > working
>> >> > in
>> >> > debug mode.
>> >> > Can anyone think what may cause this?
>> >> >
>> >> > --
>> >> > Snr. Des. Eng.
>> >> > Northern Hi-Tec
>> >>
>> >>
>> >>
>>
>>
>>