GUI doesn't work anymore after I2C error

FLuba.1 · ‎2024-12-18

For my project, an error message must display on the screen when there's a I2C related communication error. To simulate an I2C error, I pulled out the resistor that is connected between SDA and VCC(for good working of I2C communication, a resistor between VCC and SDA is necessary).

When I2C error communication occurs, I2C error callback is called, a lot of things are apparently deactivated such as systick timer etc, using of a delay halts the code(since tick value doesn't increase). The MCU can't enter presenter and view of touchgfx anymore.

What can be done so that TouchGFX works again, so that I can display the needed error message on the screen)?

FLuba.1 · ‎2025-04-24

I have found the solution to this problem. Cause of the issue: calling my error handler function in "void HAL_I2C_ErrorCallback(I2C_HandleTypeDef *hi2c)". My error handler function calls the function: "MX_TouchGFX_Process();". Calling of "MX_TouchGFX_Process();" in a callback function(of a interrupt) can result in unexpected behaviour of the MCU.

What i do now is the following, when I2C related error occurs, i define the state of error in error callback function for example: "eErrorState = genFuncI2C1_BUS_ERROR;". And i call the error handler function in main.c function. My code does now what i expect.

View solution in original post

Andrew Neil · ‎2024-12-18

@FLuba.1 wrote:
When I2C error communication occurs, I2C error callback is called, a lot of things are apparently deactivated such as systick timer etc, using of a delay halts the code(since tick value doesn't increase).

So don't do that, then!

Presumably, this is just a default, generic error handler?

@FLuba.1 wrote:
What can be done so that TouchGFX works again, so that I can display the needed error message on the screen)?

You need to adapt the error handler to suit your particular requirements - so that it doesn't kill your system!

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

FLuba.1 · ‎2024-12-18

Thank you for your answer.

"You need to adapt the error handler to suit your particular requirements - so that it doesn't kill your system!"
This is what i try to do. But i don't know what i have to re-init(re-activate) or don't know what is deactivated by the MCU/software. I have my own error handler, that the mcu enters after the I2C error callback function, the mcu don't halt, it keeps running(LED blinks by use of for-loop as delay).

I have tried using the functions: HAL_I2C_MspDeInit(), MX_TouchGFX_Init() and SystemClock_Config() to re-activate the Touchgfx, but it doesn't help. What else can i do?

"So don't do that, then!"
I don't think that calling of I2c error callback function is the cause of deactivating MCU hardwares. But i will try without error callback function.

Andrew Neil · ‎2024-12-18

@FLuba.1 wrote:
don't know what is deactivated by the MCU/software. .

Nothing is "deactivated" of its own accord - only the things that you specifically deactivate in your error handling.

An I2C failure shouldn't stop SysTick working.

And, of course, anything which continues to rely on the I2C working is not going to work until you've fixed the I2C error.

Some stuff here on recovering from I2C errors:

https://community.st.com/t5/stm32-mcus-embedded-software/hal-i2c-geterror-reporting-error-codes/m-p/677103/highlight/true#M47943

@FLuba.1 wrote:

The MCU can't enter presenter and view of touchgfx anymore.

So you need to determine what, exactly, prevents it ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

FLuba.1 · ‎2024-12-18

Your link seems to have some good information. I will try what is told in your link. Thanks.

Andrew Neil · ‎2024-12-18

Note that the information there is just about clearing the STM32's I2C state.

It won't help if the external fault persists - eg, you removed the pullup.

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Andrew Neil · ‎2024-12-18

@Andrew Neil wrote:
you need to determine what, exactly, prevents it ...

eg, are you using a touch display which relies upon I2C for the touch operation?

Clearly, that cannot work when the I2C is not working

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

FLuba.1 · ‎2024-12-18

No, my display communicates with MCU trough RGB(24-bit). So theorically, I2C shouldn't halt touchgfx processes. I will let you know more, when i'll do a correction of the code.

Andrew Neil · ‎2024-12-18

That wasn't the question.

The question was whether your display has touch and, if so, whether that touch relies upon I2C

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

FLuba.1 · ‎2024-12-19

My display has no touch.