none
'unusual' driver architecture RRS feed

  • Question

  • Hi all,
    I have been involved in the troubleshoot process for an ARM9 board running WinCE 6.0 which is randomly reset by hardware watchdog.
    Digging around in the platform code I have seen a custom driver for FPGA device with an 'unusual' interrupt handling architecture.

    1) An event is created and registered (InterruptInitialize) in XXX_Init() procedure as so many drivers do. 
    2) No Interrupt Service Thread is created !
    3) In XXX_Read() a WaitForSingleObject on such event is performed to wait for device data !
    4) Then InterruptDone() is invoked by XXX_Read() regardless WaitForSingleObject result code (signaled or timed-out) !

    As far as I know an event handle is a process resource.
    In this driver we have an event created in NK process context and used (waited-on)  from user application process context.

    Any suggestion, idea, comment on such an architecture will be highly appreciated.

    Best regards,
    PaoloC


    PaoloC

    Friday, March 8, 2013 7:19 PM

All replies

  • It sounds like the driver was someone's first Windows CE driver. The ReadFile() call from an application will block until the interrupt fires and then do whatever it does. The WaitForSingleObject() call for interrupts normally does not specify a time out. If this one is doing so, the InterruptDone() is improperly called. That may not do anything bad as it probably just clears the processor interrupt status register bit associated with the interrupt, but it's strange.

    Without any documentation of the code or driver intent I'm not sure what we could say. If you believe it's wrong, fix it. Presumably you are in a position to replace the driver with a properly written one and test that it works correctly.

    All uses of the event are in the context of the driver/device manager so I don't see any problem with that.

    Paul T.

    Friday, March 8, 2013 8:44 PM
  • Have you done following for interrupt initialization and all the functions shall return successfully :

    1. CreateEvent -> to create the interrupt event.

    2. KernelIoControl -> "IOCTL_HAL_REQUEST_SYSINTR" to get sysintr from physical intr

    3. InterruptInitialize -> associate sysintr to interrupt event.

    As you said you dont have a IST and you are blocking on read call. But how will you make sure that you have cleared the previous interrupt to be able to get the new. Do you any timeout during WaitforsingleObject() ??

    If you have an IST you can synchronize the interrupt making read call still blocked and signal it from the IST using another event.

    --- Misbah


    Senior Design Engineer T.E.S Electroni Solutions (Bangalore-India) www.tes-dst.com email-misbah.khan@tes-dst.com

    Monday, March 11, 2013 6:38 AM
  • Thanks a lot Paul,

    I will investigate the driver from a different point of view and forget the event handle problem. 

    PaoloC


    PaoloC

    Monday, March 11, 2013 8:28 AM