Skip to main content
Associate II
February 12, 2025
Solved

STM32C0 SDA signal on PC14

  • February 12, 2025
  • 14 replies
  • 1952 views

Hi,

I'm trying to configure pin PC14 to be used as SDA signal as it stated in the datasheets STM32C031C6 and STM32C031G4:

rnicolas_0-1739374796623.png

rnicolas_1-1739374868084.png

To configure the pin (and the the I2C) I am using:

 

 

void SDK_I2C_Init(SDK_I2C_HandleTypeDef *hi2c) {
 LL_I2C_InitTypeDef I2C_InitStruct = {0};
 LL_GPIO_InitTypeDef GPIO_InitStruct = {0};

 LL_RCC_SetI2CClockSource(LL_RCC_I2C1_CLKSOURCE_PCLK1);
 LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOB);
 LL_IOP_GRP1_EnableClock(LL_IOP_GRP1_PERIPH_GPIOC);
 /**I2C1 GPIO Configuration
 PB8 ------> I2C1_SCL
 PC14 ------> I2C1_SDA
 */
 GPIO_InitStruct.Pin = LL_GPIO_PIN_8;
 GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
 GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
 GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_OPENDRAIN;
 GPIO_InitStruct.Pull = LL_GPIO_PULL_UP;
 GPIO_InitStruct.Alternate = LL_GPIO_AF_6;
 LL_GPIO_Init(GPIOB, &GPIO_InitStruct);

 GPIO_InitStruct.Pin = LL_GPIO_PIN_14;
 GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
 GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
 GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_OPENDRAIN;
 GPIO_InitStruct.Pull = LL_GPIO_PULL_UP;
 GPIO_InitStruct.Alternate = LL_GPIO_AF_14;
 LL_GPIO_Init(GPIOC, &GPIO_InitStruct);

 LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_I2C1);

 I2C_InitStruct.PeripheralMode = LL_I2C_MODE_I2C;
 I2C_InitStruct.Timing = I2C_TIMING;
 I2C_InitStruct.AnalogFilter = LL_I2C_ANALOGFILTER_ENABLE;
 I2C_InitStruct.DigitalFilter = 2;
 I2C_InitStruct.OwnAddress1 = 180;
 I2C_InitStruct.TypeAcknowledge = LL_I2C_ACK;
 I2C_InitStruct.OwnAddrSize = LL_I2C_OWNADDRESS1_7BIT;
 LL_I2C_Init(I2C1, &I2C_InitStruct);
 LL_I2C_EnableAutoEndMode(I2C1);
 LL_I2C_SetOwnAddress2(I2C1, 0, LL_I2C_OWNADDRESS2_NOMASK);
 LL_I2C_DisableOwnAddress2(I2C1);
 LL_I2C_DisableGeneralCall(I2C1);
 LL_I2C_EnableClockStretching(I2C1);

 LL_I2C_Disable(I2C1);
 LL_I2C_SetTiming(I2C1, I2C_TIMING);
 LL_I2C_Enable(I2C1);
}

 

 

 which is almost the same code that we can find here.

If I configure another pin to work as SDA (PB9 or PB7) the system works perfectly and I can communicate using the I2C protocol.

Is there any configuration that I am missing for that specific pin?

This topic has been closed for replies.
Best answer by rnicolas

Hey everyone, I just wanted to take a moment to say thank you for all the insights and suggestions!

After hours of debugging, I finally got my I2C communication working with sensor. The issue? A hidden EXTI pin configuration buried in some project files that I wasn't even considering.

I kept reading through my code again and again, and eventually, I realized that the EXTI settings were conflicting with my I2C pinout. Once I removed those calls—boom! Everything started working perfectly.

This was a great reminder that sometimes the problem isn't where you're looking—it’s hiding in plain sight.

Big thanks to everyone who shared their knowledge and helped me troubleshoot this! Your support made all the difference.

14 replies

Andrew Neil
Super User
February 12, 2025

What board are you running on?

Are you sure that there's no external hardware issues that would prevent PC14 to be used as SDA?

eg, is the pullup present on PC14?

Have you used an oscilloscope to see what, if anything, is happening externally on the pin?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
rnicolasAuthor
Associate II
February 12, 2025

For the most basic test I'm using the Nucleo-C031C6. The configuration is that one I already sent, and I see if I configure and connect other pins everything works fine, but not PC14. I'm doing the connection with jumper wires. There is nothing else connected between the two components. This setup does not include pull-ups and I rely on the internal pull-ups as described in the pin configuration

For the STM32C031G4 I'm using a propriertary board with 4k7 external pull-ups, and then configuring the pins with 

 

GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;

 

lines are directly connected between the two components, no switching between boards, nothing.

In both cases, PC14 does not seem to work as SDA. 

Andrew Neil
Super User
February 12, 2025

Again, check that there's no external hardware issues that would prevent PC14 to be used as SDA.

I2C needs pullups - it won't work without them. Internal microcontroller pullups are seldom suitable.

See: https://community.st.com/t5/stm32-mcus-boards-and-hardware/i2c-between-two-nucleo-f446re-boards/m-p/769665/highlight/true#M23992

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
KnarfB
Super User
February 12, 2025

Scan the ref.man. RM0490 Rev 5 for PC14. Especially 4.7.6 FLASH option register (FLASH_OPTR) HSE_NOT_REMAPPED bit. Don't know if this applies to your case.

hth

KnarfB

rnicolasAuthor
Associate II
February 12, 2025

Just checked, I see the value of FLASH_OPTR is 11111111111111111111111010101010, so I can see it is disabled, and still, there is no communication.

Karl Yamashita
Principal
February 12, 2025

@rnicolas wrote:

Just checked, I see the value of FLASH_OPTR is 11111111111111111111111010101010, so I can see it is disabled, and still, there is no communication.


It is unclear what you mean by no communication? Do you mean you don't see activity using an oscilloscope? 

 

If a reply has proven helpful, click on Accept as Solution so that it'll show at top of the post.CAN Jammer an open source CAN bus hacking toolCANableV3 Open Source
TDK
February 12, 2025

If you configure PC14 as a GPIO output and toggle it, can you see the waveform on a scope or multimeter? Take the measurement at the SDA pin of the I2C device.

Code seems good. Don't think there's anything else that hasn't been pointed out.

"If you feel a post has answered your question, please click ""Accept as Solution""."
rnicolasAuthor
Associate II
February 13, 2025

First of all, thank you all of you guys for pointing several things.

It was really helpful to discover the pin PC14 in nucleo board is not connected, but I need to do some rework there to get it working, as pointed by @Andrew Neil . Since I have already tested the code with other pins and I proved it is working, I just switch to the second board (the proprietary board with 4k7 external pull-ups) that has the PC14 exposed. In that board I analyzed the value of FLASH_OPTR which is 11111111111111111111111010101010, so I can see HSE_NOT_REMAPPED is disabled according to the datasheet (1: disabled, 0: enabled). That means I should be able to use PC14 as a GPIO.

So something else is happening, and after a morning of debugging I see the following, when this code is executed:

GPIO_InitStruct.Pin = LL_GPIO_PIN_8;
GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_OPENDRAIN;
GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
GPIO_InitStruct.Alternate = LL_GPIO_AF_6;
LL_GPIO_Init(GPIOB, &GPIO_InitStruct);

The application ends in here:

Default_Handler:
Infinite_Loop:
 b Infinite_Loop

but if I debug step by step, the code seems to run fine, but I cannot let the code run autonomously because whenever I let it then run autonomously it ends in the Infinite_Loop.

TDK
February 13, 2025

> but I cannot let the code run autonomously because whenever I let it then run autonomously it ends in the Infinite_Loop.

Surely this is a bug which should be fixed first, not avoided.

Look at VECTACTIVE bit in SCB->ICSR to understand what interrupt is active.

"If you feel a post has answered your question, please click ""Accept as Solution""."
rnicolasAuthorBest answer
Associate II
February 13, 2025

Hey everyone, I just wanted to take a moment to say thank you for all the insights and suggestions!

After hours of debugging, I finally got my I2C communication working with sensor. The issue? A hidden EXTI pin configuration buried in some project files that I wasn't even considering.

I kept reading through my code again and again, and eventually, I realized that the EXTI settings were conflicting with my I2C pinout. Once I removed those calls—boom! Everything started working perfectly.

This was a great reminder that sometimes the problem isn't where you're looking—it’s hiding in plain sight.

Big thanks to everyone who shared their knowledge and helped me troubleshoot this! Your support made all the difference.