We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
It's about the STM32F103. Due to my previous post my application first fills all (at that moment) free stack memory locations with a value of 0x55555555. This all works fine so does the application. I can monitor the stack behaviour in the Memory1 debug window.
But what I see is that at a certain moment data is placed in the stack at some location leaving some gaps of 2 to 10 times (32-bits) dwords containing 0x55555555.
The stack grows downwards in memory addresses. For example I see: (highest memory on top)
Address Data 0xnnnnnnnn-0 data start of stack 0xnnnnnnnn-1 data 0xnnnnnnnn-2 data 0xnnnnnnnn-3 0x55555555 0xnnnnnnnn-4 0x55555555 0xnnnnnnnn-5 data 0xnnnnnnnn-6 data 0xnnnnnnnn-7 0x55555555 0xnnnnnnnn-8 data 0xnnnnnnnn-9 data 0xnnnnnnnn-10 0x55555555 0xnnnnnnnn-12 0x55555555 until 0xnnnnnnnn-nn 0x55555555 end of stack
I do use many interrupt handlers. Is there an explanation for this or is my application buggy?
Thanks
Henk
This is not an indication that your program is faulty. If you allocate a variable on the stack but don't assign anything to it, why would it change the content of the stack, then? Once the variable does out of content, you could get a pattern line the one above.
I investigated it a little more and found out that you are right.
The specific (first) function allocates memory for a structure with that structure containing a non initialized buffer of 255 bytes. Then a second function is called with the address of this structure as an argument...
I declared this structure as static and now the stack memory does not show this 'gaps'. Also declaring the buffer as static will speed up the program execution I think because the microcontroller does not have to copy and uncopy this buffer to and from the stack when entering or leaving the second function.
regards,
The specific (first) function allocates memory for a structure with that structure containing a non initialized buffer of 255 bytes. That was probably not a terribly good idea to begin with. Data objects of that size usually shouldn't be on the stack unless you have very good reasons they need to be there.
speed up the program execution I think because the microcontroller does not have to copy and uncopy this buffer to and from the stack when entering or leaving the second function.
There will be no speed-up if your earlier statement that you're only passing the address of that struct to the sub-function was true. And that's before we begin worrying about what "uncopying" a buffer might even mean.
to be more specific, it's about a c-sourcecode driver that comes with a specific hardware object. This structure is send as part of a message system to this hardware object where transmitted data to this object may contain 0 to 255 bytes of data depending on the message type which is also part of this structure. 'Uninitialized' is not correct as in this particular case at least one byte in this buffer is set.
If a (non-static) structure is declared in some first function A and data is put into this structure, then calling a second function B with the address of this structure as an argument, then I would suspect that the compiler needs to reserve somewhere some memory to store this structure content to be available for function B. As I was learned as far as I remember is that non-static local data is saved on the stack when a next function B is called and retrieved from the stack ('uncopied') when the called function B returns. So maybe the compiler recognizes that the structure data is not needed after return of function B (which sends it further on to function C) and just saves this data on stack and grabs it from stack when accessing function C...
?
If a (non-static) structure is declared in some first function A and data is put into this structure, then calling a second function B with the address of this structure as an argument, then I would suspect that the compiler needs to reserve somewhere some memory to store this structure content to be available for function B.
That suspicion would be incorrect. The only storage the compiler needs for that operation is the storage the data object already occupies. That's one of the advantages of passing the thing by address. And BTW, that mechanism works the same way for static and non-static objects.
What all this tells me is that you may have some more learning about the basics of C programming to do yet, before you worry about intricacies like the detailed contents of the stack at some particular moment of program execution.
Nothing is retrieved from the stack as local/auto variables are simply destroyed as their scope collapses.
The problems really occur when you have an array of static constants when "static const" is NOT used, some compilers will copy these to the stack every time the scope opens.
That was probably not a terribly good idea to begin with. Data objects of that size usually shouldn't be on the stack unless you have very good reasons they need to be there.
Really? Where else? malloc? static? Many of the 'big' blocks of 255 bytes either or both in either way would not be a great choice on many embedded systems.
Choosing a sensible stack size is normally a sensible part of a sensible design. As is sensible use of static and malloc.