STM say:
Dear Mr. Jagdis,
about the section 3.1.2 of RM0016 you are right it is legacy of RM0009
which has covered all STM8A devices. STM8AF devices were on newer
revisions of reference manuals merged with STM8S to RM0016. The STM8AL3
devices, for example has the stack roll-over limit not implemen
On 25/04/2022 08:35, Daniel Drotos wrote:
>
> AN3181
> (https://www.st.com/resource/en/application_note/an3181-guidelines-for-obtaining-ulcsaiec-607301603351-class-b-certification-in-any-stm8-application-stmicroelectronics.pdf)
> mentions roll-over on page12, some Lxx types are listed in the table.
On Fri, 22 Apr 2022, Basil Hussain wrote:
A couple of STM8L datasheets I then looked at (STM8L050 & STM8L151) *do* show
a limited stack of 512 bytes on their memory map, so one could assume that
they behave the same as the STM8S/AF. But, without parts in hand to actually
test, who really knows
On 22/04/2022 14:26, Mike Jagdis via Sdcc-user wrote:
I suspect that what it means is that only S and AF parts covered by
RM0016 implement roll-over limits and you should not assume other
variants are the same. I guess there's some regulation in the automotive
world that says stack space must be
On 21/04/2022 19:16, Basil Hussain wrote:
>
> Maybe when RM0016 says "The stack roll-over limit is not implemented
> on all devices", they actually mean that "a limit does not exist",
> rather than "a limit exists, but does not automatically roll over".
> Because, I guess, thinking about it, what w
On 21/04/2022 16:20, Mike Jagdis via Sdcc-user wrote:
Start within the 0x3ff..0x1ff region and the stack
wraps around. Start outside that and... well... you can have... fun...?
I found the following article in which the author finds through some
experimentation that - at least for the STM8S103
I think it's even weirder than you might expect. Certainly on the
STM8S103F3 SP seems to be a full 16bit register, can be loaded with any
value, and then behaves as you might expect. BUT... there seems to be a
single bit comparator, active for push/pop, that triggers the wrap at
0x3ff and 0x1ff in
On Thu, 21 Apr 2022, Basil Hussain wrote:
All have a stack limit, but some of them may not have the roll-over.
So, in those cases the stack pointer just stops decrementing at the limit
when there is no roll-over?
I don't know, but I don't think so. According to page 32 of RM0016, I
think R
On 21/04/2022 06:07, Ori Idan wrote:
All have a stack limit, but some of them may not have the roll-over.
So, in those cases the stack pointer just stops decrementing at the
limit when there is no roll-over? That is, a push instruction will not
decrement the SP, and the data pushed will just
>
> BTW, I noticed while researching that STM8 Reference Manual RM0016,
> section 3.1.2 "Stack handling" has a note on Figure 4 saying "The stack
> roll-over limit is not implemented on all devices". I'm not actually
> aware of any STM8 devices that _don't_ have a stack limit. Does anybody
> know o
stm8 simulator is in very bad state actually, several things must be
fixed to make them work again. I'll put wrapping on the todo list.
Okay, thanks. Yes, it would be nice if STM8 simulator could implement
this accurately.
BTW, I noticed while researching that STM8 Reference Manual RM0016,
s
On Mon, 18 Apr 2022, Basil Hussain wrote:
Does ucSim simulate this accurately?
No. Wrapping is not implemented. SP is checked against a limit after
push operations, but this generates an error message only. You can set
the limit with "sp_limit=value" command, but it will not be wrapped.
st
12 matches
Mail list logo
