Hi Kelly,
Kelly Murray wrote:
I'm using a x1232 part with 8k flash and 256 bytes of ram.
I have tracked down problems that stem from stack overflows.
In my latest version I've eliminated a couple calls off the stack,
but I think I may still be having problems from it. It's hard to
track down and debug, as interrupt routines are certain points seem to
be where it occurs.
I'm looking for suggestions to help avoid it. It seems that unused
local variables still use stack space. This surprised me.
Can I test the SP in code against _end or something to see if stack over
is occuring in an interrupt routine.
You can use a watermark by setting your whole stack (or at least the
area near 0x200) with an initial value and while stepping through your
program keep watching this area for changes in the bytes around 0x200.
Then you can also check this area automatically with a regularly called
function. This method can be useful at least for debugging purposes (and
sometimes even in production code).
One question that would likely help, is that I have config settings in
information area that have a shadow copy in ram. If I can eliminate the
copy in ram, that would free up some stack space. I now erase the
entire section to rewrite it, so if the ram copy is gone, I need another
way to update it.
I assume (especially with your 256 Bytes RAM) that your config data
aren't very big. I don't know what you are using the rest of your info
memory for. If these config data are the only portions of data using the
info flash you can kill two birds with one stone:
One thing is the RAM loss and the other one is the number of write
cycles to the same positions in flash (OK Flash can stand a number of
erase/write cycles but sometimes it is worthwhile to think about this
too). Just virtually partition your infomem to blocks corresponding with
your config data size. Add some space for meta information bearing a
valid-flag for each block of config data and then move your current
config data block along your flash. In code this can look somewhat like:
#define ERASED_FLASH ( '\xff' )
...
/* Config Data: Info Flash resident */
char confData [ NUM_CONF_DATA_BLOCKS] [ CONF_DATA_SIZE + 1 ];
...
/* global Config Data Index: RAM resident */
char cdi = 0;
...
while
(
( confData [ cdi ] [ POS_VALID_FLAG ] != ERASED_FLASH ) &&
( ++cdi < NUM_CONF_DATA_BLOCKS )
);
if ( cdi == 0 ) /* confData has never been initialized */
{
initConfData();
confData [ cdi ] [ POS_VALID_FLAG ] = ~ ERASED_FLASH; /* or 0 or ... */
}
else
{
--cdi; /* last checked data block has been the last valid one */
}
/* now confData [ cdi ] is the current block */
...
Some things have to be mentioned with this method:
- To avoid copy routines with temporary stack copies of these blocks you
have to take both banks of info flash (so you have one block in one bank
while erasing the other bank, then you can copy from one to the other bank).
- When using the last block in the first bank the second bank has to be
erased ->directly after(!) writing this block. After the first
turnaround this prevents the blocks of the second bank from being
considered the currently valid blocks (when searching for it p.e. after
new startup).
- When using the last block in the second bank the first bank has to be
erased ->directly before(!) the next write action to the first block of
the first bank. Otherwise the info flash is considered to be
uninitialized and will be reinitialized.
- If config data are changed more frequently and in a merely loose
manner some hybrid method (using only partial portion of RAM) may be
useful to avoid an every time rewriting the whole block with only one
data changed. Some caching strategy can then be helpful.
Hope that's not more words than news ;-)
Good luck
Arnd-Hendrik
Any suggestions welcome.
-Kelly
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
