Bug - Stack/heap sizes in cm0gcc.ld file for BLE OTA do not change with .cydwr entries?

[AnSa_1225656]

Looks like I need to edit the cm0gcc.ld file manually to change the stack/heap sizes for the BLE OTA?

Is there a way to make it use the values entered in the System entry of the .cydwr?

What are the minimum values for the Stack and Heap when using BLE OTA (assuming that is the biggest user of stack and heap)

[Anonymous · Accepted solution]

OTA projects make use of custom linker scripts. The values set in the .cydwr affect the default linker script(cm0gcc.ld). Therefore, you have to manually change the heap and stack sizes as required in the custom linker script. I don't think there's a way to use the values entered in the .cydwr file.

[AnSa_1225656]

Thanks for the response.  Its a bummer that we don't have access to the sized in the cydwr file in the linker script, but at least you have verified my suspicion.  Still would like to have more guidance on stack/heap sizes.  In the "PSoC® Creator™ Component Datasheet Bluetooth Low Energy (BLE)", it claims a stack of 2048 is needed for the bootloader (Page 524 of 552).  Do I assume the stack is always 2048, or do I need to allocate additional when I use multiple multiple/custom profiles?  How do you calculate Flash and SRAM in these cases where multiple profiles are being used?  Feel free to break this out in a different thread if you like.

[Anonymous]

Generally, setting all values in the stack/heap area to a specific unique value (like 0xAA or 0x55) and then running the program for some amount of time, and checking how big the stack/heap got by where the specific unique values end is useful for measuring runtime stack/heap usage

I would expect the stack to not increase with more/custom profiles, but that's just my guess...

[AnSa_1225656]

Thanks.  That has been my go to method, but when using third party libs, I always wonder what else might bite me .  Thanks for your responses.  Its good to validate my assumptions with another.

[Anonymous]

You're welcome; It's always rough starting with a new chip and figuring out the unique things it does

Based on the values being 2048 (looking at the datasheet here ) I would go with the assumption that the stack will be a constant amount; The profile is more of a flash database stored on the chip, with some binary DLLs/APIs for programmers to access/use them. Thus, the stack would be more for the fixed functions/calls to the different internal APIs within the BLESS software to run the radio. The Flash and SRAM would obviously change based on how big your profiles are, and how many characteristics are in them. Otherwise, the stack will be more or less consistent for the BLESS regardless of the profile/characteristic configuration