For PSoC 6 there is no option to modify the stack and heap. PSoC Creator will take care of this automatically. The only way to modify would be to modify the default linker script. But this is not recommended.
One correction to Hima's answer - Yes it is true that we have removed the stack/heap configuration from the dwr for PSoC 6. However, in order to modify the stack/heap size, you have the below two options:
1. Add the heap and stack size as macros to compiler settings (Project > Build settings > CM0+ or CM4 > Compiler). Define __STACK_SIZE=400 for defining a stack of size 400 bytes and __HEAP_SIZE=400 for defining a heap of size 400 bytes in the "Preprocessor definitions" under the General compiler settings. Note that you will have to define this for each/all compiler(s) and both "Release/Debug" configurations.
2. Look for "startup_psoc63_xxx.s/S" files in the source folder of both CM4 and CM0+. Again these startup files are compiler/toolchain specific and hence open the file for the compiler you are using (right-click the file and select Properties to see the "Toolchain" the file is supposed to build in). In the file, look for "Heap_Size" and "Stack_Size" definitions and edit the values to your requirement. It should be noted that for IAR this is different and the heap/stack sizes are defined in the linker (.icf) file - __ICFEDIT_size_cstack__ and __ICFEDIT_size_heap__.
I recommend using the compiler settings for modification rather than editing the files, as that is cleaner and useful/maintainable in the long-run when the source files gets updated.
Let me know if this helps.
Meenakshi Sundaram R
Yes, Meenakshi, this answer helps.
Although I am a bit (or byte ;-) disappointed about the handling. Unused sram memory (neither stack nor static variable's memory) is not usable as the name says and imho should be allocated as heap as it is done in other IDEs or different common languages. This will assure that there is a programmatic access to this "unused" memory area. In complex applications the use of malloc() and free() helps dealing with the usual tight amount of sram available. Especially when using multiple tasks.
I completely agree Bob
I will pass this on to our software team for consideration.