STM32CubeMX generated code inconsistency when changing I2C pins to another GPIO Port

[gada]

Dear All,

I have a nucleo-l010rb board and I am generating a code to read 24C512 EEPROM on I2C.

I have tried CubeMX Firmware Version 1.12.1 and 1.11.3.

When I generate the code for the IDE default PA9 and PA10 following is the HAL_I2C_MspInit function generated in stm32l0xx_hal_msp.c file.

void HAL_I2C_MspInit(I2C_HandleTypeDef* hi2c)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  if(hi2c->Instance==I2C1)
  {
  /* USER CODE BEGIN I2C1_MspInit 0 */
 
  /* USER CODE END I2C1_MspInit 0 */
 
    __HAL_RCC_GPIOA_CLK_ENABLE();
    /**I2C1 GPIO Configuration
    PA9     ------> I2C1_SCL
    PA10     ------> I2C1_SDA
    */
    GPIO_InitStruct.Pin = GPIO_PIN_9|GPIO_PIN_10;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF6_I2C1;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
 
    /* Peripheral clock enable */
    __HAL_RCC_I2C1_CLK_ENABLE();
  /* USER CODE BEGIN I2C1_MspInit 1 */
 
  /* USER CODE END I2C1_MspInit 1 */
  }
 
}

Now when I want to change from PA9/PA10 to PB8/PB9 for the same I2C1 following is the HAL_I2C_MspInit function generated in stm32l0xx_hal_msp.c file.

void HAL_I2C_MspInit(I2C_HandleTypeDef* hi2c)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  if(hi2c->Instance==I2C1)
  {
  /* USER CODE BEGIN I2C1_MspInit 0 */
 
  /* USER CODE END I2C1_MspInit 0 */
 
    __HAL_RCC_GPIOB_CLK_ENABLE();
    /**I2C1 GPIO Configuration
    PB8     ------> I2C1_SCL
    */
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
 
    /* Peripheral clock enable */
    __HAL_RCC_I2C1_CLK_ENABLE();
  /* USER CODE BEGIN I2C1_MspInit 1 */
 
  /* USER CODE END I2C1_MspInit 1 */
  }
 
}

I updated this code manually for PB8/PB9 on the lines of PA9/PA10 and only then I was able to get I2C working.

There is another set of I2C pins as well on PB6/PB7 and for those pins as well the code generated is as generated for PB8/PB9.

I want to know why is there such a discrepancy when I am changing pins for the same peripheral.

This is happening in the latest and the previous version of the Cube repository.

Is this normal? or what am I missing over here.

This wasted my 3-4 days and much more for my junior engineers.

Can anyone from ST enlighten us on this?

Regards

[Tesla DeLorean]

I guess that's one of the pitfalls of using automated code generation tools, and the reliance on them doing that job properly.

PB8/PB9 would use AF4 for I2C1

PB6/PB7 would use AF1 for I2C1

I'd imagine such configuration could be added with success. The pin designations and tables can be found in the Data Sheet for the IC.

The all-use-cases, real world testing and QA of the tools is generally pretty lackluster. I don't think this is repository driven, but boiler-plate / template one, and perhaps one of the pin databases.

If stuff doesn't work, I would avoid just pressing the button over and over, but rather go through a basic checklist of items to ensure clocks, pins, routing, and peripheral were configured and enabled correctly and in the right sequence. Cube obfuscates the HAL in ways I don't find productive or helpful.

https://www.st.com/resource/en/datasheet/stm32l010rb.pdf

[gada]

I don't think this happens in every peripheral but this has to be the most silliest bugs in such a highly marketed tool.

Unbelievable!

Just as in crypto they say Not Financial Advice, ST should say Do not rely on the Generated Code!

[Foued_KH]

Hi @gada​,

Thanks for bringing this issue to our attention. I reported it to our STM32CubeMX team.

Internal ticket number: 137038 (This is an internal tracking number and is not accessible or usable by customers).

Foued

[Foued_KH · Accepted solution]

Hello @gada​,

The issue is fixed with the STM32CubeMx 6.7.0 available under this link. :grinning_face:

Foued.