C5515 Boot-Image Programmer

Bootloader Features

The bootloader is a program that runs from ROM at power-on and loads a boot-image from a peripheral to the internal RAM of the C5515 DSP. It is always invoked after power-on-reset. Once the transfer is completed, the bootloader switches control to the user code so that it is automatically executed.

In order to ensure the code cannot be accessed and read outside of the system, only encrypted images can be boot from MMC/SD and USB. Both encrypted and non-encrypted images can boot from NAND, NOR, 16-bit SPI EEPROM, and I2C EEPROM.

The C5515 has a fixed order in which it checks for a valid boot-image on each supported boot device. The order is NOR Flash, NAND Flash, 16-bit SPI EEPROM, I2C EEPROM, MMC/SD, and USB. The first device with valid boot-image is used to load and execute the user code. If none of these devices has a valid boot-image, the bootloader goes into an endless loop checking for data received on the USB. If a valid boot image is received, it is used to load and execute user code. If no valid boot-image is received, the bootloader continues to monitor the devices.

The C5515 eZdsp only contains a NOR Flash memory, which supports both encrypted and non-encrypted boot images.

Creating a Non-Encrypted Boot Image

A boot image can be created using the hex conversion utility (hex55.exe) versions 4.3.5 or later. Earlier versions may not support the boot table features correctly.

The hex55.exe can be found in the directory path “<Install_Dir>\ccsv5\tools\compiler\c5500_4.4.1\bin”

NOTE: It is very important to make a copy of the hex55.exe file in the folder of the file to be converted, otherwise the DOS command will not work.

The most common DOS command for generating a non-encrypted boot image:

hex55 -i filename.out -o boot_image_file_name.bin -boot -v5505 -b -serial8

NOTE: The option -v5505 works for all C5515/35 family products. V5505 is the first device of this family.

NOTE: The option -serial8 is to specify the boot table is an 8-bit serial interface table.

How to program a boot image onto C5515 EVM

Once a boot image (*.bin) is generated, customers can burn the boot image into the NOR Flash, NAND Flash, 16-bit SPI EEPROM, I2C EEPROM, and MMC/SD card, on the C5515 EVM through a utility called programmer that runs on C5515 using an emulator with Code Composer Studio™ software.

The instructions stated below applies to the version of programmer in CSL 3.03 only

Choose the device...

1x - NAND Flash [CSx: 2,3,4,5]

2x - NOR Flash [CSx: 2,3,4,5]

3 - SPI EEPROM (16 bit address)

4 - IIC EEPROM

5 - MMC

6 - SD

7x - SPI Serial Flash (24 bit address) [PinMap x: 1=MODE5,2=MODE6]

8 - MCSPI Serial Flash

141C:\Userdata\C5515\Boot\cleaner.bin

NAND Flash...

Writing data to NAND...

Writing Sector 0...

Writing Sector 1 (MBR)...

Flushing Data...

Writing Boot Record...

Flushing Data...

Opening C:\Userdata\C5515\Boot\cleaner.bin...

Input file opened

Writing Boot-image to NAND...

Programming... [TotalSize=256 (0x100)]

Programming... [TotalSize=512 (0x200)]

Programming... [TotalSize=550 (0x226)]

Flushing Data...

done

• Note: NOR Flash must support the Flash reset command (0x00F0 on data) and return to the read array mode afterwards, NOR Flash should support the common flash memory interface (CFI).

221C:\Userdata\C5515\Boot\cleaner.bin

NOR Flash...

The Flash ID is 89, 8818, a2a5

Erasing chip (NOR)...

Writing data to device...

Opening C:\Userdata\C5515\Boot\cleaner.bin...

Input file opened

Programming Complete

• Note: Programming SPI is a bit tricky. SPI cannot be the first peripheral to access after a power up on C5515 EVM. Access either NOR or NAND before SPI. Boot image size is limited to 32kBytes max for this revision.

311C:\Userdata\C5515\Boot\cleaner.bin

SPI EEPROM...

Writing data to device...

Opening 1C:\Userdata\C5515\Boot\cleaner.bin...

Input file opened

Programming Complete

41C:\Userdata\C5515\Boot\cleaner.bin

IIC EEPROM...

Writing data to device...

Opening C:\Userdata\C5515\Boot\cleaner.bin...

Input file opened

Programming Complete

NOTE: There cannot be any white spaces in the file directory path or the program will not run correctly. Programmer will not be able to find the input file as it considers the white space the end of the input.

Please remember that the bootloader runs in a fix order of peripherals for boot image; that means all the previous Flash and EEPROM peripherals have to be properly cleaned. There is a cleaner file available at File:Cleaner.zip.

NOTE: Be sure to set the PLL clock frequency to 12.288 MHz in order for the I2C EEPROM to work properly. All other peripherals will also run at this frequency

Setting the PLL clock frequency

See Figure 4:

1. Use the c5505evm_pg20.gel in CSL303_0001/c55xx_csl/build folder or download the 5515evm.gel file available at File:5515evm.zip.
2. Under “View” menu in CCS, select “Target Configurations”
3. Double-click on the active target. The “Basic” configuration setup window will open.
4. Click on "Target Configuration" under “Advanced Setup”.
5. Click on the “C55xx” connection
6. Under "CPU Properties", click on “Browse” to select a different .gel file
7. Load either gel file from above and click "Save".
8. Launch the new Target Configuration. The “Scripts” menu in CCS should become available
9. Select Scripts>C5505EVM_Configuration>SetPLL_12p288MHz

How to program a boot image onto C5515 eZdsp

Figure 5

Figure 6

Once a boot image (*.bin) is generated, customers can burn the boot image into the NOR Flash memory of the C5515 eZdsp through a utility called programmer that runs on C5515 using an emulator with Code Composer Studio™ software.

First, load the programmer_c5515_eZdsp.out from File:Programmer C5515 eZdsp.zip using the Code Composer Studio as shown in Figure 5 by selecting “Load Program…” under the Target menu in CCS.

Next, run the program, when the user will be asked to input the filepath and filename for the boot image:

C5515 eZDSP...Input <filepath>

Figure 6 show how to program lednonencrypted.bin to the C5515 eZdsp using programmer_c5515_eZdsp.out.

NOTE: There cannot be any white spaces in the file directory path or the program will not run correctly. Programmer will not be able to find the input file as it considers the white space the end of the input.

Common Mistakes in Boot Image User Code

Relying on GEL File for initialization

A frequent issue is that the user code works fine in CCS environment but fails to work after converted to boot image. This is most likely because the user code relies on a GEL file in the CCS environment to initialize and setup PLL. This is easily corrected by not using GEL in CCS environment, but instead including all the necessary initialization steps in the user code. It is a good practice to re-initialize everything you need from within your bootloaded user code.

Example code to program PLL in user code:

   // Bypass the PLL as the system clock source
   asm("	*port(#0x1C1F) = #0x0 "); //Clock Configuration MSW reg
   //  program PLL to 100MHz with CLK_SEL = 0 
   asm("	*port(#0x1c20) = #0x8BE8 "); //PLL Control 1 reg
   asm("	*port(#0x1c21) = #0x8000 "); //PLL Control 2 reg
   asm("	*port(#0x1c22) = #0x0806 "); //PLL Control 3 reg
   asm("	*port(#0x1C23) = #0x0000 "); //PLL Control 4 reg	
   // wait at least 4 milli sec for PLL to lock
   asm("	repeat(0xC350)	"); 
   asm("		nop		")
   asm("	*port(#0x1c1F) = #0x0001 "); // Clock configuration MSW reg

Loading code into SARAM31

Another common mistake is allocating program code to SARAM31 memory. The bootloader writes to SARAM31 (CPU byte address 0x4E000 – 0x4FFFF) thus any user code residing in SARAM31 will be corrupted. Do not use SARAM31 if you intend to convert this code to a boot image. Once the bootloader has finished loading the program into RAM, SARAM31 can be used.

How to tell whether SARAM31 is used? Refer to the .cmd file in CCS project folder. The usable SARAM location is defined in the memory section. SARAM is resided in CPU byte address 0x010000 to 0x04FFFF, refer to memory block in data manual, and is partitioned into 32 blocks.

This is an example of SARAM31 is used. SARAM is defined as starting from 0x010000 with a lenght of 0x040000 which igoes all the way to 0x050000 which includes SARAM31 (CPU byte address 0x4E000 – 0x4FFFF)

MEMORY {

 PAGE 0:
   VEC(RX)   : origin = 0000100h length = 000100h
   SARAM(RW) : origin = 0010000h length = 040000h 

}

Ports idled by bootloader

By the time the bootloader releases control to the user code, all peripheral clocks will be off and all domains in the ICR, except the CPU domain, will be idled. This means that DMA and USB CDMA will not work until the MPORT is enabled. The HWAFFT will not work until HWA port is enabled. After the boot process is complete, the user is responsible for enabling and programming the required clock configuration for the DSP. This is the example code to enable the MPORT and disable the FFT HWA.

   // enable the MPORT and disable HWA
   *(volatile ioport Uint16 *)0x0001 = 0x020E;
   asm("   idle");

Software Tools Checklist

These are the required tools to test boot from flash or EEPROM:

1. hex55.exe to convert .out COFF file to binary.
2. programmer.out to download to flash and EEPROM.
3. CCS to run programmer.out.
4. 5515evm.gel to set the PLL frequency for the I2C EEPROM.
5. cleaner.bin file to erase previous boot images from peripherals.

Frequently Asked Questions

Q: How to bypass NOR boot in eZdsp?

• A: The bootloader device order is NOR Flash, NAND Flash, 16-bit SPI EEPROM, I2C EEPROM, and MMC/SD.
  • Remove R7 which supplies VDD_IO2 (power to NOR flash)
    • Will prevent bootloader from booting
    • Reconnect supply after connected in CCS to erase the flash
    • Don't recommend "hot switching" of VDD_IO2 but only way to erase NOR without hardware
  • Other methods to prevent booting from NOR
    • Short EM_CS2n to VDD_IO2 (3.3V) during boot to prevent chip select appearing low to NOR flash - short S29AL032 Pin 26 to R61, C4, or some other VDD_IO2, 3.3V node
    • Short VDD_IO2 to GND (cringe) - short C4 to GND
  • After device power is applied, wait a second then remove the short - bootloader will have gven up on the NOR flash and allow you to connect as it tries to perform UART/USB boot in an endless loop.