Hi,
I'm using CCS C/C++ Compiler v7.2.1, SYS/BIOS 6.31.4.27, and NDK 2.20.4.26, building for a C6670.
I was having dificulty getting a code project working using NDK. However I had previously been able to get IP comms going OK.
It appears to be something to do with the fact that I had turned on Exception handling in the C++ compiler options (--exceptions) for my CPP source files and then linked against the _eh core library. I say this because when I removed the code that actually used exceptions, and recompiled my code without --exceptions, and the exception handling core library, the code started working as intended.
The error seen was very reproducable but very wierd. It seemed to crash out with a stack overflow while trying to allocate memory. There is room on the heap, and other allocations had worked ok. I had 8kB reserved for my stack, which should be more than enough for what was (visibly) going on the stack. Plus, as I say I rebuilt my project without exceptions (the only change) and it all seems to work OK.
I haven't done anything to attempt to prove this as yet. I was thinking of compiling the hello world MCSDK example in C++ with exceptions and see if it crashes out. But before I started doing anything like that I thought I'd ask the question to see if anyone knows anything about it.
As a final question, during my digging into trying to find out why it was crashing out, can anyone tell me why SPRU523g, the NDK User Guide, section 3.4.1 states "The NDK assumes there is some L2 cache. If the DSP is configured to all internal memory with nothing left for L2 cache, the NDK drivers will not function properly". Surely with the use of the OSAL type functions, implemented in the MCSDK examples with the resourcemgr.c source file, these control what caching mode(s) are used? Is there any other reference to caching elsewhere in the NDK? Is this just a comment more relating to older versions on the NDK on older architecture?
