Basic questions about running a program with/without CCS 6678

Hi,

When the 6678 boots, all core start executing an RBL (ROM Boot Loader) from an internal PROM, as described in SPRUGY5 "KeyStone Architecture Bootloader User Guide". The core 1..7 simple wait fo an interrupt from core 0, while core 0 execute the boot-load depending on the configuration of some external PINs.

The process of creating a bootable image is docoumented in SPRA544D "TMS320C6000 Tools: Vector Table and Boot ROM Creation" and in SPRAA64 "Using OFD Utility to Create a DSP Boot Image".

In general your application shall execute all the platform initialization and the C translation of the other initilaization executed via GEL files, but the one already executed by the RBL.

The format of the file shall be one supported by the RBL, so ELF file cannot directly be used. Yuo can consider to use a secondary level boot loader,as the EVM on-board IBL, see also spra999a Creating a Second-Level Bootloader for FLASH Bootloading on TMS320C6000 Platform With Code Composer Studio.

To experiment a bit with the boot, you can set-up the EVM switch to place the EVM in EMIF16/no-boot mode and then run your program from CCS without using a GEL file to configure the board. In this case the EVM (the one I have) start with main PLL clock in bypass mode (so it execute at a low frequency) and the DDR not configured (so you have to start with a program in L2RAm or MCSM).

Johannes, you could start with the document "C66x CorePac User's Guide".   All the memories you mention "L2SRAM, MSMCSRAM or DDR3", are directly addressable - meaning that the processor can execute code directly from this memory.  Whether these memories are cached is configurable, (see the sections on L1 and L2 caching in the CorePac User's Guide". 

<<

And is there any difference if using the CCS/emulator or not?

>>

When you run your code via CCS/JTAG, it is first loaded in to these memories (where it is loaded depends on the executable image and where the linker has place sections), and then the processor executes it.  As far as 'memory' is concerned there is no difference between loading via JTAG and loading via some other mechanism (bootloader).

Johannes said:

2 - What happens when a program is run? I mean, we can choose, in the platform, if the code is stored in L2SRAM, MSMCSRAM or DDR3, the code is executed directly from these memory? Is it cached? And is there any difference if using the CCS/emulator or not

The code is executed directly from the memory where you load it (that should be at the same addres you link it), regardles the way to use to load (bootloader or CCS), with the transparency intermediation of the cache depending on how you have configred it. By default L1 cache is enabled, while L2 is disabled so you can use it as RAM. L2RAM and MCSM are cachable by default so code and data running on that memories is cached at least al  L1. DDR is not cachable by default.

Look at srupw0 TMS320C66x DSP CorePac for info about the cache architecture (para.2, 3 and 4).

The only remarkable different between CCS and boolader is in the initial state of the DSP, since CCS can alter it by means of the a GEL file (init DDR? enable L2 cache?). Also, when using CCS, the target could have already executed some code that could have altered the default configuration (that's way, to do experiments,  I suggest you to configure the EVM in no-boot mode, without GEL initialization script).