cancel
Showing results for 
Search instead for 
Did you mean: 

Configuring pins PA5 or PA6 as output push-pull pins on STM32L432KC causes I2C1 peripheral to stall

kj.obara
Associate III

I'm using STM32L432KC on Nucleo-L432KC board with the following set up:

I2C -- PB6=I2C1_SCL, PB7=I2C1_SDA

SPI -- PA1=SPI1_SCK, PA11=SPI1_MISO, PA12=SPI1_MOSI, PB0=software CS for SD card reader

EXTI - PB1=EXTI1

It all works fine until I want to configure another CS pin for second SPI device using PA6 or PA5.

Please note that nothing is connected yet, I am merely configuring a new PIN in this way - as push-pull, pull-up, and outputting high:

  /*Configure GPIO pin Output Level */
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
 
  /*Configure GPIO pin : PA5 */
  GPIO_InitStruct.Pin = GPIO_PIN_5;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; // Change to GPIO_MODE_OUTPUT_OD 
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

This I have isolated to cause I2C1 peripheral to hang (waiting for TC flag to be cleared) while taking with the connected devices.

I have noticed the following:

If I apply the exact same configuration (push-pull) which causes issue on PA5 to e.g. PB5 instead then I2C1 works fine.

If I change PA5 or PA6 configuration to use open-drain instead of push-pull then again I2C1 starts working fine.

So the questions are:

* Is this buggy behaviour that unrelated pin that isn't even connected to anything yet causes an unrelated device to stall?

(My assumption is that GPIO pins should not impact functioning of I2C peripheral which uses pins on a different PORT? Or are there any special cases?)

* Is there any particular reason why push-pull configuration causes this hang while open-drain configuration does not?

1 ACCEPTED SOLUTION

Accepted Solutions

Double check signal paths, connections and solder bridges options for related pins on the schematic.

Check also Errata docs.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

4 REPLIES 4

Double check signal paths, connections and solder bridges options for related pins on the schematic.

Check also Errata docs.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

> and solder bridges

Indeed - SB16 and SB18.


_legacyfs_online_stmicro_images_0693W00000bhwzqQAA.pngJW

Thank you Tesla, you are probably right - I looked into UM1956 to check the schematics and I noticed something that I should have noticed a long time ago, but I was so sure that the default setup must work since I haven't made any changes to the soldering bridges.

But alas, UM1956 says for SB16 (pp20-21):

STM32 PB6 is connected to CN4 pin 7 for I2C SDA support on

Arduino Nano A5. In such case STM32 PB6 does not support

Arduino Nano D5 and PA6 must be configured as input floating.

The schematics further reveals that PB6 is linked to PA6 and PB7 to PA5. Which obviously explains why my I2C peripheral would get wrecked if I setup constant high signal on those pins.

Now, I have some desoldering to do to verify this resolves the issue but looks like a very dumb overlook my side (but why would anyone solder 2 pins together...) 🙂 Thanks again!

Yes, that's exactly what I completely ignored although I've skimmed through that manual 50 times in the last week... Also explains the issue I had in the past with Nucleo-L412KB. I just somehow never registered, that they have pins soldered to connect...