Page 1 of 2
STM32F7 SV#8 error
Posted: Sat Nov 28, 2015 2:26 pm
by Anubirux
I have a problem with sv8 error. It happens sometimes in may application so I ported irq-storm from f4 to f7 and it happens there also.
I post ported code - it uses cdc instead of serial but it shouldn't be the case.
Re: STM32F7 SV#8 error
Posted: Sat Nov 28, 2015 3:04 pm
by Giovanni
Probably you have an IRQ at an above-kernel priority level: 0 or 1.
Giovanni
Re: STM32F7 SV#8 error
Posted: Sat Nov 28, 2015 4:21 pm
by Anubirux
SV#8 happens in TIM3 IRQ. Priority of this irq is set to 7, ive checked nvic register and its 0x70 so its ok.
Error happens in irq-storm also, not only in my application.
Please check posted example. It's simple copy paste from STM32F4 to STM32F7.
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 12:07 am
by AndreR
I fiddle with the exact same problem for a week now and was not able to identify the root cause.
Problem:
#SV8 after random time (5mins - 8 hours)
I print out all IRQ levels in my own chSysHalt hook, they are all below kernel level.
Furthermore, I also checked that all IRQ control paths call CH_IRQ_PROLOGUE and CH_IRQ_EPILOGUE.
Processor: STM32F7
Any hints on what can cause a SV8 would be great. I expect the core and the exception stacking to be the same as in the M4, but maybe you have a deeper insight into the changes of M4 to M7.
I am running my F7 at maximum speed, 216MHz, caches and ART are on. Flash access via ITC.
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 7:48 am
by Giovanni
SV#8 is usually caused by an IRQ preempting a critical zone (it should never happen). The only way to have this is to have some ISR at priority 0 or 1, those levels are reserved as "fast interrupts" and can preempt the kernel.
You may activate CORTEX_SIMPLIFIED_PRIORITY in chconf.h, this makes the kernel mask all priority level, if my hypothesis is right the error should disappear.
Giovanni
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 7:49 am
by Giovanni
AndreR wrote:I fiddle with the exact same problem for a week now and was not able to identify the root cause.
You mean it started happen recently? could you assess the repository revision that started the problem? that would point right to the cause.
Giovanni
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 8:04 am
by Anubirux
CORTEX_SIMPLIFIED_PRIORITY works, but it is only work around of real problem. As far as I remember this problem fallowed me from the beginning. The earliest revision which I'm sure I used is 8391.
Edit: I also checked BASEPRI register when error happens and its 0. To check it I modified _dbg_check_leave_isr() as fallow (to use PRIMASK instead of BASEPRI thus leaving BASEPRI intact):
Code: Select all
void _dbg_check_enter_isr(void) {
__disableIRQ();
if ((ch.dbg.isr_cnt < (cnt_t)0) || (ch.dbg.lock_cnt != (cnt_t)0)) {
chSysHalt("SV#8");
}
ch.dbg.isr_cnt++;
__enableIRQ();
}
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 9:24 am
by Giovanni
I added IRQ storm to the F7, it happens here too...
Giovanni
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 9:30 am
by Giovanni
It seems to be specific on the M7, I am running IRQ Storm on the F4 and nothing...
This is hinting to a fundamental difference between M4 and M7 because the code is exactly the same.
Giovanni
Re: STM32F7 SV#8 error
Posted: Sun Nov 29, 2015 10:31 am
by Giovanni
Found the problem and it is really ugly...
There is an errata on the M7 (r0p1, 837070) that states:
Increasing priority using a write to BASEPRI does not take effect immediately
This update is required to be serialised to the instruction stream meaning that after this update completes, it takes effect
immediately and no exceptions of lower priority than the new boosted priority can pre-empt execution.
Because of this erratum, the priority boosting does not take place immediately, allowing the instruction after the MSR
to be interrupted by an exception of lower priority than the new boosted priority.
This effect is only limited to the next instruction. Subsequent instructions are guaranteed to see the new boosted
priority.
The proposed workaround is:
Which really bothers me. If the effect is limited to the next instruction shouldn't a simple NOP suffice?
Anyway, I am going to try this.
Giovanni