increase default stack size (CW for ARM)
Completed
All projects I made in Crossworks (for different M0/M3/M4 derivates) had a default stack size of 128 bytes, that's just a meager 32 words.
Especially when I ported projects from other toolchains to Crossworks, that landed me early in the HardFault handler.
If I create a new project, increasing the stack size to 512 or 1024 bytes is now one of the first things I do. It would be nice to increase that, or have it presented in the "new project" wizard.
-
Being present at some fora of Cortex M vendors, I several times came across posts complaining about strange behavior and target crashes after small and seemingly irrelevant changes with Crossworks. Suggesting to increase the stacksize most often helped ...
So much for the background of my suggestion.
-
Is this true for all projects?
I created a empty executable project using the STMicroelectronics ST_STM32F4DISCOVERY template yesterday, and I ended up with a Main stack of 256 bytes as well as a process stack of 0 bytes... This did cause some odd issues.
Is there by the way any plans of implementing an "hierarchy based" property viewer, where you can see a full set of properties as well as on which levels they are set, and in the end which level is the one in effect? This would probably be something similar to XCode...
In my case I just realized that the Solution properties gives the full set of stacks (Abort, FIQ, IRQ, Supervisor, Undef & User/Sys) and not the M4 stacks (Main & Process) which are shown on project level. Maybe this could be improved so that if a solution only contains Cortex M projects the properties on solution level will be the same?
-
> Main stack of 256 bytes as well as a process stack of 0 bytes...
All project templates should now default to a non-zero process stack size -- I think.
> This would probably be something similar to XCode...
Show the Properties under the node in the Project Explorer. This shows you which properties are set on the node and in which configuration. Use the dropdown in the Project Explorer toolbar.
> Maybe this could be improved so that if a solution only contains Cortex M projects the properties on solution level will be the same?
This is a tough one...
-
On the last point; Could it be made an option to select if the solution is for a Cortex M target or regular ARM? I'm assuming that the intention with the solution is to group together artefacts meant for the same target hardware, or would there be uses where multiple types of targets are encountered?
If one has selected Cortex M one set of stacks would be available, if regular ARM another.
An alternative could be to expose both of these, and maybe prefix the property with ARM / Cortex so one at least can see the setting applicable to your current projects from solution level?
-
It is quite possible for a solution to contain two projects that are for different architectures. We have customers that do this now, some with >7 processors on a JTAG chain. And, for instance, the LPC4350 has Cortex-M0 and Cortex-M4 on a chip and the 4370 2xM0 and 1xM4, so again, it's possible to have three projects for the three cores in a single solution, press F5, and have all three get up and running. So, it's a hard problem, and reducing it for a simple case is, um, hard...
Please sign in to leave a comment.
Comments
8 comments