C5000 DSP FAQ

Which applications are a good fit for 55x DSP

The 55x DSP core from TI combines low power with processing efficiency. It is capable of single-cycle dual-MAC and features excellent code density due to its variable length instruction set. It is a good fit in products that require a good mix of low power and solid performance.

What tools are available for development?

Development is usually done using the Code Composer Studio (CCS) integrated development environment (IDE). CCS comes bundled with the 55x compiler as well as a chip support library (CSL) and DSP library.

Typically an evaluation board is used for initial software development.

Several are available at the Spectrum Digital Support page under C5000 Family.

You can use the XDS100 with the 55x and Code Composer Studio v4

You can also write C55xx DSP core software by using the C55xx Simulators.

An example how to set CCSv41 for C5505 CPU Cycle Accurate Simulator can be found here

Q: What tools versions do you usually use for development of C5000 SW?

• A: As of Sept 2012, the C5000 SW team will be transitioning to the following tools:
  • SW: Code Composer Studio version 5.2.1 with compiler version 4.3.9
• A: As of Nov 28, 2011, the C5000 SW development team primarily use are:
  • HW: 5515 EVM C5515#EVM
  • SW: Code Composer Studio version 4.2.4 with compiler version 4.3.9 and DSP/BIOS version 5.41.10.36
    • Note these are available from: DSP/BIOS Download Page and Compiler Releases
• A: Please check the release notes for the SW products you are using for tools versions.

Where can I find examples that will configure the DSP and its peripherals for off-chip communication?

Check out the C5000 Chip Support Library page for more information.

What are the CPU versions for the different Silicon versions of the C55x devices?

Please click here to see our application note on various Silicon versions, CPU versions and corresponding compile options to be used for the C55x devices.

Does 55x have a unified address map?

Sort of:

• Program/Data
• I/O (peripheral space)

The 55x has a unified address map in the sense that the code and data reside in the same physical RAM. However, that RAM is byte addressable for code and word (16 bit) addressable for data. See the "byte vs word" FAQ for more info.

What's the deal with byte addressing vs word addressing?

Bottom line:

• CPU data accesses are all word (16-bit) accesses, i.e. MAU=16-bit
• CPU program accesses are all byte (8-bit) accesses, i.e. MAU=8-bit

When accessing program space (i.e. CPU executing an instruction) it utilizes a byte address. When accessing data space (i.e. CPU reading a variable in RAM) it utilizes a 16-bit address. As an example let's consider the case of locating code at the beginning of the DARAM4 block on a 5502. This would correspond to byte address 0x8000. If instead we located a data array at that same place it would be accessed at address 0x4000 (i.e. byte_addr >> 1).

When I write my linker command file should I use byte addresses or word addresses?

Everything in the linker command file should use byte addresses.

The linker will then assign addresses based on whether it is code or data. Labels corresponding to code are given a byte address while labels corresponding to data are given a data address. This is shown in the map file which the linker outputs.

55x faq linker.png

How do I read and write binary files on the C5000? / How do I use fread/fwrite on the C55?

• A: See: Fread and Write (file I/O) on the C5000

How do I access peripheral registers?

To access the peripheral address space you need to use the ioport keyword. This tells the compiler to generate the appropriate instructions to access I/O space.

<syntaxhighlight lang="c"> volatile ioport unsigned short int* pDMACSR1; // declare pointer to DMACSR1 register

pDMACSR1 = (unsigned short int*)0x0C23; // assign the register address to the pointer

DMACSR1 = *pDMACSR1; // clears CSR (by reading it) </syntaxhighlight>

Why can I not correctly move data that spans a 64K-word boundary?

This applies to all devices that use the 55x Rev 2.x core (5510A, 5509A, 5507, 5506, 5503, 5502, 5501). The A-unit inside the CPU that does the arithmetic associated with any address mode only operates on the lower 16-bits of the address registers. For example, when doing an auto-increment of a 23-bit XARn it only modifies the 16-bit ARn portion of the register causing the address to wrap if crossing a 64K-word boundary.

Due to this hardware limitation, the linker generates an error if any data section (though not a code section) spans a 64k-word boundary. This protects the user against most cases where it would be an issue.

Resolving linker errors due to data spanning 64k-word boundaries

• Determine which section is causing an issue.
• Check the size of the section. If it is bigger than 64k words you will need to break up the section.
• If it is less than 64k you will need to force the linker to allocate the section inside a 64k-word aligned block. This can be achieved using the block keyword which will bump the section's start address up to the next aligned boundary if the section will not fit in the current block aligned to the given size. (Note that for sections greater than 64k words the block keyword merely forces the section to start on a 64k-word boundary, but since the section is greater than 64k of course this will not solve the problem.) Here is an example of how to use the block keyword:

   .cinit: block(0x20000)  {} > SARAM

Despite the fact that the linker actively tries to prevent this issue, there are still rare cases where this issue pops up. Generally this occurs when programmers start manually manipulating pointers to memory. In particular you might very well run into this issue if you are using memory overlays for run-time relocation of code. In that case you generally define load and run addresses in the linker command files and relocate the code at run-time (e.g. from external memory to internal memory). In this scenario your code in external memory or internal memory might very well span a 64k boundary. However, the linker will not give a warning because it's ok for code to span these boundaries. However, when you are in the process of copying the code from external memory to internal memory the code is actually being treated like data and so the 64k boundary issue can pop up.

Ways of working around the 64k boundary issue

• Use DMA to move the data.
• Write a less optimal copy function that is "boundary safe". For example, in Large or Huge Memory Model force address arithmetic to be done in more than 16 bits by casting the addresses to 32-bit integers, doing the arithmetic, and casting back to pointers to do the memory accesses.

<syntaxhighlight lang="c"> {

 uint32_t src, dst, x;
 ...
 // Copy CNT bytes without worrying about 64k boundaries for src and dst pointers
 for(x = 0; x < CNT; x++) {
     *(uint16_t*)dst++ = *(uint16_t*)src++;
 }

} </syntaxhighlight>

How do I program the address of my data in the DMA?

The DMA "sees" memory as byte addresses, so if you are referencing an array you need to do appropriate shifting to give a byte address. For example, if you have declared an array data_buf[] and wanted to use it as a source address you would write code something like this:

<syntaxhighlight lang="c"> // SET THE DMA SOURCE ADDRESSES dma0.dmacssal = (DMA_AdrPtr)(((unsigned long int)data_buf)<<1); dma0.dmacssau = (unsigned short int)(((unsigned long int)data_buf)>>15); </syntaxhighlight>

How do I change stack modes?

Short answer:

• Create a new interrupt vector table with the appropriate mode encoded into the reset vector.
• Modify IVPD/IVPH to point to that table.
• Execute a software reset instruction.
• See this example code.

Long answer:

The 55x has 3 stack modes as documented in Section 4.2 (Stack Configurations) of the 55x CPU Reference Guide. When the device comes out of reset the CPU registers IVPD and IVPH are set to 0xFFFF which causes them to fetch the reset vector from 0xFFFF00. That address corresponds to the boot ROM on devices shipping today. So the decision as to how the reset vector should be configured was made at the creation of the boot ROM. When the CPU comes out of reset and fetches that vector from the boot ROM the stack mode gets set.

You can create a new vector table and modify IVPD and IVPH to point to the vector table. However, in order for the CPU to "read" your stack configuration which is embedded in the reset vector you need to execute a soft reset. This will cause the CPU to branch to the address in the reset vector (e.g. _c_int00) and to set its stack mode based on the embedded value.

Why am I getting a bunch of linker errors such as, "can't find input file 'bios5510.a55'" when I build my BIOS project?

By default in CCS 3.3 when you create a new 55x project it will default to "small memory model". Also, when you create a new BIOS configuration for 55x it will also default to "small memory model". However, BIOS does not ship libraries for small memory model! To solve the issue you must change both your compiler options and your BIOS configuration to use "large memory model".

• Go to Project -> Build Options -> Compiler -> Advanced and select Memory Model as "Large (-ml)".
• In your BIOS configuration file (*.tcf) go to System -> Global Settings -> (right click) Properties. Choose Memory Model as LARGE.

Note that small memory model severely constrains your memory usage in that all data must be confined to a single 64k-word page. Whether you use BIOS or not it is generally a good idea to select the large memory model for your compiler build options.

As of BIOS 5.33.05 the new default for 55x configuration files is the large memory model. As of CCS 4.0 the new project default for 55x is also large memory model.

How are the bus keepers implemented on GPIO A.x lines and how do they work under different configurations?

Background: The C5500 EMIF is configured in Data-only mode. The GPIO A.x (EMIF address bus) lines are used to control external logic or peripherals. Applies to C5503, C5506, C5507, C5509A.

Answer: The buskeeper is implemented as shown in the diagram below. The resistor values are adjusted from device to device. This implementation is for the TMS320VC33 and is obtained from the data manual

Buskeeper Circuit.jpg

The "main buffer" is a strong driver (mA range) that shown here controlled by the R/W-. The bus keeper is a weak driver (uA range) that is controlled here by the SHZ-.

Here is a truth table that defines how the bus keepers will operate:

 SHZ-	               R/W-   Internal   External Data Bus Pin (w/o pull-up)
                            Data Bus
0   (BK disabled)	0	0	Driven to 0 by the main buffer
0   (BK disabled)	0	1	Driven to 1 by the main buffer
0   (BK disabled)	1	X	Hi-Z (output voltage will go to some intermediate voltage between the rails)
1   (BK enabled)	0	0	Driven to 0 by the main buffer (bus keeper follows the main buffer)
1   (BK enabled)	0	1	Driven to 1 by the main buffer (bus keeper follows the main buffer)
1   (BK enabled)	1	X	Bus keeper weakly holds the state of the pin at the last state that was
                                       driven either by the main buffer or y the external world.

Can you show me some CCSv41 configurations?

An example how to set CCSv41 for C5505 CPU Cycle Accurate Simulator can be found here .

An example how to setup the C5505 USB Stick under CCSv41 can be found here .

How do I use Software Breakpoint (estop_1) to debug my code?

In addition to setting SW breakpoints in Code Composer Studio by double clicking on a line of code, there are some other uses for this feature. The SW breakpoint is actually an instruction that gets embedded in your application by CCS by swapping out the instruction where the BP is being set. This is why the SW breakpoint can only be used in RAM memory. The SW breakpoint instruction is ESTOP_1 in mnemonic or ESTOP_1() in algebraic (op code: 0x460c) which stands for emulation stop. Here are some additional uses you can make of this instruction:

1. Embed instruction in your code to stop execution at a particular address. Works for RAM or Flash.
2. Fill all unused memory in your system with the op code to make it easier to debug when execution does not flow as you intended. You can do this with the linker or by manually adding this in CCS with Memory Fill command. This technique only works in RAM memory.

What is the difference between the Small, Large and Huge memory models?

The memory model defines how data memory is accessed.

Small Memory Model: (rts55.lib) 16 bit data address is used for data access.

Large Memory Model: (rts55x.lib) 23-bit data address is used, but there is memory boundary limitation. The offset address should be within 64K. If offset address goes over 64K, it will be wrapped around.

Huge Memory Model: (rts55h.lib) 23-bit data address without the 64K boundary limit. For v3.x CPU only.

Is the Device Driver Kit (DDK) still supported for C5000?

Q: App note SPRA856 references a software package called Device Driver Kit (DDK). I can't locate this package. How can I find it?

A: The DDK is no longer supported for the C5000 family. It was based off an old version of DSP BIOS which has been superceded. The closest software we have today is the Chip Support Library (CSL). It is not full driver implementation like previous DDK. You can access the CSL package here: Chip Support Library down load page.

What does emulation error 0x80001240/-1062 mean? I get this trying to connect to target board

Typically, this message is generated when the emulator sees a low level on TVD pin of emulator JTAG interface. TVD is target voltage detect. Pin 5 on the 14-pin header, it might also be referred to as VTref. Essentially, this is the first thing that the emulator checks for and if there is no voltage detected, it considers the target to be unpowered.

Our Documentation calls for a 100 ohm current limiting resistor on TVD/VTref. For more details see:

XDS Target Connection Guide

If you have a larger pull-up on TVD rather than a small current limiting resistor the XDS may get confused. There have been cases with some emulators where a target board gets designed with the size of current limiting resister just at the right value (~1K ohms), where it will work sometimes and other times it will fail and report target voltage failure.

Why am I getting a "Syntax Error" and "Invalid Mnemonic Specified" when creating a new project on CCSv4 after including the CSL library?

In order to avoid such an error please rebuild CSL with the following compiler option enabled:

1) Go to "Runtime Model Options" tab in the C/C++ Build options of the project.

2) Check "Codegen outputs algebraic assembly".

3) Select assembly source language to "algebraic" instead of "mnemonic" which was a cause of the error you've got due to the source files of CSL was written using algebraic assembly.

4) Rebuid the project with the new parameters.

Assembly Code Review Checklist

C55 Assembly Code Review Checklist

Where can I find help for C55x Common Errors and Fixes?

See C55x_Common_Errors_and_Fixes

Is SYS/BIOS Supported on the 55x?

• There are no plans at this time for support of SYS/BIOS on the 55x. (Last updated October 2011).
• DSP/BIOS 5.xx is supported and used by a large majority of 55x customers.

Q: What Kind of Flash Memory can be used with the C55x?

• A: Please check the EVM or EZDSP reference designs.
• A For C5535 booting from SPI Serial Flash, see C5532/33/34/35_FAQ#Q:_What_Serial_Flash_memories_are_compatible_with_C5535.2F34.2F33.2F32_devices.3F
• A: For 5515/5535 and similar parts you can use:
  • SST Flash

Q: Where can I learn how to port 54x code to the 55x?

• A: 54x to 55x Code Migration Guide
• A: Check the Assembly tools Guide chapter 6: "Running 54x code on 55x".

How to change the CLKIN on the C5515 eZdsp from 32KHz RTC Clock to 12MHz external clock

Modify the board:

CLK_SEL needs to be high to select the external 12MHz clock

• Remove R50
• Short together R51 (use solder to make a 0ohm connection)

CLKIN needs to select the 12MHz clock from U10

• Remove R54
• Short together R53

For debug purposes, the CLKOUT pin can be used to tap different clocks within the DSP clock generator. The SRC bits in the CLKOUT Control Source Register (CCSSR) can be used to specify the CLKOUT pin source. Additionally, the slew rate of the CLKOUT pin can be controlled by the Output – Slew Rate Control Register (OSRCR) [0x1C16].

CLKOUT Control Source Register (CCSSR) [0x1C24@IO] - specify the CLKOUT pin source Bits 3-0 SRC: CLKOUT source bits. These bits specify the source clock for the CLKOUT pin.

- 0h CLKOUT pin outputs System PLL output clock, PLLOUT.
- 1h CLKOUT pin is set high.
- 2h CLKOUT pin outputs System PLL output clock, PLLOUT.
- 3h CLKOUT pin is set low.
- 4h CLKOUT pin outputs System PLL output clock, PLLOUT.
- 5h CLKOUT pin is set low.
- 6h CLKOUT pin outputs System PLL output clock, PLLOUT.
- 7h CLKOUT pin outputs USB PLL output clock.
- 8h CLKOUT pin outputs System PLL output clock, PLLOUT.
- 9h CLKOUT pin outputs SAR clock.
- Ah CLKOUT pin outputs System PLL output clock, PLLOUT.
- Bh CLKOUT pin outputs system clock, SYSCLK (default mode).
- Ch CLKOUT pin outputs System PLL output clock, PLLOUT.
- Dh Reserved, do not use.
- Eh CLKOUT pin outputs System PLL output clock, PLLOUT.
- Fh CLKOUT pin outputs USB PLL output clock.

CPU ST3_55[0x0004@DATA]: CLKOFF bit (bit 2) - The CLKOUT pin is enabled/disabled When CLKOFF = 0, the CLKOUT pin is enabled; the associated clock signal appears on the pin. When CLKOFF = 1, the CLKOUT pin is disabled.

Output Slew Rate Control Register (OSRCR) [0x1C16] - control the slew rate

Why wont my program work in Stand-Alone Mode?

• You must understand how the bootloader works. It is a program that runs from ROM at power-on and modifies the DSP registers and memory as it copies your binary boot image into memory. You should not trust the bootloader to leave the DSP in a reset state. It is safer to re-initialize everything you need from within your bootloaded program.

• You should understand the purpose of the GEL file and understand what features of the GEL file your program relies on.

• Try using no GEL file in CCS and see if the program can work without the GEL file. The GEL file is not used in stand-alone mode, so it is important that your program performs any and all initialization that the GEL might do.

• Most common reasons your program doesnt work when bootloaded:
  • PLL initialization
  • Clock Gating is preventing a clock from arriving at a peripheral
  • IDLE configuration is leaving some part of the DSP in IDLE mode (most frequently XPORT when using DMA)
  • Peripherals are not being reset and are in an undefined state when trying to use them
  • Your program uses SARAM31, which is reserved for the bootloader - anything in SARAM31 is probably corrupt after the bootloader runs.
  • Interrupt vector table if you are using interrupts
  • Interrupts Enabled/Disabled correctly
  • Using |= and &= for registers like EBSR, instead just use = to be sure of the setting, or always use |= with complementary &= to be certain you have setup the register correctly - DONT ASSUME ANY BITS WILL BE SET OR CLEARED

How to set the DSP_LDO output to 1.05V or 1.3V

1. Using CCS4...
2. Open View --> Memory
3. Set Memory Page to I/O
4. Set address to 0x7004
5. Set bit 1 high for DSP_LDO = 1.05V
6. Set bit 1 low for DSP_LDO = 1.3V

Error: "This project was created for a device-variant that is not currently recognized: TMS320C55XX.TMS320VC5515. Please install the device-variant descriptor, or migrate the project to one of the supported device-variants."

• If you see the above error message after trying to build a project in Code Composer, use a text editor find and replace the following keywords from .cdtbuild (located in the project directory):
  • Replace "TMS320VC5515" with "TMS320C5515" in every instance...

Where can I find recommended compiler settings for c55x?

This presentation (pdf) is the collective wisdom on C5500 Compiler build options from a highly experienced development team within TI. Many points made, however, apply equally well to other TI compilers.

Do the C5509A/07/06/03 DSPs require a specific power-up sequence ?

The DSPs do not require specific power sequencing between the core supply and the I/O supply. However, systems should be designed to insure that neither supply is powered up for extended periods of time if the other supply is below the proper operating voltage. Excessive exposure to these conditions can adversely affect the long term reliability of the device. System-level concerns such as bus contention may require supply sequencing to be implemented. In this case, the core supply should be powered up at the same time as, or prior to (and powered down after), the I/O buffers.

Is the C5509A DPLL sensitive to CVDD supply ripple? There is excessive jitter on CLKOUT.

According to Hardware Designer's Resource Guide (SPRAA30.pdf) P.11 about PLL, there is a description as "CVdd power supply ripple of less than 20mV is recommended for optimal DPLL jitter performance".

Additional information on clock jitter:

Typically, you will see around 2-5% jitter. Besides the input clock, the CLKOUT jitter depends on the following factors:

a. Supply noise (both core and IO)

b. On chip activity (more activity will generate more inductive noise)

c. High activity of the peripherals around the CLKOUT I/O buffer.

d. High activity on the other I/O pins which increases switching noise to the internal IO supply rail that is also shared by the CLKOUT pin.

How can I use the I2S signals on the C5545 BoosterPack header?

The C5545 BoosterPack was designed to connect to the CC3200 LaunchPad, which has I2S signals on the same LaunchPad header pins as the C5545 BoosterPack (LaunchPad pins 27 – 30 / BoosterPack header J7 pins 14, 16, 18, 20) The CC3200 I2S can only function as the I2S master and with an IO voltage of 3.3V.

Since the C5545 BoosterPack has an IO voltage of 1.8V (for power saving), level shifters are required between the C5545 and the LaunchPad header. U13 level shifts I2S bit clock and frame sync and U 12 level shifts I2S RX and TX signals.

Level shifters require a direction, and the default direction for the I2S bit clock and frame sync is from the LaunchPad to the C5545 BoosterPack (R127 populated).

To change the direction of the U13 level shifter so that the C5545 is the I2S clock master, R127 needs to be unpopulated and R126 needs to be populated with a 10k resistor. Additionally, the level shifters require a reference voltage to level shift to, which is to be supplied on J7 pin 1 (Pin 1 on the LaunchPad). If there is no LaunchPad attached or no voltage is supplied on J7 pin 1, then the reference voltage needs to be supplied another way.

• To level shift to 3.3V, wire 3.3V from TP3 to JP7 pin 1
• To level shift to 1.8V, wire 1.8V from TP4 to JP7 pin 1
• Supply JP7 pin 1 externally or with an attached board (LaunchPad / BoosterPack)

When building the diagnostics for the C5545BP Booster Pack, why are there CCS errors such as "struct"<unamed>" has no field CGCR1"?

Ensure that the C55XXCSL_LP.lib has been generated with the correct Macro defined in csl_general.h. This library is a dependency for the diagnostics examples for the C5545 Booster Pack.

All the microphones on my Circular Microphone Board (CMB) do not work. What is wrong with it?

The first batch of the Circular Microphone Boards (CMB) had an incorrectly installed jumper when used out of the box. The J8 four-post header on the underside of the CMB must have pins 1 & 2 shorted and NOT 1 & 3. The picture below show the CORRECT installation of the jumper. Please ensure the jumper is correctly seated.

Where can I find more information on TI's Embedded Speech Recognizer (TIesr)?

Please see this dedicated FAQ for TIesr

I get an error when trying to build C55x CSL projects in CCS v7.2. Why is that?

"Buildfile generation error occurred. This project was created using a version of compiler that is not currently installed - 4.4.1[C5500]"
In CCSv7 onwards, the C5000 code generation tools have to be manually installed through the CCS App center. Please see this e2e thread for the solution.

When the BOOST5545ULP Boosterpack is connected to a circular mic array (CMB) or linear mic array (LMB), CCS disconnects when the array initializes. Why is that?

Problem:
CCS disconnects from C5545 Boosterpack after running the CMB/LMB software for the first time. Must reload the software and it works the second time.

Root cause:
As soon as I2S signals start toggling from the CMB, a reset pulse comes from the U13 level shifter that sits between the C5545 chip and the LaunchPad headers. The U13 level shifter has no VCCB supply when no LaunchPad is attached. Specifically, the LP_SOFT_RST reset signal, which shares the U13 level shifter with I2S, glitches low when the level becomes back-powered by I2S signals. I2S signals are received from CMB and translated from 3.3V to 1.8V through a level shifter that is back-powered with a VCCB supply that settles at 1.14V (< 1.2V out of spec). Before configuring CMB/LMB to start transmitting I2S signals, VCCB supply is at 0V and the level shifter forces the signals to be hi-z, so LP_SOFT_RST is pulled high. After I2S signals transmission has begun, LP_SOFT_RST is pulled high to VCCB = 1.14V and level shifted to 1.8V, and thus out of reset. But during the transition, the LP_SOFT_RST reset signal pulses low, resetting all components on the C5545 Boosterpack, disconnecting JTAG.

Other observations:
1) When 3.3V is supplied to the CMB/LMB from the C5545 Boosterpack and CMB/LMB is generating audio clocks/data, we observe 540mV p-p ripple on 3.3V (this was initially thought to be the source of the CCS connection issue).
2) U12 level shifter has same issue - has no VCCA supply with no LaunchPad connected

Workarounds:
1) Populate a single post header on TP3/3.3V and connect it with a jumper wire to J7:Pin 1 LP_3V3 - the VCCB supply of U12 and U13 level shifter. This supplies both U12 and U13 level shifters with both VCCA and VCCB supplies when no LaunchPad is connected. Risk for issue when LaunchPad connected and wire from TP3/3.3V attached - LaunchPad 3.3V shorts to Boosterpack 3.3V - could be slightly different potentials resulting in current flow.
2) Connect and power a LaunchPad to the C5545 Boosterpack when using with CMB/LMB, ensure LaunchPad does not drive I2S signals to avoid contention
3) If building your own board, have ORing diodes from both local 3.3V and LP_3V3 so that diodes block flow between boards when both are attached. Level shifter will shift to higher of the two 3.3V supplies.

How do I generate a SD card image to boot the Audio Preprocessing demo from TIDEP-0077?

This can be done by running the hex utility tool on the DOS prompt on a Windows machine.
The hex55.exe is typically located in the CCS installation at <CCS_INSTALL_PATH>\tools\compiler\c5500_4.4.1\bin\hex55.exe
Command: hex55 -boot -v5505 -serial8 -b -o bootimg.bin BF_rt_bios.out

A guide on creating an SD card image and proper formatting of the card is available here Creating_a_SD_card_boot_image_for_C55x

Where can I find geotrustglobalca.der as described in the TIDEP-0083 Voice Triggering and Processing with Cloud Connection to IBM Watson Reference Design?

geotrustglobalca.der is needed on the CC3220 in order to run the IBM Watson demo. This requirement has since been changed and an updated certificate is needed. Please see the below e2e thread on how to get the new certificate.
e2e thread

A guide on creating an SD card image and proper formatting of the card is available here Creating_a_SD_card_boot_image_for_C55x

How do I add a post-build step to Code Composer Studio (CCS) to automatically generate a .bin from a .out for my C55x project

A post-build step in the CCS project properties can be added to automatically generate the .bin file when the CCS project is built.
The below example is used for C5517 projects.

${CCS_INSTALL_ROOT}/tools/compiler/c5500_4.4.1/bin/hex55 -q -i "${BuildDirectory}/BF_rt_bios.out" -o "${BuildDirectory}/bootimg.bin" -boot -v5505 -b -serial8

Related FAQs

General C55x DSP

• 55x_FAQ
• DSP Library FAQ

C5000 Device Families

• C5504/05/14/15 FAQ
• C5501/02 FAQ
• C5503/06/07/09A FAQ
• C54xx FAQ

C5000 Device Tools

• C5502 EVM FAQ
• C5502 eZdsp FAQ
• C5505 eZdsp FAQ
• C5505 EVM FAQ
• C5509A DSK/EVM FAQ
• C5509A eZdsp FAQ
• C5510 DSK FAQ
• C5515 eZdsp FAQ
• C5515 EVM FAQ

C5000 tools

Code Composer Studio

• Code Composer Studio v4
  • Start here
• Target Configuration - Custom Configurations

Compiler, Assembler, Linker

• Compiler
  • Start here for information about the compiler
  • Download new versions
• CGT_Tips_&_Tricks_for_Beginners
  • Good guide for getting started with the tools
• Recommended_Compiler_Options
• C5000_Compiler:_Optimization_Tips_and_Tricks
  • Good guide which describes how to get the most out of the C5000 Compiler

Emulation

• Debugging JTAG Connectivity Problems
• JTAG
• Emulation

Manuals

• C55x Compiler Users Manual tidoc:spru281
• C55x Assembly User Manual tidoc:spru280
  • This manual includes information on creating linker command files