STM32F7 SV#8 error

[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.

[Giovanni]

Probably you have an IRQ at an above-kernel priority level: 0 or 1.

Giovanni

[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.

[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.

[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

[Giovanni]

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

[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();
}

[Giovanni]

I added IRQ storm to the F7, it happens here too...

Giovanni

[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

[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:

Code: Select all

CPSID i
MSR to BASEPRI
CPSIE i

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