A look at interrupts What are interrupts and why are they needed in an embedded system? Equally as important – how are these ideas handled on the Blackfin

Dispatch_Tasks ( )

The “standard” instruction cycle of a microprocessor (ENCM369) RESET THE PROCESSOR RESET* INTERRUPT (ACTIVE low) FETCH AN INSTRUCTION FROM PROGRAM MEMORY DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY EXECUTE THE INSTRUCTION WRITE BACK THE ANSWER PROCESSOR RESET* +5V RC time constant 200 ms on 68K +5V GROUND

The “standard” instruction cycle RESET THE PROCESSOR RESET* (ACTIVE low) FETCH AN INSTRUCTION FROM PROGRAM MEMORY DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY EXECUTE THE INSTRUCTION WRITE BACK THE ANSWER EXECUTING ‘YOUR PROGRAM’ UNTIL POWER IS REMOVED

The “standard” instruction cycle with external device having important data RESET THE PROCESSOR RESET* (ACTIVE low) FETCH AN INSTRUCTION FROM PROGRAM MEMORY DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY EXECUTE THE INSTRUCTION WRITE BACK THE ANSWER EXTERNAL HARDWARE Control signal – I have data for you 16-bits This is the data Control signal – Thanks Data received Check if ready

The “wait till ready” approach of reading data from external device In decode phase – read control register value In execute phase – check if 1 -- keep waiting (fetch-decode-execute-writeback instruction cycle) until the control value changes from 0 (device not ready) to 1 (device ready) When 1 – go to a different part of your program code to read the data e.g. call ReadData( ) Then your program must send an acknowledge back to device that the data has been read. e.g. call AcknowledgeReadData( ). The device can then go and get more values for you. PROBLEM: You have no time to do anything else other than wait Not a problem if waiting for this device is the only thing you want to do with the processor

Wait till ready approach Very problematic if many devices RESET THE PROCESSOR RESET* (ACTIVE low) FETCH AN INSTRUCTION FROM PROGRAM MEMORY DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY EXECUTE THE INSTRUCTION WRITE BACK THE ANSWER EXTERNAL HARDWARE 16-bits EXTERNAL HARDWARE 16-bits EXTERNAL HARDWARE 16-bits Check if ready WAITS TOO LONG

The “Poll approach” of getting data Not much waiting – but a lot of “doing” read control register value of device 1 -- if 1 go to a different part of the code to “read the data” (ReadData1( ) ) – after reading the data send an acknowledge signal back to device 1 (AcknowledgeReadData1( ) ) -- if 0 go and read the control value of device 2 – don’t worry about device 1 for some time read control register value of device 2 -- if 1 go to a different part of the code to “read the data” (ReadData2() ) – after reading the data send an acknowledge signal back to device 2 (AcknowledgeReadData2( ) ) -- if 0 go and read the control value of device 3 – don’t worry about device 2 and 3 for some time ETC PROBLEM: What happens if, while you are handling device 2, device 1 has “time sensitive information” that will disappear if device 1 is not serviced immediately

Interrupt Approach – basic idea Extra “phase” in instruction cycle RESET THE PROCESSOR RESET* (ACTIVE low) FETCH AN INSTRUCTION FROM “NORMAL” (NOT ISR) PROGRAM MEMORY DECODE THE INSTRUCTION AND FETCH ANY VALUES NEEDED FROM REGISTER OR MEMORY EXECUTE THE INSTRUCTION WRITE BACK THE ANSWER EXTERNAL HARDWARE 16-bits data CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL DATA READY SIGNAL BECOMES INTERRUPT REQUEST NO yes DO ISR CONTINUE AS BEFORE Acknowledge Request done

Issues that MUST be solved if using interrupts on a real uP 1.What if device hardware can only provide a “quick” I am ready signal? 2.What if more than one hardware device wants to send an interrupt request? 3.What if the programmer wants to “ignore” “low priority” interrupt requests? 4.What if certain interrupt requests are too important to ignore?

What if hardware device can only provide a “quick” I am ready signal? Add interrupt (capture) latch to processor EXTERNAL HARDWARE 16-bits CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL FAST CHANGING DATA READY SIGNAL Signal send (1) and then becomes 0 yes DO ISR CONTINUE AS BEFORE Acknowledge done Interrupt Buffer Interrupt Latch (Capture Request) Processor clock signal causes load of the latch to capture the transient interrupt

What if the programmer wants to “ignore” a “low priority” interrupt? Add (Ignore) Interrupt Mask EXTERNAL HARDWARE 16-bits CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL DATA READY SIGNAL BECOMES INTERRUPT REQUEST LINE yes DO ISR CONTINUE AS BEFORE Acknowledge done Interrupt Buffer Interrupt Mask Ignore Processor clock signal causes load of the latch to capture the transient interrupt Interrupt Latch (Capture) e.g. IGNORE INTERRUPT IF FIO_MASK_A BIT is 0

What if certain hardware interrupts are too important to ignore? NMI bypass the IGNORE Interrupt Mask EXTERNAL HARDWARE 16-bits CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL DATA READY SIGNAL BECOMES INTERRUPT REQUEST LINE yes DO ISR CONTINUE AS BEFORE Acknowledge done Interrupt Buffer Interrupt Mask Ignore Processor clock signal causes load of the latch to capture the transient interrupt Interrupt Latch (Capture)

What if more than one hardware wants to send an interrupt? EXTERNAL HARDWARE 16-bits CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL DATA READY SIGNAL BECOMES INTERRUPT REQUEST LINE yes DO ISR CONTINUE AS BEFORE Acknowledge done Interrupt Buffer Interrupt Mask Ignore Processor clock signal causes load of the latch to capture the transient interrupt Interrupt Latch (Capture) Pending interrupts (still to be done

Blackfin MASKS and Latches Same hardware in concept

Using “idle” low power mode in Lab. 2

Normal “linear flow” PC increments to next instruction Use program counter PC as an Instruction Pointer register Fetch instruction at memory location PC then increment the PC to point at the next instruction PC = PC+2 PC = PC + 4;

Subroutine call flow PC = PC + 2 CALL INSTRUCTION DOES RETS = PC + 4 (FFA03C78) PC set to 0xFFA01E24 So instruction 0xFFA01E24 done next This instruction is NOT fetched (until end of subroutine) This instruction is now fetched HAVE JUMPED TO SUBROUTINE

Interrupt occurs HERE Must Jump to ISR NOW– but how? Use program counter PC as an Instruction Pointer register Fetch instruction at memory location PC then increment the PC to point at the next instruction PC = PC+2 PC = PC + 4;

Interrupt occurs HERE (green arrow) Must Jump to ISR NOW – but how? First step is obvious PC has 0xFFA01E44 in it – Just about to fetch P0.L = instruction Remember what instruction you were about to execute – so you can do that instruction after finishing the ISR RETI is “register used to remember the instruction “stopped” by interrupt RETI = PC (0xFFA01E44) PC now set to ????? value to make interrupt happen How make this happen?

Interrupt occurs HERE Must Jump to ISR – but how First step is obvious Remember what instruction you were about to execute RETI = PC (0xFFA01E44) PC = ????? Some how – like magic we must set PC = start of Timer ISR 0xFFA01EC0 then processor will start executing TimerISR code

Solution – Blackfin has Lookup table of what value to put into PC for each interrupt than can occur Look-up table for the start of every interrupt routine is stored in EVR table Event vector register table Event (e.g interrupts) Table

Why are all these “event addresses” in the EVR (ISR jump) table the same? This is the address of the “ the processor does not know what to do if there is an interrupt of this sort” EXCEPTION

IDLE This is the assembly code While (wait till some happens) instruction VDSP Emulator puts in a “breakpoint” so for us the program stops. In real life – processor can’t “stop”, just goes into an infinite loop until “watchdog timer” resets the processor The “don’t know what to do” “exception” service routine (ESR)

“Don’t know what to do” Exception This exception hangs the processor –Keeps doing same instruction (doing nothing) which is safer than doing something –The developer should have provided a better ESR if had known what to do Problem solved by using “WATCHDOG TIMER”

Solution – Lookup table of what value to put into PC for each type of interrupt that occurs Question – the start of the ISR is in the event table – How did it get there? Event (e.g interrupts) Table

The start address of the ISR got into the event table HOW? Tell (register) the processor how to handle each interrupt service routine Also we can understand what the raise( ) C++ function does – This is a special C++ instruction to allow us to test ISR

Blackfin MASKS and Latches Raise( ) use “software to put a 1 into the interrupt latch register – making the processor think that a hardware interrupt has happened

Event table information can be found in the Blackfin Hardware Manual

What happens if the device does take away its “I’m ready” signal during an interrupt? EXTERNAL HARDWARE 16-bits CHECK IF AN INTERRUPT REQUEST HAS OCCURRED CONTROL SIGNAL DATA READY SIGNAL yes DO ISR CONTINUE AS BEFORE Acknowledge done Interrupt Buffer Interrupt Latch (Capture) Processor clock signal causes load of the latch to capture the transient interrupt

Tackled today Three ways of handling hardware requests for service Wait till the device signals “ready” then process the data If device 1 ready – process its data Else If device 2 ready – process its data POLL Interrupt – start processing the data from a “specific device NOW!