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.

[HTD]

https://community.st.com/s/question/0D53W00000rYquGSAS/having-problem-with-i2c4-in-stm32h747-disco

How did that guy made it to work? He used I2C4 on the same board, changed something in code and told it works. I don't understand the other post what is happening there. There is a vague link to the documentation page, but not even a specific document to read.

Another example:

https://github.com/Sheraz-hassan/STM32H747I-DISCO_I2C_SD/blob/main/CM7/Core/Src/main.c

Again, I2C4 used.

[AGaun.1]

I'm glad you found a fix for it, even if it required renaming a function.

I was using an I2C thermocouple board on I2C4, which worked absolutely fine when I wrote a test program with no touchscreen and the touchscreen worked fine when I used it on its own. When I used cubeMX to intialise I2C4, along with the touch screen I started having errors, and it was code conflicts. The hardware hadn't changed. I also tried it on a second dev board (I was trying to rule out a faulty board), and had the same result.

CubeMX generates conflicting code using touchGFX and I2C4. If it is just a bug in the code generation, then it could be circumvented by altering the code (which you say seems to have worked), or writing your own (cubeMX is not required to initialise the peripherals, it just makes it a lot easier).

I'm sure it's a bug in the code generation of cubeMX. Ultimately, I found it easier to use I2C1 instead, for the sake of 5 mins of soldering on the fan board.