nRF52840-DK - SSD1306 - Display

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Mon, 08 Apr 2024 07:33:59 GMT

Sorry for the late reply, I just saw that you asked a question.

Of course it does not work, because it is a custom written code by myself specifically for a 0.96" OLED Display (128x64), but my code is available on github as already mentioned in my original post, but here is the link again https://github.com/DBS06/test_zephyr_oled .

For your display, you most likely need to adapt the overly, prj and main file to fit four your display, but you need to do this by your own, if you still have questions you should raise a new ticket, because this one is closed

RE: nRF52840-DK - SSD1306 - Display

Amank0623 — Fri, 29 Mar 2024 08:44:56 GMT

I am facing issue when tring to interface 1.3" ssd1306 oled with nrf52832 with above given overlay, prj and main file but there is showing "#include "logo_image.h". please help

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 13 Feb 2024 20:28:41 GMT

Imho It's always good to give something back to the community.

I really went down into a deep rabbit hole 😂 I was really happy when it worked.

My thoughts when I saw the switch in the wrong position: "f*** my life, this can't be true..." 😳

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Tue, 13 Feb 2024 20:14:43 GMT

Thank you for providing all the details of debugging and problem description, I am sure this will help others down the line!

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 13 Feb 2024 20:10:55 GMT

Hi, I made it!

I checked the I2C Bus with a logic analyzer (which looked okay, no timing issues or else) and compared it with the Arduino, nothing really different, except some minor differences, which shouldn't matter.

I still had no clue what causes these strange behavior. Then I rewrote the SSD1306_init() function to get the same initialization procedure as the Arduino, but without success and I still had no 😮ue, but I knew, it must be a small issue, which I didn't thought about. I was near to give up, but I am not a person who gives up easily and I had nights were I layed in the bed and thought about it. 😮‍💨

The Zephyr driver wasn't the problem, which didn't actually surprised me anymore. The error or solution was quite easy, but not really obvious on the first or 100th look 😉 and I am feeling a little bit stupid 😞‍, that I haven't carefully checked the board first.

I am using the BMD-340 DK from Rigado (now UBlox) and the "nRF only mode" switch was set somehow to LV and not to HV on my board... The switch, especially the description/labels on the board, differs from the nRF52840-DK from Nordic, so it wasn't easy to see. I switched the switch to the correct position and the display worked.

Then I was interested why these strange behavior occured and used an oscilloscope and made some measurements. The display did work after connecting and disconnecting from the Arduino to the BMD-340 DK, because it was parasitically powered by the I2C Bus and the onboard capacitos from the display were still charged from the Arduino. Without using the Arduino beforehand, the display had to less current for powering up initially and to load the capacitors. Who had thought about this?

Nevertheless, this issue had something quite good too. I studied the SSD1306 datasheet a couple of times and now I know how the SSD1306 IC works in detail. Furthermore, I got a lot of knowledge how the device tree concept works (I am new to Zephyr), how the layering works (awesome btw), how drivers are implemented in Zephyr and many little things more.

I wrote you my journey to the solution of my problem, because I think it could be helpful for you or others, if someone else will ran in some similar problem and didn't checked, if the "nrf only switch" is in the "correct" position.

So thanks for your help and time!
Kind regards

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Wed, 07 Feb 2024 08:18:56 GMT

[quote user="DBS06"]I thought that the "chosen {..." just defines/declares an alias for a device, (in this case the display)?[/quote]

Yes, or at least it defines the default chosen configuration. But it should not really matter in your case no.

Looking at your TWIM_LOG it seems like everything is working, so then it is more likely some missing configuration (hopefully the logic analyzer will help) or some timing issue (hopefully the logic analyzer will help there also).

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 06 Feb 2024 22:41:47 GMT

Here is the TWIM_LOG without the constant change in my while loop:

[00:00:00.252,838] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
--- 2 messages dropped ---
[00:00:00.253,845] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.254,302] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.254,333] <inf> NRFX_TWIM: Transfer buffers length: primary: 3, secondary: 0.
[00:00:00.254,364] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.254,821] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.254,852] <inf> NRFX_TWIM: Transfer buffers length: primary: 3, secondary: 0.
[00:00:00.254,882] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.255,340] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.255,371] <inf> NRFX_TWIM: Transfer buffers length: primary: 3, secondary: 0.
[00:00:00.255,432] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.255,889] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.255,889] <inf> NRFX_TWIM: Transfer buffers length: primary: 2, secondary: 0.
[00:00:00.255,950] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
*** Booting nRF Connect SDK v2.5.2 ***
[00:00:00.256,347] <inf> display: x_resolution: 128
[00:00:00.256,347] <inf> display: y_resolution: 64
[00:00:00.256,378] <inf> display: supported pixel formats: 4
[00:00:00.256,378] <inf> display: screen_info: 1
[00:00:00.256,408] <inf> display: current_pixel_format: 4
[00:00:00.256,408] <inf> display: current_orientation: 0
[00:00:00.256,439] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.256,469] <inf> NRFX_TWIM: Transfer buffers length: primary: 2, secondary: 0.
[00:00:00.256,530] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.256,866] <dbg> ssd1306: ssd1306_write: x 0, y 0, pitch 128, width 128, height 64, buf_len 1024
[00:00:00.256,896] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.256,927] <inf> NRFX_TWIM: Transfer buffers length: primary: 9, secondary: 0.
[00:00:00.256,988] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.258,117] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.258,148] <inf> NRFX_TWIM: Transfer buffers length: primary: 1025, secondary: 0.
[00:00:00.258,209] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.
[00:00:00.360,046] <inf> NRFX_TWIM: Transfer type: XFER_TX.
[00:00:00.360,046] <inf> NRFX_TWIM: Transfer buffers length: primary: 3, secondary: 0.
[00:00:00.360,107] <wrn> NRFX_TWIM: Function: nrfx_twim_xfer, error code: NRFX_SUCCESS.

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 06 Feb 2024 18:57:25 GMT

I ordered today a cheap logic analyzer, which should arrive on Thursday.

The TWIM Log looks actually pretty good, I get always a Success. The I2C connection itself seems to work, otherwise the content of the display wouldn't change between the Arduino and the nrf52840-DK. But nevertheless I will provide a Log as soon as possible.

Btw thanks a lot for your time and effort!

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 06 Feb 2024 18:51:46 GMT

I thought that the "chosen {..." just defines/declares an alias for a device, (in this case the display)?

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Tue, 06 Feb 2024 13:30:13 GMT

Let me know when you have some logs to share (e.g. logic analyzer and with CONFIG_NRFX_TWIM_LOG)

Kenneth

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Tue, 06 Feb 2024 13:28:54 GMT

A collegue tipped me off that you may be missing in the devicetree the following:

/ {
chosen {
zephyr,display = &sh1106_sh1106_128x64;
};
};

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Tue, 06 Feb 2024 11:56:46 GMT

I made a video about the strange behavior: youtu.be/hgGmu3kxtwU

First the display is connected to the nR53849-DK -> nothing
Then connected to Arduino BLE Sense -> works
Then connected back to the nRF52840-DK -> works, as long the board is not powered off a long time

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Mon, 05 Feb 2024 18:09:14 GMT

Thanks, good idea!

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Mon, 05 Feb 2024 18:02:49 GMT

Also setting CONFIG_NRFX_TWIM_LOG=y in prj.conf may provide some low level debug information here.

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Mon, 05 Feb 2024 17:46:08 GMT

It is really interesting.

As I already said, that's one of the weirdest issues I ever had, and I am programming microcontrollers since 15 years: "Connecting the display to the Arduino BLE and then connecting it to the nRF52840 DK and the display is working"... WTF?!

I will try to make a video of it, because I think no one is believing me 😅

I will definitely retry to add the sleep at ssd1306_init().

You know, I really want this to work with NCS/Zephyr and this issue is really annoying and frustrating.

Actually I want to use this display as a mobile debug terminal (without using a PC) for other applications, which can redirect their log output to serial output and I could see what they are doing.

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Mon, 05 Feb 2024 17:03:45 GMT

Interesting, if that is the case you may just try to add a k_msleep(50); in start of ssd1306_init() in \zephyr\drivers\display\ssd1306.c for test. (I used 50 just to ensure there is good margin).

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Mon, 05 Feb 2024 16:45:07 GMT

First, thanks for your reply!

According to the datasheet of my 0.96" OLED, the pull-ups should be already on the board. Nevertheless I will give it a try.

In the meanwhile I looked closer on the SSD1306 driver on the Zephyr Repo and there I found this issue https://github.com/zephyrproject-rtos/zephyr/pull/62049. This fix is already merged into Zephyr SDK 3.5, but the newest version of zephyr in NCS is 3.4.99, so this could probably solve my issue.

I already tried to replace the SSD1306 driver from NCS with the driver from the Zephyr Repo, but I had no success, but I have to say, I did this really quick and dirty and had no time to investigate this further, because my child is ill...

I also have the same display with SPI, and I will try this out.

RE: nRF52840-DK - SSD1306 - Display

Kenneth — Mon, 05 Feb 2024 12:17:53 GMT

Hello,

As you mention, it could be interesting to get an logic analyzer trace of the i2c pins to see if anything stands out. I think the problem is there.

One thing I can think of is that you may be missing pull-up resistors on the i2c pins, if there are none externally you can add bias-pull-up; to pinctrl.

Kenneth

RE: nRF52840-DK - SSD1306 - Display

DBS06 — Fri, 02 Feb 2024 16:31:28 GMT

Ok, I looked deeper into this issue and after I powered the nrf52 off and waited for at least an hour, the Display does not display the image anymore, after powering up again.

I am guessing, that the SSD1306 driver from Adafruit for the Arduino does something, which the Zephyr Driver does not do, or does it in a different way. I don't think it has something to do with my application and the configuration.

I already compared the initialization from both drivers quickly, but wasn't able to go deeper into this issue, because I ran out of time.

Sadly I don't have a logic analyzer at home, which would make debugging a lot easier.

Maybe I try out an earlier version of the SDK, most likely the v2.1.0 from this example Printing to an I2C OLED display using nRF Connect SDK .

If anyone has a hint, I am looking forward to hear it