STM32F769I-DISCO: No audio output from wm8994

[JB2500]

Posted on October 14, 2017 at 03:33

With 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]

Posted on October 14, 2017 at 18:53

The 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 ms

11025 => 325 ms

16000 => 300 ms

22050 => 325 ms

32000 => 300 ms

44100 => 325 ms

48000 => 300 ms

96000 => 300 ms

From 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.

[Imen.D]

Posted on October 20, 2017 at 17:27

Hello

Bladen.John

,

Many thanks for the detailed issue.

After check, I confirm this problem and I will raise it internally to developer team to work on this topic.

Kind Regards

Imen

[W M]

Posted on November 30, 2017 at 09:42

I have the same problem with STM32F746 Discovery board and STM32Cube_FW_F7_V1.8.0 - no audio on headphones (audio synthesizer program). After changing delay in wm8994.c to 350 ms problem is fixed. Thx for the tip.

Regards,

WM

[daniele239955]

Posted on February 26, 2018 at 09:18

Please, take a look also at the following issue (found in STM32F7Cube package version 1.9.0 file wm8994.c).

I tested the WM8994 driver on the STM32F746G-discovery board. If I try to activate both input and output calling function wm8994_Init with the parameter 'OutputInputDevice' set to, for example, OUTPUT_DEVICE_HEADPHONE | INPUT_DEVICE_DIGITAL_MICROPHONE_2, there is no audio output on headphone jack. The problem seems to be at line 593; at this point, the variable 'power_mgnt_reg_1' is 0 therefore, the following register write instruction switch off the headphone amplifier. A possible fix is to set the variable '

power_mgnt_reg_1' to 0x0300 at line 477 where the headphone amplifier is intialized. Maybe this issue arises also for the speaker path but I've not tested that part.

Kind Regards.

Daniele