[BUG] Shifty I2C OLED on LPC1768

[istyszy]

Hello,

I have found this topic on the bugs list and it is closed, but the problem still exists.

I have an i2c OLED display, with marlin 2.0 (2019-06-24) + SKR V1.3, i use hardware i2c from E1. When the board starts everything is OK, display works as it should, but after 40 sec or so, the display crashes. Did someone had this problem? I used the display with ramps+mega and never had any issues? I use U8GLIB_SH1106. (also tried U8GLIB_SSD1306 same result). My diy display: https://reprap.org/forum/read.php?13,499572,500608#msg-500608

I have tried all the solutions on https://github.com/MarlinFirmware/Marlin/issues/13257 even with a 3.3V regulator. the problem remains. display artifacts after some time.

[tigertooth4]

I have exactly the same problem, connecting a sh1106 i2c oled display to the cohesion3d-remix board. The display is connected to i2c0, and connected to 5V instead.

[istyszy]

I tried with 5V and 3.3V same result

[istyszy]

i think i am missing the pull-up resistors for the I2C bus?

[rundercaster]

Just want to add to this, the screen is still responsive but just layer shifted (i have the same issue)

[istyszy]

So problem solved, added 4.7k resistors for clock and data line( the board was not designed to use I2C on these pins so it has no pull-up resistors).

[thinkyhead]

Thank you for the update! That will be useful troubleshooting information.

[istyszy]

Thank you for the update! That will be useful troubleshooting information.

The issue was closed too soon, the problem still persists but now it appears after 4 minutes or so. i have no tools for data logging. Maybe you could recommend something affordable,

[thinkyhead]

i2c is always fun to wire up. You do need resistors to +V on the line.

[thinkyhead]

Assuming the circuit is right, the next thing to look at is the quality and length of the wires, plus interference from nearby. If you have some ferrite cores, put them on the LCD leads to reduce induction. I'll take a look and see if there's an easy way to change the i2c data rate for the display. Perhaps a slightly slower transfer rate would be more reliable. You might try introducing noise intentionally to see if it induces the same artifacts. Put the wires very close to a spinning servo, or something…

[rundercaster]

I don't think it's hardware issues, as it doesn't randomly shift, or continues to shift further, also I tried 10k resistor for both lines pull up and tried pull down, didn't work for both. It's just that one line shift and it stays there forever until restart

(I didn't say anything because I thought resistors have solved the problem for istyszy)

[thinkyhead]

I'm not sure exactly where to look. I'll poke around the HAL i2c code, if any, for a few minutes… Meanwhile, here are some other options you can try just for fun:

#define OLED_PANEL_TINYBOY2

#define MKS_12864OLED

#define MKS_12864OLED_SSD1306

#define ULTI_CONTROLLER

[thinkyhead]

There are some comments about timings, commented-out defines, etc. in these files that you might want to try messing around with to see if it has any effect (even negative) and maybe something will emerge from that.

[istyszy]

Thanks for the info, i will play around.

[istyszy]

LPC_I2C1->I2DAT = I2CDEV_S_ADDR & I2C_I2DAT_BITMASK i cand find the definition / value for : I2C_I2DAT_BITMASK

[tigertooth4]

Thank you for the update! That will be useful troubleshooting information.

The issue was closed too soon, the problem still persists but now it appears after 4 minutes or so. i have no tools for data logging. Maybe you could recommend something affordable,

Yes, I can confirm that problem persists. I've tried 10K and 5K pull up resistors, still have the problem.

[thinkyhead]

Google says that CMSIS (core headers) define I2C_I2DAT_BITMASK.

[tigertooth4]

I tried change the I2C_TIMEOUT today. When the value was setting to 1, the screen went more corrupted, for I2C_TIMEOUT ≥ 3， no essential improvements, the screen behaves just like description before.

[istyszy]

Google says that CMSIS (core headers) define I2C_I2DAT_BITMASK. i ordered a Logic Analyzer i have to see what is going wrong. There is something strange with this anomaly. i have tried frrite core to on the wire and makes no difference.
Untill my equipment arrives i will play around with my 2004 LCD and rotary encoder( i got it working this way, just a temporary solution)

[tigertooth4]

Today I tried disable the status screen and menu by comment out the contents of u8g main loop in ultralcd.cpp, by doing so, only the splash screen was showed. And there was no screen crashing then.

Is this an indication of a u8g loop problem instead of i2c routines?

[rundercaster]

If you disable the status screen, it only sends 1 frame at the beginning and it doesn't update it after. So technically you just cant see the line shift, because the screen have 1 frame and it is displayed indefinitely

[istyszy]

@thinkyhead So, status update: If i use the the source from: https://github.com/obertr0n/Marlin/tree/marlin_2.0.x_ssd1306/Marlin , the Oled display works perfectly, so i made the changes

Affected files: HAL_LCD_I2C_routines.c u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp

to a new version of of marlin... the problem appars so i guess the problem is from somewhere else?

[tigertooth4]

@thinkyhead So, status update: If i use the the source from: https://github.com/obertr0n/Marlin/tree/marlin_2.0.x_ssd1306/Marlin , the Oled display works perfectly, so i made the changes

Affected files: HAL_LCD_I2C_routines.c u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp

to a new version of of marlin... the problem appars so i guess the problem is from somewhere else?

Great!

Check this out: in u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp，there are two more lines in the obertr0n version of marlin: I've added these two lines to my marlin build (my marlin bugfix 2.0.x was forked in April, it's 508 commits behind the main stream now), the display has no problem since then.

[tigertooth4]

@thinkyhead So, status update: If i use the the source from: https://github.com/obertr0n/Marlin/tree/marlin_2.0.x_ssd1306/Marlin , the Oled display works perfectly, so i made the changes Affected files: HAL_LCD_I2C_routines.c u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp to a new version of of marlin... the problem appars so i guess the problem is from somewhere else?

I see a lot changes in u8g_dev_ssd1306_sh1106_128x64_I2C.cpp file.

Great!

Check this out: in u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp，there are two more lines in the obertr0n version of marlin: I've added these two lines to my marlin build (my marlin bugfix 2.0.x was forked in April, it's 508 commits behind the main stream now), the display has no problem since then.

[istyszy]

I will take a look

[istyszy]

u8g_dev_ssd1306_sh1106_128x64_I2C.cpp I compared to the latest version of marlin and they are identical.

[tigertooth4]

The change history to the u8g_dev_ssd1306_sh1106_128x64_I2C.cpp file can be found:

https://github.com/MarlinFirmware/Marlin/commits/bugfix-2.0.x/Marlin/src/lcd/dogm/u8g_dev_ssd1306_sh1106_128x64_I2C.cpp

it shows the changes happened in commits on May 7, 2019. My copy and I believe obertr0n's copy of Marlin were before this commit (hereafter "the commit" will be referring to this commit). I think your copy was after this commit?

What's happens to me is that according to the hints made by obertr0n's version, I added two lines to the my copy of u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp (my version was before the commit) as I showed above, I found the display became normal.

And I found some inconsistency exists before and after the commit, in the u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp. For example the definition of macro SH1106_START_LINE(N) provides a value (0x40 | (0)) when N = 0, while according to the previous version, this value should be 0x40.

I'm not sure if this leads to the crash. I may try substitute this file with the previous version or substitute in the other way, to see if everything is fine or not.

So @istyszy can you try replacing your version of the following three files with obertr0n's version, see if it works?

• u8g_dev_ssd1306_sh1106_128x64_I2C.cpp
• HAL_LCD_I2C_routines.c
• u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp

[istyszy]

@tigertooth4

• u8g_dev_ssd1306_sh1106_128x64_I2C.cpp -> Identical
• HAL_LCD_I2C_routines.c -> Coped from obertr0n's version
• u8g_com_HAL_LPC1768_ssd_hw_i2c.cpp -> Coped from obertr0n's version The modifications in theese 2 files fixes the LCD problems.

I think this is the fix in u8g_com_HAL_LPC1768_ssd_hw_i2c : (u8g_i2c_send_byte(arg_val ? 0x40 : 0x80))

I am sorry i am just a begginer : (

[boelle]

@istyszy is the issue still there?

[istyszy]

@boelle can someone work on software I2c? to see if we have the same problems?

[boelle]

@istyszy you never answered my question?

[boelle]

since there has been no activity since 27 sep i will close this one

if multiple users can confirm this one and we have their configs we stand a better chance

we can always reopen

[obertr0n]

@istyszy, @boelle, @thinkyhead, @tigertooth4 I can confirm that the issue is still present even on the bugfix branch. I don't expect many people to report an issue, because of the limited number of users of this hardware combination.

With the patch that I have made a few months ago, the display works fine, even though I don't understand why. Maybe a more capable person can dig into the internals of the I2C functions for LPC1768, because from my limited experience with this platform, I couldn't tell what is the actual problem. I suspect some incorrect order of transmission of the data to the display chip.

@thinkyhead, to my understanding, there is no "Wire" library fully implemented for LPC platform, right? I tried to use a similar implementation to the one for STM platforms, without any luck.

[KingTomaHawk]

@boelle I can also confirm that the bug is still present (using Marlin 2.0.5.3).

[istyszy]

i was playing around and... the problem appears after you define the correct prins for the rotary encoder... maybe it was a coincidence?

[ajanky]

@boelle I also can confirm that this one line shift is still an issue. with no action at all it takes up to a5min to appear, after homing it comes pretty fast.

@istyszy after commenting out my encoder pins ( -1) I hoped that helped BUT after 30+ min it appeared again. I will try to dig deeper into the problem the next days...

[iotricity]

The row shifting happens after a few minutes, but it can be sped up by browsing thru menu's fast. At first the shift is one row, later on the shift was even three rows (see attached image). Since the display is not corrupted it's not a timing problem. It's more an offset problem where the start row is wrong. The SKR has more RAM available so I will change the U8Glib from paged mode to single buffer to see if that changes anything.

[KingTomaHawk]

Just a reminder, that the bug still persists in Marlin 2.0.6. I forgot to mention: I'm using a SKR 1.4 Turbo board.

[sjasonsmith]

Can someone point to the hardware needed to reproduce this? I’m n it familiar with display and clearly sharing how to obtain it might help open it up to other people to debug.

[KingTomaHawk]

@sjasonsmith My setup is a little bit different as I use the OLED Controller of a Wanhao Duplicator 6.

But the OLED used is a SSD1306.

[KingTomaHawk]

I found a thread in the reprap.org forum where they are talking about the same problem. Also there is a possible fix, where you have to uncomment all commented code in the Marlin/src/HAL/LPC1768/u8g/u8g_com_HAL_LPC1768_ssd_hw_i2c.ccp file. It didn't worked for me, but it maybe it works for one of you.

https://reprap.org/forum/read.php?13,499572,page=7 (Post by user enif posted April 26, 2020 03:27PM)

[Arakon]

Getting this same issue, on a SKR 1.4 Turbo using the latest Marlin 2.0.6 stable version.

[boelle]

the latest Marlin 2.0.6 stable version.

and with bugfix-2.0.x branch ?

[Arakon]

the latest Marlin 2.0.6 stable version.

and with bugfix-2.0.x branch ?

Also happening with the latest bugfix revision, just tested.

[Arakon]

I found a thread in the reprap.org forum where they are talking about the same problem. Also there is a possible fix, where you have to uncomment all commented code in the Marlin/src/HAL/LPC1768/u8g/u8g_com_HAL_LPC1768_ssd_hw_i2c.ccp file. It didn't worked for me, but it maybe it works for one of you.

https://reprap.org/forum/read.php?13,499572,page=7 (Post by user enif posted April 26, 2020 03:27PM)

This doesn't work for me, btw. Same with adding 4.7k pullups to the signal pins to reduce possible interference, no difference at all.

Edit: Also updated the U8glib-HAL version to 0.4.2 since that was updated recently, and it also made no difference.

[Arakon]

With the patch that I have made a few months ago, the display works fine, even though I don't understand why. Maybe a more capable person can dig into the internals of the I2C functions for LPC1768, because from my limited experience with this platform, I couldn't tell what is the actual problem.

I tried your modifications adapted to the latest bugfix branch and it STILL doesn't work for me.. behavior is completely unchanged.

[iotricity]

The I2C communication is correct. Even when the display shows the offset info. Somehow the offset of the buffer or a register is set wrong at some point in time. If timing for the I2C bus was wrong, data would be corrupted on the display and the next frame would be shown correctly since it's a full buffer transfer for each new frame.

[Arakon]

To keep this issue updated: Same issue remains on 2.0.6.1.

[KingTomaHawk]

FYI: I tested 2.0.7 a few days ago and the issue still exists.

[atoomnetmarc]

FYI: I tested 2.0.7 a few days ago and the issue still exists.

+1, also on 2.0.7 Printing works fine, even for >12hr jobs. I am able to reset the row shift by entering the menu. After returning to the status screen the row shift will happen within a minute or so. Navigating the menu will row shift within a few scrolls.

This is a ULTI_CONTROLLER with a diy LPC1768 board (which is similar to the SKR1.3). FWIW: Configuration.zip

[yet-another-average-joe]

MAYBE I found a solution.

I have this well known issue with a SKR 1.4 Turbo I received 3 days ago, and the known good OLEDs I have been playing with for a couple years (using u8g2, without a problem).

And I also have 2 other problems...

Issue 1 : an horizontally shifted display depending on the OLED (0.96" or 1.3"). Easily solved by editing u8g_dev_ssd1306_128x64_data_start in u8g_dev_ssd1306_128x64.c

Issue 2 : the vertical shifted display after 5mn or so : solved with a ferrite (see picture). Wires are 300mm long, the ferrite comes from the salvaged parts bin (probably from a hallogen dimmer). Better if near to the OLED. Adding pullups didn't help at all (I²C is already pulled up onboard). Therefore it is probably hardware (wiring) related.

Issue 3 : the whole thing still randomly reboots from time to time (with no reproductible pattern)..

The scope shows a data line with a weird signal at the begining of every frame (? - not 100% sure), but I don't know how to interpret it. If it's an issue, it is most likely software related (or at MC level)...

[EDIT]after a few more hours, the problem was back. SKR 1.4 + I²C SSD1306 = unusable. I give up.