STM32F4 Audio Buffer Glitch

[Giovanni]

Hi,

No clear idea, I thought it could be garbage picked up the DMA, you need to understand if the cause is SW, HW or measurement first.

Giovanni

[everdrone]

Hi,

No clear idea, I thought it could be garbage picked up the DMA, you need to understand if the cause is SW, HW or measurement first.

Giovanni

Hi Giovanni,

I tested the program on another brand new STM32F4 Discovery Board and the problem still occurs, in my opinion it's not an hardware problem (if it is, it's common to both my boards).

As for measurement, i have no professional measurement equipment to test this, the images i have uploaded before are software generated, this meaning that part of the spectral noise you see there may be due to my audio interface or the cables i use to connect the board to it. In a way, it's somehow a lo-fi measurement.

I also thought of a current loop since all of the equipment i use is connected to my PC (audio card is connected via USB to the PC, the board is connected via USB to the PC and via audio jack to the audio card). I also tried to power up my Discovery Board with an external 5V power source but i found out it doesn't work properly until you connect it to the power source through the USB plug on the board, by breaking down a USB cable and connecting the 5V and GND pins to the power source directly, leaving out D- and D+ floating.

I'll try the way described above as soon as i can get my hands on the soldering iron again.

The fact that the noise is present even if the STM32 board audio output is not routed to the speakers bugs me tho.

I will let you know by the way.

Thanks again.

[everdrone]

Ok, software tests have been made.

I added another sine wave generator modulating the amplitude of the first sine wave, this resulted in heavy latency.

I also made the orange LED turn on whenever the Half Transfer interrupt is fired and turn off when the Transfer Complete interrupt occurs.

The orange LED is clearly blinking, meaning that there's a significant delay between the two interrupts.

Then i added even more float arithmetic computation to the processing() function and the LED blinked even more slowly, generating lots of noise.

So is this a latency issue?

How come the MCU get slowed down this much just by computing some floating point arithmetic?

[Giovanni]

Hi,

Is FPU handling enabled in the makefile? by default it is disabled.

Giovanni

[everdrone]

Hi,

Is FPU handling enabled in the makefile? by default it is disabled.

Giovanni

FPU was set to "no".

The noise disappeared!! Thanks!!!

But one last question: should i use "softfp" or "hard" ?

The program is meant to handle a heavy load of floating point functions such as <math.h> sin(), tanh(), log() and pow(). even if i'm planning to switch to some polynomial approximations of the functions there will be a lot of them.

What configuration do you suggest, and why? (what's the real difference in the ARM context?)

Thanks again (and a lot!)

[Giovanni]

Hi,

You should look into GCC documentation, "hard" is the performance setting anyway.

https://gcc.gnu.org/onlinedocs/gcc-5.4. ... RM-Options

Giovanni