cancel
Showing results for 
Search instead for 
Did you mean: 

INTERRUPTS enabled state on ST10

jf23
Associate II
Posted on October 24, 2005 at 07:34

INTERRUPTS enabled state on ST10

2 REPLIES 2
jf23
Associate II
Posted on October 22, 2005 at 02:07

ON ST10F MPU:

The management of interrupt disabling is not so obvious it appears :

When disabling interrupts with the 'BCLR IEN' instruction, the interrupts are not disabled immediately, but only one instruction later.

- ; interrupts are enabled

- BCLR IEN

- ; interrupts are not yet disabled

- INSTRUCTION_1

- ; interrupts are now disabled

- INSTRUCTION_2

This seems ok for every one, but what appends if an interrupt is acknowledged between BCLR IEN and INSTRUCTION_1 ?

As interrupts are not yet disabled, it is possible (more, be sure it will append in all your programs if you use interrupts) that an interrupt is acknowledged and an interrupt routine is entered just at this time.

Usualy, when you enter an interrupt, it is because interrupts are enabled.

The ST10 mpu does not manage anything about enabling or disabling interrupts when it enters an interrupt routine (note that many other mpu automatically enable or disable interrupts at the interrupt routine entrance, just after saving status register).

The ST10 only saves return address instruction then saves status register (PSW). And the interrupt enabling state is not forced to any state but fellows its life.

So, usually, when you enter an interrupt routine, you think that interrupt are enabled, and if you do not explicitly disable interrupts in your interrupt routine, all the interrupts with a better priority will be acknowledged.

With ST10, it does not run like that.

Take a look to the previous instruction sequence with an interrupt acknowledgement :

- ; interrupts are enabled

- BCLR IEN

- ; interrupts are not yet disabled, and an interrupt is acknowledged

- ; mpu pushes return address

- ; mpu pushes status with PSW.IEN = 0

- ; mpu jumps to interrupt routine

- IT_INSTRUCTION_1

- ; interrupts are now disabled, no other interrupt can be acknowledged

- IT_INSTRUCTIONS_...

- ; interrupts are still disabled

- RETI

- ; mpu PSW pop with PSW.IEN = 0

- ; mpu return address pop

- ; interrupts are still disabled

- INSTRUCTION_1

- ; interrupts are still disabled

- INSTRUCTION_2

Note that in this case for the main program point of view, the interrupts are disabled before INSTRUCTION_1, in contrary to the first case where they where disabled only after INSTRUCTION_1.

Now, what appends if you enable interrupts in your interrupt routine ?

- ; interrupts are enabled

- BCLR IEN

- ; interrupts are not yet disabled, and an interrupt is acknowledged

- ; mpu pushes return address

- ; mpu pushes status with PSW.IEN = 0

- ; mpu jumps to interrupt routine

- IT_INSTRUCTION_BSET IEN

- ; interrupts are now disabled, no other interrupt can be acknowledged

- IT_INSTRUCTION_2

- ; interrupts are still disabled

- IT_INSTRUCTION_3

- ; interrupts are now enabled

- IT_INSTRUCTIONS_...

- ; interrupts are still enabled

- RETI

- ; mpu PSW pop with PSW.IEN = 0

- ; mpu return address pop

- ; interrupts are still enabled

- INSTRUCTION_1

- ; interrupts are now disabled

- INSTRUCTION_2

Note that in this case for the main program point of view, the interrupts are disabled in the same maner to the first case.

CONCLUSION :

In your IT routines, always set explicitely the enbling interrupt state with an IEN managing instruction (BCLR or BSET).

maxime2399
Associate II
Posted on October 24, 2005 at 07:34

Your description is correct and is due to the pipeline.

When possible, it's always better to use ATOMIC instruction instead of using BCLR IEN.

When using BCLR IEN, application implications of the behavior you described should be taken in account.

In your first and last case INSTRUCTION_1 should be a NOP to ally software clarity and correct behavior