cancel
Showing results for 
Search instead for 
Did you mean: 

Conflicting types (function signature for MX_I2C4_Init()) in auto generated code. How to fix this properly?

HTD
Senior III

I configured I2C4 for a H747 DISCO board.

Here's generated code in main.c:

static void MX_I2C4_Init(void);
 
// ...
 
MX_I2C4_Init();
 
// ...
 
static void MX_I2C4_Init(void)
{
// ...
}

It doesn't compile because of function signature conflict with

HAL_StatusTypeDef MX_I2C4_Init(I2C_HandleTypeDef *phi2c, uint32_t timing);

defined in stm32h747i_discovery_bus.h.

AFAIK in C you can't overload functions, so it's the reason it doesn't work.

My workaround for this is either changing function signature in main.c by adding "1" to the name, or - change the function in stm32h747i_discovery_bus.h by adding "1" at the end of the name.

The downside is at least in main.c the code is generated, so each time I would use code generation option my changes would be overwritten.

Is there a better way to solve this issue?

5 REPLIES 5
Pavel A.
Evangelist III

You can raise a bug on github against this file.

Or, just do not include stm32h747i_discovery_bus.h into main.c.

Call the BSP function from some other C file (divide and conquer).

Markus GIRDLAND
ST Employee

The problem is that CubeMX will keep auto-generating back the code and the files if you enable the I2C4.

A work-around until the bug is fixed could be to manage the I2C4 "externally" (not by MX).

1. Don't enable I2C4 in CubeMX.

2. Instead copy the init code to your own c/h-files

3. Then copy the stm32xyz__hal_i2c.c and stm32xyz__hal_i2c.h into your Src and Inc folder respectively.

4. Probably some iterations of resolving symbols before a clean build result

At least not MX will not keep re-generating error code for the I2C peripheral.

Keep a new CubeMX project in parallel in your workspace where you only play with I2C settings to get generated code that can then be copied to you real project.

GitHub issue created:

https://github.com/STMicroelectronics/stm32h747i-disco-bsp/issues/1

As a workaround I just renamed BSP bus driver function adding "_" before the name.

I actually changed the BSP bus driver function signature not to conflict.

I tested that generating code from IOC change doesn't overwrite my changes.

It's probably the easiest possible fix.

Hello @Adam �?yskawa​,

First let me thank you for having reporting 😊

Currently STM32CubeMX doesn't support BSP. Actually it is an MCU initialization code generator and it is not meant to support the Board Support Package .

Thus, stm32h747i_discovery_bus.h will not be overwritten at the next CubeMX code generation, since it has been added manually ( I assume).

With this being said could you please attach your project / .ioc file for further check.

Khouloud.