cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H747 I2S slave mode

lukasma
Associate III

Hello,

I have a setup where I use an STM32H747XIH6U and an ADAU1361 codec on the I2S-interface. I want to use the PDM-mics on the ADAU, and in order to do that, ADAU has to be in I2S master mode according to the datasheet. Consequently, STM has to be in slave mode. However, in slave mode STM does not generate an MCK, which for some reason is required by ADAU, even though it is supposedly in master mode (it uses the MCK input to generate its internal clocks both in slave and master mode, apparently). So, my question is: Is there a way to output a MCK in STM slave I2S mode anyways? I'm using CubeMX to generate code, and from there it is not possible to configure I2S in full-duplex slave and have a MCK. Can I use another clock, or is there some other workaround?

15 REPLIES 15
lukasma
Associate III

We have also tried to measure on an STM32H735G-DK devboard, with MCO frequency set to 50 MHz, and there, the duty cycle is almost exactly 50%. Are there other functionalities that, when activated, might disturb the MCO2 clock? Or is it the hardware on STM32H747I-DISCO which is the culprit? By the way, where do we find the PCB layout for STM32H747I-DISCO? I have looked around for a while, but can only get my hands on schematics

lukasma
Associate III

Well, turns out that when we configured PLL2 to provide the clock for MCO2, we used dividers which were not even, According to the reference manual, you don't get a duty cycle of 50 % in that case. Switching these to even numbers instead now gives a duty cycle around 51.3 %, which is a great improvement. We would like it to be more smack on 50 %, but maybe it doesn't matter if we can get it to work

Ans signal looks ok now ? (no sine wave...?)

If you feel a post has answered your question, please click "Accept as Solution".

I mean, we still have some under-and overshoots:

h747--00002.jpg

Between each vertical line is 20 ns. But it doesn't look at all that bad as it did initially.

>some under-and overshoots

These are from your measurement (probably too long ground to scope tip). Try with ground spring at tip, no cable !

The square wave can be assumed to be perfect, as is should be.

 

btw

If you wanna try, to see "good" signal : there is a simple solution ->

If your scope (this fat DSO should) can be switched to 50 ohm input,

just use a 50 ohm coax cable (RG174 is thin version, i use it) and as "probe tip" solder an 470 ohm resistor at the end; and short wire from screen to local ground. (shorter is better ...in this case. 🙂 )

Then you get a broadband 10:1 input , with about 500 ohm impedance ; cpu can drive this easy at 3v3 ;

If you feel a post has answered your question, please click "Accept as Solution".

We did measure with a spring tip, but by hand, and the easiest way to ground the spring tip was to keep it in contact the metal "cover" of the microSD connector at the same time as trying to keep the probe steady, so it is not surprising that we have overshoots. Anyway, I think my main question has been answered, as we are confident that things will work out from now on with this solution, so I'll mark one of the posts as the solution.