Glcd/SSD1306 bug?

15 views
Skip to first unread message

Mike

unread,
Apr 19, 2026, 10:32:20 PMApr 19
to jallist
I've attached a sample program that demonstrates the problem.  The 128x32 OLED display stops updating after some time (between 0 and 20 minutes, usually less than 5).  The problem doesn't occur at a repeatable time.  I confirmed that the ISR does continue to operate.  If I comment out the ssd1306_goto() statements it appears to run without a problem, but I only let it run for a bit over an hour.  I suspect the issue is with the display size, but not certain.

I don't, actually, use the jallib libraries for these little OLED displays, as the stuff I've written runs faster, but I was trying to convert one of my programs to include in JAL's sample files.  I'm just pointing out that I'm in no hurry to resolve this, but I thought others who use the libraries might have a need.

Regards,
Mike

test1.jal

Rob CJ

unread,
Apr 20, 2026, 3:04:51 AMApr 20
to jal...@googlegroups.com
Hi Mike,

I will see if I can reproduce it and see if I can find the root cause.

Thanks for the info.

Kind regards,

Rob


Van: 'Mike' via jallist <jal...@googlegroups.com>
Verzonden: maandag 20 april 2026 04:32
Aan: jallist <jal...@googlegroups.com>
Onderwerp: [jallist] Glcd/SSD1306 bug?
 
--
You received this message because you are subscribed to the Google Groups "jallist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallist+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jallist/cf145e45-1438-485b-9342-aa5e8e4ae2f3n%40googlegroups.com.

Rob CJ

unread,
Apr 20, 2026, 10:34:54 AMApr 20
to jal...@googlegroups.com
Hi Mike,

I did  a test using a PIC16F1823 (other chip but same family) but the timer did not run so I changed
T1CON = 0b1000_1110 --> T1CON = 0b0000_1110. It was running too fast but at least I got something on the display.

In your program I saw this: const word _i2c_bus_speed = 10 -- 400kHz (set to 1 gives 100 kHz)

But that is not correct. If you use the value 10 the IIC clock speed is 1 MHz when you use the I2C hardware library and according to the datasheet of the SSD1306 the maximum IIC clock is 400 kHz.

It works if I change the value to 4 (400 kHz) but as soon as I use the value 10 the SSD1306 hangs immediately on my breadboard.

So I thing the IIC clock speed is too high.

Kind regards,

Rob




Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: maandag 20 april 2026 09:04
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallist] Glcd/SSD1306 bug?
 

Mike

unread,
Apr 20, 2026, 12:13:04 PMApr 20
to jallist
Hi Rob,

Yes, the I2C value of 10 is for 1MHz, and 1 is for 100kHz.  The comment is just from one of the jallib sample programs.

I will try the same program at 400kHz, but I have already tested this exact display at 4MHz on a Raspberry Pi Pico and it was fine...which is why I was using 1MHz in JAL.  If the display won't run at 1MHz with a PIC I suspect the problem is with the PIC, because when the problem happens the PIC completely stops sending anything to the display.

Regards,
Mike

Rob CJ

unread,
Apr 20, 2026, 1:26:26 PMApr 20
to jallist
Hi Mike,

This is from the data sheet. The minimum clock time is 2.5 us or 400 kHz. Using it out of specification does not guaranteer correct operation.

I did not measure or check the clock with the value of 1MHz, will have a look at it later.

Kind regards,

Rob



Van: 'Mike' via jallist <jal...@googlegroups.com>
Verzonden: maandag 20 april 2026 18:13
Aan: jallist <jal...@googlegroups.com>

Mike

unread,
Apr 20, 2026, 1:47:34 PMApr 20
to jallist
Hi Rob,

I'll do some testing as well.  I'm really curious about this now.  I suspect it has to do with ACK's.
indicates that the SSD1306 can be pushed very fast if you don't care about ACK.  Some of the comments are enlightening.

If it comes down to being an ACK issue, I wonder if the PIC hardware can be told to not wait for an ACK...I'll check the datasheet.

Regards,
-Mike

Mike

unread,
Apr 20, 2026, 3:40:13 PMApr 20
to jallist
I just remembered that I did some I2C tests not long ago.  I measured the SCK speed with my oscilloscope for different speed settings.  And with _i2c_bus_speed = 10 the measured clock speed was 442kHz with the PIC running at 8MHz.

Mike

unread,
Apr 20, 2026, 4:10:31 PMApr 20
to jallist
Right now I'm testing the I2C_HARDWARE_TIMEOUT setting, which I didn't know existed.

Mike

unread,
Apr 20, 2026, 5:35:08 PMApr 20
to jallist
Yeah, it looks like the timeout setting is needed.  Without it, code execution stays in the WHILE loop waiting for the ACK.  My test circuit is now at 1 hour 25 minutes without freezing.  I'll let it run through the evening and then try it with the PLL enabled, for 32MHz, which will raise the I2C bus speed a little bit.

-Mike

Mike

unread,
Apr 20, 2026, 9:20:56 PMApr 20
to jallist
Rob,

I ran it for several hours with the I2C timeout parameter set, and didn't have any problems.  When I switched the oscillator to 32MHz I had to up the timeout considerably, otherwise the display was very glitchy.  But the display didn't lock up.

Regards,
Mike

Rob CJ

unread,
Apr 21, 2026, 12:46:20 PMApr 21
to jal...@googlegroups.com
Hi Mike,

I added the timeout option a few years ago since, as you mentioned, if for some reason you do not get an ACK, it will wait forever and then the system hangs.

So without checking for the ACK you can use a higher clock speed. Interesting.

Kind regards,

Rob



Van: 'Mike' via jallist <jal...@googlegroups.com>
Verzonden: dinsdag 21 april 2026 03:20

Mike

unread,
Apr 21, 2026, 2:40:09 PMApr 21
to jallist
Hi Rob,

Thanks for looking into this and tolerating my wild goose chase.

Regards,
Mike
Reply all
Reply to author
Forward
0 new messages