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

[dpp]

we have just purchased a NUCLEO-H743ZI board. upon configuring a test application to work with an audio codec, we found that there is no option to enable *Master Clock Output* when I2S mode *Full-Duplex* is selected.

we were wondering what the rational behind this is? the codec we are currently looking at needs an external clock signal and prior STM32 ( e.g. STM32F405 ) are capable of provding it. why has it vanished with STM32H7 MCUs?

any help or pointer would be appreciated.

[MikeDB]

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.

[dpp]

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?

[MikeDB]

As you are probably becoming aware, CubeIDE is a pile of **** so problems like this aren't uncommon. The best thing is to enable the MCK pin in your own code and see if MCK comes out. If it does it's CubeIDE at fault, but if not I'd say the IC design is faulty and they need to change the datasheet. Worryingly I was about to change from a TI/BB PCM5102 to an AKM VelvetSound device that does need MCK so I think I'll delay that until you've found a solution.

[dpp]

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.

[MikeDB]

I totally agree. I had to switch to NXP's i.mx devices because the debugging in CubeIDE simply didn't work for the H7 series. I gather it does now so I may try it again in the future but ST really do shoot themselves in the foot by refusing to accept that both Cube and HAL are 1990's solutions and people want better nowadays. Also they cling to gcc when most people have converted to clang. Sad

[dpp]

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);

[dpp]

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*

[MikeDB]

ST just doesn't get audio, does it. Are you too late to use NXP ? The only thing ST has on its side is better SPDIF ports.

[Imen.D]

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

[MikeDB]

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 ?)

[Piranha]

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?

[MikeDB]

I don't use Ethernet or SD so couldn't comment. But the fact their 'fix' of this problem broke something else tends to indicate a total lack of audio experience in their software team, whereas whilst NXP isn't perfect they do seem to have a basic understanding of what is needed.

[Piranha]

But for any serious product one can't use manufacturer provided code anyway, because they all have a track record of providing crapware. For example, ChibiOS seems to be of an uncomparably higher quality than anything I've seen from chip manufacturers.