Skip to main content
Explorer II
February 12, 2025
Solved

STM32C0 SDA signal on PC14

  • February 12, 2025
  • 5 replies
  • 1884 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.

    5 replies

    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?

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

    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

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

    Graduate II
    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? 

     

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

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

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

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