st20-gp6 STMicroelectronics, st20-gp6 Datasheet - Page 32

• Manufacturer Part Number: st20-gp6
• Description: Gps Processor
• Manufacturer: STMicroelectronics

ST20-GP6
The interrupt routine is initialized with space below Wptr. The Iptr and Status word for the routine
are stored there permanently. This should be programmed before the Wptr is written into the vector
table. The behavior of the interrupt differs depending on the priority of the CPU when the interrupt
occurs.
When an interrupt occurs when the CPU was running at high priority, and the interrupt is set at a
higher priority than the high priority process queue, the CPU saves the current process state
(Areg, Breg, Creg, Wptr, Iptr and Status) into the workspace of the interrupt handler. The value
HandlerWptr, which is stored in the interrupt controller, points to the top of this workspace. The
values of Iptr and Status to be used by the interrupt handler are loaded from this workspace and
starts executing the handler. The value of Wptr is then set to the bottom of this save area.
When an interrupt occurs when the CPU was running at high priority, and the interrupt is set at a
lower priority than the high priority process queue, no action is taken and the interrupt waits in a
queue until all higher priority interrupts have been serviced (see section 5.4).
Interrupts always take priority over low priority processes. When an interrupt occurs when the CPU
was idle or running at low priority, the Status is saved. This indicates that no valid process is run-
ning ( Null Status ). The interrupted processes (low priority process) state is stored in shadow regis-
ters. This state can be accessed via the ldshadow (load shadow registers) and stshadow (store
shadow registers) instructions. The interrupt handler is then run at high priority.
When the interrupt routine has completed it must adjust Wptr to the value at the start of the han-
dler code and then execute the iret (interrupt return) instruction. This restores the interrupted state
from the interrupt handler structure and signals to the interrupt controller that the interrupt has
completed. The processor will then continue from where it was before being interrupted.
5.3
The interrupt latency is dependent on the data being accessed and the position of the interrupt
handler and the interrupted process. This allows systems to be designed with the best trade-off use
of fast internal memory and interrupt latency.
5.4
Each interrupt channel has an implied priority fixed by its place in the interrupt vector table. All
interrupts will cause scheduled processes of lower priority to be suspended and the interrupt han-
dler started. Once an interrupt has been sent from the controller to the CPU the controller keeps a
record of the current executing interrupt priority. This is only cleared when the interrupt handler
executes a return from interrupt ( iret ) instruction. Interrupts of a lower priority arriving will be
blocked by the interrupt controller until the interrupt priority has descended to such a level that the
routine will execute. An interrupt of a higher priority than the currently executing handler will be
passed to the CPU and cause the current handler to be suspended until the higher priority interrupt
is serviced.
In this way interrupts can be nested and a higher priority interrupt will always pre-empt a lower pri-
ority one. Deep nesting and placing frequent interrupts at high priority can result in a system where
low priority interrupts are never serviced or the controller and CPU time are consumed in nesting
interrupt priorities and not executing the interrupt handlers.
32/123
Interrupt latency
Preemption and interrupt priority