Table 4-1 System Module Register Memory Map

4.2.1 Boot Modes Overview

The ARM ROM boot loader (RBL) executes when the BTSEL[2:0] pins indicate a condition other than the normal ARM EMIF boot.

• If BTSEL[2:0] = 001 - Asynchronous EMIF boot mode (NOR or OneNAND). This mode is handled by hardware control and does not involve the ROM. In the case of OneNAND, the user is responsible for putting any necessary boot code in the OneNAND's boot page. This code shall configure the AEMIF module for the OneNAND device. After the AEMIF module is configured, booting will continue immediately after the OneNAND’s boot page with the AEMIF module managing pages thereafter.
• The RBL supports 7 distinct boot modes:
  • BTSEL[2:0] = 000 - NAND Boot mode
  • BTSEL[2:0] = 010 - MMC0/SD0 Boot mode
  • BTSEL[2:0] = 011 - UART0 Boot mode
  • BTSEL[2:0] = 100 - USB Boot mode
  • BTSEL[2:0] = 101 - SPI0 Boot mode
  • BTSEL[2:0] = 110 - EMAC Boot mode
  • BTSEL[2:0] = 111 - HPI Boot mode
• If NAND boot fails, then MMC/SD mode is tried.
• If MMC/SD boot fails, then MMC/SD boot is tried again.
• If UART boot fails, then UART boot is tried again.
• If USB boot fails, then USB boot is tried again.
• If SPI boot fails, then SPI boot is tried again.
• If EMAC boot fails, then EMAC boot is tried again.
• If HPI boot fails, then HPI boot is tried again.
• RBL shall update boot status (PASS/FAIL) in MISC register bits 8 and 9 in System control module.
• ARM ROM Boot - NAND Mode
  • No support for a full firmware boot. Instead, copies a second stage user boot loader (UBL) from NAND flash to ARM internal RAM (AIM) and transfers control to the user-defined UBL.
  • Support for NAND with page sizes up to 4096 bytes.
  • Support for magic number error detection and retry (up to 24 times) when loading UBL
  • Support for up to 30KB UBL (32KB IRAM - ~2KB for RBL stack)
  • Optional, user-selectable, support for use of DMA and I-cache during RBL execution (i.e.,while loading UBL)
  • Supports booting from 8-bit NAND devices (16-bit NAND devices are not supported)
  • Uses/Requires 4-bit HW ECC (NAND devices with ECC requirements ≤ 4 bits per 512 bytes are supported)
  • Supports NAND flash that requires chip select to stay low during the tR read time
• ARM ROM Boot - MMC/SD Mode
  • No support for a full firmware boot. Instead, copies a second stage User Boot Loader (UBL) from MMC/SD to ARM Internal RAM (AIM) and transfers control to the user software.
  • Support for MMC/SD Native protocol (MMC/SD SPI protocol is not supported)
  • Support for descriptor error detection and retry (up to 24 times) when loading UBL
  • Support for up to 30KB UBL (32KB - ~2KB for RBL stack)
  • SDHC boot supported by RBL
• ARM ROM Boot - UART mode
  • If the state of BTSEL[2:0] pins at reset is 011, then the UART boot mode executes. This mode enables a small program, referred to here as a user boot loader (UBL), to be downloaded to the on-chip ARM internal RAM via the on-chip serial UART and executed. A host program, (referred to as serial host utility program), manages the interaction with RBL and provides a means for operator feedback and input. The UART boot mode execution assumes the following UART settings: 24 MHz reference clock, Time-Out 500 ms, one-shot Serial RS-232 port 115.2 Kbps, 8-bit, no parity, one stop bit Command, data, and checksum format Everything sent from the host to the device UART RBL must be in ASCII format
  • No support for a full firmware boot. Instead, loads a second stage user boot loader (UBL) via UART to ARM internal RAM (AIM) and transfers control to the user software.
  • Support for up to 30KB UBL (32KB - ~2KB for RBL stack)
• ARM ROM Boot – USB Mode
  • No support for a full firmware boot. Instead, loads a second stage User Boot Loader (UBL) via USB to ARM Internal RAM (AIM) and transfers control to the users software.
• ARM ROM Boot – SPI Mode
  • The device will copy UBL to ARM Internal RAM (AIM) via SPI interface from a SPI peripheral like SPI EEPROM. RBL will then transfer control to the UBL.
• ARM ROM Boot – EMAC Mode
  • The device will send a boot request packet and the host/server will respond with the boot packets. RBL will wait for all boot packets to arrive and then transfer control to the UBL which is received via boot packets. In EMAC boot mode an I2C EEPROM or SPI EEPROM is necessary for programming EMAC descriptor (including EMAC address for the device)

  Note: If a magic number is not found in the EEPROM, then the EMAC boot mode will use a default MAC address. In this case, there will be no magic number support.

• ARM ROM Boot – HPI Mode
  • The Host will copy UBL to ARM Internal RAM (AIM) via HPI interface and notify the ROM bootloader after copy is finished. RBL will then transfer control to the UBL.

The general boot sequence is shown in Figure 4-1. For more information, see the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

Figure 4-1 Boot Mode Functional Block Diagram

4.3.1 Overview

The device requires one primary reference clock. The reference clock frequency may be generated either by crystal input or by external oscillator. The reference clock is the clock at the pins named MXI1/MXO1, and which drives two separate PLL controllers (PLLC1 and PLLC2). PLLC1 generates the clocks required by the ARM, EDMA, VPSS and the rest of the peripherals. PLL2 generates the clock required by the DDR PHY interface and is also capable of providing clocks to the ARM, USB, Video, or Voice Codec modules and a flexible clocking option. Figure 4-2 represents the clocking architecture for the ARM subsystem. For more information on device clocking and the system PLL controller, see the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

Figure 4-2 Clocking Architecture

4.3.2 PLL Controller Module

Two PLL controllers provide clocks to different components of the chip. The PLL controller 1 (PLLC1) provides clocks to most of the components of the chip. The PLL controller 2 (PLLC2) provides clocks to the DDR PHY and is also capable of providing clocks to the ARM, USB, VPSS or the Voice Codec modules instead as well.

As a module, the PLL controller provides the following:

• Glitch-free transitions (on changing PLL settings)
• Domain clocks alignment
• Clock gating
• PLL bypass
• PLL power down

The various clock outputs given by the PLL controller are as follows:

• Domain clocks: SYSCLKn
• Bypass domain clock: SYSCLKBP
• Auxiliary clock from reference clock: AUXCLK

Various dividers that can be used are as follows:

• Pre-PLL divider: PREDIV
• Post-PLL divider: POSTDIV
• SYSCLK divider: PLLDIV1, …, PLLDIVn
• SYSCLKBP divider: BPDIV

The Multiplier values supported are handled by:

• PLL multiplier control: PLLM

Notes:

• PLLCxSYSCLKy is used to denote post divide clock output SYSCLKy from PLL controller x
• 'x', which denotes PLL Controller number, can assume values 1 and 2
• 'y', which denotes post divide clock outputs, can assume values 1 to 9 in case of PLLC1 and 1 to 5 in case of PLLC2

The PLL Controllers for PLL1 and PLL2 are described in detail in the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

4.3.3 PLLC1

There are two PLLs on the device, and they are independently controlled. PLLC1 generates the frequencies needed for the ARM, Video Processing Sub System (VPSS), MJCP coprocessor block, EDMA, and peripherals.

The reference clock for both PLLs is the single crystal input. Both PLLs will be of the same type . It should be noted that the USB2.0 PHY contains a third PLL embedded within it. The following list, Table 4-2, and Figure 4-3 describe the customization of PLLC1.

• Provides primary system clock
• Software configurable
• Accepts clock input or internal oscillator input
• PLL pre-divider value is programmable
• PLL multiplier value is programmable
• PLL post-divider value is programmable. See the data manual for all supported configurations.
• Only SYSCLK [9:1] are used

Figure 4-3 PLLC1 Configuration

4.3.4 PLLC2

PLLC2 provides the USB reference clock, ARM926EJ-S, DDR 2x clock, Voice Codec clock and VENC 27MHz, 74.25MHz clock. The PLLC2 functionality can be programmed via the PLLC2 registers. The following list, Table 4-3, and Figure 4-4 describe the customization of PLLC2.

The PLLC2 customization includes the following features:

• PLLC2 provides DDR PHY, USB reference clock , ARM926EJ-S clock, VENC 27MHz, 74.25Hz clock and Voice codec clock
• Software configurable
• Accepts clock input or internal oscillator input (the same input as PLLC1)
• PLL pre-divider value is programmable
• PLL multiplier value is programmable
• PLL post-divider value is programmable
• Only SYSCLK [5:1] are used

Figure 4-4 PLLC2 Configuration

4.3.5 Processing, Video, EDMA and DDR EMIF Subsystems Maximum Operating Frequencies

shows the maximum speeds supported for each of the major blocks supported on the different speed grade devices.

4.3.6 PLL Controller Clocking Configurations Examples

Like the DM365, the DM369 uses two PLLs to generate the two fundamental clocks used on the device. These two clocks feed two divider blocks which generate all of the functional clocks used by the peripherals and cores in the DM369. The ARM926 and DDR peripheral in the DM369 are limited to a maximum clock frequency of 432 MHz and 340 MHz respectively. There are some peripheral clocks on the DM369 which are required to operate at a specific frequency by functional specification or convention. These frequencies are detailed in Table 4-5.

While it is possible to generate both a 432 MHz and 340 MHz clock with the two PLLs, these two frequencies cannot be divided down to generate all required frequencies from Table 4-5. Several different frequency solutions are required to cover all of these requirements. The different solutions for different input crystal frequencies are listed in the tables below.

The following tables show examples of the PLL combinations that can be supported with DM369. Please see the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5) for additional details on special peripherals clocking considerations and for additional PLL controller configuration details.

There are several important points to note from these tables.

• A 432 MHz functional clock will result in DM369 voice codec sampling frequency of 16.07KHz. The difference of 0.4375% versus 16KHz specification should be acceptable for the majority of audio applications. If the DM369 voice codec is required to operate at precisely 16 kHz then the functional clock can be reduced to achieve precisely that sample frequency but the ARM926 and HDVICP will have to run at a reduced rate resulting in lower video performance.
• If a 24 MHz input crystal is used it is not possible to generate a 74.25 MHz HD video output clock.
• If a 19.2 MHz input crystal is used it is not possible to generate a valid 74.25 MHz HD output clock.

For maximum H.264 encode performance the ARM must run at 432 MHz and the DDR at 340 MHz. Any speed decrease to either of these will reduce encode performance. This means that if the ARM speed must be reduced to enable another function it will impact the encode performance.

If USB is required then a 36 MHz, 24 MHz or 19.2 MHz input crystal is preferred as those can support USB at full ARM rate.

If a video output is needed then a 36 MHz, 27 MHz or 24 MHz input crystal should be used. For HD video output it may be preferred to use the EXTCLK input to inject an external 74.25 MHz clock and at the same time operate the ARM at 432 MHz.

4.3.7 Peripheral Clocking Considerations

The device supports several peripherals with special clocking considerations (VPBE, USB, Key Scan, ADC, Voice Codec, MJCP, HDVICP, AUXCLK, DDR2 EMIF). For more detail on these special considerations, see the Peripheral Clocking Considerations section of the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

Table 4-10 Peripheral Pin Mux Overview

Table 4-11 Reset Types

4.7.1 Device Configuration Pins

The device configuration pins are described in Table 4-12. The device configuration pins are latched at reset and allow you to configure all of the following options at reset:

• ARM Boot Mode
• Asynchronous EMIF pin configuration

These pins are described further in the following sections.

Note: The device configuration pins are multiplexed with AEMIF pins. After the device configuration pins are sampled at reset, they automatically change to function as AEMIF pins. Pin multiplexing is described in Section 4.5.

4.7.2 PLL Configuration

After POR, warm reset, and max reset, the PLLs and clocks are set to their default configurations. The PLLs are in bypass mode and disabled by default. This means that the input reference clock at MXI1 (typically 24 MHz) drives the chip after reset. For more information on device clocking, see Section 4.3 . The default state of the PLLs is reflected in the default state of the register bits in the PLLC registers. See the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

4.7.3 Power Domain and Module State Configuration

Only a subset of modules are enabled after reset by default. Table 4-13 shows which modules are enabled after reset. Table 4-13 shows that the following modules are enabled depending on the sampled state of the device configuration pins. For example, if UART boot mode is BTSEL[2:0] = 011, then the default state of the UART module is enabled. For more information on module configuration, see the TMS320DM36x DMSoC ARM Subsystem User's Guide (SPRUFG5).

4.7.4 ARM Boot Mode Configuration

The ARM can boot from either Asynchronous EMIF (OneNand/NOR) or from ARM ROM, as determined by the setting of the device configuration pins BTSEL[2:0]. The boot selection pins (BTSEL[2:0]) determine the ARM boot process. After reset (POR, warm reset, or max reset), ARM program execution begins in ARM ROM at 0x0000: 8000, except when BTSEL[2:0] = 001, indicating AEMIF (OneNand/NOR) flash boot.

Boot modes are further described in Section 4.2.

4.7.5 AEMIF Configuration

4.7.6 Oscillator Frequency Configuration

The oscillator input pins, MXI1, MXO, are designed to operate in two frequency ranges depending on the GIO81(OSCCFG) pin sampled at reset, which should be set according to the required input frequency of operation. See Table 4-15 for details.

The frequency selection pin cannot be changed dynamically while the oscillator is running. They should only be set once before oscillator startup.

The GIO81(OSCCFG) state is latched during reset, and it specifies the oscillation frequency mode as shown in Table 4-15.

4.8.1 Pullup/Pulldown Resistors

Proper board design should ensure that input pins to the DMSoC device always be at a valid logic level and not floating. This may be achieved via pullup/pulldown resistors. The DMSoC features internal pullup (IPU) and internal pulldown (IPD) resistors on most pins to eliminate the need, unless otherwise noted, for external pullup/pulldown resistors.

An external pullup/pulldown resistor needs to be used in the following situations:

• Boot and Configuration Pins: If the pin is both routed out and 3-stated (not driven), an external pullup/pulldown resistor is strongly recommended, even if the IPU/IPD matches the desired value/state.
• Other Input Pins: If the IPU/IPD does not match the desired value/state, use an external pullup/pulldown resistor to pull the signal to the opposite rail.

For the boot and configuration pins, if they are both routed out and 3-stated (not driven), it is strongly recommended that an external pullup/pulldown resistor be implemented. Although, internal pullup/pulldown resistors exist on these pins and they may match the desired configuration value, providing external connectivity can help ensure that valid logic levels are latched on these device boot and configuration pins. In addition, applying external pullup/pulldown resistors on the boot and configuration pins adds convenience to the user in debugging and flexibility in switching operating modes.

Tips for choosing an external pullup/pulldown resistor:

• Consider the total amount of current that may pass through the pullup or pulldown resistor. Make sure to include the leakage currents of all the devices connected to the net, and any internal pullup or pulldown resistors.
• Decide a target value for the net. For a pulldown resistor, this should be below the lowest V_IL level of all inputs connected to the net. For a pullup resistor, this should be above the highest V_IH level of all inputs on the net. A reasonable choice would be to target the V_OL or V_OH levels for the logic family of the limiting device; which, by definition, have margin to the V_IL and V_IH levels.
• Select a pullup/pulldown resistor with the largest possible value; but, which can still ensure that the net will reach the target pulled value when maximum current from all devices on the net is flowing through the resistor. The current to be considered includes leakage current plus, any other internal and external pullup/pulldown resistors on the net.
• For bidirectional nets, there is an additional consideration which sets a lower limit on the resistance value of the external resistor. Verify that the resistance is small enough that the weakest output buffer can drive the net to the opposite logic level (including margin).
• Remember to include tolerances when selecting the resistor value.
• For pullup resistors, also remember to include tolerances on the DV_DD rail.

For most systems, a 1-kΩ resistor can be used to oppose the IPU/IPD while meeting the above criteria. Users should confirm this resistor value is correct for their specific application.

For most systems, a 20-kΩ resistor can be used to compliment the IPU/IPD on the boot and configuration pins while meeting the above criteria. Users should confirm this resistor value is correct for their specific application.

For more detailed information on input current (I_I), and the low- andhigh-level input voltages (V_IL and V_IH) for the device, see Table 6-2, Recommended Operating Conditions.

For the internal pullup/pulldown resistors for all device pins, see the peripheral/system-specific terminal functions table.