STM32F769I-DISCO: No audio output from wm8994

Question

Posted on October 14, 2017 at 03:33With STM32CubeF7 V1.8.0, there is no audio output from the wm8994 audio chip via the 3.5 mm blue audio output jack on the STM32F769I-Discovery board when parameter OUTPUT_DEVICE_HEADPHONE (or alias OUTPUT_DEVICE_HEADPHONE1) is passed to BSP_AUDIO_OUT_Init().As a result, example SAI_AudioPlay in folder 'STM32Cube_FW_F7_V1.8.0\Projects\STM32F769I-Discovery\Examples\SAI\SAI_AudioPlay' does not work.The problem does not occur with STM32CubeF7 V1.7.0.In file wm8994.c of STM32CubeF7 V1.8.0 (in folder 'STM32Cube_FW_F7_V1.8.0\Drivers\BSP\Components\wm8994'), the following 'cold / warm / soft start' code (lines 470 to 496) has been added since V1.7.0 that gets run when OUTPUT_DEVICE_HEADPHONE is passed to BSP_AUDIO_OUT_Init(): if (output_device == OUTPUT_DEVICE_HEADPHONE)
 { 
 /* Select DAC1 (Left) to Left Headphone Output PGA (HPOUT1LVOL) path */
 counter += CODEC_IO_Write(DeviceAddr, 0x2D, 0x0100);
 
 /* Select DAC1 (Right) to Right Headphone Output PGA (HPOUT1RVOL) path */
 counter += CODEC_IO_Write(DeviceAddr, 0x2E, 0x0100); 
 
 /* Startup sequence for Headphone */
 if(ColdStartup)
 {
 counter += CODEC_IO_Write(DeviceAddr,0x110,0x8100);
 
 ColdStartup=0;
 /* Add Delay */
 AUDIO_IO_Delay(300);
 }
 else /* Headphone Warm Start-Up */
 { 
 counter += CODEC_IO_Write(DeviceAddr,0x110,0x8108);
 /* Add Delay */
 AUDIO_IO_Delay(50);
 }
 
 /* Soft un-Mute the AIF1 Timeslot 0 DAC1 path L&R */
 counter += CODEC_IO_Write(DeviceAddr, 0x420, 0x0000);
 }This code gets run INSTEAD of this existing output configuration code that starts: else
 {
 /* Analog Output Configuration */
...Solution: I've found that increasing the first delay in the new code from 300 to 350 (i.e. AUDIO_IO_Delay(350)) solves the problem. I've not investigated why this works or whether it is a complete solution.A workaround, that doesn't involve editing wm8994.c, is to call BSP_AUDIO_OUT_Init() twice.*** Moderator: Please pass this information to the relevant (STM32CubeF7) personnel. ***JB.Bug in wm8994.c in STM32CubeF7 V1.8.0 re audio output.#stm32f769i-disco #wm8994 #no-audio-output #stm32f7cube

JB2500 · Answer

Posted on October 14, 2017 at 18:53The headphone initialization sequence that was added in Cube V1.8.0 is that given in the WM8994 datasheet, table 142, page 238. The datasheet says that the headphone cold start takes around 296 ms and suggests waiting 300 ms, which is what the newly added code does. I've confirmed that the delay is exactly 300 ms by toggling a pin either side of the delay and using a logic analyzer on that pin.HOWEVER...Although seemingly not documented, the times for processes to complete that are given in the WM8994 datasheet appear to assume the sample frequency, fs, is 48 kHz or a multiple or sub-multiple of that. The newly added code therefore works with the 300 ms delay if the sample frequency is 8 / 16 / 32 / 48 / 96 kHz.However, if fs = 44.1 kHz, the 300 ms delay is insufficient. For things to work correctly, the delay needs to be scaled by a factor of 48 / 44.1, giving 322.2 ms, which is why my delay of 350 ms was sufficient.Here is a table of sample frequency vs required delay that I acquired empirically:8000 => 300 ms11025 => 325 ms16000 => 300 ms22050 => 325 ms32000 => 300 ms44100 => 325 ms48000 => 300 ms96000 => 300 msFrom this, the maximum delay required is 325 ms.The SAI_AudioPlay example in folder 'STM32Cube_FW_F7_V1.8.0\Projects\STM32F769I-Discovery\Examples\SAI\SAI_AudioPlay' uses a sample frequency of 22 kHz and so requires a delay of 325 ms. As it only has a delay of 300 ms, it does not work. (The reason it does not work is that the WM8994 ignores the unmute / volume instructions that follow shortly after the 300 ms delay because it is not ready to receive them).The delay required comes down, I think, to the frequency of the internal clock of the WM8994. This is 11.289 MHz for fs = 11025 / 22050 / 44100 Hz and 12.288 MHz for fs = 8000 / 16000 / 48000 / 96000 Hz. When it's 11.289 MHz, it requires a 300 ms delay; when it's 11.289 MHz, it requires a 325 ms delay.Incidentally, the WM8994 gets its internal clock from its input MCLKA, which connects to board wire SAI1_MCLKA, which connects to MCU pin PG7, which is SAI1_MCLK_A. This is 256 times the sample frequency. Therefore, with a sample frequency of 44.1 kHz it is 11.289 MHz, and with a sample frequency of 48 kHz it is 12.288 MHz. This clock can be probed at TP22, which is near the MCU and on the same side as the MCU.To fix the problem, I've scaled the durations of the AUDIO_IO_Delay() calls in wm8994.c by 48 / 44.1, rounded them up, and added a few milliseconds.*** Moderator: Again, please forward this information to the relevant personnel in the team so that they can fix the Cube library. ***JB.

Sign up

Login with SSO

Login to the community

Login with SSO