Question to developers of stm8 core about interruption behavior

[Vyacheslav Azarov]

Posted on October 18, 2017 at 15:06

Hello. 

I'm trying to develop for STM8 one simple but correct program. But I can not find an answer to one important question. Please explain the behavior of the interrupt system in the following situation. In the errata sheet (DocID17140 Rev 5, Section 2.1.3), a workaround for the abnormal behavior of the interrupt system was suggested. However, this requires that at least one interrupt handler instruction be guaranteed executed. Otherwise, the process of nested interrupt will start, which can lead to program crash. I would also like to clarify what is meant by the phrase ' interrupt is cleared or masked when the context saving has already started'? Means this the interruption of the interrupt request logic signal and the arrival of a new request with a different interrupt  level, or something else?  I ask you to explain, in the same way, the behavior of the interrupt system, due to the impact of a flurry of events, that is, at simultaneously sending interrupt signals to the controller, with different priorities and levels. And one more question.  Why, in the errata sheet (DocID17922 Rev 7 Section 1.1.1) for STM8Lxxx, this situation have not a workaround.  Does this mean that interrupts cannot be reliable used ?

I will be very grateful for the informative answer.

Sincerely.

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/c9/f9/ef/bf/63/91/4a/1f/CD00265449.pdf/files/CD00265449.pdf/jcr:content/translations/en.CD00265449.pdf

http://www.st.com/content/ccc/resource/technical/document/errata_sheet/61/c9/01/6a/2b/f5/4b/24/CD00284474.pdf/files/CD00284474.pdf/jcr:content/translations/en.CD00284474.pdf

#interrupt #stm8 #errata #workaround

[raimond]

Posted on January 13, 2018 at 18:52

I'll try a response.

When you protect a critical section with 'sim' and 'rim' instructions, there is a chance that when you execute 'sim' to disable interrupts, a context saving for an interrupt to be started already and that interrupt will run with the priority '10' of main. Probably the silicon bug is that the CC saved takes the I1:I0 of main in this case (or remains at 10 value) and doesn't get the correct value from IPSR register. That interrupt will so get preempted by any other interrupt. This is seldom a problem, unless it is a very very critical one designed to not be interrupted by anything (due to timing constraints).

Usually you can live with that.

A very simple workaround is to just not use the 'rim' ... 'sim' instructions but to use specific masking of the interrupts from the interrupt mask bits from ther control/status registers (for example, mask a uart rx interrupt by reseting the RXNEIE bit). This a good practice in general, don't use global enable disable as much as possible.

The ST workaround is to set I1:I0 bits as required manually at the beginning of the interrupt routine (by push #val/pop cc instruction sequence) but this procedure also leaves a small window of a few cycles in which another interrupt can preempt the current one, and as I said, maybe this current one is very very time critical....

[Vyacheslav Azarov]

Posted on January 13, 2018 at 21:38

Thanks for reply Gradomir,

This problem is more serious than you think. And it's not  about time only. Interrupt handlers with the highest preemption priority can be performed near the boundary of the stack. In addition, they usually serve urgent events in the system, what require quick response. When such a handler is superseded by a lengthy interrupt process with a lower level, this will not only lead to a delay in servicing a higher priority event but also to stack overflow. Given such an unusual behavior of the interrupt controller, it is necessary not only to significantly increase the stack of interrupt handlers, but also to provide for the possibility of hardware operation with service failures, on the part of the processor. Which is not always possible. I would very much like to receive detailed explanation of the mechanism of the interrupt system of this remarkable microprocessor.

[raimond]

Posted on January 14, 2018 at 07:42

Probably you confuse some things. There is no such thing as 'stack of interrupt handlers'. There is only one stack. You can have 3 levels of interrupts stacked at one time, and with this bug we can have one more, so 4 levels. This is an increase of course, but a finite one and quite controllable. Remember that this bug happens when the program is in 'main' (no interrupt). As long as one interrupt fires and you are in interrupt processing, there is no bug. You can hape up to three preemptions (as designed) or 4 preemptions (with the bug).

I admit, as I said, the problem is when you have a very critical interrupt that just doesn't support interruption of another long interrupt. In this case you have a workaround: just don't use critical sections with global disable and enable. Enable and disable interrupts be individual mask bits of the peripherals. Or organize the code to have only short interrupts, an no one so critical....

Yes, I also want to know more about it.  But it seems no STM8 engineers are around here. It seems the STM8 family is freezed in this state, no design workforce allocated by ST anymore for it (the 8pin 001 chips this year is an exception, but they are no more than the 003 chips put in a different package. They even not bothered to cut the unused pins from the hardware core...). It is understandable, ST is focusing on the STM32 chips, and they do a pretty good job there. We will remain with the STM8 chips in the rpesent state. They are quite amazing. I'm using STM8 for my 5V designs, usually simple designs which dono't require more than a uart, a timer, one spi, sometimes an i2c... basic staff.

[Vyacheslav Azarov]

Posted on January 14, 2018 at 10:47

Thanks for the support. Maybe I did not exactly said, but it does not really matter where the interrupt routine stack is, in the memory of the current process or in a separate area. I'm not confusing anything. Interrupt service mechanism is not described in sufficient detail. And the presence of this limitation makes the nested interrupt system almost unusable.

[raimond]

Posted on January 14, 2018 at 11:48

You say you don't confuse things but at the same time you don't care wether

an interrupt routine stack is (or can be). But I told you, there is no

possibility to define a separate stack area just for the interrupts. This

is not a cortex-m cpu.

If you say that the interrupt system is almost unusable these are hard

words. It's like the ST designed an MCU with no interrupts. I'm sure it is

not the case. You seem to just look at these chips and you declare you

cannot use them. I'm using them, and I'm using them with interrupts a lot.

I can't say more about it.

2018-01-14 11:47 GMT+02:00 Vyacheslav Azarov <st-microelectronics@jiveon.com

>:

STMicroelectronics Community

<https://community.st.com/?et=watches.email.thread>

Re: Question to developers of stm8 core about interruption behavior

reply from Vyacheslav Azarov

<https://community.st.com/people/Azarov.Viacheslav?et=watches.email.thread>

in STM8 MCUs Community - View the full discussion

<https://community.st.com/message/181176-re-question-to-developers-of-stm8-core-about-interruption-behavior?commentID=181176&et=watches.email.thread&sharpcomment-181176>

[Vyacheslav Azarov]

Posted on January 14, 2018 at 12:46

That is why I would like to receive exhaustive answers to my questions. What would eliminate this misunderstanding.