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.

[dpp]

thank you for getting back on this. it is always good to see that people care ;)

i have updated to STM32CubeIDE 1.3.0 and can confirm that the *Master Clock Ouput* is now available. however two other things are still in missing or faulty:

• option to select the second DMA channel
• a way to start transfer and receive ( i.e something like `HAL_I2SEx_TransmitReceive_DMA` known from STM32F4 implementation )

i would be grateful to see both implemented in a future release.

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