Skip to main content
kj.obara
Associate III
April 12, 2023
Solved

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

  • April 12, 2023
  • 4 replies
  • 5702 views

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?

This topic has been closed for replies.
Best answer by Tesla DeLorean

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

Check also Errata docs.​

4 replies

Tesla DeLorean
Tesla DeLoreanBest answer
Guru
April 12, 2023

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 (See Profile) Up vote any posts that you find helpful, it shows what's working..
kj.obara
kj.obaraAuthor
Associate III
April 12, 2023

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!

waclawek.jan
Super User
April 12, 2023

> and solder bridges

Indeed - SB16 and SB18.


_legacyfs_online_stmicro_images_0693W00000bhwzqQAA.pngJW

kj.obara
kj.obaraAuthor
Associate III
April 12, 2023

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