- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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