The boot sequence of Concerto 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 through 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.
|BOOT MODE #||MASTER SUBSYSTEM BOOT MODES||PF2_GPIO34
|0(2)||Boot from Parallel GPIO||0||0||0||0|
|1(2)||Boot to Master Subsystem RAM||0||0||0||1|
|2(2)||Boot from Master Subsystem serial peripherals (UART0/SSI0/I2C0)||0||0||1||0|
|3(2)||Boot from Master Subsystem CAN interface||0||0||1||1|
|4(2)||Boot from Master Subsystem Ethernet interface||0||1||0||0|
|5(2)(4)||Not supported (Defaults to Boot-to-Flash), future boot from Cortex-M3 USB||0||1||0||1|
|7(2)(4)||Boot to Master Subsystem Flash memory||0||1||1||1|
|8||Not supported (Defaults to Boot-to-Flash)||1||0||0||0|
|9(4)||Boot from Master Subsystem serial peripheral – SSI0 Master||1||0||0||1|
|10(4)||Boot from Master Subsystem serial peripheral – I2C0 Master||1||0||1||0|
|11(4)||Not supported (Defaults to Boot-to-Flash)||1||0||1||1|
|12(3)||Boot from Master Subsystem Ethernet interface||1||1||0||0|
|13(4)||Not supported (Defaults to Boot-to-Flash)||1||1||0||1|
|14(4)||Not supported (Defaults to Boot-to-Flash)||1||1||1||0|
|15(4)||Boot to Master Subsystem Flash memory||1||1||1||1|
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 JTAG debug probe 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. 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 JTAG debug probe. 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.
|BOOT_FROM_RAM||0x0000 0001||Upon receiving this command from the Master Subsystem, C-Boot ROM will branch to the Control Subsystem RAM entry point location and start executing code from there.|
|BOOT_FROM_FLASH||0x0000 0002||Upon receiving this command, C-Boot ROM will branch to the Control Subsystem FLASH entry point and start executing code from there.|
|BOOT_FROM_SCI||0x0000 0003||Upon receiving this command, C-Boot ROM will boot from the Control Subsystem SCI peripheral.|
|BOOT_FROM_SPI||0x0000 0004||Upon receiving this command, C-Boot ROM will boot from the Control Subsystem SPI interface.|
|BOOT_FROM_I2C||0x0000 0005||Upon receiving this command, C-Boot ROM will boot from the Control Subsystem I2C interface.|
|BOOT_FROM_PARALLEL||0x0000 0006||Upon receiving this command, C-Boot ROM will boot from the Control Subsystem GPIO.|
|BOOT_FROM_SPI(1)||0x0000 0007||Upon receiving this command, C-Boot ROM will boot from the Control Subsystem SPI interface.|
The boot process can be considered completed once the Cortex-M3 and C28x are both running out of their respective application programs. 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.