Example at ...\ncs\v1.4.0\zephyr\samples\drivers\display does not work with SSD1306 wired directly to nRF9160DK

[craig.stephan]

When I program the nrf9160dk with the example, the code detects the SSD1306, but the display looks like:

The image is only using the middle half (16 rows) of the display that has 32 rows and 128 columns. 

And the left side of the image is a random set of pixels.

What can I do to get the example to give me text on the screen?

I am using the SSD1306 OLED at: https://www.amazon.com/Pieces-Display-Module-SSD1306-3-3V-5V/dp/B08CDN5PSJ/ref=sr_1_8?dchild=1&keywords=ssd1306&qid=1606702037&sr=8-8

Do I have to modify any of the files to target the nRF9160 instead of the nRF52 family?

[helsing]

Hi Craig,

Sorry for not replying, I am currently on vacation. I will continue working on this when I am back the first week of January. Below is the current status on my side:

I got the example to compile and I flashed the nRF9160 DK, however, the display was completely black. I am not entirely sure I powered the display correctly.

Would you be able to share the code that produced the pattern which is visible in the image you shared initially? Or is this the code that you already shared?

Which voltage are you powering your display with? I am worried the I/O-voltages are not high enough. From the limited documentation for the display(the images in the Amazon-link you shared), It looks like the I/O-voltages of the display requires V_{IH_Min} = 0.8V x Vcc. If Vcc = 5V, then the 3V I/O from the DK might not be sufficient. Please correct me if I am wrong. As I was writing this I read one of the comments on the Amazon ad: '[...]the product is supposed to support 3.3v to 5v as claimed in title, but in fact it only supports 5v[...]'. This, however, is not consistent with the table.

[helsing]

Today I was able to reproduce a similar pattern as you.

I will keep you posted when I find something.

[helsing]

A colleague has some suggestions that you could try. I will try this myself next week.

He suggests to add this to your overlay:

&twim2 {

status = "okay";

concat-buf-size = <1024>;

};

It would then look something like this:

&twim2 {
    status = "okay";
    concat-buf-size = <1024>;
};


&i2c2 {
    status = "okay";
    compatible = "nordic,nrf-twim";
    sda-pin = <30>;
    scl-pin = <31>;
    clock-frequency = <I2C_BITRATE_FAST>;
    ssd1306@3c {
        compatible = "solomon,ssd1306fb";
        reg = <0x3c>;
        label = "SSD1306";
        width = <128>;
        height = <32>;
        segment-offset = <0>;
        page-offset = <0>;
        display-offset = <0>;
        segment-remap;
        com-invdir;
        prechargep = <0x22>;
        multiplex-ratio = <31>;
    };
};

Also try these configs:

CONFIG_I2C=y
CONFIG_I2C_NRFX=y
CONFIG_NRFX_TWIM2=y

[Quard]

I had the same issue on my nRF52-DK and the solution for me was to add a shield to my CMakeLists.txt as it's described here https://jimmywongiot.com/2020/03/30/tutorial-how-to-create-an-application-on-the-nrf9160-dk/ in example #4

[craig.stephan]

I tried the suggestion to add the 2 attributes to the twim2 entry in the device tree. This twim2 entry is apparently not available for the NRF9160. Maybe it is only used for the NRF52? Was it replaced with the i2c2 entry that I am already using?

&twim2 {
  status = "okay";
  concat-buf-size = <1024>;
};

-- Found BOARD.dts: D:/Users/craig/ncs/v1.4.99-dev1/zephyr/boards/arm/nrf9160dk_nrf9160/nrf9160dk_nrf9160ns.dts
-- Found devicetree overlay: D:/nordicProjects/cfb/nrf9160dk_nrf9160ns.overlay
Error: nrf9160dk_nrf9160ns.dts.pre.tmp:577.1-7 Label or path twim2 not found
FATAL ERROR: Syntax error parsing input tree
CMake Error at D:/Users/craig/ncs/v1.4.99-dev1/zephyr/cmake/dts.cmake:206 (message):
command failed with return code: 1

The addition of the prj.conf options did not result in any errors or functional change.

CONFIG_NRFX_TWIM2=y
CONFIG_I2C_NRFX=y

Please let me know what you find out when you try this out this week.

I also looked at the i2c signals the i2c2 master in the NRF9160 is sending to the ssd1306. The edge rates look good, and the ssd1306 is consistently acknowledging the transfers. Here was one random data sample to demonstrate the signal integrity. 

I have also included a screenshot with a "stop" and a "start" that shows the 0x78 device address followed by 0x00 data byte.

Regards,

Craig