SSD1306 OLED display fails for nRF52840 boards using nRF Connect SDK 3.2.1

[zpm1066]

Hello,

I’ve been using SSD1306 128x64 OLED displays with nRF52840 boards for several years without any issues, building with nRF Connect SDK 2.5.x to 3.1.0. Recently, I've been attempting to move existing NCS 3.1.0 projects over to NCS 3.2.1. However, I’m unable to successfully get the SSD1306 OLED display to work with any of the nRF52840 boards using the latest nRF Connect SDK 3.2.1.

All the nRF52840 boards with SSD1306 display work fine when built with vanilla Zephyr 4.1.x and 4.2.x.

Also, the target for thingy53/nrf5340/cpuapp/ns failed to run successfully with both NCS 3.1.0 and NCS 3.2.1. The target thingy53/nrf5340/cpuapp ran fine with the SSD1306 OLED.

To try to isolate the issue, I’ve taken the Zephyr sample, “/opt/nordic/ncs/v3.2.1/zephyr/samples/subsys/display/cfb_custom_font” and built it for a couple of different nRF52840 boards (e.g. particle_xenon_nrf52840, promicro_nrf52840) plus thingy/nrf5340/cpuapp.

Built exactly the same sample "cfb_custom_font" main.c (modified to display board target and Zephyr version) & used the same devicetree overlays. All the builds compiled and linked without any issues.  However, only particle_xenon/nrf52840 using NCS 3.1.0 and thingy53/nrf5340/cpuapp using NCS 3.2.1 ran successfully with the SSD1306 displays.

I used the below board configuration and the overlays with the ssd1306 devicetree included in the I2C sections of the overlays. Default sysbuild option used from with the nRF Connect SDKs.

I don't see anything that is obvious that may be wrong. I would appreciate if you could determine the cause of the issue with the nRF52840 boards with SSD1306 when using  nRF Connect SDK 3.2.1.

Also, Is there any reason as to why the target for thingy53/nrf5340/ns doesn’t run successfully with the I2C SSD1306 display?

Thank you.

particle_xenon_nrf52840.overlay:

/ {
	chosen {
		zephyr,display = &ssd1306;
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
	};
};

&uart0 {
	compatible = "nordic,nrf-uarte";
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart0_default>;
	pinctrl-1 = <&uart0_sleep>;
	pinctrl-names = "default", "sleep";
};

&gpio0{
	status = "okay";
};

&i2c0 {
	compatible = "nordic,nrf-twi";
	status = "okay";
	pinctrl-0 = <&i2c0_default>;
	pinctrl-1 = <&i2c0_sleep>;
    pinctrl-names = "default", "sleep";
	ssd1306: ssd1306@3c {
		compatible = "solomon,ssd1306fb";
		reg = <0x3c>;
		width = <128>;
		height = <64>;
		segment-offset = <0>;
		page-offset = <0>;
		display-offset = <0>;
		multiplex-ratio = <63>;
		segment-remap;
		com-invdir;
		prechargep = <0x22>;
	};
};

thingy53_nrf5340_cpuapp.overlay

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

&pinctrl {
	i2c0_default: i2c0_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 5)>,
				<NRF_PSEL(TWIM_SCL, 0, 4)>;
		};
	};

	i2c0_sleep: i2c0_sleep {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 5)>,
				<NRF_PSEL(TWIM_SCL, 0, 4)>;
		};
	};
};

&i2c0 {
	compatible = "nordic,nrf-twim";
	status = "okay";
	clock-frequency = <I2C_BITRATE_FAST>;
	zephyr,concat-buf-size = <4096>;
	pinctrl-0 = <&i2c0_default>;
	pinctrl-1 = <&i2c0_sleep>;
    pinctrl-names = "default", "sleep";
	ssd1306: ssd1306@3c {
		compatible = "solomon,ssd1306fb";
		reg = <0x3c>;
		width = <128>;
		height = <64>;
		segment-offset = <0>;
		page-offset = <0>;
		display-offset = <0>;
		multiplex-ratio = <63>;
		segment-remap;
		com-invdir;
		prechargep = <0x22>;
	};
};

prj.conf:

CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_DISPLAY=y
CONFIG_SSD1306=y

CONFIG_CHARACTER_FRAMEBUFFER=y
CONFIG_CHARACTER_FRAMEBUFFER_USE_DEFAULT_FONTS=n

CONFIG_LOG=y

# Preferred SHELL options
CONFIG_SHELL=y
CONFIG_DEVICE_SHELL=y
CONFIG_INIT_STACKS=y
CONFIG_KERNEL_SHELL=y
CONFIG_SHELL_STATS=n
CONFIG_I2C_SHELL=y

# Enable RTT to replace UART
CONFIG_UART_CONSOLE=y
CONFIG_USE_SEGGER_RTT=n
CONFIG_SHELL_BACKEND_RTT=n

CONFIG_LOG_BACKEND_UART=y
CONFIG_SHELL_LOG_BACKEND=y

Console Output 

NCS 3.2.1 build  - particle_xenon_nrf52840 with  SSD1306 (particle_xenon/nrf52840):

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***

Display device not ready

Failed to turn off display blanking

NCS 3.1.0 build  - particle_xenon_nrf52840 with  SSD1306 (particle_xenon/nrf52840):

*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
Zephyr v4.1.99
Board target: particle_xenon/nrf52840

NCS 3.2.1 build  - thingy53_nrf5340_cpuapp with  SSD1306:

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.035,614] <inf> udc_nrf: Initialized
Zephyr v4.2.99
Board target: thingy53/nrf5340/cpuapp

NCS 3.1.0 build  - thingy53_nrf5340_cpuapp with  SSD1306:

[Disconnected]
[Connected]
*** Booting nRF Connect SDK v3.1.0-6c6e5b32496e ***
*** Using Zephyr OS v4.1.99-1612683d4010 ***
Zephyr v4.1.99
Board target: thingy53/nrf5340/cpuapp

Vanilla Zephyr 4.2.x from terminal command line: SSD1306 displays works fine.

*** Booting Zephyr OS build v4.2.0-717-g85e135362445 ***
Zephyr v4.2.99
Board target: particle_xenon/nrf52840
uart:~$ 

[Vidar Berg]

Hi Ravi, 

Good to hear that it works now. What configuration to use for your TF-M image depends on what you are going to use it for. The configuration I used provides the crypto services needed to perform LE secure connections pairing. Please refer to the SDK documentation here for more details on this: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/tfm/tfm_supported_services.html#tf-m-version-in-the-ncs

zpm1066 said:

I'm finding that I need to turn off logging (CONFIG_LOG=n) in order to get the non-BT thingy53/nrf5340/cpuapp/ns applications to run successfully.

Is this related to "When building TF-M with logging enabled, UART instance used by TF-M must be disabled in the non-secure application, otherwise the non-secure application will fail to run." as mentioned in the TF-M Logging docs?  Thingy53 has the TF-M logging on UART0, same as the console.

The ns application is using the USB device for console/logging. UART0 is not used. 

Best regards,

Vidar

[zpm1066]

HI Vidar,

For the non-BT TF-M applications, I have tried to use your suggested TF-M minimal configuration. The applications build but din't run. However, as mentioned, when I turn off logging, the applications run successfully.

I've reviewed the TF-M docs but will take another look later today. The issue now is how to get successful TF-M for non-BT applications. I've tried a few different configurations but not been successful yet, other than by disabling logging.

I tried building the "tfm_hello_world" sample unmodified on the Thingy53 as NS. The build runs successfully if I disable TF-M logging (CONFIG_TFM_LOG_LEVEL_SILENCE=y) .



Best Regards,
Ravi

[Vidar Berg]

Hi Ravi,

I don't see any reason for why the same TF-M configuration should not work for non-BT applications. I'm not able to reproduce this here with the same board modifications I posted earlier either.

Best regards,

Vidar

[zpm1066]

Hi Vidar,

I agree. The same TF-M configuration should also work for non-BT applications on Thingy53.

In my previous comment, I meant to say that the non-BT applications work if I silence the TF-M logs (CONFIG_TFM_LOG_LEVEL_SILENCE=y) and use the TF-M minimal configuration. 

If TFM logs are enabled and "CONFIG_RESET_ON_FATAL_ERROR=n ", then the non-BT applications don't run and the USB serial console doesn't show up.

This thingy53_nrf5340_cpuapp_ns works but fails if CONFIG_TFM_LOG_LEVEL_SILENCE=n

# TF-M profile has to be properly configured to be able to run
# the Bluetooth stack which uses PSA crypto API.
# The following configuration is a minimal set of options required.
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_PARTITION_PLATFORM=y
CONFIG_TFM_PARTITION_CRYPTO=y
CONFIG_TFM_PARTITION_INTERNAL_TRUSTED_STORAGE=y
CONFIG_TFM_PARTITION_PROTECTED_STORAGE=n
CONFIG_TFM_PARTITION_INITIAL_ATTESTATION=n

# This Board implies building Non-Secure firmware
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Disables reboots on fatal error
CONFIG_RESET_ON_FATAL_ERROR=n

# TFM logs disabled
CONFIG_TFM_LOG_LEVEL_SILENCE=y

Best Regards,
Ravi

[Vidar Berg]

Hi Ravi,

This don't make much sense to me. I can try to debug this on my end, but I would need to know the exact sample and configuration to use in that case.

Best regards,

Vidar