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.

Memory limitations in data segment?

Hi all,

 

I have a simple main programm which just outputs  "Hello World". This works fine. Now I want to link several CPP code object files to this program. And here is where Iam getting stucked. For example if one of the objects of the CPP code allocates to much memory its static (global) variables, suddenly the print statemant from the main routine does not work anymore. If I increase the memory consumption of such a static variable within the CPP code which is just linked to the main program, the debugger can't even find the main access point anymore.

 

Iam using CCv4.2, developing code for C6748 DSP processor, using CGT v7.0.4 and xdc tool version 3.20.08.88. I use a generated linker file by the xdc platform evm6748 since I also have an evm6748 by LogicPD.

 

Any help on this issue would be very appreciated. Please let me know if you need additional information.

 

Kind Regards,

Steve

  • I would recommend you start by checking the map file and see if everything makes sense.

    Moving this to the bios forum for more comments.

     

  • Hi Steve,

    Is it possible to attach your project to this post? You can select the File -> Export menu to launch the export wizard. 

    Regards

    Amit

  • Hi,

    thanks for your answer and help. Unfortunately Iam not allowed to attach the code here. But if it would help I can attach the map file? Maybe you can see some mysterious things going on there? For me everything looks plausible, but Iam really not an expert. If you want I can attach a mapfile from a working program and a map file from a not working one.

     

    Kind Regards,

    Steve

  • Hi,

    I got a bit further. I've found out that if the global and static variables from the linked CPP code  (which are put into the far segment) get to big, dynamic memory allocation (malloc, etc) does not work anymore. That is assumable also the reason why printf fails. Do you have an idea what could be wrong here? In which segment is dynamic memory allocation located when using an xdc platform and an autogenerated linker file? .sysmem?

    I've already specified (at least I hope so) enough heap within the project options. Please see the linker call.

     

    "D:/Programme/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/bin/cl6x" -mv6740 -g --diag_warning=225 -z -m"LaserFirmware_20110405.map" --stack_size=0x4000 --heap_size=0x20000 --warn_sections -i"D:/Programme/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/lib" -i"D:/Programme/Texas Instruments/ccsv4/tools/compiler/C6000 Code Generation Tools 7.0.4/include" --reread_libs --rom_model -o "LaserFirmware_20110405.out" -l"./configPkg/linker.cmd"  "./config/ConfigManagerAbstract.obj" "./main.obj" "./Scan.obj" "./LuxConfigAbstract.obj" "./segmentation/Segmentation.obj" "./segmentation/Segment.obj" "./segmentation/Contour.obj" "./util/Polygon2D.obj" "./util/Point2D.obj" "./util/LuxTools.obj" "./util/Line2D.obj" "./util/LinRegression.obj" -l"libc.a"

    And why has the compiler option --heap_size no impact onto the outcoming map file? When compiling my project with --heap_size=0x20000 and without the option --heap_size I cannot see any diffs in the outcoming map file.

     

    Thank you and sorry that I cannot provide the project here.

     

    Kind Regards,

    Steve

  • http://focus.ti.com/lit/ug/spru186u/spru186u.pdf states that the heap is in the section .sysmem.

    Check the file configPkg/linker.cmd, or a file with the extensions xdl referenced in linker.cmd for another heap size directive. If there is one, it could overwrite your heap directive from the command line. If that's the case you can try adding

    Program.heap = 0x20000;

    to your config script and see if that helps.

  • Hi Sasha,

     

    thanks for your answer. Setting the Program.heap variable to a higher value solves the issue. But Iam still concerned that this would only be a workaround, or in other words: Why does the size of the .far section (where the global and static variables are placed to) (and maybe also all sections before sysmem) has an impact on the sysmem section? I cannot explain this to myself. Do you have an answer?

     

    Thanks,

    Steve

  • Steve,
    please attach map files from a working and a non-working program. When you say that malloc() doesn't work anymore, what does it mean? Does it return NULL all the time?

    Can you try adding your CPP modules in stages to see if one of them can be detected as the cause of the problem? The problem could be that you have a memory leak somewhere that shows up only when .far section and the part of .sysmem that gets used are close in the memory map. I am just guessing here, it's hard to debug such an issuewithout seeing code.