Exceptions And Interrupts Control; Master Subsystem Nested Vectored Interrupt Controller - Texas Instruments Concerto F28M35 Series Technical Reference Manual

Table of Contents

Advertisement

www.ti.com
each boot ROM reads their respective WIR mode register it will exit WIR mode and continue to boot or
give a software or debugger reset to the subsystem.
Set EMU0 and EMU1 pins to a value other than the WIR_MODE_YES value and set the sample bit in
each WIR mode register. The next time boot ROM reads this register, it will exit the WIR mode and
continue to boot or give a software reset or debugger reset to the device and restart boot ROM
execution.
1.5

Exceptions and Interrupts Control

This device has exception capturing and handling ability which enables the device to be used in many
safety critical applications. Device run-time exceptions that can be detected and acted upon include clock
failure detection, memory access errors detection, bus fault detection, and interrupt handler address
mismatch errors. This device also supports back-to-back non-maskable interrupt handling capability along
with highly configurable peripheral interrupt handling.
The master subsystem is built around the Cortex-M3 ARM core and has the Nested Vectored Interrupt
Controller (NVIC) module, while the control subsystem is built around the C28x core and has the
peripheral interrupt expansion (PIE) module. This enables the user to configure, handle, and serve
interrupt requests from different subsystem peripherals and handle various exceptions that can occur in
the device during its operation. The master subsystem is capable of handling exceptions on the control
subsystem and ACIB, whereas the control subsystem is capable of handling exceptions related to control
peripherals. Exception handling on the master subsystem is built such that, it will be able to identify and
handle the errors even if the control subsystem fails to handle its exceptions.
This section provides details about interrupts and exception handling supported by both the master and
control subsystems. Both the master and control subsystems each have an independent NMI module
which captures various exceptions that can occur in the system and trigger an NMI to the respective CPU
core.

1.5.1 Master Subsystem Nested Vectored Interrupt Controller

Refer to the NVIC section of the Cortex-M3 Peripherals chapter of this document for more details on
exceptions and interrupts supported by the NVIC in the master subsystem.
As part of the master subsystem, the Cortex-M3 NVIC handles exceptions that can occur on the control
subsystem and ACIB. The Cortex-M3 NVIC module supports a non-maskable interrupt, which has higher
priority than all other NVIC supported interrupts or exceptions. The master subsystem's non-maskable
interrupt module (MNMI) is responsible for generating this non-maskable interrupt to the Cortex-M3 CPU
core in the master subsystem. Refer to
The NVIC supports a HARDFAULT exception interrupt which has higher priority than any programmable
interrupts but less priority than an NMI. Other programmable exceptions supported by the NVIC are
memory management faults, bus faults, and usage fault programmable exceptions. These programmable
exceptions are disabled by default and the system errors which can cause these exception events end up
triggering a HARDFAULT exception.
exceptions.
On power-up and any reset that resets the master CPU, the NVIC is mapped to the address of 0x0000
0000 in ROM. The M-Boot ROM installs pre-defined interrupt handlers in the default NVIC table as
needed for the boot ROM execution and control. Once the user application is started by boot ROM, they
should have their own NVIC vector table and map the NVIC base address to user locations. If users fail to
re-map the NVIC to their application needs, any interrupt that occurs while the application is executing
ends up calling interrupt and exception handlers installed by boot ROM. Refer to the Boot ROM chapter
for more details on boot ROM handlers in the NVIC.
NOTE:
NVIC Interrupt No. 89 (System/USB PLL OutOfLock) is generated whenever the system
PLL or USB PLL is no longer locked. The interrupt handler should check the status bits to
find out which PLL is no longer locked, and the master subsystem should indicate out-of-lock
status to the control subsystem using an IPC. This has to be taken care of by the user as per
the application requirements.
SPRUH22I – April 2012 – Revised November 2019
Submit Documentation Feedback
Section 1.5.3
and
Section 1.5.2
provides details on the events that cause these
Copyright © 2012–2019, Texas Instruments Incorporated
Exceptions and Interrupts Control
Section 1.5.6
for more details on NMI handling.
System Control and Interrupts
95

Advertisement

Table of Contents
loading

Table of Contents