Keil Logo


Information in this article applies to:

  • C166 Version 5.00 or higher
  • Advanced RTX166 Version 1.10 or higher


I have problems with disabling a timer interrupt on Infineon XC16x devices. The following sequence was successfully used on classic C16x devices, but appears to fail on the new Infineon XC16x:

__asm {
       ATOMIC  #4 ; Use ATOMIC sequence to avoid pipeline problems
       BCLR    GPT12E_T2IC_IE
       NOP                      ; Timer 2 Interrupt disabled
; at this point, I still get a Timer 2 interrupt

It appears that this sequence does not protect my code from Timer 2 interrupts. When I change the code to the following sequence, it seems to work as expected:

__asm {
       BCLR    PSW_IEN
       ATOMIC  #4
       BCLR    GPT12E_T2IC_IE
       ATOMIC  #4
       ATOMIC  #2
       BSET    PSW_IEN

It seems to be essential that PSW.IEN is cleared during this sequence. Is there a better solution? Does this also affect my Real-Time Operating Systems?


Your work-around sequence executes correctly on the XC16x. A read back of the IE (Interrupt Enable) flag is a better method and may be implemented in C with:

   IEN = 0;                /* Avoid pipeline effect for XC16x   */
   GPT12E_T2IC_IE  = 0;
   while (GPT12E_T2IC_IE); /* Wait till flag is really cleared. */
   IEN = 1;

This sequence ensures that the IE flag is clear when the interrupt system is re-enabled.

In contrast to classic C16x/ST10 devices, some of the old pipeline effects are solved in the new C166 V2 core (that is used by the XC161, XC164, and XC167 devices). Now, resetting PSW.IEN is immediately effective (no interrupt will happen afterwards). The old work-arounds (documented for C16x/ST10 core) are still OK on XC16x devices.

However, the Infineon C166 V2 core (which is used in the XC161, XC164, and XC167 devices) serves interrupts after ATOMIC when a single IE flag is disabled within the ATOMIC sequence. The interrupt module processes interrupts very early and delays execution just for the ATOMIC sequence.

Note: The assignment IEN=0 must not be part of an ATOMIC sequence. If it is, the interrupt request is delayed until the end of the ATOMIC sequence.


The change in the interrupt behaviour of XC16x may affect several Real Time Operating Systems.

  • Advanced RTX166 Version 1.0x did not handle this situation correctly.
  • Advanced RTX166 Version 1.10 or higher implements the correct task lock sequences. Ensure that your application uses the current version of the AR166_Config.C file.
  • RTX166 Tiny does not have a problem with the modified Interrupt behaviour.
  • When using any other Operating System, check with the vendor.



Last Reviewed: Friday, January 12, 2007

Did this article provide the answer you needed?
Not Sure
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.