This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange stack behaviour question.

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

Parents
  • Hi,

    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...

    ?

    Henk

Reply
  • Hi,

    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...

    ?

    Henk

Children
  • 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.