Krimskrams: STM32G431 and OLED

[STM32ardui]

Odds & Ends: various things of different types, usually small and not important, or of little value.
In german language "Krimskrams".

A user has problem with STM32F411 and OLED-display (I²C) and thinks he solved it with a "reset pin".

I'm lazy and STLink is still connected to a STM32G431 board. So I use this for a test.
Instead of Adafruit GFX etc. I'm using U28g library from Oli Kraus for monochrome displays.

Here is the sketch:

Code: Select all

//-----------------------------------------------------------------------------
// Board: STM32G431CBU6 (WeactStudio "long type")
// https://github.com/stm32duino/Arduino_Core_STM32/blob/main/variants/STM32G4xx/G431C(6-8-B)U_G441CBU/PeripheralPins.c
// https://github.com/stm32duino/Arduino_Core_STM32/blob/main/variants/STM32G4xx/G431C(6-8-B)U_G441CBU/variant_generic.h
// DAC:   PA4, PA5
// I2C:   PA8 (SDA), PA9 (SCL)
// UART1: PA3 (RX), PA2 (TX)  
// LED:   PC6
// 
// https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#ssd1306-128x64_noname
// Reference with functions: https://github.com/olikraus/u8g2/wiki/u8g2reference
//-----------------------------------------------------------------------------

#include <U8g2lib.h>    // version U8g2@2.34.22

U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, PA9, PA8 );

void setup() {
  Serial.begin(19200);
  delay(2500);
  Serial.print("\n\n ----- Test OLED-Display 124x64 Pixel SH1106/SSD1306 and STM32G431CBU6 ----- \n");

  u8g2.setI2CAddress(0x3C * 2);
  u8g2.begin();
  u8g2.setFont(u8g2_font_ncenB08_tr);
}

void loop() {
  u8g2.clearBuffer();	
  u8g2.drawStr(10,10,"STM32G431CBU6");	
  u8g2.drawStr(10,25,"OLED 124x64");
  u8g2.setCursor(10, 50);
  u8g2.print(millis()/1000);
  u8g2.sendBuffer();
  delay(1000);
  Serial.printf("bygone time: %d s\n",millis()/1000);
}

Sketch uses 31616 bytes (24%) of program storage space. Maximum is 131072 bytes.
Global variables use 3052 bytes (9%) of dynamic memory, leaving 29716 bytes for local variables. Maximum is 32768 bytes.

1.3inch display is from AliExpress with that typical chinese description:
Display Mode 1.3" OLED
Type TFT
wide supply range: DC 3V-5V
Support for multiple operation modes: 3-wire SPI, 4-wire SPI, IIC
internal drive chip: SH1106 (operation and SSD1306 same)

Of course he's selling only a I²C version and display has 4 pins. I'm simply trying I²C-standard adress 0x3C, there is no info in offer. I don't need a delay() after U8g2.begin() and also no reset pin.

STM32G431-OLEDk.jpg (79.16 KiB) Viewed 4916 times

[ag123]

I remembered that I used Adafruit's library
https://github.com/adafruit/Adafruit_SSD1306
I remembered I encountered that 'reset' issue once.
Apparently, if I remember that situation, the lib sends a 'software reset' via i2c.
I couldn't figure out what went wrong, but I tried with the 'reset pin' option which toggles a PAxx gpio pin.
it works. I did not verify if I simply omit commit the wires if it still works the same as what the op claims, but I'd assume that the 'reset pin' on ssd1306 'works' after all, as it worked after I allocated that gpio pin to reset the lcd.

Most of the time, I did not dig further once the lib and display works, I simply get on with it and use it for some purpose e.g. to display some text etc.

[STM32ardui]

I remembered that I used Adafruit's library
https://github.com/adafruit/Adafruit_SSD1306
I remembered I encountered that 'reset' issue once.
Apparently, if I remember that situation, the lib sends a 'software reset' via i2c.

justinjools also uses Adafruit library.
And he said, his display has 4 pins.

I²C communication doesn't know a reset. I²c-master begins conversation with start-condition. That means, SCL is HIGH and SDA is going to LOW. Next is sending I²C-adress and so on. You can call it a design flaw - if I²C-bus is hanging, you have to power-off at least all I²C-slaves, because even a MCU reset will not help.

If your display has 5 pins - do you have a direct link? - it may be possible to reset a display (deleting graphic memory, setting registers to default values etc). SSD1306 can work as 8pin parallel, 3- and 4-wire SPI and I²C. And on the yellow flex-cable there is a reset-pin. In datasheet is written, after power-on reset line should go LOW for minimum 3 µs. So it depends on manufactor, if he place reset on pin-header or not. It's easy to connect a capacitor to GND and a resistor to VCC to get a LOW-condition after power-on. I guess, that's the way most manufactors do it.

As long as display has 4 pins, a reset will have any (direct) impact, it's simply impossible!
It's only the 1 ms + 10 ms delays and time for executing digitalWrite() instructions.
So I still believe, Adafruit library has a timing problem and they solve it with that pseudo-reset.
It would be more honest to tell users to place a delay(50) after display.begin() to give display "settling time".

Adafruit library is nearly 6 years old. The code still has a checking for Arduino version > 100 and > 157 inside.
It is tested on Arduinos, ESP8266/ESP32 and SAMD21, but not on STM32. Hmm ... ESP32 is also faster that Arduino UNO. In an example for I²C they wrote:

Code: Select all

This example is for a 128x64 pixel display using I2C to communicate
 3 pins are required to interface (two I2C and one reset).

But they don't sell small I²C-displays with a reset line.

U8g2 is made for a lot of microcontrollers and it should be possible to use it without Arduino IDE, STM32 is also named. From some github issues it sounds like adapted timing for different controllers. But I have not enough time to take a detailed look insdie the huge code of ilbrary.

U8g2 simply works with STM32 without a pseudo reset.

[ag123]

I did a review of the ssd1306 datasheet, this is found from a google search from adafruit's web site
https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf

Apparently, there is no specific commands for the ssd1306 lcd to do a software reset.
The only thing documented apparently is 8.5 reset circuit (page 23), which is triggered by the reset pin.

so I took a look at the source code
https://github.com/adafruit/Adafruit_SS ... 6.cpp#L553

Code: Select all

 // Reset SSD1306 if requested and reset pin specified in constructor
  if (reset && (rstPin >= 0)) {
    pinMode(rstPin, OUTPUT);
    digitalWrite(rstPin, HIGH);
    delay(1);                   // VDD goes high at start, pause for 1 ms
    digitalWrite(rstPin, LOW);  // Bring reset low
    delay(10);                  // Wait 10 ms
    digitalWrite(rstPin, HIGH); // Bring out of reset
  }

and apparently the various constructors
https://github.com/adafruit/Adafruit_SS ... 306.h#L132
defines rst_pin as either -1 or that you pass a value to it.

In my case, I've a real reset pin connected, driven by at PAxx gpio.
But I'd guess, if that is phony, i.e. just pass an arbitrary pin, then that this does 'nothing'
if it is just a 'speed' issue, then that delay()s may unintentionally have an effect, it could have given time for the lcd to initialise after power on.

If for that matter that it works, then perhaps 'reset' is after all not required.
In my case, I remembered that initially it 'didn't work', but works after I assigned and connect a valid (real) reset pin to a gpio.
Sometimes, we ignored these 'mysteries' once we got it to work, and I assumed in my case it solved the problem after the (real) reset pin is connected.

the 4 pins ones normally don't sport a reset pin I think, like you observed.
but apparently there are 7 pin ones which can be driven from spi as well, some of those has a reset pin on the module
https://www.aliexpress.com/item/1005005731875885.html
https://www.aliexpress.com/item/1005004131362533.html

I think we can reasonably conclude that it is a 'speed' issue, in that the delay()s allow time for the lcd to initialise.
Hence, a phony 'reset pin' would do as that adds the delay()s by virtue of those codes