STM32F4 I2S2 pin AF Multiplexer issue(s)?

Posted on July 08, 2014 at 16:03

Be wary that PB14 as SDext needs GPIO_AF_SPI3 (6), not GPIO_AF_SPI2 (5)

Posted on July 08, 2014 at 16:57

Clive1,

thanks for the information, I encountered that yesterday. With my chips here it makes a difference for the I2S2_SD wire if I use AF5 on PB15 or on PC3.

On PB15 I always measure GND and on PC3 I see the pattern that I output via firmware on the scope.

At the beginning I used a full duplex interface and then reduced it to a half duplex one to isolate the issue.

I checked the PCB for a short circuit on PB15 to ground, removed the I2S receiver on the other side etc. Currently it's just a pin (configured Push-Pull) without anything connected to it.

Anyway the clocks on PD3/PB9 are outputting just fine.

Posted on July 09, 2014 at 13:11

Clive1,

yesterday I created a ''minimal example'' to reproduce the issue, with interesting results: basically if only using I2S2 on those pins (with other functionality disabled) it works.

I then checked back with my software (using USB HS with ULPI, I2C, etc. ) and found it not working (same configuration).

After I disabled the USB HS peripheral (configured as ULPI) the I2S started working....

PB14 and PB15 are as other alternate function USB HS DP and DM pins.

I assume: the DP and DM pins are routed directly to the USB HS peripheral, irrespective of using ULPI or the embedded USB 2.0 FS PHY and the state of the AF multiplexer.

I hope I'll be able to post an example showing the issue today evening.

Posted on July 09, 2014 at 15:35

Finally, no example, but a solution:

If USB_OTG_GCCFG_PWRDWN is set (thus transciever power down is deactivated) the DM/DP pins are driven by USB, irrespective of their function mapping.

USB_OTG_GCCFG_PWRDWN is necessary only when using the HS peripheral with the on board FS PHY.

It would be nice if such things would be mentioned anywhere.

Posted on July 10, 2014 at 13:22

Does this happen also when those pins are used in a different AF, eg. as timer PWM output?

Is it enough to set only the USB_OTG_GCCFG_PWRDWN bit, without any other OTG initialization/setup, for the problem to occur?

That might lead to a simpler ''minimal example'' others might try to reproduce.

JW

Posted on July 10, 2014 at 14:05

As all files are auto-generated from CubeMX with small changes, the example is not complex anyway.

I attach the last source code I reproduced the issue with.

It is completely self-contained (without makefile/project file), so no external references required. To link against the local available library just exclude the lib directory.

I could provide the CrossStudio project file on request.

________________

Attachments :

i2s2_example.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0ge&d=%2Fa%2F0X0000000bdX%2Ft7g7vA9aUyD0wYgMa7aOOOJ50evFglDVo9cjvivsZxU&asPdf=false

Posted on July 10, 2014 at 14:37

> As all files are auto-generated from CubeMX with small changes, the example is not complex anyway.

Thanks, but that's unusable for me. I intended to try to reproduce it on a 40x. I don't use Cube nor any other ''library'', especially when it comes to problems which could be potentially caused by library bugs.

Nevertheless, it still sounds like a silicon bug and worth reporting through https://my.st.com/onlinesupport/app?page=onlineSupport or any other channel you have towards ST.

JW

Posted on July 10, 2014 at 16:06

JW,

i understand what you think of. I do have my own implementation of all functions I use from the processor. To create a minimal example I thought of using the generated stuff ...

Anyway, if you use a 40x series processor you'd need to change the PLL.N value to 336 and comment out the EnableOverdrive in main.c. All other files simply need to be compiled and linked together. Everything needed to compile should be included.

I already filed a support ticket with them, but I wait also for a response to my last one (from May).

BS