As far as I can tell, there are no alt i2c functions for those pins:
https://www.st.com/resource/en/datasheet/stm32f072c8.pdf
From the log file, it seems that you have a lot of random I2C errors, but it is either a timeout or a START NACK (so the address byte is not acknowledged).
If you accidentally have a logic analyzer or oscilloscope, you can verify the timings, which would help to estimate the actual I2C bandwidth.
Assuming the code is correct (I do believe I2C software implementation is solid).
I2C START NACK would probably mean that the display didn’t acknowledge the transaction at all. Unfortunately, the documentation for this device is scarce. If you can, it would be good to check the existence of pull-up resistors on the lines.
Unfortunately, I do not have benchmark data for the STM32F072 to even estimate what it is capable of.
Also, from the attached logs, it seems that you have an absurd restarts and unclean shutdowns for some reason.
Also, jfyi, there was a recent change around that display support:
So, to sum things up:
-
If you can make sure there a pull-ups for I2C 3-10kOm, depending on your lines and voltages. You can use a multimeter and test the resistance to the nearby VCCIO (if you feed the display with 3.3v, probably there should be pull-ups to the 3.3v).
(If there is critically not enough performance, there would always be I2C timeout, and no START NACKs. From the MCU load graph, it seems busy, but not 100% percent). -
If you can, you can after checking the actual I2C performance using of Logic Analyzer or oscilloscope. Generally, the SCL line timings will tell you about performance, the form of the signal the state of pull-ups.
Then it probably should work, it can be slow and garbled. Recent SBC/Host side updates should fix the garbled data.
Then the pull request with async rendering could help to reduce redraw lag.
Hope that helps.