none
Serial port not getting RX interrupt RRS feed

  • Question

  • Hello.

    I have problems working with serial ports on my device.

    I have my device connected to my PC through serial cable. When I send data from the device to PC, the PC receives the data. But when I send data from the PC to the device, the device doesn't receive the data.

    I have modified the OAL code, so I can monitor interrupts triggered during one second (function PeRPISR() in \WINCE600\PLATFORM\VIAMARK\src\x86\COMMON\intr\fwpc.c).

    When I send data from the device to the PC, I see the interrupt triggered.

    When I send data from the PC to the device, the interrupt is not triggered.

    I have the same problem with both COM1 and COM2 serial ports on the device.

     

    Operating System: Windows Embedded CE 6.0

    My device: Advantech PCM-3375 (PC-104 module, VIA MARK processor, x86 architecture) (user manual: http://downloadt.advantech.com/download/downloadsr.aspx?File_Id=GF-FSC2)

    My BSP: VIA MARK v3.322 for WinCE 6.0 (http://www.viaarena.com/Driver/viamark_v3.322_for_ce60.zip), CEPC-based

    Serial port configuration in platform.reg:

    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial]
      "SysIntr"=dword:14
      "IoBase"=dword:03F8
      "IoLen"=dword:8
      "DeviceArrayIndex"=dword:0
      "Prefix"="COM"
      "IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
      "Dll"="Com16550.Dll"
      "Order"=dword:0
      "Flags"=dword:10 ; User MOde: DEVFLAGS_LOAD_AS_USERPROC
      "Index"=dword:1
    
    [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial2]
      "SysIntr"=dword:13
      "IoBase"=dword:02F8
      "IoLen"=dword:8
      "DeviceArrayIndex"=dword:1
      "Prefix"="COM"
      "IClass"="{CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}"
      "Dll"="Com16550.Dll"
      "Order"=dword:0
      "Flags"=dword:10 ; User MOde: DEVFLAGS_LOAD_AS_USERPROC
      "Index"=dword:2
    
    

    Does anyone have a clue what could be the problem?

    Peter Supina

    Monday, January 10, 2011 2:18 PM

All replies

  • how are you sending data from the PC? maybe you're using a terminal program which expects a  HW flow contriol while your device is not using it?
    Luca Calligaris lucaDOTcalligarisATeurotechDOTcom www.eurotech.com Check my blog: http://lcalligaris.wordpress.com
    Monday, January 10, 2011 2:29 PM
  • Check what flow control your device is supporting ?

     

    In case of h/w flow control support and serial emulator configured for it:-

    Can you Check the RTS of the device.

    You can also see the fifo status and other handshake signal status in the driver. Printing it in the log will help to find the reason for no fifo trigger interrupt.

     

    In case of software flow control support in driver and serial emulator configured for it:-

    Check the status of Xon/Xoff bit and fifo status.

     

    In all case enable debug and send us the log to help you.

     

    ---Misbah

     

     

    Monday, January 10, 2011 3:24 PM
  • On the PC, I am using this terminal program (http://hw-server.com/software/termv19b.html), with handshaking turned off (none).

    On the device, there is terminal program written in .NET Compact Framework and I use the setting System.IO.Ports.Handshake.None.

    Monday, January 10, 2011 3:45 PM
  • When I have this sort of thing, the first cause that comes to mind is that I'm not connected to the correct interrupt.  That is, I've listed the wrong SYSINTR value (doesn't match the value returned from the ISR), or I'm trying to use the wrong hardware interrupt (I haven't unmasked it properly or I'm literally using the wrong one).

    Paul T.

    Monday, January 10, 2011 6:34 PM
  • When I have this sort of thing, the first cause that comes to mind is that I'm not connected to the correct interrupt.  That is, I've listed the wrong SYSINTR value (doesn't match the value returned from the ISR), or I'm trying to use the wrong hardware interrupt (I haven't unmasked it properly or I'm literally using the wrong one).

    Paul T.

     

    Hello Paul, thank you for the advice.

    I have checked the settings again. In source files, I found these definitions and statements:

    // SYSINTR_DEVICES is the base for any non-OAL system interrupts
    #define SYSINTR_DEVICES  8
    
    // SYSINTR_FIRMWARE is the base for any interrupts defined in the OAL
    #define SYSINTR_FIRMWARE (SYSINTR_DEVICES+8)
    
    BOOL OALIntrInit (void)
    {
    // ...
    
     // Serial Port Info
     //
     // The legacy COM port layout defines IRQ4 being shared by 
     // COM ports 1 and 3 and IRQ3 is shared COM ports 2 and 4. 
     // If the legacy IRQ layout is followed, only 1 COM port 
     // per IRQ should be enabled.
     //
     // COM1 - 0x3F8-0x3FF, IRQ4
     // COM2 - 0x2F8-0x2FF, IRQ3
     // COM3 - 0x3E8-0x3EF, IRQ4
     // COM4 - 0x2E8-0x2EF, IRQ3
     //
     // IRQ3 - COM2 or COM4
     OALIntrStaticTranslate(SYSINTR_FIRMWARE + 3, 3);
    
     // IRQ4 - COM1 or COM3
     OALIntrStaticTranslate(SYSINTR_FIRMWARE + 4, 4);
    
    // ...
    }
    

    So, there should be static translations:

    SYSINTR 19 (0x13) -> IRQ3 	- COM2
    SYSINTR 20 (0x14) -> IRQ4	- COM1

    Those are SYSINTR values I have specified in the platform.reg file (see above). IRQ values match those specified in the user manual (see link above).

    Also IoBase addresses in the platform.reg file are matching those specified in the user manual.

    As far as I know, the interrupt is unmasked in the serial driver (Com16550.dll) by calling InterruptInitialize() function.

    Is there anything I missed?

    Tuesday, January 11, 2011 1:42 PM
  • Trace through the code that actually handles the interrupt, handles the masking/unmasking, etc., either in the kernel debugger or by adding debug messages to the code.  While you've verified that OALIntrStaticTranslate() seems to be called correctly, that doesn't mean that the interrupt is being masked/unmasked correctly or that the ISR is returning the correct SYSINTR value.  Once you've actually checked those things, then you can move on to other possibilities (interrupt not set up as a level-sensitive interrupt, but as an edge-sensitive interrupt, etc.)

    Paul T.

    Wednesday, January 12, 2011 5:45 PM