Looking further at the documentation and generated linker script, if I understand correctly the entire RAM is being marked as usable for the heap and the stack. Perhaps my problem is that the stack and heap are overlapping?
From the linker script:
/* Provide fall-back values */
PROVIDE(__cs3_heap_start = _end);
PROVIDE(__cs3_heap_end = __cs3_region_start_ram + __cs3_region_size_ram);
PROVIDE(__cs3_region_num = (__cs3_regions_end - __cs3_regions) / 20);
PROVIDE(__cs3_stack = __cs3_region_start_ram + __cs3_region_size_ram);
Thanks for your input. That was the section of documentation I was referring to. I would like to confirm that my interpretation is correct....are the defaults in the linker script (what I copied above) in fact each allowing the entirety of the RAM and thus may be causing a corruption due to overlap?
The example linker scripts provided with CodeBench are good for getting started and will work fine for small applications; but will probably need to be adjusted as your application and target memories get more complex. We can see that __cs3_heap_end and __cs3_stack do have the same address where the heap grows upwards and the stack grows downward. The actual address can be comfirmed in your .map file. If your program uses a lot of heap without freeing it up when done, then it is possible for the heap and stack to meet resulting in a corrupted stack.
Note that for apps built againt CodeSourcery's cslibc library, malloc will call _sbrk to obtain the specified chunk of memory. _sbrk checks against __cs3_heap_end on each request for memory and then sets errno to ENOMEM when the heap has been exausted. As a result, malloc will return NULL.