This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Emulator cannot find the entry point(_c_int00) of the program on tms320c6678

Hi, TI guys!

I am in trouble when I debug my program on TMDXEVM6678LE. After I connect the target, I load my program on all the 8 cores. But CCS does not suspend the cores on the entry point of the program. All the cores are running. Then I suspend the cores by clicking the suspend button, but not all the cores can suspend normally. Some of the cores suspend, others are hung and connection of the core and the emulator is broken.

I tried several programs, and some of them can run normally, others can't.

But I find a more surprising problem. When I want to debug my trouble program, I can firstly load a normal program, the entry point of which can be found. After running the normal program, I load my trouble program. Then the surprising thing happens that the program can suspend on its entry point.

I am sorry that I cannot show my program for some reason. My program uses BIOS, and its size is 0x1c940. I locates the .text section in L2SRAM. The emulator is Blackhawk XDS560v2-USB Mezzanine Emulator.

Would you please help me solve this problem, or explain why it happens?

Thank you for your attention and help!

  • 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

  • Houzhi Shan,

    Which version of CCS are you using? You should be upgraded to CCSv5.4.0.00091 or later.

    Which version of the emulation drivers are you using? Use the CCS Help->Check for Updates feature to get the latest emupack or go to the TI Wiki Pages to get it.

    Are you using a Target Configuration that includes a GEL file for CorePac0? This will take care of system initialization.

    For these tests, you should have the DIP switches set for NoBoot to give all the control to the emulator and CCS.

    When you load your programs, exactly how are you doing it?

    Start with just CorePac0. Load the program to it and verify that you can run it correctly. Look at where it is running memory and confirm it is in the right location.

    Look at your linker output .map file to confirm the address of the c_int00 entry point. Are you using the local L2SRAM addresses starting at 0x00800000 or the global L2SRAM addresses starting at 0x1n800000 where n is the CorePacn number?

    Regards,
    RandyP

  • Thank you very much, Rafael!

    Your words throw light on the reason why it happens.

    I will check the point you mentioned.

    I will try to find Memory allocation conflicts, and load program on one core after another.


  • RandyP,

    Thank you for your help!

    I am using CCS 5.1.

    My computer on which I am working is without the Internet. So it is hard for me to download the latest CCS. Neither can I updates the emupack.

    My GEL file is correct. I can see the initialization being done. And the DIP switches set is for NoBoot.

    The address of c_int00 entry point is locating at L2SRAM. And the L2SRAM addresses is starting at 0x00800000.

    I group the cores. I load my program on all cores at one time.

  • Houzhi Shan,

    Since you marked this thread as Answered, I understand that you do not need to proceed further at this time.

    You can download updates to a Flash Drive and carry them to your computer. There have been many improvements since CCSv5.1 and the emupack's have been updated, also. If you continue to have problems, please update these as the first thing to solve any new problems, or if this problem continues.

    Regards,
    RandyP

  • Hi, Rafael

    The guy who post this question is my college, and unfortunatly, we still have this problem unsolved.

    I think we can rule out num2,3, because we tried to download program to only core 0, and the outcome was the same~the only core was running and couldn't possibly stop it.

    So that leaves us with only the first one, memory allocation conflicts. I check the .map, all but the .const section are  in L2SRAM, due to its size, we put the .const in MSMCSRAM, the 4M shared ram with in the dsp. The setting is done in .cfg of our bios system.

    One interesting phenomenon is that we have 2 user data section in the top of L2SRAM, before .text , and when I mannually set the 2 sections in the middle of the L2SRAM, say 0x00830000, give the beginning of the L2SARM to .text , the program can be download and stop at the init entry successfully. But the srio init function within it wont function well. However, when I download a simple , non-periheral normal program, run it and download the program i altered, the srio init fuction is able to function well.

    Can you throw some light on that?

    Thank you

                                                                                                                                                                                 David Yang

  • And what does the normal program which i download first do? I mean what does it change?

    During each load operation, we use the same gel and emulater, and the gel offered by ccs contains initializations of pll,ddr,ect.