I may be missing something, but this looks like a buffer underflow issue in the latest code.
In SSD1306I2C::display(), the code writes the I2C control byte (0x40) to buffer[-1].
However, getBufferOffset() returns 0, so no extra byte is reserved before the framebuffer.
This means buffer[-1] is outside the allocated memory.
In partial update mode, this seems especially problematic when minBoundX == 0:
start = &buffer[(minBoundX + y * width) - 1];
This becomes &buffer[-1], which is undefined behavior.
From what I can see, the intention is to prepend the control byte without copying, which makes sense.
However, the required buffer offset does not seem to be allocated.
Possible fixes might be:
- Make getBufferOffset() return 1
- Or use a separate TX buffer instead of modifying the framebuffer
I confirmed this using the latest code from the repository.
I may be missing something, but this looks like a buffer underflow issue in the latest code.
In SSD1306I2C::display(), the code writes the I2C control byte (0x40) to buffer[-1].
However, getBufferOffset() returns 0, so no extra byte is reserved before the framebuffer.
This means buffer[-1] is outside the allocated memory.
In partial update mode, this seems especially problematic when minBoundX == 0:
This becomes &buffer[-1], which is undefined behavior.
From what I can see, the intention is to prepend the control byte without copying, which makes sense.
However, the required buffer offset does not seem to be allocated.
Possible fixes might be:
I confirmed this using the latest code from the repository.