Full-Duplex I2S with *Master Clock Output* on STM32H7 in STM32CubeIDE?

My audio DAC doesn't need the master clock but I assumed the clock was automatically enabled in Master mode if you set the pin to that mode - page 2195 of RM0433 document.

thank you for the quick answer. you are right the manual clearly states that a *Master Clock Output* can be created. however, there is no option in STM32CubeIDE to enable this. so this might be more of an STM32CubeIDE question …

​

a brief inspection of the HAL implementation shows that the `HAL_I2S_MspInit` in `stm32h7xx_hal_msp.c` only initializes the GPIO pins `SDI, SDO, CK, WS` and no master clock `MCK`.

before digging deeper ( or switching to SAI ) we are wondering if we are missing something obvious here or if it was just a decision to leave *Master Clock Output* out of the STM32H7 I2S implementation?

thank you again mike for the pointers. long story short: i was able to initiate a *Master Clock Output* in Full-Duplex I2S mode. for future reference i will explain my steps:

i did exactly what you suggested and created the *Master Clock Output* manually. first i set up STM32CubeIDE in *Half-Duplex* I2S mode, where the option is available. i then generated the source code and looked for the implementation. i found two relevant locations, i switched back to Full-Duplex mode and did the following modifications:

​

enabled *Master Clock Output* in `main.c` in `MX_I2S2_Init(void)` ( approx in line 263 )

hi2s2.Init.MCLKOutput = I2S_MCLKOUTPUT_ENABLE;

added the according GPIO initialization in `stm32h7xx_hal_msp.c` in `HAL_I2S_MspInit(I2S_HandleTypeDef* hi2s)` ( approx line 187 )

 /* PC6 ------> I2S2_MCK */
 GPIO_InitStruct.Pin = GPIO_PIN_6;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
 GPIO_InitStruct.Alternate = GPIO_AF5_SPI2; // GPIO_AF6_SPI2
 HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);

the oscilloscope was then able to detect a clock on pin `PC06`. also my setup with a WM8731 audio codec works well with this manual tweak.

PS despite being happy to having solved this issue and also receiving helpful feedback from the community, i cannot help but saying that i am not very happy with the quality management of the STM32CubeIDE ( and also parts of the HAL implementation ). i know that this has been mentioned before many times in many places but IMHO every voice counts. the wide and flexible architecture matrix of STM32 MCU is a really great thing and definitely a strong selling proposition. however, this needs to be reflected on the software and development side as well … otherwise people will turn to NXP or ATMEL. which would be a shame, wouldn’t it.

for the sake of completeness: if both channels are supposed to be DMA channels it does not suffice to merely call `HAL_I2S_Receive_DMA` and `HAL_I2S_Transmit_DMA`. the second call will return with a `HAL_BUSY`. the reason for this appears to be that the state flag never gets cleared. however, a manually setting of the flag after the first call works:

HAL_I2S_Receive_DMA(&hi2s2, mDataRX, BUFFER_SIZE);
hi2s2.State = HAL_I2S_STATE_READY; // state flag needs to be cleared manually
HAL_I2S_Transmit_DMA(&hi2s2, mDataTX, BUFFER_SIZE);

just to document the absurdity of it: i have just updated to STM32CubeIDE 1.3.0 and now it is possible to check the *Master Clock Output* in the *Device Configuration Tool* ( which produces pretty much the code i posted above ) however now the option to create a second DMA channel is gone … well *SIGH*

Hi @dpp​ ,

I raised internally your request to the STM32CubeIDE team.

Thank you for your contribution and we really appreciate the help from community users to improve our product.

Best Regards,

Imen

While we're on "Audio on H7 devices" topic, could your hardware people please consider for future devices putting a x256 PLL on the I2S_CKIN pin (pin 66 on 100pin package). Most audio systems use a frame sync pulse (44.1, 48, 96, 192 or 384kHz) as the master clock and derive other clocks such as MCLK and I2S clocks from it. Providing an optional fixed x256 PLL on this input would reduce system costs by quite a bit. Either a new PLL or borrowing one of the three from the main clock system (does anybody ever use all three anyway ?)

For audio protocol needs, including I2S, SAI is better and should be the first choice! Use SPI only if you can't use SAI.

> ST just doesn't get audio

@MikeDB​, when talking about software - what do they do get? Ethernet/lwIP is not even worth mentioning. SD/FatFS and USB seems to be similar. Heck, they can't even make decent full-duplex USART working. I'll turn this around - is there any ST's HAL/CubeMX/Example code that is not flawed or bloated?