Division by zero exception flag not set in STM32H7 FPU

[Gpeti]

I'm digging into the FPU of a STM32H743 (Nucleo board, Keil IDE).

I've checked that the FPU is enabled in register CPACR.

I've compiled the following dumb code:

volatile double test = 0;
 
test = 1.0 / test;

If I look at the assembly I've got:

VDIV.F64 d0,d1,d0

where d1 contains the double representation for 1, d0 contains the double representation for 0.

After the instruction d0 contains

0x7F00...00

which is a representation for infinity, so the result is consistent.

However the flag DZC in register FPSCR is not set, as I was expecting it would be.

Am I missing something ?

[berendi]

See this item in the errata

[Gpeti]

Oh my god ! Thank you, completely missed this point. I usually look to the errata for peripherals but I forgot there can be errors in the core itself...

[Gpeti]

However the errata is about the mapping of the FPU interrupt in the NVIC but I was more looking at the flags in register FPSCR. These flags are completely independant from NVIC. So they should be set anyway ?

[waclawek.jan]

And do you see the flag being set if you perform a single-precision division?

JW

[berendi]

How do you examine FPSCR?

Because when I just look at it in the CubeIDE register view while single-stepping a division by zero, sometimes the debugger forgets to update its value in the view.

When the code reads it via __get_FPSCR() after a division by zero, bit 1 is always correctly set.

The interrupt handler is never called.

When I change the debugger probe setting from ST-Link GDB Server to OpenOCD, it always updates the value of FPSCR.

[Gpeti]

I'm using Keil debugger. But it's a very good tip, I will try it ASAP.

[Gpeti]

Berendi, you were exactly right.

Reading FPSCR from the executable (through CMSIS function, using instruction VMRS) returns 0x00000002 ie. bit DZC set.

Reading from the debugger FPU tab returns 0 (System Viewer tab).

More confusing, Keil provides another way to read FPSCR, from the Registers tab where the output is correct.

I assume this debugger inaccuracy might be linked to the Cortex FPU implementation error mentioned in the STM32H7 errata sheet ?

[berendi]

Or it might be the lazy stacking feature, if the debugger is using interrupts to handle breakpoints. Check the lazy stacking bit in FPU->FPCCR, or try to clear it.

FPU->FPCCR &= ~FPU_FPCCR_LSPEN_Pos;__ISB();

[waclawek.jan]

Or it's simply a bug in Keil. Try to ask at their forum.

JW