WinCE6 COM端口间歇性失败 [英] WinCE6 COM Ports Intermittently Fail

问题描述

嗨。 
我有一台使用COM1或COM2与串口设备通话的WinCE6设备。  
WinCE6设备请求数据，设备响应。 
不花哨，只需RS232 19,200波特，3线，无握手。  
问题是，在10分钟到几个小时之后，通信将会失败。  
当它失败时，CE设备似乎停止从硬件接收中断。  
使用调试版本的操作系统并使用调试区域，似乎串口中断事件（m_hISTEvent）停止设置。  
等待此事件的"pdd16550.cpp"代码如下：

Hi.  I have a WinCE6 device that uses COM1 or COM2 to talk to a serial device.   The WinCE6 device requests data and the device responds.  Not fancy, just RS232 19,200 baud, 3-wire, no handshaking.   The problem is that the comms will fail after anywhere from 10 minutes to many hours.   When it fails the CE device appears to stop getting receive interrupts from the hardware.   With a debug build of the operating system and using debug zones, it appears the serial interrupt event (m_hISTEvent) stops being set.   The code from "pdd16550.cpp" that waits for this event is below:

  
while（m_hISTEvent！= NULL&&！IsTerminated（））{

   while ( m_hISTEvent!=NULL && !IsTerminated()) {

               
<跨度>&NBSP; 如果（WaitForSingleObject的（m_hISTEvent，无限）== WAIT_OBJECT_0）{

                 if (WaitForSingleObject( m_hISTEvent,INFINITE)==WAIT_OBJECT_0) {

失败时，关闭并打开COM1端口不会使其恢复。  
但是使用调试版本，如果我中断并手动设置"m_hISTEvent"，它就会恢复。  
如果我在失败之前和之后转储了16550个寄存器（使用串行驱动程序函数m_pReg16550-> DumpRegister（）），则所有寄存器值都相同。

When failed, closing and opening the COM1 port does not make it recover.   But with a debug build, if I break and manually set "m_hISTEvent" then it recovers.   If I dump the 16550 registers (using serial driver function m_pReg16550->DumpRegister()) before and after the failure, all the registers values are the same.

如果我理解正确，当PeRPISR（）进入时，此事件由核心设置OAL返回串行中断。 
我尝试使用断点或添加调试消息来调试PeRPISR（），但操作系统崩溃或陷入困境以致其他事情失败。 
根据我读到的内容，您实际上无法调试此功能。

If I understand correctly, this event is set by the core when PeRPISR() in the OAL returns for the serial interrupt.  I have tried debugging PeRPISR() using breakpoints or adding debug messages, but the OS either crashes or bogs down so much that other things fail.  Based on what I read you really can’t debug this function.

为了排除WinCE问题并确定硬件，我尝试在平台上运行XP SP3。  
使用XP，主板不会失败。   这表明它是CE问题或CE硬件兼容性问题。

To rule out WinCE as the problem and incriminate the hardware, I’ve tried running XP SP3 on the platform.   With XP the board doesn’t fail.   This indicates it is a CE problem, or CE hardware compatibility problem.

Another interesting thing is that the failure does not occur when looping back data between COM1 and COM2.   The failure only occurs if a COM port is used in half duplex fashion, transmitting, waiting, and then receiving.  My thought is that when looping back the tx and rx interrupts are coming in together, so it somehow masks the problem.

该平台是商用ETX Atom板，带有Windbond 83627 Super I / O芯片，BSP由制造商提供<跨度>&NBSP;&NBSP;
串口platform.reg设置如下所示。 
我尝试过注册表设置的两项更改是：  添加"Priority256"= dword：67以增加线程优先级，并删除"Flags"= dword ：10在内核中加载驱动程序。 
两个修改都没有修复失败。

The platform is a commercially available ETX Atom board with Windbond 83627 Super I/O chip, and the BSP is supplied by the manufacturer.   The serial port platform.reg settings are shown below.  Two changes I have tried to the registry settings are:  adding "Priority256"=dword:67 to increase the thread priority , and removing the "Flags"=dword:10 to load the driver in the kernel.  Neither change fixed the failure.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial]

<跨度风格= "字体大小：10PT"> <跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" SysIntr" = dword：13

                "SysIntr"=dword:13

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" IoBase" = dword：02F8

                "IoBase"=dword:02F8

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" IoLen" = dword：8

                "IoLen"=dword:8

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" DeviceArrayIndex" = dword：0

                "DeviceArrayIndex"=dword:0

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" Prefix" =" COM"

                "Prefix"="COM"

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" ICLASS" =" {CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"

                "IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"

<跨度风格=" 字体大小：10PT"> <跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP ;&NBSP;
" Dll" =" Com16550.Dll"

                "Dll"="Com16550.Dll"

< span style ="font-size：10pt">                
" Order" = dword：0

                "Order"=dword:0

<跨度>&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;
" Flags" = dword：10;用户模式：DEVFLAGS_LOAD_AS_USERPROC

                "Flags"=dword:10 ; User MOde: DEVFLAGS_LOAD_AS_USERPROC

<跨度风格= "行高：115％;字体大小：10PT">唯一的改变我对BSP来源做的是禁用操作系统将COM1用于调试消息，因为即使项目设置为"Release"构建和"WINCESHIP = 1"，COM1也是
不可用。  ; 根据一些帖子的建议，我修改了
中的"debug.c" \\Platform\Common\Src\x86\Commmon \ other 。 <跨度>&NBSP;&NBSP;
我不认为这种改变可能导致失败，但我在此提及以防万一。

The only change I’ve made to the BSP sources was to disable the OS from using COM1 for debug messages, because even with the project set for "Release" build and "WINCESHIP=1", COM1 was not free.  Following the advice of some posts, I modified "debug.c" in \\Platform\Common\Src\x86\Commmon\Other.   I don’t think this change could be causing the failure, but I mention it here just in case.

我想知道是否有没有人见过这种类型的失败或有想法来诊断这个问题？

你最好的猜测是什么：CE安装，BSP，超级I / O芯片实现，BIOS？

是否有更好的串口驱动程序可供使用？

感谢您的帮助。

推荐答案

物理上你是否在中断线上获得了处理器的中断？在半双工模式下是否存在有争议的uart错误？

Physically are you getting the interrupt on the interrupt line to the processor ? Does there a uart error occurring contentiously in half duplex mode ?

您的ISR是否每次都在确认中断？ &NBSP;

Is your ISR acknowledging the interrupt every time ?  

您是否为每个uart使用了共享irq机制或单个中断？

Have you used a shared irq mechanism or single interrupt for each uart ?

--- Misbah

--- Misbah

这篇关于WinCE6 COM端口间歇性失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！