 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
| Program for the stack depth analysis for dSPIC33EP256 |
 Posted: Mon Jul 01, 2024 1:03 am |
 |
|
Hi,
I am looking for a program to analyze the stack depth of my program.
one question Is stack created at the staring of RAM location or ending?
_________________
Thanks,
Vinod |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19326
|
|
| Posted: Mon Jul 01, 2024 3:38 am |
|
|
Just look at the listing file. Tells you the stack usage. Nothing else is
needed.
The stack is normally towards the top of RAM, but often chip limitations
mean it cannot be.be right at the top. You can specify where this is as
part of the #build instruction (and the size). |
|
|
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
|
| Posted: Mon Jul 01, 2024 5:04 am |
|
|
| Ttelmah wrote: | Just look at the listing file. Tells you the stack usage. Nothing else is
needed.
The stack is normally towards the top of RAM, but often chip limitations
mean it cannot be.be right at the top. You can specify where this is as
part of the #build instruction (and the size). |
Thanks Thelma,
I just want to write some information in the stack location and check whether the data I have written is modified or not over time.
I am facing an issue of variables updating during the running for a longer period, but as per code, it should not modified.
_________________
Thanks,
Vinod |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19326
|
|
| Posted: Mon Jul 01, 2024 10:17 am |
|
|
OK.
So first thing, what compiler version?
What does the stack data at the top of the listing say?.
Variables?.
These are not stored on the stack, except when being passed to/from a
function. Sounds to me more like a memory leak. Look carefully at anything
using pointers, array accesses etc.. Remember there is no protection in
the PIC hardware for things like writing beyond the end of an array.
Add defensive variables in front of the ones changing. If these get changed,
look at what the values in these are. Do these correspond to a value
you are writing anywhere?. |
|
|
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
|
| Posted: Tue Jul 02, 2024 12:58 am |
|
|
| Ttelmah wrote: | OK.
So first thing, what compiler version?
What does the stack data at the top of the listing say?.
Variables?.
These are not stored on the stack, except when being passed to/from a
function. Sounds to me more like a memory leak. Look carefully at anything
using pointers, array accesses etc.. Remember there is no protection in
the PIC hardware for things like writing beyond the end of an array.
Add defensive variables in front of the ones changing. If these get changed,
look at what the values in these are. Do these correspond to a value
you are writing anywhere?. |
I agree with you, The Global variables not stored in stack, it will be in data/code section.
Controller: dsPIC33EP256 - 32K of RAM
RAM allocation - AdaptionRegler1 structure update will modify the critical parameters of my program. before SimRegelstrecke is structure which is no where used during init stage after that no operation perform on that.
1B42-1B61 SimRegelstrecke
1B62-1B69 AdaptionRegler1
1B6A-1B73 strRM100
Stack also allocated at the bottom of the RAM
3388 ChecksummeBerechnen.CRC
8000-80FF SRV_In_Buffer
8F80-8FFF Stack
The compiler version was V5.007 and the latest version was V5.117
For both build settings are same : +DF +LN +T +A +M +Z +Y=9 +EA
CCS PCD C Compiler, Version 5.007, 3379 07-Jul-16 08:43
Filename: D:\Daten\ExReg\Firmware\Anzeigemodul_EP\ExReg.lst
ROM used: 133218 bytes (76%)
Largest free fragment is 32110
RAM used: 7917 (24%) at main() level
9480 (29%) worst case
Stack used: 660 locations (624 in main + 36 for interrupts)
Stack size: 128
CCS PCD C Compiler, Version 5.117, 3041 27-Jun-24 18:55
Filename: C:\VinodWorkSpace\Schischek\Firmware\CloneDemo\DisplayModuleV230\anzeigemodul\ExReg.lst
ROM used: 129496 bytes (74%)
Largest free fragment is 35832
RAM used: 7927 (24%) at main() level
8396 (26%) worst case
Stack used: 128 locations (76 in main + 52 for interrupts)
Stack size: 144
While debugging my code using PICkit3 with the new compiler version (V5.117), I noticed that the variables remain intact and I did not encounter the issues previously observed. My suspicion lies with either optimization settings or the stack size configuration.
During testing, I found that in the release build with V5.117, issues persisted when the stack size was not explicitly defined. However, after specifying a stack size of 2K using #Build, the problem was no longer present.
_________________
Thanks,
Vinod |
|
|
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
|
| Posted: Tue Jul 02, 2024 12:59 am |
|
|
| Ttelmah wrote: | OK.
So first thing, what compiler version?
What does the stack data at the top of the listing say?.
Variables?.
These are not stored on the stack, except when being passed to/from a
function. Sounds to me more like a memory leak. Look carefully at anything
using pointers, array accesses etc.. Remember there is no protection in
the PIC hardware for things like writing beyond the end of an array.
Add defensive variables in front of the ones changing. If these get changed,
look at what the values in these are. Do these correspond to a value
you are writing anywhere?. |
I agree with you, The Global variables not stored in stack, it will be in data/code section.
Controller: dsPIC33EP256 - 32K of RAM
RAM allocation - AdaptionRegler1 structure update will modify the critical parameters of my program. before SimRegelstrecke is structure which is no where used during init stage after that no operation perform on that.
1B42-1B61 SimRegelstrecke
1B62-1B69 AdaptionRegler1
1B6A-1B73 strRM100
Stack also allocated at the bottom of the RAM
3388 ChecksummeBerechnen.CRC
8000-80FF SRV_In_Buffer
8F80-8FFF Stack
The compiler version was V5.007 and the latest version was V5.117
For both build settings are same : +DF +LN +T +A +M +Z +Y=9 +EA
CCS PCD C Compiler, Version 5.007, 3379 07-Jul-16 08:43
Filename: D:\Daten\ExReg\Firmware\Anzeigemodul_EP\ExReg.lst
ROM used: 133218 bytes (76%)
Largest free fragment is 32110
RAM used: 7917 (24%) at main() level
9480 (29%) worst case
Stack used: 660 locations (624 in main + 36 for interrupts)
Stack size: 128
CCS PCD C Compiler, Version 5.117, 3041 27-Jun-24 18:55
Filename: C:\VinodWorkSpace\Schischek\Firmware\CloneDemo\DisplayModuleV230\anzeigemodul\ExReg.lst
ROM used: 129496 bytes (74%)
Largest free fragment is 35832
RAM used: 7927 (24%) at main() level
8396 (26%) worst case
Stack used: 128 locations (76 in main + 52 for interrupts)
Stack size: 144
While debugging my code using PICkit3 with the new compiler version (V5.117), I noticed that the variables remain intact and I did not encounter the issues previously observed. My suspicion lies with either optimization settings or the stack size configuration.
During testing, I found that in the release build with V5.117, issues persisted when the stack size was not explicitly defined. However, after specifying a stack size of 2K using #Build, the problem was no longer present.
_________________
Thanks,
Vinod |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19326
|
|
| Posted: Tue Jul 02, 2024 1:29 am |
|
|
OK.
The stack is at the _top_ of the RAM, not the bottom.
What is happening, is that when the stack overflows it is overwriting
the variables adjacent to it. The later compiler will be using more ROM,
by default it will 'inline' functions to optimise speed, so has reduced the
stack size. There are two big caveats on stack size. First, if you use a
debugger, _this uses some stack space_. You need to allocate some
more space when the debugger is used. The second is nomenclature.
The stack 'locations', each use two bytes. Stack sizes are in bytes (silly),
so both your shown versions are overflowing the stack. |
|
|
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
|
| Posted: Wed Jul 03, 2024 6:44 am |
|
|
| Ttelmah wrote: | OK.
The stack is at the _top_ of the RAM, not the bottom.
What is happening, is that when the stack overflows it is overwriting
the variables adjacent to it. The later compiler will be using more ROM,
by default it will 'inline' functions to optimise speed, so has reduced the
stack size. There are two big caveats on stack size. First, if you use a
debugger, _this uses some stack space_. You need to allocate some
more space when the debugger is used. The second is nomenclature.
The stack 'locations', each use two bytes. Stack sizes are in bytes (silly),
so both your shown versions are overflowing the stack. |
Thanks for input Ttelmah.
One silly question.
Is the SRAM in dsPIC33EP256 will intact the information after power loss?
because generally it should erased. but im my program the data still intact after power loss.
Before the power off
Gain = 0.7500 , Kp = 8.8980
b1 = -0.8999 , b0 = 0.0000
FuncReg = 1
MOb1.MReg = 3
a1 = -0.8999 , a0 = 0.0000
AdC1.FReg = 0
PID std
Valid Parameters loaded
After power Cycle
Program Started
ResetReason RCON = 0x83
ResetReason INTCON1 = 0x8000
Gain = 0.7500 , Kp = 8.8980
b1 = -0.8999 , b0 = 0.0000
FuncReg = 1
MOb1.MReg = 3
a1 = -0.8999 , a0 = 0.0000
AdC1.FReg = 0
PID std[/u]
_________________
Thanks,
Vinod |
|
|
gaugeguy
Joined: 05 Apr 2011
Posts: 291
|
|
| Posted: Wed Jul 03, 2024 10:05 am |
|
|
| The contents of the RAM are undefined on power up. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9160
Location: Greensville,Ontario
|
|
| Posted: Wed Jul 03, 2024 10:44 am |
|
|
SRAM is very low power so how long it remains 'good' depends upon VDD being 'good'.
Once VDD goes below the 'retention' value, or whatever it's called, SRAM is no longer 'good'. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19326
|
|
| Posted: Wed Jul 03, 2024 10:56 am |
|
|
Yes, and very low voltage.
The SRAM will retain it's contents down to very close to 1v. Once the
processor actually 'stops', a capacitor on the supply rail can hold the
SRAM contents for many minutes. They guarantee SRAM is held at
1.8v on your chip, and I know it'll actually hold well below this. The
current drawn by the chip with nothing actually working is only a few
nA. Almost certainly what is happening is that the rails are not actually
dropping to zero. |
|
|
Vinod.chinthoti
Joined: 28 Jun 2024
Posts: 8
|
|
| Posted: Thu Jul 11, 2024 7:56 am |
|
|
| Ttelmah wrote: | Yes, and very low voltage.
The SRAM will retain it's contents down to very close to 1v. Once the
processor actually 'stops', a capacitor on the supply rail can hold the
SRAM contents for many minutes. They guarantee SRAM is held at
1.8v on your chip, and I know it'll actually hold well below this. The
current drawn by the chip with nothing actually working is only a few
nA. Almost certainly what is happening is that the rails are not actually
dropping to zero. |
Thanks for info.
How to disable the watchdog timer I tried couldn't successes.
unsigned int FWDT;
#locate FWDT=0x2AFF4
FWDT = 0x0000;
_________________
Thanks,
Vinod |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19326
|
|
| Posted: Thu Jul 11, 2024 8:31 am |
|
|
Depends how you have the fuses set. If it is enabled in the fuses it
cannot be disabled. The point about the software bit is it enables it to
be enabled or disabled _if it is not enabled in the fuses_. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
