librelist archives

Stack limitations on STM8

Stack limitations on STM8 by Spencer Russell
- Re: [atomthreads] Stack limitations on STM8 by Kelvin Lawson
  - Re: [atomthreads] Stack limitations on STM8 by Kelvin Lawson
    - Re: [atomthreads] Stack limitations on STM8 by Kelvin Lawson

Stack limitations on STM8

From:: Spencer Russell
Date:: 2010-10-08 @ 20:52

I've been told by both Bruno at Raisonance and our ST FAE that care needs 
to be taken with the stack pointer on STM8 processors. Apparently the bits
9 and 10 of the SP are fixed at one, so the range of the SP is really 
0x600 - 0x7FF.

Is this accounted for somewhere in AtomThreads that I haven't found yet? 
It would seem that care is necessary as to where you allocate the thread 
stack arrays to make sure they're within the allowed stack space. (perhaps
this is related to my last query about the _stack variable use).

-Spencer

Re: [atomthreads] Stack limitations on STM8

From:: Kelvin Lawson
Date:: 2010-10-09 @ 11:32

Hi Spencer,

> I've been told by both Bruno at Raisonance and our ST FAE that care 
needs to be taken with the stack pointer on STM8 processors. Apparently 
the bits 9 and 10 of the SP are fixed at one, so the range of the SP is 
really 0x600 - 0x7FF.

I have so far worked on the basis that the following text in the STM8
programmer's reference was true: "The 16-bit Stack Pointer provides
access to a 64K-level Stack.". However I now see that this is
qualified elsewhere as follows: "Depending on the product, the most
significant bits can be forced to a preset value."

> Is this accounted for somewhere in AtomThreads that I haven't found yet?
It would seem that care is necessary as to where you allocate the thread 
stack arrays to make sure they're within the allowed stack space. (perhaps
this is related to my last query about the _stack variable use).

It looks like Atomthreads needs to use the CPU part to determine the
location of all stacks. Do you know if there is a table somewhere
which shows the stack locations by part? I have just looked at the
STM8S105 reference manual (the part I used) and the text refers to 64K
stack space without any qualification, other than a diagram which
shows stack at a particular location. This is confusing to say the
least.

Incidentally the core Atomthreads kernel port does not care where the
stack is located. It is up to the application to decide where
everything is located in the memory map, so all you need to do is to
tell the linker where your stacks should live. However as you've
pointed out, this is not done for the example application
tests-main.c. Once I get to the bottom of which parts have limited
stack locations I will fix up the example application to pay attention
to it, but meanwhile you should be able to continue by explicitly
putting your application's stacks in the correct location.

Thanks for bringing this to my attention,
Kelvin.

Re: [atomthreads] Stack limitations on STM8

From:: Kelvin Lawson
Date:: 2010-10-18 @ 20:25

Hi Spencer,

>> I've been told by both Bruno at Raisonance and our ST FAE that care 
needs to be taken with the stack pointer on STM8 processors. Apparently 
the bits 9 and 10 of the SP are fixed at one, so the range of the SP is 
really 0x600 - 0x7FF.
>
> I have so far worked on the basis that the following text in the STM8
> programmer's reference was true: "The 16-bit Stack Pointer provides
> access to a 64K-level Stack.". However I now see that this is
> qualified elsewhere as follows: "Depending on the product, the most
> significant bits can be forced to a preset value."

I've been looking through the datasheets for various STM8 parts and
see that generally the memory maps mention a particular stack size
(512 bytes in the case of the STM8S105), but there is nothing that
states that the device force some upper bits to particular values,
leaving you with impression that it could just be a suggestion on how
to allocate your memory.

Nevertheless, there is the text in the programmer's reference
"Depending on the product, the most significant bits can be forced to
a preset value", and I found the following in an errata document:
"Stack pointer address compatibility across STM8S105xx family devices
is not currently possible due to the present RAM mapping.". So it
looks a bit like the limitation was not highlighted to those
generating the part-specific documentation.

I was surprised that this has not caused me issues before, however,
given that I have run several threads simultaneously with stack
locations other than that described in the memory map. I decided to
experiment with an STM8S105 device and this particular device seems to
be happy to use a stack pointer outside of the 512 byte range.
According to the memory map, this device should use stack in
0x600-0x7FF, however I can set the SP register to 0x3FF and on reading
it back it still contains 0x3FF (implying that the bits are not fixed
within the register). Furthermore if I carry out PUSH or POP
instructions and examine the memory contents, they do indeed modify
the memory below 0x3FF rather than modifying the 0x600-0x7FF range as
you might expect. Either the limitation is part-specific or it only
applies to particular addressing modes. I will seek clarification from
ST about this.

Best regards,
Kelvin.

Re: [atomthreads] Stack limitations on STM8

From:: Kelvin Lawson
Date:: 2010-11-17 @ 00:28

Hi Spencer,

> I've been looking through the datasheets for various STM8 parts and
> see that generally the memory maps mention a particular stack size
> (512 bytes in the case of the STM8S105), but there is nothing that
> states that the device force some upper bits to particular values,
> leaving you with impression that it could just be a suggestion on how
> to allocate your memory.

I posed the question to ST and they said the following:

"the stack is a 16-bit register (SPL, SPH), freely updateable. It is
reset at power up and system reset to its default value, that may
later be changed by RTL code with the information from linker, or your
own code."

So according to this response there are no limitations on the stack
locations, which tallies with my own findings so far. I can impose
specific limits to the stack regions in Atomthreads, but according to
ST there are no limits to impose. Are you finding that there is an
issue for you?

Best regards,
Kelvin.