The MPT612 is the first dedicated IC perf or min g Maximum Power Point Tracking (MPPT)
designed for applications using solar photovoltaic (PV) cells, or fuel cells. To simplify
development and maximize system efficiency, the MPT612 is supported by:
• a patent-pending MPPT algorithm
• an application-specific software library
• easy-to-use application programming interfaces ( A PIs)
Dedicated hardware functions for PV panels, including voltage and current measurement
and panel parameter configuration, simplify design and speed development.
MPT612 is based on a low-power ARM7TDMI-S RISC core operating up to 70 MHz
achieving overall system efficiency ratings up to 98 %. It controls the external switching
device through a signal derived from a patent-pending MPPT algorithm which delivers up
to 99.5% Maximum Power Point Tra cking (MPPT) efficiency. The solar PV DC source can
be connected to the IC through appropriate voltage and current sensors. The IC
dynamically extracts the maximum power from the PV panel without user intervention
when enabled. The IC can be configured for boundar y conditions set in so ft ware. Ther e is
up to 15 kB of flash memory available for application software.
UM10413
MPT612 User manual
2. Features
In this user manual, solar PV terminology is primarily used as an example. However, the
MPT612 is equally useful for fuel cells or any other DC source which has MPP
characteristics.
• ARM7TDMI-S 32-bit RISC core operating at up to 70 MHz
• 128-bit wide interface and accelerator enabling 70 MHz operation
• 10-bit ADC providing:
– Conversion times as low as 2.44 s per channel and dedicated result registers
minimize interrupt overhead
– Five analog inputs available for user-specific applications
• One 32-bit timer and external event counter with four capture and four compare
channels
• One 16-bit timer and external event counter with four compare channels
• Low-power Real-Time Clock (RTC) with independent power supply and dedicated
32 kHz clock input
• Serial interfaces including:
– Two UARTs (16C550)
2
– Two Fast I
– SPI and SSP with buffering and variable data length capabilities
C-buses (400 kbit/s)
• Vectored interrupt controller with configurable priorities and vector addresses
• Up to 28, 5 V-tolerant fast general-purpose I/O pins
• Up to 13 edge- or level-sensitive external interrupt pins available
AHB peripherals are allocated a 2 MB range of addresses at the top of the 4 GB ARM
memory space. Each AHB peripheral is allocated a 16 kB address space within the AHB
address space. A pin connect block controls on-chip peripheral connections to device pins
(see Section 12.4 “
application requirements for the use of peripheral functions and pins.
5.1 ARM7TDMI-S processor
The ARM7TDMI-S is a general purpose 32-bit processor core offering high performance
and very low-power consumption. The ARM architecture is based on Red uced Instruction
Set Computer (RISC) principles making the instruction set and decode mechanisms much
simpler than micro programmed Complex Instruction Set Computers (CISC). This
simplicity results in a high instruction throughput and impressive real-time interrupt
response from a small, cost-effective processor core.
Pipeline techniques are employed ensuring all parts of the processing and memory
systems can operate continuously. Typically, while one instruction is being executed, its
successor is being decoded and a third instruction is being read from memory.
The ARM7TDMI-S processor also employs a unique architectural strategy known as
Thumb making it suitable for high-volume applications with memory restrictions, or
applications where code density is an issue.
UM10413
MPT612 User manual
Register description” on page 62) configured by software to specific
The key idea behind Thumb is a super-reduced instruction set. Essentially, the
ARM7TDMI-S processor has two instruction sets:
• the standard 32-bit ARM set
• the 16-bit Thumb set
The Thumb 16-bit instruction sets allow up to twice the density of standard ARM code
while retaining most of the performance advantage of ARM over a traditional 16-bit
processor using 16-bit registers, made possible using the ARM code 32-bit register set.
Thumb code provides up to 65 % of standar d ARM code and 16 0 % of the perfo rmance of
an equivalent ARM processor connected to a 16-bit memory system.
The particular flash implementation in the MPT612 also allows full speed execution in
ARM mode. Programming performance-critical and short code sections in ARM mode is
recommended. The impact on the overall code size is minimal but the speed can increase
by 30 % over Thumb mode.
5.2 On-chip flash memory system
The MPT612 incorporates a 32 kB flash memory system. This memory can be used for
both code and data storage. V ari ous methods can be used to program flash memory, such
as using:
The application program can erase and/or program flash memory while the application is
running using IAP, allowing greater flexibility, for example, data storage field firmware
upgrades. The entire flash memory is available for user code as the bootloader resides in
a separate memory.
The MPT612 flash memory provides a minimum of 100 000 erase/write cycles and 20
years of data-retention memory.
5.3 On-chip Static RAM (SRAM)
On-chip static RAM can be used for code and/or data storage. The SRAM can be
accessed as 8-bit, 16-bit and 32-bit. The MPT612 provides 8 kB of static RAM.
6. Block diagram
UM10413
MPT612 User manual
PV configuration parameters
MPT612
PV voltage sense
PV current sense
battery voltage sense
battery current sense
temperature sense
load current sense
PV VOLTAGE
MEASUREMENT
PV CURRENT
MEASUREMENT
BATTERY VOLTAGE
MEASUREMENT
BATTERY CURRENT
MEASUREMENT
TEMPERATURE
MEASUREMENT
LOAD CURRENT
MEASUREMENT
these blocks are needed for MPPT functionality
these blocks can be used for customer specific applications
Figure 3, Figure 4, and Table 2 show different views of the peripheral address space. Both
the AHB and APB peripheral areas are 2 MB spaces which are divided up into 128
peripherals. Each peripheral space is 16 kB in size, simplifying address decoding for each
peripheral. All peripheral register addresses are wor d aligned (to 32-bit boundaries)
regardless of their size, eliminating the need for byte lane mapping hardware to allow b yte
(8-bit) or half-word (16-bit) accesses at smaller boundarie s. This method requires all wo rd
and half-word registers to be accessed at once. For example, it is not possible to read or
write the upper byte of a word register separately.
00xE000 0000Watchdog timer
10xE000 4000reserved
20xE000 8000Timer 1
30xE000 C000UART0
40xE001 0000UART1
50xE001 4000not used
60xE001 8000not used
70xE001 C000I
80xE002 0000SPI0
90xE002 4000RTC
100xE002 8000GPIO
110xE002 C000pin connect block
120xE003 0000not used
130xE003 4000ADC
14 to 220xE003 8000
230xE005 C000I
240xE006 0000not used
250xE006 4000not used
260xE006 8000SSP
270xE006 C000not used
280xE007 0000reserved
290xE007 4000Timer 3
30 to 1260xE007 8000
1270xE01F C000system control block
0xE005 8000
0xE01F 8000
2
C0
not used
2
C1
not used
UM10413
MPT612 User manual
7.2 MPT612 memory remapping and boot block
7.2.1 Memory map concepts and operating modes
Basically, each memory area in the MPT612 has a "natural" location in the memory map,
and is the address range for which code residing in that area is written. Most memory
spaces remain permanently fixed in the same location, eliminating the need to design
parts of the code to run in different address ranges.
Because of the ARM7 processor interrupt vector locations (at addresses 0x0000 0000
through 0x0000 001C, as shown in Table 3
spaces need remapping to allow alternative uses of interrupts in the different operating
modes described in Table 4
. Remapping of the interrupts is accomplished via the memory
Remark: Identified as reserved in ARM documentation, used by the
bootloader as the valid user program key. Details described in
Section 25.5.2 on pa ge 218
bootloader always executes after any reset. Boot block interrupt
vectors are mapped to the bottom of memory to allow handling
exceptions and using interrupts during the boot loading process.
activated by bootloader when a valid user program signature is
recognized in memory and bootloader operation is not forced. Interrupt
vectors are not remapped and are found at the bottom of the flash
memory.
activated by a user program as desired. Interrupt vectors are
remapped to the bottom of the static RAM.
.
7.2.2 Memory remapping
In order to allow for compatibility with future derivatives, the entire boot block is mapped to
the top of the on-chip memory space. This arrangem en t avo id s larg er or sm alle r fla sh
modules having to change the location of the boot block (which requires changing the
bootloader code) or changing the boot block interrupt vector mapping. Memory spaces
other than the interrupt vectors remain in fixed locations. Figure 5
memory mapping in the modes defined in Table 4
.
shows the on-chip
The portion of memory remapped to allow interrupt processing in different modes includes
the interrupt vector area (32 bytes) and an additional 32 bytes for a total of 64 bytes. The
remapped code locations overlay addresses 0x0000 0000 through 0x0000 003F. A typical
user program in the flash memory can place the entire FIQ handler at address
0x0000 001C without any need to consider memory boundaries. The vector in the SRAM,
external memory, and boot block, must contain branches to the interrupt handlers, or to
other instructions that establish the branch to the interrupt handlers.
There are three reasons this configuration was chosen:
• To give the FIQ handler in the flash memory the advantage of not having to take a
memory boundary, caused by the remapping, into account.
• Minimize the need for the SRAM and boot block vectors to deal with arbitrary
• To provide space to store constants, for jumping beyond the range of single word
Remapped memory areas, including the interrupt vectors, continue to appear in their
original location in addition to the remapped address.
UM10413
MPT612 User manual
branch instructions.
Details of remapping and examples can be found in Section 10.7 “
Memory mapping
control” on page 42.
Fig 5.Map of lower memory showing remapped and remappable areas (MPT612 with
32 kB flash)
7.3 Prefetch abort and data abort exceptions
If an access is attempted for an address that is in a reserved or unassigned address
region, the MPT612 generates the appropriate bus cycle abort exception. The reg ions
are:
• Areas of the memory map that are not implemented for a specific ARM derivative. Fo r
the MPT612:
– Address space between on-chip Non-Volatile Memo ry and o n-ch ip SRAM, labe led
"Reserved Address Space" in Figure 2
from 0x0000 8000 to 0x3FFF FFFF.
– Address space between on-chip static RAM and the boot block. Labeled
"Reserved Address Space" in Figure 2
from 0x4000 2000 to 0x7FFF DFFF.
– Address space between 0x8000 0000 and 0xDFFF FFFF, labeled "Reserved
Address Space".
– Reserved regions of the AHB and APB spaces; see Figure 3
For these areas, both attempted data acce ss and in struction fetch genera te an exception.
In addition, a prefetch abort exception is generated for any instruction fetch tha t maps to
an AHB or APB peripheral address.
Within the address space of an existing APB peripheral, a data abort exception is not
generated in response to an access to an undefined address. Address decoding within
each peripheral is limited to distinguish only defined registers within the peripheral itself.
For example, an access to address 0xE000 D000 (an undefined address within the
UART0 space) can result in a register access defined at address 0xE000 C000. Details of
such address aliasing within a peripheral space are not defined in the MPT612
documentation and are not a supported feature.
Remark: the ARM core stores the prefetch abort flag and the (meaningless) associated
instruction in the pipeline, and processes the abort only if an attempt is made to execute
the instruction fetched from the illegal address. This method prevents accidental aborts
caused by prefetches occurring when code is executed very close to a memory boundary.
8. Memory Acceleration Module (MAM)
UM10413
MPT612 User manual
The MAM block in the MPT612 maximizes the performance of the ARM processor when it
is running code in flash memory using a single flash bank.
8.1 Operation
Essentially, the Memory Accelerator Module (MAM) attempts to have the next ARM
instruction that is needed in its latches in time to prevent CPU fetch stalls. The MPT612
uses one bank of flash memory, compared to the two banks used on predecessor
devices. It includes three 128-bit buffers called the prefetch buffer, the branch trail buffer
and the data buffer. The ARM is stalled while a fetch is initiated for the 128-bit line for an
Instruction Fetch not satisfied by either the prefetch or branch trail buffer, or a prefetch not
initiated for that line. If a prefetch is initiated but not yet completed, the ARM is stalled for
a shorter time. Unless aborted by a dat a access, a prefetch is initi ated wh en th e flash has
completed the previous access. The flash module latches the prefetched line, but the
MAM does not capture the line in its prefetch buffer until the ARM core presents the
address from which the prefetch is made. If the core present s a dif ferent addre ss from the
one from which the prefetch is made, the prefetched line is discarded.
The prefetch and branch trail buffers each include four 32-bit ARM instructions or eight
16-bit Thumb instructions. During sequential code execution, typically the prefetch buffer
contains the current instruction and the entire flash line that contains it.
The MAM uses the LPROT[0] line to differentiate between instruction and data accesses.
Code and data accesses use separate 128-bit buffers. Three of every four sequential
32-bit code or data accesses "hit" in the buffer without requiring a flash access (7 of 8
sequential 16-bit accesses, 15 of every 16 sequential byte accesses). The fourth (eighth,
16th) sequential data access must access flash, aborting any prefetch in progress. When
a flash data access is concluded, any prefetch in progress is re-initiated.
Timing of flash read operations is programmable and is described later in this section.
There is no code fetch penalty for sequential instruction execution when the CPU clock
period is greater than or equal to one fourth of the flash access time. The average amount
of time spent processing program branches is relatively small (less than 25 %) and can be
minimized in ARM (rather than Thumb) code by using the conditional execution feature
present in all ARM instructions. This conditional execution can often be used to avoid
small forward branches that would otherwise be necessary.
Branches and other program flow changes cause a break in the sequential flow of
instruction fetches previously described. The branch trail buf f er ca ptur es th e line to wh ich
such a non-sequential break occurs. If the same branch is taken again, the next
instruction is taken from the branch trail buffer. When a branch outside the contents of the
prefetch and branch trail buffer is taken, the br anch trail buffer is loaded af ter several clock
periods. Typically, there are no further instruction fetch delays until a new and different
branch occurs.
8.2 MAM blocks
The MAM is divided into several functional bloc ks:
• A flash address latch and an incrementing function to form prefetch addresses
• A 128-bit prefetch buffer and an associated address latch and comparator
• A 128-bit branch trail buffer and an associated address latch and comparator
• A 128-bit data buffer and an associated address latch and comparator
• Control logic
• Wait logic
UM10413
MPT612 User manual
Figure 6
In the following descriptions, the term “fetch” applies to an explicit flash read request from
the ARM. “Pre-fetch” is used to denote a flash read of instructions beyond the current
processor fetch address.
shows a simplified block diagram of the MAM data paths.
8.2.1 Flash memory bank
There is one bank of flash memory on the MPT612 MAM.
Flash programming operations are handled as a separate function and not controlled by
the MAM. A separate boot block in ROM contains flash programming algorithms that can
be called by the application program, and a loader that can be run to allow serial
programming of flash memory.
Fig 6.Simplified block diagram of the Memory Accelerator Module (MAM)
ARM LOCAL BUS
UM10413
MPT612 User manual
MEMORY ADDRESS
FLASH MEMORY
BANK
BUS
INTERFACE
BUFFERS
aaa-000572
8.2.2 Instruction latches and data latches
The MAM treats code and data accesses separately. There is a 128-bit latch, a 15-bit
address latch, and a 15-bit comparator associated with each buf fer (pre fetch, bran ch trail,
and data). Each 128-bit latch holds 4 words (4 ARM instructions, or 8 Thumb instructions).
Also associated with each buffer are 32 4:1 multiplexers that select the requested word
from the 128-bit line.
Each data access that is not in the data latch causes a flash fetch of 4 words of data,
which are captured in the data latch. This speeds up sequential data operations, but has
little or no effect on random accesses.
8.2.3 Flash programming issues
Since the flash memory does not allow access dur ing programming and erase operation s,
the MAM must force the CPU to wait if a memory access to a flash address is requested
while the flash module is busy . Under some conditions, this delay can result in a watchdog
time-out. You must ensure that an unwanted watchdog reset does not cause a system
failure while programming or erasing the flash memory.
To preclude the possibility of stale data being read from the flash memory, the MPT612
MAM holding latches are automatically invalidated at the beginning of any flash
programming or erase operation. Any subsequent read from a flash address initiates a
new fetch after the flash operation has completed.
8.3 MAM operating modes
There are three MAM modes of operation defined, trading off performance for ease of
predictability:
Mode 0: MAM off. All memory requests result in a flash read operation (see Table 5
note 2). No instruction prefetches are performed.
Mode 1: MAM partially enabled. If the data is present, sequential instruction accesses
are fulfilled by the holding latches. Instruction prefetch is enabled. Non-sequential
instruction accesses initiate flash read operations (see Table 5
all branches cause memory fetches. All data operations cause a flash read because
buffered data access timing is hard to predict and is very situation-dependent.
Mode 2: MAM fully enabled. Any memory request (code or data) for a value that is
contained in one of the corresponding holding latches is fulfilled from the latch.
Instruction prefetch is enabled. Flash read operations are initiated for instruction
prefetch and code or data values not available in the corresponding holding latches.
T able 5.MAM Responses to program accesses of various types
Program memory request typeMAM mode
Sequential access, data in latchesinitiate fetch
Sequential access, data not in latchesinitiate fetchinitiate fetch
Non-sequential access, data in latchesinitiate fetch
Non-sequential access, data not in latches initiate fetchinitiate fetch
UM10413
MPT612 User manual
, note 2). This means that
012
[2]
use latched
[1]
data
[1]
[2]
initiate fetch
[1][2]
[1]
use latched
[1]
data
initiate fetch
use latched
[1]
data
initiate fetch
[1]
[1]
[1] Instruction prefetch is enabled in modes 1 and 2.
[2] If available, the MAM actually uses latched data, but mimics the timing of a flash read operation. This
method saves power while resulting in the same execution timing. The MAM can truly be turned off by
setting the fetch timing value in MAMTIM to one clock.
Table 6.MAM responses to data accesses of various types
Data memory request typeMAM mode
012
Sequential access, data in latchesinitiate fetch
[1]
initiate fetch
[1]
use latched data
Sequential access, data not in latchesinitiate fetchinitiate fetchinitiate fetch
Non-sequential access, data in latchesinitiate fetch
[1]
initiate fetch
[1]
use latched data
Non-sequential access, data not in latches initiate fetchinitiate fetchinitiate fetch
[1] If available, the MAM actually uses latched data, but it mimics the timing of a flash read operation. This
method saves power while resulting in the same execution timing. The MAM can truly be turned off by
setting the fetch timing value in MAMTIM to one clock.
8.4 MAM configuration
After reset the MAM defaults to the disabled state. Software can turn memory access
acceleration on or off at any time. This method allows most of an application to be run at
the highest possible performance, while certain functions can be run at a slower but more
predictable rate if more precise timing is required.
8.5 Register description
All registers, regardless of size, are on word address boundaries. Details of the registers
appear in the description of each function.
MAMCR MAM control register. Determines MAM functional
MAMTIM MAM timing control. Determines number of clocks
[1] Reset value reflects the data stored in used bits only. It does not include reserved bits content.
8.6 MAM Control register (MAMCR - 0xE01F C000)
Two configuration bits select the three MAM operating modes, as shown in Table 8.
Following reset, MAM functions are disabled. Changing the MAM operating mode causes
the MAM to invalidate all of the holding latches, resulting in new reads of flash information
as required.
Table 8.MAMCR - address 0xE01F C000 bit description
BitSymbolValue DescriptionReset
1:0MAM_mode
7:2--reserved; user software must not write logic 1s to reserved
mode: to what extent the MAM performance
enhancements are enabled; see Table 8
used for flash memory fetches (1 to 7 processor
clocks).
00MAM functions disabled0
_control
01MAM functions partially enabled
10MAM functions fully enabled
11reserved; not to be used in application
bits; value read from a reserved bit is not defined
.
UM10413
MPT612 User manual
Address
[1]
value
R/W0x00xE01F C000
R/W0x070xE01F C004
value
n/a
8.7 MAM Timing register (MAMTIM - 0xE01F C004)
The MAM Timing register determines how many CCLK cycles are used to access the
flash memory. This method allows tuning MAM timing to match the processor operating
frequency. Flash access times from 1 clock to 7 clocks are possible. Single clock flash
accesses removes the MAM from timing calculations. In this case, the MAM mode can be
selected to optimize power usage.
T able 9.MAM Timing register (MAMTIM - address 0xE01F C004) bit description
BitSymbolValue DescriptionReset
2:0MAM_fetch_
7:3--reserved; user software must not write logic 1s to reserve d
cycle_timing
UM10413
MPT612 User manual
value
0000 - reserved07
0011 - MAM fetch cycles are 1 processor clock (CCLK) in
duration
0102 - MAM fetch cycles are 2 CCLKs in duration
0113 - MAM fetch cycles are 3 CCLKs in duration
1004 - MAM fetch cycles are 4 CCLKs in duration
1015 - MAM fetch cycles are 5 CCLKs in duration
1106 - MAM fetch cycles are 6 CCLKs in duration
1117 - MAM fetch cycles are 7 CCLKs in duration
Remark: these bits set duration of MAM flash fetch operations as
listed. Improper setting of values can result in incorrect operation of
the device.
n/a
bits; value read from a reserved bit is not defined
8.8 MAM usage notes
When changing MAM timing, the MAM is turned off by writing a zero to MAMCR. A new
value can then be written to MAMTIM. Finally, the MAM can be turned on again by writing
a value (1 or 2) corresponding to the desired operating mode to MAMCR.
For a system clock slower than 20 MHz, MAMTIM can be 001. A suggested flash access
time for a system clock between 20 MHz and 40 MHz is 2 CCLKs, while systems with a
system clock faster than 40 MHz, 3 CCLKs are proposed. System clocks of 60 MHz and
above require 4CCLKs.
Table 10. Suggestions for MAM timing selection
System clockNumber of MAM fetch cycles in MAMTIM
< 20 MHz1 CCLK
20 MHz to 40 MHz2 CCLK
40 MHz to 60 MHz3 CCLK
> 60 MHz4 CCLK
9. Vectored Interrupt Controller (VIC)
9.1 Features
• ARM PrimeCell Vectored Interrupt Controller
• 32 interrupt request inputs
• 16 vectored IRQ interrupts
• 16 priority levels dynamically assigned to interrupt requests
The Vector ed Interrupt Controller (VIC) t akes 32 interrupt request inputs and assigns th em
to 3 categories, FIQ, vectored IRQ, and non-vectored IRQ. The programmable
assignment scheme means that priorities of interrupt s from the va rious peripherals can be
dynamically assigned and adjusted.
Fast Interrupt reQuest (FIQ) requests have the high est priority. If more than one request is
assigned to FIQ, the VIC ORs the requests to produce the FIQ signal to the ARM
processor. The fastest possible FIQ latency is achieved when only one request is
classified as FIQ because the FIQ service routine then deals with that device. If the FIQ
class is assigned several requests, the FIQ service routine can read a word from the VIC
that identifies which FIQ source(s) is (are) reques tin g an interr up t.
Vectored IRQs have the midd le priority, but only 16 of the 32 requests can be assigned to
this category. Any of the 32 requests can be assigned to any of the 16 vectored IRQ slots
where slot 0 has the highest priority and slot 15 the lowest.
Non-vectored IRQs have the lowest priority.
The VIC ORs the requests from all the vectored and non-vectored IRQs to produce the
IRQ signal to the ARM processor. The IRQ service routine can start by reading a register
from the VIC and jumping there. If a vectored IRQ is requesting, the VIC provides the
address of the highest-priority requesting IRQ service routine, otherwise it provides the
address of a default routine shared by all the non-vectored IRQs. The default routine can
read another VIC register to see what IRQs are active.
UM10413
MPT612 User manual
All registers in the VIC are word registers. Byte and halfword rea d/write are not suppo rted.
Additional information on the Vectored Interrupt Controller is available in the ARM
one of the 16 vectored IRQ slots. Slot 0 has highest priority and slot
15 the lowest.
VICVectCntl1vector control 1 registerR/W00xFFFF F204
VICVectCntl2vector control 2 registerR/W00xFFFF F208
VICVectCntl3vector control 3 registerR/W00xFFFF F20C
VICVectCntl4vector control 4 registerR/W00xFFFF F210
VICVectCntl5vector control 5 registerR/W00xFFFF F214
VICVectCntl6vector control 6 registerR/W00xFFFF F218
VICVectCntl7vector control 7 registerR/W00xFFFF F21C
VICVectCntl8vector control 8 registerR/W00xFFFF F220
VICVectCntl9vector control 9 registerR/W00xFFFF F224
VICVectCntl10vector control 10 registerR/W00xFFFF F228
VICVectCntl11vector control 11 registerR/W00xFFFF F22C
VICVectCntl12vector control 12 registerR/W00xFFFF F230
VICVectCntl13vector control 13 registerR/W00xFFFF F234
VICVectCntl14vector control 14 registerR/W00xFFFF F238
VICVectCntl15vector control 15 registerR/W00xFFFF F23C
[1] Reset value reflects the data stored in used bits only. It does not include content of reserved bits.
…continued
value
Address
[1]
9.4 VIC registers
The following section describes the VIC registers in the order in which they are used in the
VIC logic, from the closest to the interrupt request inputs to the most abstracted for use by
software. In most cases, it is the best order to read about the registers when learning the
VIC.
This register is write only. It allows software to clear one or more bits in the interrupt
enable register without having to read it first; see Section 9.4.4
0assigns interrupt request with this bit number to IRQ category0
1assigns interrupt request with this bit number to FIQ category
9.4.7 IRQ Status register (VICIRQStatus - 0xFFFF F000)
This register is read only. It reads out the state of those interrupt requests that are enabled
and classified as IRQ. It does not differentiate between vectored and non-vectored IRQs.
Table 24. IRQ Status register (VICIRQStatus - address 0xFFFF F000) bit allocation
Table 25. IRQ Status register (VICIRQStatus - address 0xFFFF F000) bit description
BitSymbolDescriptionReset
value
31:0see Table 24
a bit read as logic 1 indicates a corresponding interrupt request being enabled,
0
classified as IRQ, and asserted
9.4.8 FIQ Status register (VICFIQStatus - 0xFFFF F004)
This register is read only. It reads out the state of those interrupt requests that are enabled
and classified as FIQ. If more than one request is classified as FIQ, the FIQ service
routine can read this register to see which request(s) is (are) active.
Table 27. FIQ Status register (VICFIQStatus - address 0xFFFF F004) bit description
BitSymbolDescriptionReset
value
31:0see Table 26
a bit read as logic 1 indicates a corresponding interrupt request being enabled,
0
classified as FIQ, and asserted
9.4.9 Vector control registers 0 to 15 (VICVectCntl0-15 0xFFFF F200 to 23C)
These registers are read/write accessible. Each controls one of th e 16 vectored IRQ slots.
Slot 0 has the highest priority and slot 15 the lowest. Disabling a vectored IRQ slot in one
of registers VICVectCn tl does not disable the interrupt itself, the interrupt is changed to the
non-vectored form.
Table 28. Vector control registers 0 to 15 (VICVectCntl0 to 15 - 0xFFFF F200 to 23C) bit description
BitSymbolDescriptionReset
4:0int_request/
sw_int_assig
5IRQslot_enif logic 1, enables vectored IRQ slot and can produce a unique ISR address
31:6-reserved; user software must not write logic 1s to reserved bits; value read from
the number of interrupt requests or software interrupts assigned to this vectored
IRQ slot. Software must not assign the same interrupt number to more than one
enabled vectored IRQ slot, otherwise a lower numbered slot is used when
interrupt request or software interrupt is enabled, classified as IRQ, and
asserted.
when its assigned interrupt request or software interrupt is enabled, classified
as IRQ, and asserted
a reserved bit is not defined
value
0
0
n/a
9.4.10 Vector address registers 0 to 15 (VICVectAddr0 to 15 0xFFFF F100 to 13C)
These registers are read/write accessible. They hold the addresses of the Interrupt
Service routines (ISRs) for the 16 vectored IRQ slots.
Table 29. Vector address registers 0 to 15 (VICVectAddr0 to 15 - addresses 0xFFFF F100 to 13C) bit description
BitSymbolDescriptionReset value
31:0IRQ_vectorif an interrupt request or software interrupt is enabled, classified as IRQ,
asserted and assigned to an enabled vectored IRQ slot, the value from this
register is used for the highest priority slot, and is provided when IRQ service
routine reads vector address register -VICVectAddr; see Section 9.4.10
This register is read/write accessible. When an IRQ interrupt occurs, the IRQ service
routine can read this register and jump to the value read.
Table 31. Vector address register (VICVectAddr - address 0xFFFF F030) bit descriptio n
BitSymbolDescriptionReset value
31:0IRQ_vectorif an interrupt request or software interrupt assigned to a vectored IRQ slot is
0x0000 0000
enabled, classified as IRQ and asserted, reading this register returns the
address in this register for the highest priority (lowest-numbered) slot.
Otherwise it returns the address in the default vector address register.
Writing to this register does not set the value for future reads from it. Instead,
write to this register near the end of an ISR to update the priority hardware.
0VIC_access0VIC registers can be accessed in User or Privileged mode0
31:1-reserved; user software must not write logic 1s to reserved bits;
value
1VIC registers can only be accessed in Privileged mode
n/a
value read from a reserved bit is not defined
9.5 Interrupt sources
Table 33 lists the interrupt sources for each peripheral function. Each peripheral device
has one interrupt line connected to the Vectored Interrupt Controller, but can have several
internal interrupt flags. Individual interrupt flags can represent more than one interrupt
source.
Fig 7.Block diagram of the Vectored Interrupt Controller (VIC)
9.6 Spurious interrupts
Spurious interrupt s are possib le in the ARM7TDMI based ICs such as the MPT612 due to
asynchronous interrupt handling. The asynchronous character of the interrupt processing
has its roots in the interaction of the core and the VIC. If the VIC sta te is changed between
the moments when the core detects an interrupt, and the core actually processes an
interrupt, problems can be generated.
Real-life applications can experience the fo llowing sc en arios:
1. VIC decides there is an IRQ interrupt and sends the IRQ signal to the core
2. Core latches the IRQ state
3. Processing continues for a few cycles due to pipelining
4. Core loads IRQ address from VIC
Furthermore, it is possible that the VIC state has changed during step 3. For example, VIC
was modified so that the interrupt that triggered the sequence starting with step 1) is no
longer pending, interrupt got disabled in the executed code. In this case, the VIC is not
able to identify clearly the interrupt that generated the interrupt request, and as a result
the VIC returns the default interrupt VicDefVectAddr (0xFFFF F034).
This potentially disastrous chain of events can be prevented in two ways:
NXP Semiconductors
• Application code must be set up in a way to prevent the spurious interrupts from
• Correctly set up and test the VIC default handler.
9.6.1 Details and case studies on spurious interrupts
This chapter contains details that can be obtained from the official ARM website, FAQ
section.
What happens if an interrupt occurs as it is being disabled?
Applies to: ARM7TDMI
If an interrupt received by the core during execution of an instruction disables interrupts,
the ARM7 family still takes the interrupt (IRQ or FIQ).
For example, consider the following instruction sequence:
occurring. Simple guarding of changes to the VIC cannot be enough since, for
example, glitches on level-sensitive interrupts can also cause spurious interrupts.
If an IRQ interrupt is received during execut ion of the MSR instruction, then the behavior
is as follows:
1. The IRQ interrupt is latched.
2. The MSR cpsr, r0 executes to completion setting both bit I and bit F in the CPSR.
3. The IRQ interrupt is taken because the core was committed to taking the interrupt
exception before bit I was set in the CPSR.
4. The CPSR (with bit I and bit F set) is moved to the SPSR_IRQ.
This means that, on entry to the IRQ interrupt service routine, you can see the unusual
effect that an IRQ interrupt has been taken while bit I in SPSR is set. In the example
above, bit F is also set in both CPSR and SPSR. This means that FIQs are disabled upon
entry to the IRQ service routine until explicitly re-enabled. The IRQ return sequence does
not automatically re-enable FIQs.
Although the example shows both IRQ and FIQ interrupts be ing disabled, similar beha vior
occurs when only one of the two interrupt types is being disabled. The core processes the
IRQ after completing the MSR instruction which disables IRQs, and does not normally
cause a problem, as an interrupt arriving one cycle earlier is expected to be taken. When
the interrupt routine returns with an instruction like:
SUBS pc, lr, #4
the SPSR_IRQ is restored to the CPSR. The CPSR now has bit I and bit F set, and
therefore execution continues with all interrupts disabled. However, problems can be
caused in the following cases:
Problem 1: A particular routine maybe called as an IRQ handler, or as a regular
subroutine. In the latter case, the system guarantees that IRQs have been disabled before
the routine being called. The routine exploits this restriction to determine how it was called
(by examining bit I of SPSR), and returns using the appropr iate instruction. If the routine is