STM8S207C8 initial stack pointer

fggnrc · ‎2009-10-27

Posted on October 28, 2009 at 01:49

fggnrc · ‎2011-05-17

Posted on May 17, 2011 at 15:05

I'm debugging my firmware which runs on a STM8S207C8T6 (other markings are: 99059 V6 MYS 901).

This device RAM seems to be 6Kb, since the initial SP value is $017FF and subroutine calls work without resetting the SP value.

According to the STM8S20x datasheet, this device should have 4Kb of RAM, and its initial SP should be $0FFF.

Where is the error?

Regards

EtaPhi

brazov2 · ‎2011-05-17

Posted on May 17, 2011 at 15:05

Hi,

stack is @17FFh, but I think that only 4k RAM is guaranteed. You can try to enjoy 6k RAM under your risk if not specified in the datasheet 🙂

coluber

fggnrc · ‎2011-05-17

Posted on May 17, 2011 at 15:05

Hello, coluber.

If it's true what you say, my device must be considered defective because it doesn't meet datasheet specifications.

Those surplus bytes are automatically assigned to the stack area.

If there is no guarantee on their functionality, the same applies to the STM8 core...

EtaPhi

brazov2 · ‎2011-05-17

Posted on May 17, 2011 at 15:05

Hi,

I don't think those surplus bytes are assigned to the stack, as you say, I suppose stack is the same size as specified in the datasheet (if I remember well 1024 bytes), and starting @17FFh. This just to give an explanation of what you're observing.

Coluber :D

fggnrc · ‎2011-05-17

Posted on May 17, 2011 at 15:05

I partially agree with you, Coluber.

STM8S207C8 stack is 1024 bytes depth.

STM8S20x datasheet states that stack grows downwards from the highest RAM address.

This address should be 0x0FFF for 4K devices, while it should be 0x17FF for 6K devices.

The STM8S20x datasheet states also that the hardware initializes SP to its upper value and forces its upper bits so that, when SP overflows, it ''wraps'' to its higher value.

This behaviour doesn't allow my firmware to ignore this issue, since if I reset SP to 0x0FFF, the hardware will change the upper bits.

Even if this constraint seems to be uneffective during debug, since SP may be changed to 0x0FFF, it doesn't agree with the datasheet. So my device is defective (even if it seems to work properly) because it doesn't follow STM specification.

This strange behaviour was discovered by my boot code, which checks core registers and RAM. If all checks are passed, the firmware can run.

Now I'm experimenting what happens to devices with this gift from STM, since 2K are always welcome.

EtaPhi