Hi,
The symptoms you are describing are consistent with application errors - i.e., some of the applications are conflicting with the other ones, thus preventing the processor to execute normally.
Although it is difficult to pinpoint the exact cause, a few points are useful to better understand what may be happening:
- Memory allocation conflicts. Although you say that .text is always allocated to the core's exclusive SRAM memory, the other memory sections (.const, .cio, .data, .bss, etc.) may be allocated to a shared memory location outside the device (external DDR, for example). In this case, before the code reaches main() it performs an initialization of the C runtime environment (initializing constants and variables, allocating buffers, etc.) - if there is a memory conflict, it is possible that some of this initialization will not be able to complete without problems. To verify if this is the issue, try to allocate ALL your code to the core's exclusive SRAM memory.
- Peripheral conflicts. Similar to the case above, if two cores are trying to initialize or access a specific peripheral at the same time (clocks, serial ports, busses, etc.) a lockup may occur. The least severe is if two cores are waiting for the same peripheral to be available, and each core simply hangs at a specific function waiting for the peripheral to be ready. The most critical scenario happens if two initialization attempts are made by different cores in critical peripherals such as PLL, clock, EMIF and possibly others; in this case a specific core (or the entire device) may be completely unstable and therefore the debugger connection is severed. To verify this, run the code in each core and see if they work (apparently they do, as per your description above).
- Interprocessor communication (IPC) conflicts. Those are similar to the previous scenario, where a given core tries to get control of a given transport mechanism (pipe, message queue, stream) that is already in use by another core. This issue, however, would rarely manifest itself prior to reaching main() - it would be more evident after the system is already up and running.
From this perspective CCS itself and the chosen emulator do not influence the scenario you are experiencing. For specific details about the components you are running (BIOS, IPC, the device initialization) it would be better to check with the experts in the respective forums (BIOS and C66x).
Hope this helps,
Rafael