View previous topic :: View next topic |
Author |
Message |
soonc
Joined: 03 Dec 2013 Posts: 215
|
Stack Size PIC24 |
Posted: Fri Jun 17, 2016 6:28 pm |
|
|
Currently my project .lst file is reporting:
ROM used: 48916 bytes (56%)
Largest free fragment is 22520
RAM used: 6134 (75%) at main() level
6383 (78%) worst case
Stack used: 348 locations (42 in main + 306 for interrupts)
Stack size: 512
It's a PIC24FJ128GA306 and has 8K RAM.
With a Stack Size of 512 how does it look ? Just how more stack usage is possible ?
Can the compiler really predict every scenario as it appears to be doing !
Should I increase the stack size ? |
|
![](templates/subSilver/images/spacer.gif) |
guy
Joined: 21 Oct 2005 Posts: 291
|
|
Posted: Sat Jun 18, 2016 2:33 am |
|
|
I have a large project with a similar PIC - 24FJ64GA308 .
I ran into random resets which had to do with the printf() function. This is known to take up a lot of stack (due to floating point conversions done inside printf). The following solved it: #BUILD(STACK = 0x200) so apparently it was a stack issue which was not noted by the compiler during Build.
I understand you are already working with a 512 byte stack.
To answer your question, from my experience the compiler doesn't know exactly how much stack it would take up so it's better to have a safe margin and look out for bugs and phenomena that smell like Stack Overflow. There is also the Stack Overflow fuse (I don't remember the exact name) that handles this. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Sat Jun 18, 2016 5:24 am |
|
|
While I don't use that PIC... my 'gut' feeling is to increase the stack to 1024.
There always seems to be a lot of stack related queries here.
A lot of your STACK(90%) is used for interrupts, so adding one or two more ISRs ...and.. poof...PIC stops working ! You still have enough 'main RAM' to assign to the STACK.
Try it, see what happens. if your program needs more RAM, THEN reduce the STACK to say 768 (nice binary number...).
As for HOW the compiler predicts.... it has a very good crystal ball !
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19382
|
|
Posted: Sat Jun 18, 2016 11:55 am |
|
|
I wouldn't go so far as 1024. Seems a bit 'OTT'.
The calculated figure is always pretty reasonable, except for certain things. In particular, CCS doesn't always seem to 'know' the stack used by the printf. I think it uses some form of dynamic allocation, based on the actual values involved. So some numbers (particularly some float values), can result in 'extra' stack being used, beyond what is 'expected'. The '42 in main', sounds suspiciously small to me. You can get stack overflow, at a size of 256, with a main 'saying' it only uses about 100 bytes, if you printf several float values. I've developed a 'rule' of running the stack to 256 greater than the figure the compiler says is being used, and (touch wood), so far have not seen a stack overflow, with it set like this. So I'd suggest taking the stack to 640, as a compromise between wasting space, and leaving a margin.... |
|
![](templates/subSilver/images/spacer.gif) |
soonc
Joined: 03 Dec 2013 Posts: 215
|
Thanks for all the replies |
Posted: Sat Jun 18, 2016 3:21 pm |
|
|
I was having graphics issues, and these started after adding totally unrelated code.
I ended up with stack at 768 and that fixed the graphics problem.
Thanks again for all the good advice. |
|
![](templates/subSilver/images/spacer.gif) |
|