• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 977 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.

C6713 : ".out" upload to DSP result in garbage data in DSP memory

Tomy Rodrigue
Prodigy 20 points

Other Parts Discussed in Thread: CCSTUDIO

Device : TMS320C6713

Code Composer Studio version : 3.1.0

Code Generation Tools version : 5.1.0

Build options : -q -s -pden -pds232 -o3 -fr"c:/work/LVTTS/DSP/PABX/Release" -i"." -i"c:/work/LVTTS/DSP/PABX/Code" -i"C:/SignalMaster/lsp/matlab/r12p1/rtw/sm/target" -i"C:/matlabR12/simulink/include" -i"C:/matlabR12/rtw/c/src" -i"c:/work/LVTTS/DSP/PABX/RTW Generated" -i"C:/matlabR12/rtw/c/libsrc" -i"C:/SignalMaster/lsp/smc6xx/dsp/inc" -i"c:/work/LVTTS/DSP/PABX/Lyr_Make_LIB/src" -i"c:/work/LVTTS/Software/Common" -i"c:/work/LVTTS/Software/LVTTSPABX" -i"c:/work/LVTTS/DSP/PABX/Matlab/Common" -i"c:/work/LVTTS/Software/LVFC/C++/General" -i"C:/SignalMaster/lsp/smc6xx/dsp/src" -i"c:/work/LVTTS/Software/LVFC/C/General" -d"SMC6xx" -d"C6713" -d"SM_DATALOG_SIZE=10000" -d"ENABLE_PCACHE=0" -d"MODEL=LVDigitalPabx" -d"RT" -d"NUMST=1" -d"MT=0" -d"TID01EQ=0" -d"NCSTATES=0" -d"EXT_MODE" -ml2 -ms3 -mv6710 -c -@"../../../../work/LVTTS/DSP/PABX/Release.lkf"

Link options (autogenerated file : Release.lkf) : -z -cr -heap2500 -m"./Release/LVDigitalPabx.map" -o"./Release/LVDigitalPabx.out" -stack1500 -x -i"C:/CCStudio_v3.1/C6000/rtdx/lib" -i"C:/CCStudio_v3.1/C6000/csl/lib" -i"C:/CCStudio_v3.1/C6000/xdais/lib" -i"C:/CCStudio_v3.1/C6000/bios/lib" -i"C:/CCStudio_v3.1/C6000/cgtools/lib" -l"C:/CCStudio_v3.1/C6000/cgtools/lib/rts6700.lib" (+ all the .obj listed)

Hi everybody,

We have a pretty big application (.out) running on the C6713 as part of a bigger system. This application was designed 10 years ago and was last compiled with CCS 2.0 using "Matlab/Real Time Workshop". The DSP is part a of a system using a CPU and FPGA, USB, Serial and Ethernet connection. We had a major issue that we needed to address a couple months ago. We created a new CCS 3.1 project and got rid of Matlab/RTW (we couldn't debug with a J-Tag with CCS 2.0 and Matlab).

When we run the application with CCS 3.1 loading the ".out" with the J-Tag, everything works great. When we load the ".out" using an Ethernet connection (like we should load it with our system) all the DSP memory is garbage. We have more than 15 applications (designed with CCS 3.1 not Matlab) loading and working great with the Ethernet connection. The last build (with CCS 2.0 and Matlab) works fine expect for the major issue :(

- Instead of loading the program, garbage data is loaded in memory. For the same build, the same data is loaded (so it's not random data). I created sections were I didn't put anything (so the memory shouldn't be overwrite) and it's still overwritten with garbage data.

- I compiled a version with an infinite loop at the RESET (address 0x00000000) and it result in the same garbage data in memory. So it is not a faulty program that overwrites garbage in memory.

- I noticed that there's debug info sections (to be able to debug with the C code) added in the ".out" with version 3.1 that wasn't there with CCS 2.0. This result in a ".out" file 3 times bigger than it was. But those sections are also included in the 15 applications that work great.

Does somebody have any idea how to resolve this issue? I tried a lot of things and nothing seems to work.

I don't know if I provided enough information. If you need more info don't hesitate to ask.

I hope somebody can help me, thanks in advance.

Tomy

  • 0
    TI__Guru**** 253390 points

    I presume that, when you are loading over Ethernet, some non-TI loader is responsible for parsing the .out file and getting the contents into system memory.  My guess is that this loader has some problem which is exposed by the upgrade in the compiler.  I agree that .debug sections might be the problem.  Try adding --symdebug:none to the compile.  That will cause those sections to not be created, which matches the behavior of the older tools.  If that fixes the problem, then you have a short term fix.  A longer term fix is to change the loader to ignore the .debug sections.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 20 points

    Thanks a lot George.

    The compiler switch worked perfectly. The memory in the DSP reflects the asm code I uploaded. I suspect the ".out" was to big for our custom "loader" program because other application work fine with those debug sections. Anyway I will take a closer look at this.

    Thank you for the quick reply.

    Tomy