How can I resolve a conflicting type error from automatically generated TouchGFX/cubeMX code?

[AGaun.1]

I have built a simple gui using TouchGFX 4.18.0 for my H747I-DISCO.

I also need to use I2C to read some sensors, so I have used CubeMX 6.4.0 to enable I2C4 (and also the NVIC interrupts), and generated the code.

When I try to compile this in CubeIDE 1.8.0 (or TouchGFX), I get the following error:

C:/TouchGFXProjects/testApplication/CM7/Core/Src/main.c:86:13: error: conflicting types for 'MX_I2C4_Init'
 86 | static void MX_I2C4_Init(void);
 | ^~~~~~~~~~~~
In file included from ../../../CM7/Core/Inc/main.h:37,
 from C:/TouchGFXProjects/testApplication/CM7/Core/Src/main.c:21:
../../../Drivers/BSP/STM32H747I-Discovery/stm32h747i_discovery_bus.h:115:19: note: previous declaration of 'MX_I2C4_Init' was here
 115 | HAL_StatusTypeDef MX_I2C4_Init(I2C_HandleTypeDef *phi2c, uint32_t timing);
 | ^~~~~~~~~~~~
make: *** [Application/User/Core/subdir.mk:39: Application/User/Core/main.o] Error 1

Is there any way I can avoid this, aside from manually renaming one of the automatically generated functions?

[Romain DIELEMAN]

I don't know but i'll just step in to ask if the first MX_I2C4_Init(void) in main.c is in a User Code section ? If not changes will be overwritten at every code generation from STM32CubeMX. On the other hand changes in the BSP folder should not be overwritten to my knowledge.

/Romain

[CLee.21]

No, I encountered the same problem. The MX_I2C4_Init(void) is generated by CubeMX. The code generated by CubeMX seems conflict with the BSP driver in TouchGFX.

[AGaun.1]

I realised that I never posted about what I found out.

After much testing, and trying things out between two different H747 disco boards, I also came to the conclusion that it was probably a conflict between the touchscreen/TouchGFX and I2C4. It would have been very helpful if cubeMX had flagged this, as it does with other conflicts.

Ultimately, I made some solder connections to the fanout board (pins 19 and 20) from the STM+ connector, which gave me access to another I2C bus (I think I2C1, from memory) which worked perfectly.

[HTD]

Is there a way to solve this without soldering? What's going on, is I2C4 broken, or the CubeMX generates invalid code for it?

[AGaun.1]

As far as I can tell, the touchscreen requires the same pins that I2C4 use. If you use CubeMX with touchGFX, and also enable I2C4, it will not show as an error or a conflict, and will generate code for both which results in code which conflicts. With most other pin conflicts, CubeMX shows a warning, but it does not for this.

Without using a touchscreen (touchGFX), I2C4 works fine. The issue is that the code generated using CubeMX is invalid if you try to use both touchGFX and I2C4 in the same project. This is quite annoying, as I2C4 is the most easily accessible on the dev board.

[HTD]

I was too curious, so I tested it ;) Connected an EEPROM chip to I2C4. As soon as I run the code (I fixed the initialization function signature to workaround the conflict) the screen died displaying a bunch of random pixels. After disconnecting I2C4 from the board physically it works again (the altered code doesn't seem to break it). It seems like it's a bug in the board design. That I2C bus is "general purpose" and it shouldn't be shared with the built in display. It makes many custom daughter boards incompatible.

BTW, I tested default pins for I2C1 (PB6, PB7) - according to documentation - also used by touchscreen.

EDIT: Now I'm completely confused. I disconnected I2C pins, reconnected then again, run the debugger again and IT WORKS! What is happening there? My only fix for the conflict was renaming the MX_I2C4_Init() to MX_I2C4_Init1(). My EEPROM is connected to PD12, PD13 pins, screen works, EEPROM works. I've read in the documentation that I2C4 may be shared so I should be careful for the address conflict, but it's not the case. The EEPROM uses A0 address that is not likely used by anything else on the board. If it was used it would be a special case of bad luck. Address like 00 would probably more likely cause a conflict. As I previously thought - if I2C4 was not usable without hacking the board it would be a serious design bug. There is still a bug in the auto-generated code, but it seems to be fixable by just refactoring the init function name.