At the beginning of main I have two variables, namely:
unsigned char audioDataBuffer1[512]; unsigned char audioDataBuffer2[512];
Later in the code I use them as buffers for audio data from SD Card.
The problem is that the stack pointer is set too low and these big variables overwrite my stack pointer which is set automatically by Keil startup code. How is this possible?
I have noticed that the problem disappears when I set above variables to global, or when I use malloc instead.
I would appreciate if you could explain what goes wrong here and is there any reason I should not declare large variables like this?
Thank you.
Most always, it cleans up and calls main again.
I will avoid saying that what you say is just plain wrong. It is very unlikely.
You, as the creator of the system, should do something appropriate. Like fall through to code that triggers a watchdog reset.
Unfortunately, from what I've seen, this is a very rare piece of forethought. Many professional and seasoned firmware designers neglect such details.
Many embedded linkers insert a "jump reset" at the end of main, so it is, in fact likely. hiowever I see no case where relying on that would make sense.
as to some previous comments
there should always be a bit of extra thought before placing large variables on the stack. If nothing else, large stack variables are likely to trip any other developer who comes later and have to take over the code.
There is, in some camps, a fear of global variables and nobody thinks abhout the fact that variables local to main are just as much "forever variables" as globals.
I have seen projects developed with a fear of global variables where you ahve a huge structure in main() and carry a pointer to it all over the place, in fact making the variables global.
NO, do not make all variables global, but THINK (sorry) before making varibles local to main().
Erik
Just that a jump to reset may fail spectacularly - lots of startup code is written based on the assumption that the processor comes from a real reset. With just a jump to the reset vector, then timers, interrupts sources etc might already be up and spinning. After the fake-reset, the code can then get hammered by "impossible" interrupts.
Anyway - people should try to program by contract. So staying away from constructs where there doesn't exist an explicit contract promising a specific behaviour. And people should try and give some of the promises from the compiler vendor a bit less weight than they do, and try more to just follow the language standard instead of making use of a compiler-specific feature. Unless, of course, that compiler-specific feature really is important for the specific target platform.
I said "You, as the creator of the system, should do something appropriate. Like fall through to code that triggers a watchdog reset."
Is there any question about that? I hope nobody would be foolish enough to argue against it.
And curiously enough some people arrive at such a point of view without even learning enough about their programming language to recognize that they're mixing up two different concepts: a variable's lifetime and and its visibility (which C splits up further into "linkage" and "scope").
Fear of globals is primarily motivated by possible namespace pollution and lack of encapsulation. But these worries concern visiblity only. There's absolutely no need to abolish static lifetime just to get rid of (perceived) excess visibility.
In short: the keyword static exists, so use it.
Except in cases where randomly resetting equipment isn't seen as a solution, but rather could create some even more dangerous situations to arise. In those cases I'd generally argue against it.
Sometimes it's appropriate to shutdown into a safe state and sound an alarm.
Blanket statements of what something should do, without really thinking it through, are a bit asinine.
View all questions in Keil forum