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.
