STM32F407 - I2S2ext clock must be on PB13...?

[waclawek.jan]

Posted on June 04, 2012 at 17:54

While working on I2S on STM32F407, I came across an issue I believe is a bug in silicon.

I need duplex I2S, so I have configured I2S2 as Master Receiver and I2S2ext as Slave Transmitter, with outputs on port I, i.e. PI0 as I2S2_WS, PI1 as I2S2_CK, PI2 as I2S2ext_SD (to Tx) and PI3 as I2S2_SD. While I2S2 functioned as expected - there were valid clocks on PI0 and PI1 and PI3 was floating - I2S2ext's output at PI2 was stuck at 0, and I2S2ext appeared to be inoperational (no DMA interrupts). Further experimentation revealed, that bit TXE in I2S2ext->SR was permanently at 0. When the DMA which was feeding the I2S2ext's data register was disabled, upon restart the TXE bit was at 1, and after writing a single halfword to I2S2ext->DR it went to 0 and remained there. Couldn't be clearer that there is no clock to I2S2ext. More experiments, and after setting PB13 (which is the other possible pin for I2S2_CK) to Alternative Function and setting it's AF to I2S2 - voila, I2S2ext running as expected. The function of I2S2ext appears to be independent of PI1's setting. IMHO that means, that internally, I2S2ext's CK is incorrectly connected directly to PB13, rather than to the ''merged'' input of both PB13 and PI1, as is should be. More experiments with I2S2 set to Slave Receiver confirmed, that such ''merged'' input does exist and connected to I2S2's CK as expected, so only I2S2ext is affected. I did not try for I2S3/I2S3ext. My hardware is the ST3240G-EVAL board, fitted with the chip marked as STM32F457 rev. A, responding with MCU ID 0x20006411. Can somebody please try to confirm or reject these findings? Thanks, JW #i2s2_ws #i2s #i2s-i2s2ext

[Tesla DeLorean]

Posted on June 04, 2012 at 18:23

Can somebody please try to confirm or reject these findings?

Kind of hard to judge without seeing the configuration code, but one of the biggest traps is not having the pins correctly configured and muxed. I believe this mirrors the peripheral example ST provides tweaks for the PIx pins :

GPIO_InitTypeDef GPIO_InitStructure;
/* Peripheral Clock Enable -------------------------------------------------*/
/* Enable the I2Sx/I2Sx_ext clock */
RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI2, ENABLE);
/* Enable GPIO clocks */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOI, ENABLE);
/* I2S GPIO Configuration --------------------------------------------------*/
/* Connect I2S pins to Alternate functions */
GPIO_PinAFConfig(GPIOI, GPIO_PinSource0, GPIO_AF_SPI2);
GPIO_PinAFConfig(GPIOI, GPIO_PinSource1, GPIO_AF_SPI2);
GPIO_PinAFConfig(GPIOI, GPIO_PinSource3, GPIO_AF_SPI2);
GPIO_PinAFConfig(GPIOI, GPIO_PinSource2, GPIO_AF_SPI3); // !!SPI3!! AF6 required to mux I2S2ext_SD

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN;
/* I2S WS pin configuration */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_Init(GPIOI, &GPIO_InitStructure);
/* I2S CK pin configuration */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1;
GPIO_Init(GPIOI, &GPIO_InitStructure);
/* I2S SD pin configuration */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3;
GPIO_Init(GPIOI, &GPIO_InitStructure);
/* I2S Extended SD pin configuration */
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2;
GPIO_Init(GPIOI, &GPIO_InitStructure);

[waclawek.jan]

Posted on June 04, 2012 at 18:38

>> Can somebody please try to confirm or reject these findings?

> Kind of hard to judge without seeing the configuration code,

I mean, would you (or anybody else) please confirm this finding (I2S2ext not working with clock on PI1) with independently conceived code, to exclude my potential errors. > but one of the biggest traps is not having the pins correctly configured and muxed. As I am working with a real-life I2S codec and my finding is related specifically to clock output on pin PI1, it's kind of hard to miss the presence or absence of clocks, especially since I have it wired up on a LA 😉 But just for amusement, the port I pins' init code (after having moved the clock to PB13) is attached below :p   GPIOI->MODER |= 0                   OR (GPIO_Mode_AlternateFunction * GPIO_MODER_MODER0_0)   // SMORF_CODEC_LRCK // see explanation above //   OR (GPIO_Mode_AlternateFunction * GPIO_MODER_MODER1_0)   // SMORF_CODEC_BICK   OR (GPIO_Mode_AlternateFunction * GPIO_MODER_MODER2_0)   // SMORF_CODEC_SDTI   OR (GPIO_Mode_AlternateFunction * GPIO_MODER_MODER3_0)   // SMORF_CODEC_SDTO   ;   GPIOI->OTYPER |= 0                   ;   GPIOI->OSPEEDR |= 0                   OR (GPIO_Speed_25MHz * GPIO_OSPEEDER_OSPEEDR0_0)          // SMORF_CODEC_LRCK //  OR (GPIO_Speed_25MHz * GPIO_OSPEEDER_OSPEEDR1_0)   OR (GPIO_Speed_25MHz * GPIO_OSPEEDER_OSPEEDR2_0)          // SMORF_CODEC_SDTI   OR (GPIO_Speed_25MHz * GPIO_OSPEEDER_OSPEEDR3_0)          // SMORF_CODEC_SDTO   ;   GPIOI->PUPDR |= 0                   ;   GPIOI->AFR[0] |= 0                   OR (GPIO_AlternateFunction_I2S2    * GPIO_AFRL_AFRL0_0)      // SMORF_CODEC_LRCK //  OR (GPIO_AlternateFunction_I2S2    * GPIO_AFRL_AFRL1_0)      // SMORF_CODEC_BICK   OR (GPIO_AlternateFunction_I2S2Ext * GPIO_AFRL_AFRL2_0)      // SMORF_CODEC_SDTI   OR (GPIO_AlternateFunction_I2S2    * GPIO_AFRL_AFRL3_0)      // SMORF_CODEC_SDTO   ;   GPIOI->AFR[1] |= 0                   ; (yes, I do avoid CMSIS & co). --- Meantime, I noticed that there is also a third I2S2 clock on PB10, and it does provide the clock to I2S2ext, so it seems that only PI1 is affected by this problem. Thanks for your comments, JW

[waclawek.jan]

Posted on July 18, 2012 at 17:44

I believe I've hit another silicon bug.

The I2S2Ext appears to support only MSB-justified (left-justified) standard, and it does so when it is set to Philips standard. This is so both in Slave-transmit and Slave-receive mode. Setting SPI_I2SCFGR.I2SSTD to any other value than 0 (Philips) disables the I2S2Ext completely. I verified this looping back the I2S2's data pin (PI3) to the I2S2Ext's data pin (PI2 - and yes, it is configured for AF6, otherwise it wouldn't work at all, would it). Both were set to Philips mode, 24-bit (but I verified that the same applies for both 16- and 32-bit data lenghts). When the I2S2 runs as Master-transmitter transmitting all 24 bits as 1 (i.e. 0xFFFF 0xFF00  - verified by a LA that it is poroperly transmitted according to Philips standard, i.e. the MSB starts at clock 1) and the I2S2Ext is Slave-receiver, it receives 0x7FFF 0xFF80 . Vice versa, when I2S2Ext is Slave-Transmitter (transmitting 0xFFFF 0xFF00 incorrectly transmitted as MSB-justified, i.e. MSB starts at clock 0) and I2S2 is Master-Receiver, it receives 0xFFFF 0xFE01 (the received LSB is in fact the transmitted MSB). I had a look at the ST-supplied two-board example, and it links I2S2Ext as transmitter on one board to I2S2Ext as receiver on second board. That mutually compensates the error, as it occurs in both transmit and receive. A cross-connection (and appropriately modified software) should reveal the problem (I don't have two evalboards, though, so cannot try). Can anybody please confirm or reject these findings? Thanks, JW

[rx9cim]

Posted on July 18, 2012 at 19:33

Unfortunately, engineers from ST technical support usually do not read this forum. All discussion consist of posts of user.

[Tesla DeLorean]

Posted on July 18, 2012 at 20:07

Unfortunately, engineers from ST technical support usually do not read this forum.

They don't participate, but who knows who's lurking here or reading. It is certainly monitored by ST and their competitors. If you have a problem work through it with your FAE. Forums are usually a pretty poor place to interact with technical staff or the IC design group.

[waclawek.jan]

Posted on July 19, 2012 at 14:26

I was wrong in my conclusion of the observed symptoms.

There indeed *is* a bug in the silicon, and it is of the same nature as the first one - the I2S2_WS signal is not ''linked'' from PI0 to I2S2Ext. Due to the behaviour of slave described in the errata - that it starts only upon a certain level of WS - and that the internal WS input level was tied apparently to log.0 - the I2S2Ext started in Philips mode whenever the bit clock (I2S2_CK (not output on PI1 - see the first bug above)) started; and in MSB/LSB-justified modes it never started. After moving I2S2_WS to PB9 I2S2Ext as slave transmitter works as expected - in all modes data are transmitted as they should. Did not try slave receiver nor _WS at PB12, but expect it all to work too in a certain ''symmetry'' with the first bug (anybody is free to try). The same request again: can anybody please confirm or reject this finding, perhaps on a different revision of the chip? Comments from ST insiders are welcome too, of course. Note, that I don't request help - in light of the state of matters I find it foolish to rely on help from manufacturer, either can resolve issues myself or drop the chip as unsupportable - but I post here in hope these findings will help others. JW PS. Just tried I2S2Ext as slave receiver too (with I2S2_WS still on PB9) and it also works as expected.

[rx9cim]

Posted on July 20, 2012 at 23:05

I do not want to continue the discussion about ST tecnical support. I want to say, that for me, the developer must first say that this is actually a bug in the catfish in the processor or the consumer is doing something wrong. If the developer does not respond, some might think that it is better not to use this principle the processor, which affects directly on the reputation of the firm (in this case, ST).