STM32F7xxxx-Nucleo-144 boards with PolySynth code, FPU issues or code problem?

[Christopher Pappas]

Posted on May 19, 2016 at 21:44

The LowPassFilter code seems to be producing transients whenever the cutoff frequency changes rapidly from fully open (1.0f) to fully closed (<0.04f).

Is there a way to debug the operations of the processors hardware FPU? I can't seem to understand where or how these spikes are happening? I am currently using Keil to compile, maybe there is another compiler that has a debugger for debugging the CPU's internal hardware FPU?

If anyone has any ideas or comments, please let me know.

Thanks!! 

Chris

#stm32f767zi-nucleo-board #nucleo-144-synth-stm32f7xx #stm32f7xxxx-nucleo-144-synth #stm32f767zi-nucleo

[Tesla DeLorean]

Posted on May 19, 2016 at 22:12

I suggest you capture the input data so you can replicate and confine the failure.

If you have an example data set you can fixture your code to read the data, and then test FPU and non-FPU versions, and try the data on PC based equivalent code.

The FPU here is pretty basic, it does not carry intermediate results at higher precision, and the results between software/hardware may differ due to algorithms or short-cuts. So you may end up with different behaviour on systems that do, ie a PC with an 80x87

If you want to stress/exercise the FPU, there are likely benchmark tests, or computations that may serve your immediate purpose.

If you can't replicate the failure from the data, then you'll want to look at the hardware, and what the software is doing. ie use of stack space, coherency with DMA, caches, etc.

[Christopher Pappas]

Posted on May 19, 2016 at 23:16

The FPU here is pretty basic, it does not carry intermediate results at higher precision, and the results between software/hardware may differ due to algorithms or short-cuts.

 

 I think you may be right here. The hardware FPU does not have any provisions for math overflow or NaNs, so single-point precision operations may be overflowing into double-precision intermediate results. It seems like there is no ''FPU - Overflow'' error in this processor.

I wonder if Soft-FPU routines have any overflow error checking. I can re-compile with Soft-FPU and test it.

I am also wondering if the level of optimization of the C compiler(Level 3) and/or the CPU's i-caches may be throwing off the timing and causing NaNs in the output of the filter for the input data that causes the transient condition (cutoff 1.0f to cutoff 0.0f with no delay). I will try disabling the i-caches and also re-compile with Level 0 optimization.

The

http://MusicDsp.Org

site also has posts about

http://musicdsp.org/archive.php?classid=3#181

, saying it is unstable as well. My lack of knowledge about what the filter code is doing at any point in time is also not helping to resolve this.  

http://www.dspguide.com/

 maybe I need to hit the books again...hmm.

Thanks Clive for your input and taking the time to help me!

[Christopher Pappas]

Posted on May 24, 2016 at 21:34

I ordered an STM32F767ZI-Nucleo board today. Same board, but has Double-Precision FPU. This should also allow me to run the current LPF code with Double vars instead of Floats. Hopefully that will eliminate FPU-Overflow problems if they exist.

[Tesla DeLorean]

Posted on May 24, 2016 at 22:34

$23 is pretty aggressive pricing, so ordered some too...

Was looking for the DISCO to be in stock, but still waiting.

With some example datasets you should be able to make a thorough determination.

[Christopher Pappas]

Posted on May 27, 2016 at 03:31

I got the STM32F767ZI-Nucleo board today. After updating all the DFP Packs from Keil and re-writing the PolySynth project to enable Double Precision FPU, I am still getting the same transients out of the LPF routine. I think it is just an issue with the Filter code now. I will try swapping out the LPF code in hopes to find a more stable filter.

 

[Tesla DeLorean]

Posted on May 27, 2016 at 14:46

Yes, so interestingly, support for all the new F7 chips and boards is provided within the .ZIP file

http://www.keil.com/pack/Keil.STM32F7xx_DFP.2.6.0.pack

[Christopher Pappas]

Posted on May 27, 2016 at 18:59

There is a bug with the DFP v2.6.0. It will not allow the user to select ''Use Double Precision'' for the target STM32F767ZI.

This a quick workaround provided to me by Keil support.

Go to ''Options for Target...'' - ''C/C++'' tab, ''Misc Controls''. Add ''

--cpu Cortex-M7.fp.dp''

to the end of the existing string. Before you compile, go to the ''Options for Target..'' - ''Target'' tab, and select ''Not Used'' for Floating Point Hardware to prevent conflicts.

This appears to work okay. I can see valid double precision values in memory during debug.

[Tesla DeLorean]

Posted on May 28, 2016 at 00:36

The stars must have aligned, Mouser delivered my boards this morning after I left.

[Tesla DeLorean]

Posted on May 28, 2016 at 00:56

//****************************************************************************
 
// FPU Programmer Model
// http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489b/Chdhfiah.html
 
void FPUCheck(void) // [e-mail]
{
 uint32_t mvfr0;
 
 printf("%08X %08X %08X\n%08X %08X %08X\n",
 *(volatile uint32_t *)0xE000EF34, // FPCCR 0xC0000000
 *(volatile uint32_t *)0xE000EF38, // FPCAR
 *(volatile uint32_t *)0xE000EF3C, // FPDSCR
 *(volatile uint32_t *)0xE000EF40, // MVFR0 0x10110021 vs 0x10110221
 *(volatile uint32_t *)0xE000EF44, // MVFR1 0x11000011 vs 0x12000011
 *(volatile uint32_t *)0xE000EF48); // MVFR2 0x00000040
 
 mvfr0 = *(volatile uint32_t *)0xE000EF40;
 
 switch(mvfr0)
 {
 case 0x00000000 : puts("No FPU"); break;
 case 0x10110021 : puts("FPU-S Single-precision only"); break;
 case 0x10110221 : puts("FPU-D Single-precision and Double-precision"); break;
 default : puts("Unknown FPU");
 }
}
 
//****************************************************************************
Testing printf
STM32 2048 KB FLASH, 512 KB RAM, 0046002F-33355109-36343130 UNIQUE
C0000000 FFFFFFF8 00000000
10110221 12000011 00000040
FPU-D Single-precision and Double-precision

Fixed forum transition destruction of content

[Tesla DeLorean]

Posted on May 28, 2016 at 18:21

Double multiply looks to be taking 12 cycles now vs 53.5 in software. Building with GNU/GCC...