Showing results for 
Search instead for 
Did you mean: 

Division by zero exception flag not set in STM32H7 FPU

Senior II

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


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 ?


See this item in the errata


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

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 ?

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



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.

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

Senior II

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 ?


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.


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