2017-08-02 02:42 AM
I have a clean slate CubeMX project on a STM32F401C-Discovery board. I have set up the onboard Cirrus audio DAC, and send a hard-coded test signal to it via DMA-driven I2S. I can hear the sound, but it is at wrong frequency.
The 2kHz test signal, and the i2s-3 is set to 48kHz samplerate, but depending on how I configure the PLL, I hear 122Hz, 180Hz or 244Hz audio. I have confirmed with a logic analyzer that the I2S protocol runs too slow. The only things I have changed from the CubeMX generated template project is:In the source code, I only initialize the DAC and enable the DMA. No other changes to the generated source are done.
The three configurations I tried with:
PLLM=4 gives a I2S WS (frame clock) of 2.93kHz, and the 2kHz audio is at 122Hz:With PLLM=6, I see a WS of 4.4kHz, and audio at 184Hz:
And with PLLM=8, WS is at 5.859kHz, and the audio at 244Hz:
CubeMX is version 4.21.0, F4-firmware package is version 1.16.0
Going through the STM32F401 reference manual and device registers hasn't yet given me a clue where CubeMX generates the bug.
Suggestions (and CubeMX bugfixes) much appreciated
kalle
#cubemx #i2s #frequencySolved! Go to Solution.
2017-08-02 09:04 AM
Yeah, that's strange. This is why it would be nice to see the clock as close to the root as possible.
Could you try to configure the PLL to the lowest possible frequency (PLLM set to 8 so that I2SPLL input is 1MHz, PLLI2SN set to so that PLL output is 192MHz, R divider set to 7 thus I2S input frequency is ) and then output it onto MCO2 while dividing it as much as possible (/5) - that should bring it down to 5.485MHz which should already be measurable with what you have at hand.
JW
2017-08-02 11:00 AM
Try to set the lower 5 bits in RCC_PLLI2SCFGR to 0x08, i.e. in the example
https://community.st.com/0D50X00009XkXzCSAV
set RCC_PLLI2SCFGR = 0x20003008JW
PS. What's written on the chip?
2017-08-02 12:10 PM
Good point. Why didn't I think of that
Anyways, doing just that, PLLM=8, PLLI2SN=192, PLLI2SR=7, I can see at MCO2 a 666/705 kHz clock.8x666kHz and 8x705kHz bracket your calculation of 5.485 MHz nicely, considering the measuring apparatus accuracy.
The '8x' matches the observed I2S WS and bitclock also: when PLLM=8 (like here), I2S WS was ~6kHz.
And 8*6kHz is the desired 48kHz. (In this recording, however, the 'I2S clocks' is too low, and the HAL_I2S_Init() returns a failure).
I don't think the board/crystal is damaged in anyways. If I enable the USB Audio Device class from CubeMX, I can see this board enumerate just fine as a sound card. If the other clocks were wrong, I guess the host computer would print out errors in the system log (and not show the USB device).
I'll go through the registers with a finer toothed comb... Thanks for the help thus far, I appreciate it!
kalle
2017-08-03 12:59 AM
waclawek.jan wrote:
PS. What's written on the chip?
That's it! Thanks for the tip.
While the board is clearly labeled 'STM32F401C-DISCO', the chip on it is, in fact a STM32F411VET6U.
So in Cube's jargon, I have a 'STM32F411E-DISCO' board. Perhaps it said so on the package, but that is lost in time.
(Now looking on my Nucleo boards, the board label is on a sticker. But seems the Nucleo boards don't seem to have a default value under the sticker... Anyways, I can't recall this Discovery board ever having had a sticker on it.)
Almost besides the point now, but as an explanation for the problems above: it seems the F411 has separate PLL_M divisors for I2S and the rest of the system. Using the correct chip in CubeMX solves the issue - the audio comes out at 2kHz now.
Thanks for the help. This was a learning experience
kalle
2017-08-03 02:47 AM
Wow.
I did not check and realize that there's no 401-DISCO in the current offering... The 401-DISCO has apparently been withdrawn in favour of the 411-DISCO, recycling the board.
There are some remnants of the 401-DISCO on st.com, such as UM1660.
JW