4 wire SPI OLED display not working with BLE33

I can assure you that my SSD1351 display works fine with Adafruit_SSD1351.h and with my own library.

There seems to be a Waveshare module in UK stock from Amazon.uk.
If I can find out how to buy from Amazon without signing up for Prime I might buy one.

Last time I attempted to buy from Amazon it would not let me unless I joined Amazon Prime. So I went elsewhere.

David.

That would be great. I can order it for you and send it to you. I'd pay for it all. My email address is: jscanova@gmail.com if you are ok with sending me your mailing address.

Btw: I'm Canadian on the west coast of Canada. I'm British as well by nationalization. I'm on Amazon UK a lot to send my British friends gifts.

I am quite happy to buy items online.
The Amazon item is advertised as £18.55. If I make it into a £20 order I can avoid the Prime confidence trick. Arrives by Thursday instead of tomorrow.

David.

$25?? For that?

$19. But, still. . .

Yes, you have to pay for local items. Everything has gone up in price.

If I buy the non-branded item (like my existing display) from AliExpress it costs £12.87 and probably 10-20 days delivery. e.g. https://www.aliexpress.com/item/1005004467356985.html

David.

"The driver chip of this product is SSD1351, which is very driving."
-- Aliexp

That is impressive.

I have a similar display (purchased in 2018). i.e. same pcb, same pinout. different seller.
No one gives prizes for Chinese advertising copy.

From memory, SSD1351 has 16-bit colours. So the "262,144 colors" is false.

At least it is more truthful than many Ebay TFT adverts.

David.

The Waveshare display arrived from Amazon just now.

I ran it on the BLE33 board. It worked fine with my library and worked fine with Adafruit library.
Incidentally I used VCC=3.3V

So there is nothing wrong with the hardware. It is very unlikely that you have two faulty displays.

I can only suggest that you tidy up the soldering. Check for open / short circuits. Try again.

David.

p.s. I looked in the SSD1351 datasheet. It does have 128x128x18 GDRAM. So you can have 262k colours via parallel interface. Of course you will only use 16-bit colours via SPI. (65k colours)

Thank you very much for doing all of that.

I agree that it is very unlikely faulty hardware.

I'll clean up the wiring today and try again by the end of Wednesday and post results.

I soldered up a new assembly Tuesday afternoon with the same result, i.e. a display of randomly coloured pixels.

I'm going to borrow an Uno on Wednesday and see if I can get a display working with it. That might take me a couple of days. It uses 5v logic I believe so will wire accordingly.

I confirmed that my two identical oled modules are in good working order by connection to an Elegoo Arduino UNO R3.

My wiring diagram, sketch and photo of the result are attached.

I still can't get either of my oleds working with either of my BLE 33s. I always get a screen of randomly coloured pixels sometimes with a faint line of mostly green pixels.

Here is a summary of what I know/have tried:

1)I've tried both my identical oled displays with my two BLE 33s. Still, random coloured pixels.

2)I've tried powering the display with 3.3V from the BLE 33, 5V from an external supply and 5V from the BLE 33 after shorting Vusb. Still, random coloured pixels.

3)I've successfully tested both of my BLE 33s with a Blinky example and an example that reads the onboard accelerometers.

4)I've checked the wiring diagram, wiring and continuity of connections with a multimeter many times.

5)I've checked that the pin numbers in the sketch match the wiring many times.

6)I've tried both a solderless and soldered breadboard. Still, random coloured pixels.

  1. David P. has tried the same assembly and sketch with success. Thank you very much for doing that.

  2. As just mentioned, both of my oleds work with an Elegoo UNO Rev 3.

9)I've tried two different USB cables.

10)All libraries are up to date.

I thought that I might be able to get use of a logic analyzer but no luck.

The only thing that I can imagine, as a beginner, is that the SPI circuitry in both of my BLE 33s is damaged but I think that this is extremely unlikely. But, I have ordered another BLE 33 which will arrive in a few days, i.e. during the week of 11 July 2022.

I'm a beginner doing this as a retirement project so I'm more interested in learning rather than obtaining a quick solution. So, any additional suggestions would be appreciated. I've got the time to try anything.

// Screen dimensions for 1.5" x 1.5" display
#define SCREEN_WIDTH  128
#define SCREEN_HEIGHT 128 

// Pin definitions

//#define SCLK_PIN 16
//#define MOSI_PIN 14
#define CS_PIN   13
#define DC_PIN   10
#define RST_PIN  11

// Colour definitions
#define BLACK           0x0000
#define BLUE            0x001F
#define RED             0xF800
#define GREEN           0x07E0
#define CYAN            0x07FF
#define MAGENTA         0xF81F
#define YELLOW          0xFFE0  
#define WHITE           0xFFFF

// Libraries
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1351.h>
#include <SPI.h>

// Create SSD1351 object
Adafruit_SSD1351 tft = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, &SPI, CS_PIN, DC_PIN, RST_PIN);

void setup(void) {
  tft.begin();
  lcdTestPattern();
}

void loop() {
//do nothing
}

void lcdTestPattern(void)
{
  static const uint16_t PROGMEM colors[] =
    { RED, YELLOW, GREEN, CYAN, BLUE, MAGENTA, BLACK, WHITE };

  for(uint8_t c=0; c<8; c++) {
    tft.fillRect(0, tft.height() * c / 8, tft.width(), tft.height() / 8,
      pgm_read_word(&colors[c]));
  }
}

Maybe the Adafruit libraries aren't compatible.
I tried running an ILI9341 with the Adafruit libraries on an ESP32. It compiled but No Joy.
I found another library that worked out, Arduino_GFX ('MoonOnOurNation'), but it required some tweaking.
GitHub - moononournation/Arduino_GFX: Arduino GFX developing for various color displays and various data bus interfaces
SSD1351 and Arduino Nano BLE 33 are listed as Supported (128x128, 98x64).

Thank you very much for the information. I will see what I can do with it today.

At first sight, seems your pin numbers are different form the pinout reference.

There is no way that your code could work on a Uno. Likewise, it could not work on BLE33 either.

But seriously. Never connect 5V logic directly to the SSD1351. It is a 3.5V device.

Sit down with a nice cup of tea. Choose hardware SPI pins (if you want to use HW SPI constructor).

Or just use SW SPI with random GPIO pins.

Incidentally, HW SPI is slower than bit-bash on a BLE33. (because BLE33 SPI.h library is crap)

But HW SPI is significantly FASTER on a Uno. (use 3.3V level shifters)

David.

David, Woops, my mistake, I posted the wrong sketch. The one that I used with the UNO is below. The only difference is the pin numbering.

// Screen dimensions for 1.5" x 1.5" display
#define SCREEN_WIDTH  128
#define SCREEN_HEIGHT 128 

// Pin definitions

**//#define SCLK_PIN 13**
**//#define MOSI_PIN 11**
**#define CS_PIN   8**
**#define DC_PIN   9**
**#define RST_PIN  7**

// Colour definitions
#define BLACK           0x0000
#define BLUE            0x001F
#define RED             0xF800
#define GREEN           0x07E0
#define CYAN            0x07FF
#define MAGENTA         0xF81F
#define YELLOW          0xFFE0  
#define WHITE           0xFFFF

// Libraries
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1351.h>
#include <SPI.h>

// Create SSD1351 object
Adafruit_SSD1351 tft = Adafruit_SSD1351(SCREEN_WIDTH, SCREEN_HEIGHT, &SPI, CS_PIN, DC_PIN, RST_PIN);

void setup(void) {
  tft.begin();
  lcdTestPattern();
}

void loop() {
//do nothing
}

void lcdTestPattern(void)
{
  static const uint16_t PROGMEM colors[] =
    { RED, YELLOW, GREEN, CYAN, BLUE, MAGENTA, BLACK, WHITE };

  for(uint8_t c=0; c<8; c++) {
    tft.fillRect(0, tft.height() * c / 8, tft.width(), tft.height() / 8,
      pgm_read_word(&colors[c]));
  }
}

So, I see why you say that it could not have possibly worked with the UNO. It did work with the correct pin numbers.

The concept of SW vs HW SPI is new to me. I did have a look on the Internet and understand the idea. I now see why there is two constructors in the Arduino "text.ino" for creating a display object.

While reading about this on the Internet, I came across various numberings for the pins. I think this may be where I am going wrong. My pin numbers where based on this image from **https://www.makerguides.com/arduino-nano/**:

However, I also came across this schematics from **https://content.arduino.cc/assets/NANO33BLE_V2.0_sch.pdf**:

I also found a datasheet for the Arduino BLE 33 which appears to have even another pin numbering.

I've just tried to test the alternate pin numbering but I'm having trouble connecting to both of my BLE33s. It happens sometimes. Also, as an aside, sometimes when I load a sketch for the display, the display just remains blank. But, if this continues, I'll open a new topic.

In the meantime, can you provide any clarification on the pin numbering?

I do not own one of those boards to test, but it seems unlikely that the board header number is the pin number. Lots of pinout description results in google.

Thanks for the input. Do you have a link to the list that I should be using for #define in sketches?

I found this pinout in Arduino Nano: Pinout, Wiring Diagram and Programming
I think shoul be similar for the BLE. If pin number DX does not work with the adafruit library, try DX -> X

Thank you. I will try this numbering tomorrow.

1 Like