• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 975 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Unexpected behavior from "Functional Simulator" to "Cycle Approximate Simulator"

Allen Lee
Genius 3770 points
Other Parts Discussed in Thread: SYSBIOS

Hi All,

I have established a SYSBIOS project which is expected to running on C6678.

When simulate it on Functional Simulator, all thing is ok.

But when change target cfg file to Cycle Approximate, after loading the .out, the simulator couldn't run to main() function. And when I suspend the core, the console will show a message as:Interrupt No. 14 dropped, an earlier interrupt is pending to be taken.

Is there any thing I'm missing?

Thanks.

Allen

 

 

  • 0
    TI__Guru**** 171309 points

    Allen,

    The Cycle Approximate configuration does not simulate peripherals, therefore it may be the reason why your code does not reach main().

    Check the section Simulator Configurations of the C66x Device Simulator User's Guide page below:

    http://processors.wiki.ti.com/index.php/TCI6616/C6670/TCI6608/C6678/TCI6618_Device_simulator_User_Guide

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Genius 3770 points

    Hi Rafael

    I haven't included any peripherals in the application now, but the situation remains. 

    So I follow the trace of the program from c_int00, and find out the program is falled into a function called copy_decompress_rle which is located in rts6600_elf.lib.

    Then it seems the loop inside the function is infinite, so pc can't reach main().

    So what's the role of this function?

    Allen

  • 0 in reply to Allen Lee
    TI__Guru**** 171309 points

    Allen,

    This function is part of the automatic initialization of variables in EABI binaries (check section 7.8.4 of the C6000 Compiler User's Guide).

    The function itself should not break, however it may take a long while to complete since it is running on the simulator and depending on the number of initialized variables present in the application.

    You can try to speed up things by setting this compression mechanism to off (keep in mind the size of the .out file will increase). In the project options, go to C6000 Linker --> Linktime optimization --> type off in the box Compress ELF C style auto initialization data

    The other scenario I can think of is if this function is hitting some memory region that is not defined in the simulation environment and is somehow failing to report back this issue. This would be very unusual, as the simulator has a flat memory configuration that spans throughout the entire address range.

    Hope this helps,

    Rafael

     

  • 0 in reply to desouza
    Genius 3770 points

    Hi Rafael,

    Thanks for the suggestion, but I couldn't find the Linktime optimization option in my project setting:

    Is it a feature for new-version CGTools or CCS? I'm using CGToolsv7.2.1 and CCS5.0.3.

     

    Allen

  • 0 in reply to Allen Lee
    TI__Guru**** 171309 points

    Allen,

    Hmmm, I see the same thing in 5.0.3. I guess the support for this feature was added in CCSv5.1.0.09000.

    In any case you can still add this option by manually editing the Command Line Options of the C6000 Linker (see the attached picture).

    Regards,

    Rafael

  • 0 in reply to desouza
    Genius 3770 points

    Hi Rafael,

    I have tried the option and also turn off the --zero_init. Now it can run to main in a not very long time.

    Actually, the initialization process take TOO MUCH time(even insufferable) if there is big array in the project that need to be initialized. And this is not unusual situation for many applications...

     

    Allen