My IST is no longer called. No further interrupts could be handled RRS feed

  • Question

  • I have a simple test-Environment:

    A target with a running Windows Embedded Compact 2013 OS on a TI AM3359 CPU. To one GPIO-pin I have attached a frequence Generator to toggle this GPIO. No other SW is running on the target, only my small test application which subscribes for notification on GPIO-pin Changes.

    This Environment runs fine for some minutes (I got the correct notifications), but from some Point of time on, I did no longer get any notification from the GPIO-Change.

    I have made a CELog from this Problem and could see, that at this Point of time the IST is no longer called, so the notification is no longer available and (because in the IST is normally done the re-activation from the Interrupt from this pin) all futher GPIO-changes will no longer generate a Interrupt.

    Has anyone a idea, why the kernel will not send me the Event to start the IST?

    Additional info: The error is not systematic and occurs always not at a fix time in the LifeCycle from the target, but what always happens in the errorcase is that some µs (up to 8µs) after the GPIO-System-Interrupt is logged in CeLog a  SYSINTR_NOP. Can this be the Problem? Could this be the reason for my not called IST?

    Friday, January 16, 2015 10:44 AM


All replies

  • Several others have seen this same issue.

    To date I have not seen a resolution


    Saturday, January 17, 2015 1:35 AM
  • I first identified this issue with the serial port. Time to failure is not consistent.Microsoft have been alerted to the problem and were able to reproduce it. They looking into it but thus far no solution.

    DJaus Snr SW Dev (Embedded Systems and .NET)

    Saturday, January 17, 2015 2:45 AM
  • Who's BSP are you using?


    Saturday, January 17, 2015 1:28 PM
  • Hi,

    my BSP is from Phytec.

    Is this problem new in Windows Embedded Compact 2013? I have worked for a long time with CE6 and have not seen this problem there.

    Is this bug also available in Windows Embedded Compact 7?

    Is it only available for ARM-CPU based systems?

    Has anyone from you experience with this kinds of bugs and can tell me when MSFT will bring up a solution for this topic? If this topic could not be solved, we could not work with this operating system for our project.

    Is there a official link (or post or statement) from MSFT available? You can not work with an operating System without Interrupts!

    Thanks for you Information. Regards.


    Monday, January 19, 2015 5:38 AM
  • I have not seen the same problem in WEC7, only WEC2013.

    Probably only ARM as I know the i.MX6 also has a similar issue.

    No official statement from MSFT AFAIK.

    Adeneo/MSFT did some work lately to stabilize the i.mx6 platform but information on what they did is hard to come by.


    Monday, January 19, 2015 12:57 PM
  • In the meantime I get in contact with the MSFT Support Service and they found a Problem in the WEC2013-kernel sources for ARM-CPUs. The bugfix is currently under test and will hopefully be released soon. I got a pre-delivery from the relevant libraries and I was no longer able to reproduce the error with this libraries.
    Wednesday, March 25, 2015 11:01 AM
  • I too got the pre-release libraries and it also fixed the problem on the Beaglebone Black platform.

    Hope to see the official release in a QFE soon.


    Wednesday, March 25, 2015 12:37 PM
  • A solution to this should be released as an update soon. 

    See my detailed blog on the issue on Embedded101.com.


    My system has run for 24+ hours satisfactorily.  DV has run his for 4 days + with the fix.

    David Jones

    Embedded MVP

    Monday, March 30, 2015 10:50 PM
  • We have 10 units that fail every night as a result of not having this fix.   Can someone email me these 2 lib files so that we can aid in the testing and resolve our issues at the same time?

    Mark Dixon

    • Edited by markd5 Monday, April 20, 2015 11:26 AM
    Monday, April 20, 2015 11:26 AM
  • The fix has just been released in the latest QFEs.

    Just update your installation.


    Monday, April 20, 2015 11:59 AM
  • Dave Thanks for the heads up.

    My system with the fix has been running  a serial loopback test at full bore for 21 days without failure.

    - BAUD 115200

    - Send an 8 byte packet

    - Receive it

    - Check sent = received.

    NOT ONE ERROR over the billions of bytes transmitted over 500+ hours

    David Jones

    Embedded MVP

    Monday, April 20, 2015 1:10 PM
  • Hi,
    I found a similar problem working with WEC7 on x86 device (Intel/Adeneo BSP for Bay Trail).
    Frequently, receiving bytes on serial port, the system stop signaling serial port interrupt.
    I initially analyzed the APIC ISR routine to understand if there could be some mistake on it but it seen to work correctly:
    at first, serial port interrupt were signaled, recognized, setted the event for serial port and and cleared APIC ISR with EOI message, but after a not specific number of bytes serial port interrupt were no longer available; in this condition, if I manually 'clear' the UART reading bytes at RBR till the FIFO is empty and reading IIR once, serial port interrupt signalation starts again.
    The feeling is that in unknow condition InterruptDone call doesn't work correctly or crash after scheduler handler as on WEC2013 with ARM devices.

    Do you know if someone else find this problem or if exist any workaround to solve this problem?



    Wednesday, November 9, 2016 2:56 PM
  • Sounds exactly like the issue we had with Compact 2013 that was resolved.

    I'm not aware of it being an issue with Compact 7.

    Note that the problem was in assembler code and so could be processor specific. The bug was due to an assembler label being incorrectly located by one line resulting in InterruptDone not being issued.

    Embedded MVP

    Wednesday, November 9, 2016 7:31 PM
  • I see you have visted my blog on this issue with the ARM processor for Compact 2013  at


    I would look at the euivalent x86 assembler code for a similar code error.

    It might also be worth tyring to capture the event, as we did.

    Embedded MVP

    Wednesday, November 9, 2016 7:37 PM