Trying to make sense of the audio system on the STM32F407-g Discovery board:

APara.6 · ‎2025-02-08

Hello. For a couple months now, I have been trying to get the microphone on the STM32F407-g Discovery board to work. It started out as a minor part of a self-guided course, but now it's turned into a personal quest. The farthest I've gotten so far is receiving random noise (totally random: an equal rate of 1s and 0s) into an audio buffer. Now I'm at the point where I've wired up a logic analyzer and am seeing exactly that noise coming from the microphone itself.

After two malfunctioning examples of the STM32F407, I ordered a third and was extra careful to only handle it with an anti-static wrist strap clipped to the bottom USB port. I loaded the program and got the same result:

The rising and falling edges of the data signal do closely follow the clock signal:

Furthermore, all three signals disappear if I remove the call to `BSP_AUDIO_IN_Record(&audioBuffer, 128)` from my main.c. So it looks to me that this really is the signals going into and coming back from the audio sensor.

Granted, it's Pulse Density Modulation, so under some circumstances it should look like this, but I'm testing this in a quiet environment.

Also, I am a dude-off-the-street novice; I could definitely be breaking these boards or messing up the audio sensing in some way which I just can't know to avoid. But, based on what I know about this technology, this evidence takes the problem out of the realm of software: it looks to me like something is wrong with the hardware, and it's wrong right out of the box. Find my program attached, for you to check.

I'd like to be wrong about this.

-Aidan

waclawek.jan · ‎2025-02-09

When "quiet", the microphone outputs mid-level, i.e. roughly the same number of zeros and ones.

You have to use a software filter to convert PDM to PCM. There is probably a related example in Cube, search there or at the internet.

JW

APara.6 · ‎2025-02-09

Oh, right, because audio signals need to express both positive and negative magnitudes...

Well, there goes a month of my efforts. Sorry for the dramatic thread title.

Ozone · ‎2025-02-09

Assuming you are speaking about the F407 discovery board, this is a "legacy product".
Check out ST's download page for board, there is a SPL-based (the "legacy Standard Peripheral Library") firmware package with a properly working example for this microphone.

I might add, this is one of ST's most successful MCU boards, if not <the> most successful one.

And, when doing projects for this or similiar boards, I start out with SPL code, not Cube.

APara.6 · ‎2025-02-10

Yes, I am embarrassed that I did not see the reason for the PDM signal being as it is.

I found two possible candidates for the library you mentioned: STSW-STM32068 and STSW-32065. The latter more closely matches the name "Standard Peripheral Library," but it only has one recording-related example, and I don't think it's for the STM32F407-g. The former does seem to have a microphone-use example file, and it's different from the one offered through CubeIDE.

I am curious, though: why are the examples offered through CubeIDE less current, or less helpful, than the "legacy?" examples?

Ozone · ‎2025-02-10

> I am curious, though: why are the examples offered through CubeIDE less current, or less helpful, than the "legacy?" examples?

That I can tell you.

The F407 discovery is a "legacy" board, in a sense that the SPL was still state of the art when it was released. And remained so for more than a year of it's initial phase. Thus examples were all based upon the SPL.

I think HAL/Cube was already in the making at that time, for a reason. The "silicon inflation" (release of new MCUs and variants) had already started, and proper software/firmware/example support for all variants was somewhat lacking. Cube/HAL (and CubeIDE) contains a lot of machine-generated code /headers, and code generation tools itself - assumed to speed things up. It seems this proved to be a fallacy. Support for new silicon in and the overall quality of BSPs and examples fell behind ever since. With the official inclusion of new silicon support obviously takes precedence over example code density (peripherals, use cases) and quality.

To circle back to the F4 discovery, nobody had the time to port all the "old" SPL examples to Cube.
If I remember correctly, the F429-discovery was the first board released with Cube support only.

Andrew Neil · ‎2025-02-27

@Ozone wrote:
To circle back to the F4 discovery, nobody had the time to port all the "old" SPL examples to Cube.

Not just the F4 discovery - this is true for a lot of the boards which predate Cube.

There are still loads of example projects which are not Cube-generated:

https://community.st.com/t5/stm32-mcus-products/some-example-projects-don-t-use-ioc-file/m-p/698338/highlight/true#M255312

not sure that's even limited to things which predate Cube?

Ozone · ‎2025-02-27

> There are still loads of example projects which are not Cube-generated: ...

I very much agree.
There isn't even the need to limit one's scope to the vendor.
A lot of "middleware" can easily ported between different MCUs, especially Cortex M devices. One only has to replace the respective HAL layer.

For instance, I took the LCD display graphics driver from the F407 discover package, and reused the graphic primitives and font handling on a MikroE F407 board (different LCD), and on a LPC1768 board with a EmbeddedArtist LCD display.

Or taking the F407 Discovery FatFS code and porting it to the F303 Discovery, for a SPI-driven SD card interface.

Andrew Neil · ‎2025-02-27

@Ozone wrote:
There isn't even the need to limit one's scope to the vendor.
A lot of "middleware" can easily ported between different MCUs, especially Cortex M devices. One only has to replace the respective HAL layer..

Indeed - this is, of course, the entire point of a HAL layer.

Above the stuff which actually deals directly with the proprietary MCU hardware, code should be easily portable.

Ozone · ‎2025-02-27

> Indeed - this is, of course, the entire point of a HAL layer.
> Above the stuff which actually deals directly with the proprietary MCU hardware, code should be easily portable.

Unless the HAL layer itself hijacks important MCU resources, and injects other cumbersome and detrimental concepts that taint the middleware ...