Each time I add more GT_ trace calls in my app, the trace messages from Engine_open seem to suggest that the code is making it further without error. Since I'm not making any other changes, this screams of memory partitioning, stack, heap, etc errors.
My target board has twice the SDRAM as the OMAPL137 evm. My (DSP) server requires that I take advantage of this memory. (It is bigger than the default server.tcf file for DDR2.) In my server.tcf file, I renamed DDR2 to SDRAM. I did this everywhere, so I have no problem building and linking. (The CCS configuration automatically named the memory type SDRAM, and I couldn't change it to DDR2. I couldn't get the build to complete because SDRAM was undefined, so I renamed the segment. Maybe that was the wrong thing to do, but I couldn't figure anything else out.) I've modified the location and size in the map, expanding the size to 0x40000. I shrank the DDRALHEAP space slightly at the same time.
I made no changes to the dsplink files (I'm guessing dsplink-omapl1xxgem-base.tci and CFG_OMAPL1XXGEM_SHMEM.c) that have memory info in them, but I'm thinking that I probably should.
Can someone advise me on how to modify the dsp and gpp memory map files for dsplink to have them either match the server.tcf file? I think that the (old) DDR2 in the original server.tcf and the SDRAM in the dsp and gpp memory map files did not match before, so I'm not sure if I've broken something.
If my problem is associated with renaming DDR2 to SDRAM, could someone advise me on how to get SDRAM defined when I do the server build (after copying my CCS libraries to the Linux box)?