Emulation Boot

Introduction to Emulation Boot

This article explains how to setup the boot process for Piccolo 2802x, 2803x, and 2806x devices when an emulation controller is connected. It also includes frequently asked questions with regards to emulation boot.

Documentation

The boot process for these devices is described in more detail in the Boot ROM Reference Guide:

• 2802x Boot ROM Reference Guide sprufn6
• 2803x Boot ROM Reference Guide sprugo0
• 2806x Technical Reference Manual SPRUH18

Emulation Boot Setup

The boot ROM on these devices checks the state of the TRSTn pin to determine if an emulation controller is connected to the device.

Stand-alone boot

If an emulation controller is not connected (TRSTn == 0), then the boot ROM will use two GPIO pins to determine how to boot the device.

Emulation boot

If an emulation controller such as an XDS100 or XDS510 is connected (TRSTn == 1), then the boot ROM code will check two RAM locations to determine the boot mode. These locations are known as the EMU_KEY and EMU_BMODE and are located at memory address 0x0D00 and 0x0D01.

Using GEL to Set the Emulation Boot Mode

You can use the Code Composer Studio GEL file for the device to automatically setup the boot mode for the device during debug.

The "OnReset()" GEL function is called each time you reset the device. As supplied by TI this function includes a call to set the "boot to RAM" emulation mode when you reset the device.

 
OnReset(int nErrorCode)
{
    C28x_Mode();
    Unlock_CSM();
    Device_Cal();
    CLA_Clock_Enable();             /* Enable CLA clock - allows to debugger to set CLA breakpoints after reset */

    EMU_BOOT_SARAM();               /* Set EMU Boot Variables - Boot to SARAM */
//  EMU_BOOT_FLASH();               /* Set EMU Boot Variables - Boot to flash */

The GEL file also provides a function to set the boot mode to flash.

/********************************************************************/
/* EMU Boot Mode - Set Boot Mode During Debug                       */
/********************************************************************/
menuitem "EMU Boot Mode Select"
hotmenu EMU_BOOT_SARAM()
{
    *0xD00 =  0x55AA;  /* EMU_KEY = 0x 55AA */
    *0xD01 =  0x000A;  /* Boot to SARAM     */
}
hotmenu EMU_BOOT_FLASH()
{
    *0xD00 =  0x55AA;  /* EMU_KEY = 0x 55AA */
    *0xD01 =  0x000B;  /* Boot to FLASH     */
}

Running the Application From Flash

As supplied by TI the GEL file is configured for boot to RAM for emulation boot. This mode is helpful when running RAM only based examples. Once you move to debugging code in flash, you can use the GEL file to change the boot mode after you have connected the emulator. The sequence is as follows:

CCS v5.1

1. Connect the emulator (XDS100, XDS510, Blackhawk C2000USB, etc...)
2. Connect to the device using Code Composer Studio v5.1 or later.
3. Set the emulation boot to flash: Scripts->EMU Boot Mode Select->EMU_BOOT_FLASH'
4. Run->Reset->Reset CPU
5. Run->Resume

Alternatively, you can modify the GEL file so that it calls the appropriate boot mode in the OnReset() function.

To access and edit the GEL file use the Tools->GEL Files menu.

Note: Refer to this wiki article for more information on GEL

Selecting the Emulation Boot Mode from the GEL File

CCS v4.x

1. Connect the emulator (XDS100, XDS510, Blackhawk C2000USB, etc...)
2. Connect to the device using Code Composer Studio v4.x
3. Set the emulation boot to flash: Scripts->EMU Boot Mode Select->EMU_BOOT_FLASH
4. Target->Reset->Reset CPU
5. Target->Run

Alternatively, you can modify the GEL file so that it calls the appropriate boot mode in the OnReset() function.

To access the GEL file use the ''Tools->GEL Filesmenu.

Note: Refer to this wiki article for more information on GEL

Selecting the Emulation Boot Mode from the GEL File

CCS v3.3

1. Connect the emulator (XDS100, XDS510, Blackhawk C2000USB, etc...)
2. Connect to the device using Code Composer Studio v3.3
3. Set the emulation boot to flash: GEL->EMU Boot Mode Select->EMU_BOOT_FLASH
4. Debug->Reset CPU
5. Debug->Run

Alternatively, you can modify the GEL file so that it calls the appropriate boot mode in the OnReset() function.

Common Issues

• The EMU_BMODE and EMU_KEY mode locations are at the top location of the PIE vector table. Some example software may initialize these to either 0x0000 or an illegal trap vector location. This will cause issues if you take a reset without repopulating EMU_BMODE and EMU_KEY again with valid values. For a debugger reset the GEL file will take care of this. For a watchdog reset, however, it will cause the code to go into the WaitBoot mode.

For example, with the emulator connected, if:

1. The watchdog fires a reset
2. The boot ROM detects JTAG is connected and reads EMU_BMODE and EMU_KEY.
3. Both EMU_BMODE and EMU_KEY are invalid, so the boot ROM goes into a "WaitBoot" mode
4. WaitBoot includes an ESTOP0 instruction which will halt the PC within the boot ROM.

To avoid this issue, modify the code that initializes the PIE vector table such that it skips the EMU_BMODE and EMU_KEY locations.

Frequently Asked Questions

Q: Are 0x0D00 and 0x0D01 used by the PIE module?

No, these locations are reserved in previous devices and not used. On 2802x and 2803x they are only used for emulation boot mode.

Q: Why does my code stop at an ESTOP0 instruction in the boot ROM?

If your boot mode is set to "WaitBoot" the boot ROM will go into a loop around an ESTOP0 instruction. When the debugger gets connected, the PC will stop on the ESTOP0. Note: ESTOP0 is a software breakpoint.

Q: I changed my emulation boot to Flash, but I end-up at an ESTOP0 instruction

Because the boot mode at 0xD00 and 0xD01 was not properly set boot to flash code. See the Common Issues section.

Q: Why would I use GetMode() in emulation boot?

This can be used to follow the same flow as stand-alone code would. In other words if you select GetMode() the boot ROM will read the OTP contents just as it would in stand-alone mode to determine how to boot. This can help you determine if you OTP_KEY and OTP_BMODE are programmed correctly while in emulation boot.

Q: Are there differences between the SCI Boot selected by hardware ( GPIO pins ) and selected by software ( via GetMode())?

There is no difference. SCIBOOT using GPIOs and using GetMode() behaves the same (uses the same loader).

Note: Refer to the boot ROM documentation for the exact pins used on a particular device.

Stand-alone boot

SCI boot can be selected in two ways:

1. By configuring the boot mode GPIO(s): (TRSTn == 0 && GPIO37 == 0 && GPIO34 == 1) == SCI_BOOT
2. By Configuring the boot mode GPIO(s) for GetMode() and programming OTP_KEY==0x005A and OTP_BMODE==0x01.

Emulation boot

SCI boot can be selected in two ways:

1. By Configuring EMU_KEY and EMU_BMODE values to 0x55AA and 0x0001 respectively to select SCI_BOOT directly
2. By configuring EMU_KEY And EMU_BMODE to 0x55AA and 0x0003 to GetMode() from OTP_KEY and OTP_BMODE locations and programming OTP_KEY and OTP_BMODE to 0x005A and 0x01 respectively.

Q: I have programmed the OTP_KEY and OTP_BMODE for stand-alone boot. I want to test this in emulation boot. How can I do this?

Configure the EMU_KEU and EMU_BMODE for "GetMode()". In this case the OTP locations will be read to determine the boot mode just as they are in stand-alone boot.