6.1.1 Control Subsystem Memory Map

6.1.2 Master Subsystem Memory Map

Table 6-13 Device Revision Register

6.3.1 Cortex-M3 CPU

The 32-bit Cortex-M3 processor offers high performance, fast interrupt handling, and access to a variety of communication peripherals (including Ethernet and USB). The Cortex-M3 features a Memory Protection Unit (MPU) to provide a privileged mode for protected operating system functionality. A bus bridge adjacent to the MPU can route program instructions and data on the I-CODE and D-CODE buses that connect to the Boot ROM and Flash. Other data is typically routed through the Cortex-M3 System Bus connected to the local RAMs. The System Bus also goes to the Shared Resources block (also accessible by the Control Subsystem) and to the Analog Subsystem through the ACIB. Another bus bridge allows bus cycles from both the Cortex-M3 System Bus and those of the µDMA bus to access the Master Subsystem peripherals (via the APB bus or the AHP bus).

Most of the interrupts to the Cortex-M3 CPU come from the NVIC, which manages the interrupt requests from peripherals and assigns handling priorities. There are also several exceptions generated by Cortex-M3 CPU that can return to the Cortex-M3 as interrupts after being prioritized with other requests inside the NVIC. In addition to programmable priority interrupts, there are also three levels of fixed-priority interrupts of which the highest priority, level-3, is given to M3PORRST and M3SYSRST resets from the Resets block. The next highest priority, level-2, is assigned to the M3NMIINT, which originates from the NMI block. The M3HRDFLT (Hard Fault) interrupt is assigned to level-1 priority, and this interrupt is caused by one of the error condition exceptions (Memory Management, Bus Fault, Usage Fault) escalating to Hard Fault because they are not enabled or not properly serviced.

The Cortex-M3 CPU has two low-power modes: Sleep and Deep Sleep.

6.3.2 Cortex-M3 DMA and NVIC

The Cortex-M3 direct memory access (µDMA) module provides a hardware method of transferring data between peripherals, between memory, and between peripherals and memory without intervention from the Cortex-M3 CPU. The NVIC manages and prioritizes interrupt handling for the Cortex-M3 CPU.

The Cortex-M3 peripherals use REQ/DONE handshaking to coordinate data transfer requests with the µDMA. If a DMA channel is enabled for a given peripheral, REQ/DONE from the peripheral will trigger the data transfer, following which an IRQ request may be sent from the µDMA to the NVIC to announce to the Cortex-M3 that the transfer has completed. If a DMA channel is not enabled for a given peripheral, REQ/DONE will directly drive IRQ to the NVIC so that the Cortex-M3 CPU can transfer the data. For those peripherals that are not supported by the µDMA, IRQs are supplied directly to the NVIC, bypassing the DMA. This case is true for both Watchdogs, CANs, I²Cs, and the Analog-to-Digital Converters sending ADCINT[8:1] interrupts from the Analog Subsystem. The NMI Watchdog does not send any events to the µDMA or the NVIC (only to the Resets block).

6.3.3 Cortex-M3 Interrupts

Table 6-14 shows all interrupt assignments for the Cortex-M3 processor. Most interrupts (16–107) are associated with interrupt requests from Cortex-M3 peripherals. The first 15 interrupts (1–15) are processor exceptions generated by the Cortex-M3 core itself. These processor exceptions are detailed in Table 6-15.

6.3.4 Cortex-M3 Vector Table

Each peripheral interrupt of Table 6-14 is assigned an address offset containing the location of the peripheral interrupt handler (relative to the vector table base) for that particular interrupt (vector numbers 16–107).

Similarly, each exception interrupt of Table 6-15 (including Reset) is also assigned an address offset containing the location of the exception interrupt handler (relative to the vector table base) for that particular interrupt (vector numbers 1–15).

In addition to interrupt vectors, the vector table also contains the initial stack pointer value at table location 0.

Following system reset, the vector table base is fixed at address 0x0000.0000. Privileged software can write to the Vector Table Offset (VTABLE) register to relocate the vector table start address to a different memory location, in the range 0x0000 0200 to 0x3FFF FE00. Note that when configuring the VTABLE register, the offset must be aligned on a 512-byte boundary.

6.3.5 Cortex-M3 Local Peripherals

The Cortex-M3 local peripherals include two Watchdogs, an NMI Watchdog, four General-Purpose Timers, four SSI peripherals, two CAN peripherals, five UARTs, two I²C peripherals, Ethernet, USB + PHY, EPI, and µCRC (Cyclic Redundancy Check). The USB and EPI are accessible through the AHB Bus (Advanced High-Performance Bus). The EPI peripheral is also accessible from the Control Subsystem. The remaining peripherals are accessible through the APB Bus (Advanced Peripheral Bus). The APB and AHB bus cycles originate from the CPU System Bus or the µDMA Bus via a bus bridge.

While the Cortex-M3 CPU has access to all the peripherals, the µDMA has access to most, with the exception of the µCRC, Watchdogs, NMI Watchdog, CAN peripherals, and the I²C peripheral. The Cortex-M3 peripherals connect to the Concerto device pins via GPIO_MUX1. Most of the peripherals also generate event signals for the µDMA and the NVIC. The Watchdogs receive M3SWRST from the NVIC (triggered by software) and send M3WDRST[1:0] reset requests to the Reset block. The NMI Watchdog receives the M3NMI event from the NMI block and sends the M3NMIRST request to the Resets block.

See Section 5.11 for more information on the Cortex-M3 peripherals.

6.3.6 Cortex-M3 Local Memory

The Local Memory includes Boot ROM; Secure Flash with ECC; Secure C0/C1 RAM with ECC; and C2/C3 RAM with Parity Error Checking. The Boot ROM and Flash are both accessible through the I-CODE and D-CODE Buses. Flash registers can also be accessed by the Cortex-M3 CPU through the APB Bus. All Local Memory is accessible from the Cortex-M3 CPU; the C2/C3 RAM is also accessible by the µDMA.

Two types of error correction events can be generated during access of the Local Memory: uncorrectable errors and single errors. The uncorrectable errors (including one from the Shared Memories) generate a Bus Fault Exception to the Cortex-M3 CPU. The less critical single errors go to the NVIC where they can result in maskable interrupts to the Cortex-M3 CPU.

6.3.7 Cortex-M3 Accessing Shared Resources and Analog Peripherals

There are several memories, digital peripherals, and analog peripherals that can be accessed by both the Master and Control Subsystems. They are grouped into Shared Resources and the Analog Subsystem.

The Shared Resources include the EPI, IPC registers, MTOC Message RAM, CTOM Message RAM, and eight individually configurable Shared RAM blocks. The RAMs of the Shared Resources block have Parity Error Checking.

The Message RAMs and the Shared RAMs can be accessed by the Cortex-M3 CPU and µDMA. The MTOC Message RAM is intended for sending data from the Master Subsystem to the Control Subsystem, having R/W access for the Cortex-M3/µDMA and read-only access for the C28x/DMA. The CTOM Message RAM is intended for sending data from the Control Subsystem to the Master Subsystem, having R/W access for the C28x/DMA and read-only access for the Cortex-M3/µDMA.

The IPC registers provide up to 32 handshaking channels to coordinate the transfer of data through the Message RAMs by polling. Four of these channels are also backed up by four interrupts to PIE on the Control Subsystem side, and four interrupts to the NVIC on the Master Subsystem side (to reduce delays associated with polling).

The eight Shared RAM blocks are similar to the Message RAMs, in that the data flow is only one way; however, the direction of the data flow can be individually set for each block to be from Master to Control Subsystem or from Control to Master Subsystem.

The Analog Subsystem has ADC1, ADC2, and Analog Comparator peripherals that can be accessed through the Analog Common Interface Bus. The ADC Result Registers are accessible by CPUs and DMAs of the Master and Control Subsystems. All other Analog Peripheral Registers are accessible by the C28x CPU only. The Cortex-M3 CPU accesses the ACIB through the System Bus, and the µDMA through the µDMA Bus. The ACIB arbitrates for access to the ADC and Analog Comparator registers between CPU/DMA bus cycles of the Master Subsystem with those of the Control Subsystem. In addition to managing bus cycles, the ACIB also transfers End-of-Conversion ADC interrupts to the Master Subsystem (as well as to the Control Subsystem). The eight EOC sources from ADC1 and the eight EOC sources from ADC2 are AND-ed together by the ACIB, with the resulting eight ADC interrupts going to destinations in both the Master Subsystem and the Control Subsystem.

See Section 5.10 for more information on shared resources and analog peripherals.

6.4.1 C28x CPU/FPU/VCU

The F28M36x Concerto MCU family is a member of the TMS320C2000 MCU platform. The Concerto C28x CPU/FPU has the same 32-bit fixed-point architecture as TI's existing Piccolo MCUs, combined with a single-precision (32-bit) IEEE 754 FPU of TI’s existing Delfino MCUs. Each F28M36x device is a very efficient C/C++ engine, enabling users to develop their system control software in a high-level language. Each F28M36x device also enables math algorithms to be developed using C/C++. The device is equally efficient at DSP math tasks and at system control tasks. The 32 × 32-bit MAC 64-bit processing capabilities enable the controller to handle higher numerical resolution problems efficiently. With the addition of the fast interrupt response with automatic context save of critical registers, the device is capable of servicing many asynchronous events with minimal latency. The device has an 8-level-deep protected pipeline with pipelined memory accesses. This pipelining enables the device to execute at high speeds without resorting to expensive high-speed memories. Special branch-look-ahead hardware minimizes the latency for conditional discontinuities. Special conditional store operations further improve performance. The VCU extends the capabilities of the C28x CPU and C28x+FPU processors by adding additional instructions to accelerate Viterbi, Complex Arithmetic, 16-bit FFTs, and CRC algorithms. No changes have been made to existing instructions, pipeline, or memory bus architecture. Therefore, programs written for the C28x are completely compatible with the C28x+VCU.

There are two events generated by the FPU block that go to the C28x PIE: LVF and LUV. Inside PIE, these and other events from C28x peripherals and memories result in 12 PIE interrupts PIEINTS[12:1] into the C28x CPU. The C28x CPU also receives three additional interrupts directly (instead of through PIE) from Timer 1 (TINT1), from Timer 2 (TINT2), and from the NMI block (C28uNMIINT).

The C28x has two low-power modes: IDLE and STANDBY.

6.4.2 C28x Core Hardware Built-In Self-Test

The Concerto microcontroller C28x CPU core includes a HWBIST feature for testing the CPU core logic for errors. Tests using HWBIST can be initiated through a software library provided by TI.

6.4.3 C28x Peripheral Interrupt Expansion

The PIE block serves to multiplex numerous interrupt sources into a smaller set of interrupt inputs. The PIE block can support up to 96 peripheral interrupts. On the F28M36x, 72 of the possible 96 interrupts are used. The 96 interrupts are grouped into blocks of 8 and each group is fed into 1 of 12 CPU interrupt lines (INT1 to INT12). Each of 12 interrupt lines supports up to 8 simultaneously active interrupts. Each of the 96 interrupts has its own vector stored in a dedicated RAM block that can be overwritten by the user. The vector is automatically fetched by the CPU on servicing the interrupt. Eight CPU clock cycles are needed to fetch the vector and save critical CPU registers. Hence, the CPU can quickly respond to interrupt events. Prioritization of interrupts is controlled in hardware and software. Each individual interrupt can be enabled or disabled within the PIE block.

See Table 6-16 for PIE interrupt assignments.

6.4.4 C28x Direct Memory Access

The C28x DMA module provides a hardware method of transferring data between peripherals, between memory, and between peripherals and memory without intervention from the CPU, thereby freeing up bandwidth for other system functions. Additionally, the DMA has the capability to orthogonally rearrange the data as the data is transferred as well as “ping-pong” data between buffers. These features are useful for structuring data into blocks for optimal CPU processing. The interrupt trigger source for each of the six DMA channels can be configured separately and each channel contains its own independent PIE interrupt to notify the CPU when a DMA transfer has either started or completed. Five of the six channels are exactly the same, while Channel 1 has one additional feature: the ability to be configured at a higher priority than the others.

6.4.5 C28x Local Peripherals

The C28x local peripherals include an NMI Watchdog, three Timers, four Serial Port Peripherals (SCI, SPI, McBSP, I²C), an EPI, and three types of Control Peripherals (ePWM, eQEP, eCAP). All peripherals are accessible by the C28x CPU via the C28x Memory Bus. Additionally, the McBSP and ePWM are accessible by the C28x DMA Bus. The EPI peripheral is also accessible from the Master Subsystem. The Serial Port Peripherals and the Control Peripherals connect to Concerto’s pins via the GPIO_MUX1 block. Internally, the C28x peripherals generate events to the PIE block, C28x DMA, and the Analog Subsystem. The C28x NMI Watchdog receives a C28NMI event from the NMI block and sends a counter time-out event to the Cortex-M3 NMI block and the Resets block to flag a potentially critical condition.

The ePWM peripheral receives events that can be used to trip the ePWM outputs EPWMxA and EPWMxB. These events include ECCDBLERR event from the C28x Local Memory, PIENMIERR and EMUSTOP events from the C28x CPU, and up to 12 trips from GPIO_MUX1.

See Section 5.12 for more information on C28x peripherals.

6.4.6 C28x Local Memory

The C28x Local Memory includes Boot ROM; Secure Flash with ECC; Secure L0/L1 RAM with ECC; L2/L3 RAM with Parity Error Checking; and M0/M1 with ECC. All local memories are accessible from the C28x CPU; the L2/L3 RAM is also accessible by the C28x DMA. Two types of error correction events can be generated during access of the C28x Local Memory: uncorrectable errors and single errors. The uncorrectable errors propagate to the NMI block where they can become the C28NMI to the C28x NMI Watchdog and the C28NMIINT nonmaskable interrupt to the C28x CPU. The less critical single errors go to the PIE block where they can become maskable interrupts to the C28x CPU.

6.4.7 C28x Accessing Shared Resources and Analog Peripherals

There are several memories, digital peripherals, and analog peripherals that can be accessed by both the Master and Control Subsystems. They are grouped into the Shared Resources and the Analog Subsystem.

The Shared Resources include the EPI, IPC registers, MTOC Message RAM, CTOM Message RAM, and eight individually configurable Shared RAM blocks.

The Message RAMs and the Shared RAMs can be accessed by the C28x CPU and DMA and have Parity-Error Checking. The MTOC Message RAM is intended for sending data from the Master Subsystem to the Control Subsystem, having R/W access for the Cortex-M3/µDMA and read-only access for the C28x/DMA. The CTOM Message RAM is intended for sending data from the Control Subsystem to the Master Subsystem, having R/W access for the C28x/DMA and read-only access for the Cortex-M3/µDMA.

The IPC registers provide up to 32 handshaking channels to coordinate transfer of data through the Message RAMs by polling. Four of these channels are also backed up by four interrupts to PIE on the Control Subsystem side, and four interrupts to the NVIC on the Master Subsystem side (to reduce delays associated with polling).

The eight Shared RAM blocks are similar to the Message RAMs, in that the data flow is only one way; however, the direction of the data flow can be individually set for each block to be from Master to Control Subsystem or from Control to Master Subsystem.

See Section 5.10 for more information on shared resources and analog peripherals.

6.5.1 ADC1

The ADC1 consists of a 12-bit Analog-to-Digital converter with up to 16 analog input channels of which 12 are currently pinned out. The analog channels are internally preassigned to two Sample-and-Hold (S/H) units A and B, both feeding an Analog Mux whose output is converted to a 12-bit digital value and stored in ADC1 result registers. The two S/H units enable simultaneous sampling of two analog signals at a time. Additional channels or channel pairs are converted sequentially. SOC triggers from the Control Subsystem initiate analog-to-digital conversions. EOC interrupts from ADCs notify the Master and Control Subsystems that the conversion results are ready to be read from ADC1 result registers.

See Section 5.10.1 for more information on ADC peripherals.

6.5.2 ADC2

The ADC2 consists of a 12-bit Analog-to-Digital converter with up to 16 analog input channels of which 12 are currently pinned out. The analog channels are internally preassigned to two S/H units A and B, both feeding an Analog Mux whose output is converted to a 12-bit digital value and stored in the ADC2 result registers. The two S/H units enable simultaneous sampling of two analog signals at a time. Additional channels or channel pairs are converted sequentially. SOC triggers from the Control Subsystem initiate analog-to-digital conversions. EOC interrupts from ADCs notify the Master and Control Subsystems that the conversion results are ready to be read from ADC2 result registers.

See Section 5.10.1 for more information on ADC peripherals.

6.5.3 Analog Comparator + DAC

There are six Comparator blocks enabling simultaneous comparison of multiple pairs of analog inputs, resulting in six digital comparison outputs. The external analog inputs that are being compared in the comparators come from AIO_MUX1 and AIO_MUX2 blocks. These analog inputs can be compared against each other or the outputs of 10-bit DACs (Digital-to-Analog Converters) inside individual Comparator modules. The six comparator outputs go to the GPIO_MUX2 block where they can be mapped to six out of eight available pins.

Note that in order to use these comparator outputs to trip the C28x EPWMA/B outputs, they must be first routed externally from pins of the GPIO_MUX2 block to selected pins of the GPIO_MUX1 block before they can be assigned to selected 12 ePWM Trip Inputs.

See Section 5.10.2 for more information on the analog comparator + DAC.

6.5.4 Analog Common Interface Bus

The ACIB links the Master and Control Subsystems with the Analog Subsystem. The ACIB enables the Cortex-M3 CPU/µDMA and C28x CPU/DMA to access Analog Subsystem registers, to send SOC Triggers to the Analog Subsystem, and to receive EOC Interrupts from the Analog Subsystem. The Cortex-M3 uses its System Bus and the µDMA Bus to read from ADC Result registers. The C28x uses its Memory Bus and the DMA bus to access ADC Result registers and other registers of the Analog Subsystem. The ACIB arbitrates between up to four possibly simultaneously occurring bus cycles on the Master/Control Subsystem side of ACIB to access the ADC and Analog Comparator registers on the Analog Subsystem side.

Additionally, ACIB maps up to 22 SOC trigger sources from the Control Subsystem to 8 SOC trigger destinations inside the Analog Subsystem (shared between ADC1 and ADC2), and up to 16 ADC EOC interrupt sources from the Analog Subsystem to 8 destinations inside the Master and Control Subsystems. The eight ADC interrupts are the result of AND-ing of eight EOC interrupts from ADC1 with 8 EOC interrupts from ADC2. The total of 16 possible ADC1 and ADC2 interrupts are sharing the 8 interrupt lines because it is unlikely that any application would need all 16 interrupts at the same time.

Eight registers (TRIG1SEL–TRIG8SEL) configure eight corresponding SOC triggers to assign 1 of 22 possible trigger sources to each SOC trigger.

There are two registers that provide status of ACIB to the Master Subsystem and to the Control Subsystem.

The Cortex-M3 can read the MCIBSTATUS register to verify that the Analog Subsystem is properly powered up; the Analog System Clock (ASYSCLK) is present; and that the bus cycles, triggers, and interrupts are correctly propagating between the Master, Control, and Analog subsystems.

The C28x can read the CCIBSTATUS register to verify that the Analog Subsystem is properly powered up; the Analog System Clock (ASYSCLK) is present; and that the bus cycles, triggers, and interrupts are correctly propagating between the Master, Control, and Analog subsystems.

6.8.1 Cortex-M3 Resets

The Cortex-M3 CPU and NVIC (Nested Vectored Interrupt Controller) are both reset by the POR or the M3SYSRST reset signal. In both cases, the Cortex-M3 CPU restarts program execution from the address provided by the reset entry in the vector table. A register can later be referenced to determine the source of the reset. The M3SYSRST signal also propagates to the Cortex-M3 peripherals and the rest of the Cortex-M3 Subsystem.

The M3SYSRST has four possible sources: XRS, M3WDOGS, M3SWRST, and M3DBGRST. The M3WDOGS is set in response to time-out conditions of the two Cortex-M3 Watchdogs or the Cortex-M3 NMI Watchdog. The M3SWRST is a software-generated reset output by the NVIC. The M3DBGRS is a debugger-generated reset that is also output by the NVIC. In addition to driving M3SYSRST, these two resets also propagate to the C28x Subsystem and the Analog Subsystem.

The M3RSNIN bit can be set inside the CRESCNF register to selectively reset the C28x Subsystem from the Cortex-M3, and ACIBRST bit of the same register selectively resets the Analog Common Interface Bus. In addition to driving reset signals to other parts of the chip, the Cortex-M3 can also detect a C28SYSRST reset being set inside the C28x Subsystem by reading the CRES bit of the CRESSTS register.

Cortex-M3 software can also set bits in the SRCR register to selectively reset individual Cortex-M3 peripherals, provided they are enabled inside the DC (Device Configuration) register. The Reset Cause register (MRESC) can be read to find out if the latest reset was caused by External Reset, POR, Watchdog Timer 0, Watchdog Timer 1, or Software Reset from NVIC.

6.8.2 C28x Resets

The C28x CPU is reset by the C28RSTIN signal, and the C28x CPU in turn resets the rest of the C28x Subsystem with the C28SYSRST signal. When reset, the C28x restarts program execution from the address provided at the top of the Boot ROM Vector Table.

The C28RSTIN has five possible sources: XRS, C28NMIWD, M3SWRST, M3DBGRST, and the M3RSNIN. The C28NMIWD is set in response to time-out conditions of the C28x NMI Watchdog. The M3SWRST is a software-generated reset output by the NVIC. The M3DBGRS is a debugger-generated reset that is also output by the NVIC. These two resets must be first enabled by the Cortex-M3 processor in order to propagate to the C28x Subsystem. M3RSNIN reset comes from the Cortex-M3 Subsystem to selectively reset the C28x Subsystem from Cortex-M3 software.

The C28x processor can learn the status of the internal ACIBRST reset signal and the external XRS pin by reading the DEVICECNF register.

6.8.3 Analog Subsystem and Shared Resources Resets

Both the Analog Subsystem and the resources shared between the C28x and Cortex-M3 subsystems (IPC, MSG RAM, Shared RAM) are reset by the SRXRST reset signal. Additionally, the Analog Subsystem is also reset by the internal ACIBRST signal from the Cortex-M3 Subsystem and the external ARS pin, (should be externally tied to the XRS pin), which can be reset by the POR circuitry.

The SRXRST has three possible sources: XRS, M3SWRST, and M3DBGRST. The M3SWRST is a software-generated reset output by the NVIC. The M3DBGRS is a debugger-generated reset that is also output by the NVIC. These two resets must be first enabled by the Cortex-M3 processor in order to propagate to the Analog Subsystem and the Shared Resources.

Although EPI is a shared peripheral, it is physically located inside the Cortex-M3 Subsystem; therefore, EPI is reset by M3SYSRST.

6.8.4 Device Boot Sequence

Concerto’s boot sequence is used to configure the Master Subsystem and the Control Subsystem for execution of application code. The boot sequence involves both internal resources, and resources external to the device. These resources include: Master Subsystem Bootloader code (M-Bootloader) factory-programmed inside the Master Subsystem Boot ROM (M-Boot ROM); Control Subsystem Bootloader code (C-Bootloader) factory-programmed inside the Control Subsystem Boot ROM (C-Boot ROM); four GPIO_MUX pins for Master boot mode selection; internal Flash and RAM memories; and selected Cortex-M3 and C28x peripherals for loading the application code into the Master and Control Subsystems.

The boot sequence starts when the Master Subsystem comes out of reset, which can be caused by device power up, external reset, debugger reset, software reset, Cortex-M3 watchdog reset, or Cortex-M3 NMI watchdog reset. While the M-Bootloader starts executing first, the C-Bootloader starts soon after, and then both bootloaders work in tandem to configure the device, load application code for both processors (if not already in the Flash), and branch the execution of each processor to a selected location in the application code.

Execution of the M-Bootloader commences when an internal reset signal goes from active to inactive state. At that time, the Control Subsystem and the Analog Subsystem continue to be in reset state until the Master Subsystem takes them out of reset. The M-Bootloader first initializes some device-level functions, then the M-Bootloader initializes the Master Subsystem. Next, the M-Bootloader takes the Control Subsystem and the Analog Subsystem/ACIB out of reset. When the Control Subsystem comes out of reset, its own C-Bootloader starts executing in parallel with the M-Bootloader. After initializing the Control Subsystem, the C-Bootloader enters the C28x processor into the IDLE mode (to wait for the M-Bootloader to wake up the C28x processor later via the MTOCIPC1 interrupt). Next, the M-Bootloader reads four GPIO pins (see Table 6-17) to determine the boot mode for the rest of the M-Bootloader operation.

1. By default, GPIO terminals are not pulled up (they are floating).
2. Boot Modes 0–7 are pin-compatible with the F28M35x members of the Concerto family (they use same GPIO terminals).
3. Boot Mode 12 is the same as Boot Mode 4, except it uses a different set of GPIO terminals.
4. This Boot Mode uses a faster Flash power-up sequence. The maximum supported OSCCLK frequency for this mode is 30 MHz.
5. Supported only in TMS version. On all other versions, this mode defaults to Boot-to-Flash.

Boot Mode 7 and Boot Mode 15 cause the Master program to branch execution to the application in the Master Flash memory. This branching requires that the Master Flash be already programmed with valid code; otherwise, a hard fault exception is generated and the Cortex-M3 goes back to the above reset sequence. (Therefore, for a factory-fresh device, the M-Bootloader will be in a continuous reset loop until the emulator is connected and a debug session started.) If the Master Subsystem Flash has already been programmed, the application code will start execution. Typically, the Master Subsystem application code will then establish data communication with the C28x [through the IPC (Interprocessor Communications peripheral)] to coordinate the rest of the boot process with the Control Subsystem. Boot Mode 15 (Fast Boot to Flash Mode) supported on this device is a special boot to Flash mode, which configures Flash for a faster power up, thus saving some boot time. Boot Mode 7 and other modes which default to Flash do not configure Flash for a faster power up like Boot Mode 15 does. Note that following reset, the internal pullup resistors on GPIOs are disabled. Therefore, Boot Mode 15, for example, will typically require four external pullups.

Boot Mode 1 causes the Master boot program to branch to Cortex-M3 RAM, where the Cortex-M3 processor starts executing code that has been preloaded earlier. Typically, this mode is used during development of application code meant for Flash, but which has to be first tested running out of RAM. In this case, the user would typically load the application code into RAM using the debugger, and then issue a debugger reset, while setting the four boot pins to 0001b. From that point on, the rest of the boot process on the Master Subsystem side is controlled by the application code.

Boot Modes 0, 2, 3, 4, 9, 10, and 12 are used to load the Master application code from an external peripheral before branching to the application code. This process is different from the process in Boot Modes 1, 7, and 15, where the application code was either already programmed in Flash or loaded into RAM by the emulator. If the boot mode selection pins are set to 0000b, the M-Bootloader (running out of M-Boot ROM) will start uploading the Master application code from preselected Parallel GPIO_MUX pins. If the boot pins are set to 0010b, the application code will be loaded from the Master Subsystem UART0, SSI0, or I2C0 peripheral. (SSI0 and I2C0 are configured to work in Slave mode in this Boot Mode.) If the boot pins are set to 0011b, the application code will be loaded from the Master Subsystem CAN interface. Furthermore, if the boot pins are set to 0100b, the application code will be loaded through the Master Subsystem Ethernet interface; the IOs used in this Boot Mode are compatible with the F28M35x device. If the boot pins are set to 1001b or 1010b, then the application code will be loaded through the SSI0 or I2C0 interface, respectively. SSI0 and I2C0 loaders work in Master Mode in this boot mode. If the boot pins are set to 1100b, then the application code will be loaded through the Master Subsystem Ethernet interface; the IOs used in this Boot Mode are F28M36x IOs, which are available only in a BGA package.

Regardless of the type of boot mode selected, once the Master application code is resident in Master Flash or RAM, the next step for the M-Bootloader is to branch to Master Flash or RAM. At that point, the application code takes over control from the M-Bootloader, and the boot process continues as prescribed by the application code. At this stage, the Master application program typically establishes communication with the C-Bootloader, which by now, would have already initialized the Control Subsystem and forced the C28x to go into IDLE mode. To wake the Control Subsystem out of IDLE mode, the Master application issues the Master-to-Control-IPC-interrupt 1 (MTOCIPCINT1) . Once the data communication has been established through the IPC, the boot process can now also continue on the Control Subsystem side.

The rest of the Control Subsystem boot process is controlled by the Master Subsystem application issuing IPC instructions to the Control Subsystem, with the C-Bootloader interpreting the IPC commands and acting on them to continue the boot process. At this stage, a boot mode for the Control Subsystem can be established. The Control Subsystem boot modes are similar to the Master Subsystem boot modes, except for the mechanism by which they are selected. The Control Subsystem boot modes are chosen through the IPC commands from the Master application code to the C-Bootloader, which interprets them and acts accordingly. The choices are, as above, to branch to already existing Control application code in Flash, to branch to preloaded code in RAM (development mode), or to upload the Control application code from one of several available peripherals (see Table 6-18). As before, once the Control application code is in place (in Flash or RAM), the C-Bootloader branches to Flash or RAM, and from that point on, the application code takes over.

The boot process can be considered completed once the Cortex-M3 and C28x are both running out of their respective application programs. Note that following the boot sequence, the C-Bootloader is still available to interpret and act upon an assortment of IPC commands that can be issued from the Master Subsystem to perform a variety of configuration, housekeeping, and other functions.

6.9.1 Analog Subsystem's Internal 1.8-V VREG

The internal 1.8-V Voltage Regulator (VREG) generates V_DD18 power from V_DDIO. The 1.8-V VREG is enabled by pulling the VREG18EN pin to a low state. When enabled, the 1.8-V VREG provides 1.8 V to digital logic associated with the analog functions of the Analog Subsystem.

When the internal 1.8-V VREG function is enabled, the 1.8 V power no longer has to be provided externally; however, a 1.2-µF (10% tolerance) capacitor is required for each V_DD18 pin to stabilize the internally generated voltages. These load capacitors are not required if the internal 1.8-V VREG is disabled, and the 1.8 V is provided from an external supply.

Note that while removing the need for an external power supply, enabling the internal VREG might affect the V_DDIO power consumption.

6.9.2 Digital Subsystem's Internal 1.2-V VREG

The internal 1.2-V VREG generates V_DD12 power from V_DDIO. The 1.2-V VREG is enabled by pulling the VREG12EN pin to a low state. When enabled, the 1.2-V VREG internally provides 1.2 V to digital logic associated with the processors, memory, and peripherals of the Digital Subsystem.

When the internal 1.2-V VREG function is enabled, the 1.2 V power no longer has to be provided externally; however, the minimum and maximum capacitance required for each V_DD12 pin to stabilize the internally generated voltages are 250 nF and 750 nF, respectively. These load capacitors are not required if the internal 1.2-V VREG is disabled and the 1.2 V is provided from an external supply.

Note that while removing the need for an external power supply, enabling the internal VREG might affect the V_DDIO power consumption.

6.9.3 Analog and Digital Subsystems' Power-On-Reset Functionality

The Analog and Digital Subsystems' each have a POR circuit that creates a clean reset throughout the device enabling glitchless GPIOs during the power-on procedure. The POR function keeps both ARS and XRS driven low during device power up. This functionality is always enabled, even when VREG is disabled.

While in most applications, the POR generated reset has a long enough duration to also reset other system ICs, some applications may require a longer lasting pulse. In these cases, the ARS and XRS reset pins (which are open-drain) can also be driven low to match the time the device is held in a reset state with the rest of the system.

When POR drives the ARS and XRS pins low, the POR also resets the digital logic associated with both subsystems and puts the GPIO pins in a high impedance state.

In addition to the POR reset, the Digital Subsystem’s Resets block also receives reset inputs from the NVIC, the Cortex-M3 Watchdogs (0, 1), and from the Cortex-M3 NMI Watchdog. The resulting reset output signal is then fed back to the XRS pin after being AND-ed with the POR reset (see Figure 6-6).

On a related note, only the Master Subsystem comes out of reset immediately following a device power up. The Control and Analog Subsystems continue to be held in reset until the Master Processor (Cortex-M3) brings them out of reset by writing a "1" to the M3RSNIN and ACIBRST bits of the CRESCNF Register (see Figure 6-6).

6.9.4 Connecting ARS and XRS Pins

In most Concerto applications, TI recommends that the ARS and XRS pins be tied together by external means such as through a signal trace on a PCB board. Tying the ARS and XRS pins together ensures that all reset sources will cause both the Analog and Digital Subsystems to enter the reset state together, regardless of where the reset condition occurs.

6.10.1 Internal Oscillator (Zero-Pin)

Each Concerto device contains a zero-pin internal oscillator. This oscillator outputs two fixed-frequency clocks: 10MHZCLK and 32KHZCLK. These clocks are not configurable by the user and should not be used to clock the device during normal operation. They are used inside the Master Subsystem to implement low-power modes. The 10MHZCLK is also used by the Missing Clock Detect circuit.

6.10.2 Crystal Oscillator/Resonator (Pins X1/X2 and V_SSOSC)

The main oscillator circuit connects to an external crystal through pins X1 and X2. If a resonator is used (version of a crystal with built-in load capacitors), its ground terminal should be connected to the pin V_SSOSC (not board ground). The V_SSOSC pin should also be used to ground the external load capacitors connected to the two crystal terminals as shown in Figure 6-7.

6.10.3 External Oscillators (Pins X1, V_SSOSC, XCLKIN)

Concerto has two pins (X1 and XCLKIN) into which a single-ended clock can be driven from external oscillators or other clock sources. When connecting an external clock source through the X1 terminal, the X2 terminal should be left unconnected. Most internal clocks of this device are derived from the X1 clock input (or X1/X2 crystal) . The XCLKIN clock is only used by the USB PLL and CAN peripherals. Figure 6-7 shows how to connect external oscillators to the X1 and XCLKIN terminals.

Locate the external oscillator as close to the MCU as practical. Ideally, the return ground trace should be an isolated trace directly underneath the forward trace or run adjacent to the trace on the same layer. Spacing should be kept minimal, with any other nearby traces double-spaced away, so that the electromagnetic fields created by the two opposite currents cancel each other out as much as possible, thus reducing parasitic inductances that radiate EMI.

6.10.4 Main PLL

The Main PLL uses the reference clock from pins X1 (external oscillator) or X1/X2 (external crystal/resonator). The input clock is multiplied by an integer multiplier and a fractional multiplier as selected by the SPLLIMULT and SPLLFMULT fields of the SYSPLLMULT register. For example, to achieve PLL multiply of 28.5, the integer multiplier should be set to 28, and the fractional multiplier to 0.5. The output clock from the Main PLL must be between 150 MHz and 300 MHz. The PLL output clock is then divided by 2 before entering a mux that selects between this clock and the PLL input clock – OSCCLK (used in PLL bypass mode). The PLL bypass mode is selected by setting the SPLLIMULT field of the SYSPLLMULT register to 0. The output clock from the mux next enters a divider controlled by the SYSDIVSEL register, after which the output clock becomes the PLLSYSCLK. Figure 6-8 shows the Main PLL function and configuration examples. Table 6-19 to Table 6-22 list the integer multiplier configuration values.

Figure 6-8 Main PLL

6.10.5 USB PLL

The USB PLL uses the reference clock selectable between the input clock arriving at the XCLKIN pin, or the internal OSCCLK (originating from the external crystal or oscillator via the X1/X2 pins). An input mux selects the source of the USB PLL reference based on the UPLLCLKSRC bit of the UPLLCTL Register (see Figure 6-9). The input clock is multiplied by an integer multiplier and a fractional multiplier as selected by the UPLLIMULT and UPLLFMULT fields of the UPLLMULT register. For example, to achieve PLL multiply of 28.5, the integer multiplier should be set to 28, and the fractional multiplier to 0.5. The output clock from the USB PLL must always be 240 MHz. The PLL output clock is then divided by 4—resulting in 60 MHz that the USB needs—before entering a mux that selects between this clock and the PLL input clock (used in the PLL bypass mode). The PLL bypass mode is selected by setting the UPLLIMULT field of the UPLLMULT register to 0. The output clock from the mux becomes the USBPLLCLK (there is not another clock divider). Figure 6-9 shows the USB PLL function and configuration examples. Table 6-23 and Table 6-24 list the integer multiplier configuration values.

Figure 6-9 USB PLL

Table 6-25 Master Subsystem Low-Power Modes

6.11.1 Cortex-M3 Run Mode

In Run Mode, the Cortex-M3 processor, memory, and most of the peripherals are clocked by the M3SSCLK, which is a divide-down version of the PLLSYSCLK (from Main PLL). The USB is clocked from a dedicated USB PLL, the CAN peripherals are clocked by M3SSCLK, OSCCLK, or XCLKIN, and one of two watchdogs (WDOG1) is also clocked by the OSCCLK. Clock selection for these peripherals is accomplished via corresponding peripheral configuration registers. Clock gating for individual peripherals is defined inside the RCGS register. RCGS, SCGS, and DCGS clock-gating settings only apply to peripherals that are enabled in a corresponding DC (Device Configuration) register.

Execution of the WFI instruction (Wait-for-Interrupt) shuts down the HCLK to the Cortex-M3 CPU and forces the Cortex-M3 Subsystem into Sleep or Deep Sleep low-power mode, depending on the state of the SLEEPDEEP bit of the Cortex-M3 SYSCTRL register. To come out of a low-power mode, any properly configured interrupt event terminates the Sleep or Deep Sleep Mode and returns the Cortex-M3 processor/subsystem to Run Mode.

6.11.2 Cortex-M3 Sleep Mode

In Sleep Mode, the Cortex-M3 processor and memory are prevented from clocking, and thus the code is no longer executing. The gating for the peripheral clocks may change based on the ACG bit of the RCC register. When ACG = 0, the peripheral clock gating is used as defined by the RCGS registers (same as in Run Mode); and when ASC = 1, the clock gating comes from the SCGS register. RCGS and SCGS clock-gating settings only apply to peripherals that are enabled in a corresponding DC register. Peripheral clock frequency for the enabled peripherals in Sleep Mode is the same as during the Run Mode.

Sleep Mode is terminated by any properly configured interrupt event. Exiting from the Sleep Mode depends on the SLEEPEXIT bit of the SYSCTRL register. When the SLEEPEXIT bit is 1, the processor will temporarily wake up only for the duration of the ISR of the interrupt causing the wake-up. After that, the processor goes back to Sleep Mode. When the SLEEPEXIT bit is 0, the processor wakes up permanently (for the ISR and thereafter).

6.11.3 Cortex-M3 Deep Sleep Mode

In Deep Sleep Mode, the Cortex-M3 processor and memory are prevented from clocking and thus the code is no longer executing. The Main PLL, USB PLL, ASYSCLK to the Analog Subsystem, and input clock to the C28x CPU and Shared Resources are turned off. The gating for the peripheral clocks may change based on the ACG bit of the RCC register. When ACG = 0, the peripheral clock gating is used as defined by the RCGS registers (same as in Run Mode); and when ASC = 1, the clock gating comes from the DCGS register. RCGS and DCGS clock gating settings only apply to peripherals that are enabled in a corresponding DC register.

Peripheral clock frequency for the enabled peripherals in Deep Sleep Mode is different from the Run Mode. One of three sources for the Deep Sleep clocks (32KHZCLK, 10MHZCLK, or OSCLK) is selected with the DSOSCSRC bits of the DSLPCLKCFG register. This clock is divided-down according to DSDIVOVRIDE bits of the DSLPCLKCFG register. The output of this Deep Sleep Divider is further divided-down per the M3SSDIVSEL bits of the D3SSDIVSEL register to become the Deep Sleep Clock. If 32KHXCLK or 10MHZCLK is selected in Deep Sleep mode, the internal oscillator circuit (that generates OSCCLK) is turned off.

The Cortex-M3 processor should enter the Deep Sleep mode only after first confirming that the C28x is already in the STANDBY mode. Typically, just before entering the STANDBY mode, the C28x will record in the CLPMSTAT that it is about to do so. The Cortex-M3 processor can read the CLPMSTAT register to check if the C28x is in STANDBY mode, and only then should the Cortex-M3 processor go into Deep Sleep. The reason for the Cortex-M3 processor to confirm that the C28x is in STANDBY mode before the Cortex-M3 processor enters the Deep Sleep mode is that the Deep Sleep mode shuts down the clock to C28x and its peripherals, and if this clock shutdown is not expected by the C28x, unintended consequences could result for some of the C28x control peripherals.

Deep Sleep Mode is terminated by any properly configured interrupt event. Exiting from the Deep Sleep Mode depends on the SLEEPEXIT bit of the SYSCTRL register. When the SLEEPEXIT bit is 1, the processor will temporarily wake up only for the duration of the ISR of the interrupt causing the wake-up. After that, the processor goes back to Deep Sleep Mode. When the SLEEPEXIT bit is 0, the processor wakes up permanently (for the ISR and thereafter).

Table 6-26 Control Subsystem Low-Power Modes⁽¹⁾

6.12.1 C28x Normal Mode

In Normal Mode, the C28x processor, Local Memory, and C28x peripherals are clocked by the C28SYSCLK, which is derived from the C28CLKIN input clock to the C28x processor. The FPU, VCU, and PIE are clocked by the C28CPUCLK, which is also derived from the C28CLKIN. Timer 2 can also be clocked by the TMR2CLK, which is a divided-down version of one of three source clocks—C28SYSCLK, OSCCLK, and 10MHZCLK—as selected by the CLKCTL register. Additionally, the LOSPCP register can be programmed to provide a dedicated clock (C28LSPCLK) to the SCI, SPI, and McBSP peripherals.

Clock gating for individual peripherals is defined inside the CPCLKCR0,1,3 registers. Execution of the IDLE instruction stops the C28x processor from clocking and activates the IDLES signal. The IDLES signal is gated with two LPM bits of the CPCLKCR0 register to enter the C28x Subsystem into IDLE mode or STANDBY Mode.

6.12.2 C28x IDLE Mode

In IDLE Mode, the C28x processor stops executing instructions and the C28CPUCLK is turned off. The C28SYSCLK continues to run. Exit from IDLE Mode is accomplished by any enabled interrupt or the C28NMIINT (C28x nonmaskable interrupt).

Upon exit from IDLE Mode, the C28CPUCLK is restored. If LPMWAKE interrupt is enabled, the LPMWAKE ISR is executed. Next, the C28x processor starts fetching instructions from a location immediately following the IDLE instruction that originally triggered the IDLE Mode.

6.12.3 C28x STANDBY Mode

In STANDBY Mode, the C28x processor stops executing instructions and the C28CLKIN, C28CPUCLK, and C28SYSCLK are turned off. Exit from STANDBY Mode is accomplished by one of 64 GPIOs from the GPIO_MUX1 block, or MTOCIPCINT2 (interrupt from MTOC IPC peripheral). The wakeup GPIO selected inside the GPIO_MUX block enters the Qualification Block as the LPMWAKE signal. Inside the Qualification Block, the LPMWAKE signal is sampled per the QUALSTDBY bits (bits [7:2] of the CPCLKCR0 register) before propagating into the wake request logic.

Cortex-M3 should use CLPMSTAT register bits to tell the C28x to go into STANDBY mode before going into Deep Sleep mode. Otherwise, the clock to the C28x will be turned off suddenly when the control software is not expecting this clock to shut off. When the device is in Deep Sleep/STANDBY mode, wake-up should happen only from the Master Subsystem, because all C28x clocks are off (C28CLKIN, C28CPUCLK, C28SYSCLK), thus preventing the C28x from waking up first.

Upon exit from STANDBY Mode, the C28CLKIN, C28SYSCLK, and C28CPUCLK are restored. If the LPMWAKE interrupt is enabled, the LPMWAKE ISR is executed. Next, the C28x processor starts fetching instructions from a location immediately following the IDLE instruction that originally triggered the STANDBY Mode.

6.16.1 GPIO_MUX1

One-hundred and thirty-six pins of the GPIO_MUX1 block can be selectively mapped through corresponding sets of registers to all Cortex-M3 peripherals, to all C28x peripherals, to 136 General-Purpose Inputs, to 136 General-Purpose Outputs, or a mixture of all of the above. The first 64 pins of GPIO_MUX1 (GPIO0–GPIO63) can also be mapped to 12 ePWM Trip Inputs, 6 eCAP inputs, 3 External Interrupts to the C28x PIE, and the C28x STANDBY Mode Wakeup signal (LMPWAKE). Additionally, each GPIO_MUX1 pin can have a pullup enabled or disabled. By default, all pullups and outputs are disabled on reset, and all pins of the GPIO_MUX1 block are mapped to Cortex-M3 peripherals (and not to C28x peripherals).

Figure 6-15 shows the internal structure of GPIO_MUX1. The blue blocks represent the Master Subsystem side of GPIO_MUX1, and the green blocks are the Control Subsystem side. The grey block in the center, Pin-Level Mux, is where the GPIO_MUX1 pins are individually assigned between the two subsystems, based on how the configuration registers are programmed in the blue and green blocks (see Figure 6-16 for the configuration registers).

Pin-Level Mux assigns Master Subsystem peripheral signals, Control Subsystem peripheral signals, or GPIOs to the 136 GPIO_MUX1 pins. In addition to connecting peripheral I/Os of the two subsystems to pins, the Pin-Level Mux also provides other signals to the subsystems: XCLKIN and GPIO[S:A] IRQ signals to the Master Subsystem, plus GPTRIP[12:1] and GPI[63:0] signals to the Control Subsystem. XCLKIN carries a clock from an external pin to USB PLL and CAN modules. The 17 GPIO[S:A] IRQ signals are interrupt requests from selected external pins to the NVIC interrupt controller. The 12 GPTRIP[12:1] signals carry trip events from selected external pins to C28x control peripherals—ePWM, eCAP, and eQEP. Sixty-four GPI signals go to the C28x LPM GPIO Select block where one of them can be selected to wake up the C28x CPU from Low-Power Mode. One-hundred and thirty-six (136) GPI signals go to the C28x QUAL block where they can be configured with a qualification sampling period (see Figure 6-16).

The configuration registers for the muxing of Master Subsystem peripherals are organized in 17 sets (A–S), with each set being responsible for eight pins. The first nine sets of these registers (A–J) are programmable by the Cortex-M3 CPU via the AHB bus or the APB bus. The remaining sets of registers (K–S) are programmable by the AHB bus only. The configuration register for the muxing of Control Subsystem peripherals are organized in five sets (A–E), with each set being responsible for up to 32 pins. These registers are programmable by the C28x CPU via the C28x CPU bus. Figure 6-16 shows set A of the Master Subsystem GPIO configuration registers, set A of the Control Subsystem registers, and the muxing logic for one GPIO pin as driven by these registers.

Figure 6-14 GPIOs and Other Pins

Figure 6-15 GPIO_MUX1 Block

Figure 6-16 GPIO_MUX1 Pin Mapping Through Register Set A

For each of the 8 pins in set A of the Cortex-M3 GPIO registers, register GPIOPCTL selects between 1 of 11 possible primary Cortex-M3 peripheral signals, or 1 of 4 possible alternate peripheral signals. Register GPIOAPSEL then picks one output to propagate further along the muxing chain towards a given pin. The input takes the reverse path. See Table 6-27 and Table 6-28 for the mapping of Cortex-M3 peripheral signals to GPIO_MUX1 pins.

Similarly, on the C28x side, GPAMUX1 and GPAMUX2 registers select 1 of 4 possible C28x peripheral signals for each of 32 pins of set A. The selected C28x peripheral output then propagates further along the muxing chain towards a given pin. The input takes the reverse path. See Table 6-29 for the mapping of C28x peripheral signals to GPIO_MUX1 pins.

In addition to passing mostly digital signals, four GPIO_MUX1 pins can also be assigned to analog signals. The GPIO Analog Mode Select (GPIOAMSEL) Register is used to assign four pins to analog USB signals. PF6_GPIO38 becomes USB0VBUS, PG2_GPIO42 becomes USB0DM, PG5_GPIO45 becomes USB0DP, and PG6_GPIO46 becomes USB0ID. When analog mode is selected, these four pins are not available for digital GPIO_MUX1 options as described above.

Another special case is the External Oscillator Input signal (XCLKIN). This signal, available through pin PJ7_GPIO63, is directly tied to USBPLLCLK (clock input to USB PLL) and two CAN modules. XCLKIN is always available at these modules where it can be selected through local registers.