ARM Technical Support Knowledge Articles

INTERRUPT LATENCY WITH SILABS DEVICES

Applies to: RTX51 Real-time Kernel

Answer


Information in this article applies to:


SYMPTOM

Silicon Labs describes an incompatible 8051 behavior on the interrupt system of the F12x and F13x devices that can occur when an instruction that disables an interrupt (like CLR EA) is followed by a single-cycle instruction (like CLR A). Silicon Labs suggests the following remedy (refer to page 154 of Rev 1.4 of the F12x/F13x device datasheet):

Any instruction that clears the EA bit should be immediately followed by an instruction that has two or more opcode bytes. For example:

// in 'C':

EA = 0; // clear EA bit.
EA = 0; // this is a dummy instruction
        // with two-byte opcode.

; in assembly:

CLR EA ; clear EA bit.
CLR EA ; this is a dummy instruction
       ; with two-byte opcode.
If an interrupt is posted during the execution phase of a "CLR EA" opcode (or any instruction which clears the EA bit), and the instruction is followed by a single-cycle instruction, the interrupt may be taken. However, a read of the EA bit will return a '0' inside the interrupt service routine. When the "CLR EA" opcode is followed by a multi-cycle instruction, the interrupt will not be taken.

RESOLUTION

RTX51 uses single-cycle instructions after disabling interrupts (both global and individual). Since single-cycle instructions in RTX51 only affect CPU registers, the only side-effect in RTX51 is interrupt latency of high-priority interrupts. For example, if a low-priority interrupt occurs immediately after interrupts are disabled, the interrupt flag will not be cleared (and interrupts disabled) until the low-priority interrupt begins execution. The effect is that high-priority interrupts are disabled until the low-priority interrupt service routine exits and RTX51 re-enables interrupts. Subsequently, interrupt response time is increased by the processing time of other low-priority interrupt service routines in your system.

As a solution to this problem, you could re-build the RTX51 Library with the following changes to the RTXIMASK.INC file:

RTX_EXCLUDE_INT    MACRO
                   LOCAL DONE, ONE, TWO
;;
;;      Exclude Task Interrupts
;;      -----------------------
;;      Disable all RTX interrupts, only interrupts not
;;      assigned to RTX remain enabled.
;;
               JNB   ?RTX_ENA_INT_REG1, ONE
               ; Check for 2. interrupt register

               JNB   ?RTX_ENA_INT_REG2, TWO
               ; Check for 3. interrupt register

               MOV   ?RTX_IEN2, ?RTX_NM_IE2
TWO:           MOV   ?RTX_IEN1, ?RTX_NM_IE1
ONE:           MOV   ?RTX_IE, ?RTX_NM_IE

; The following avoids Silicon Labs F12x/F13x
; pipeline effects for interrupt disable flags.
               MOV   ?RTX_IE, ?RTX_NM_IE

               DBG_LOCK_DRV
               ENDM




GLOBAL_INT_DISABLE    MACRO
;;
;;      Disable all Interrupts
;;      ----------------------
;;
               CLR   ?RTX_IE.7

; The following avoids Silicon Labs F12x/F13x
; pipeline effects for interrupt disable flags.
               CLR   ?RTX_IE.7
               ENDM

To rebuild the RTX51 Library:

  1. Open the project KeilC51RTX51KernelRTX51Lib.UV2 in µVision.
  2. Make the changes to the file RTXIMASK.INC as described above.
  3. Use the µVision command Project — Rebuild all target files.
  4. Copy the file KeilC51RTX51KernelRTX51.LIB to the folder KeilC51LIB.
  5. Re-build your RTX51 application.

Note that RTX51Tiny is not affected by the behavior of the Silicon Labs devices.

SEE ALSO

Article last edited on: 2007-04-26 16:53:51

Rate this article

[Bad]
|
|
[Good]
Disagree? Move your mouse over the bar and click

Did you find this article helpful? Yes No

How can we improve this article?

Link to this article
Copyright © 2011 ARM Limited. All rights reserved. External (Open), Non-Confidential