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

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

zpm1066 — Mon, 23 Feb 2026 14:05:09 GMT

Hi Vidar,

Thank you. Your efforts are very much appreciated.

I'll go ahead and close this ticket.

Best Regards,
Ravi

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

Vidar Berg — Mon, 23 Feb 2026 08:58:38 GMT

Hi Ravi,

Thanks for update. I think this summarises the problems you have experienced.

[quote user="zpm1066"]One thing I did notice on the nRF54l15DK, with TF-M logging on one of the BT non-secure application, was the appearance of Crypto Accelerator Engine (CRACEN) in the TF-M logs.[/quote]

The CRACEN is powered off between uses to avoid affecting the idle current. The same is done when using the CC312 crypto accelerator with the nRF5340, but it is simply not logged.

[quote user="zpm1066"]I plan using security peripherals in a TF-M partition in a few projects soon. So, hopefully this exposure to TF-M will assist.

I don't know if the DevAcademy Team have a TF-M Services in the works but it would be welcomed as IoT security requirements are gaining considerable attention in the market.[/quote]

I agree, and security in general is also something we are focusing on more now. I will forward your request internally.

Best regards,

Vidar

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

zpm1066 — Mon, 23 Feb 2026 03:27:45 GMT

Hi Vidar,

Thank you for the explanation regarding the TWIM0(i2c0) being shared with UART0 on the Thingy53, and that the application will trigger a secure fault on any writes to the shared TWIM0 / UART0 pin registers reserved for the TF-M image. This all makes perfect sense. Thank you.

On the Thingy53, I'm now using i2c2 for the SSD1306 & BME688 sensor. Now have NS applications, including BT NS applications, running successfully with TF-M logs appearing on P0.12 / P0.11 of the "Current Measurement & Debug" board plugged into the Thingy53.

As nRF5340DK uses UART1 for TF-M, I've switched over from i2c1 to i2c2 as well. So, no more TF-M bus faults there. Of course, one could if needed silence the TF-M logs and use i2c1.

One thing I did notice on the nRF54l15DK, with TF-M logging on one of the BT non-secure application, was the appearance of Crypto Accelerator Engine (CRACEN) in the TF-M logs.

What's triggering these "Powered on/off CRACEN". I don't see them on the Thingy53 or nRF5340DK for the same application.

Powered on CRACEN.
Powered off CRACEN.
Powered on CRACEN.
Powered off CRACEN.

I really appreciate your help on issues related to getting the SSD1306 OLED working (i.e. switch from TWI to TWIM) and, of course, how to use TF-M logging on Thingy53 / nRF5340DK / nRF54L15DK without the applications triggering secure faults.

I plan using security peripherals in a TF-M partition in a few projects soon. So, hopefully this exposure to TF-M will assist.

I don't know if the DevAcademy Team have a TF-M Services in the works but it would be welcomed as IoT security requirements are gaining considerable attention in the market.

Best Regards,
Ravi

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

Vidar Berg — Fri, 20 Feb 2026 06:34:57 GMT

Hi,

It all makes sense now, and I should have caught it earlier. The issue is exactly the same as the one discussed in the linked ticket below, except that the Thingy is using UART0 instead of UART1. TWIM0(i2c0) is shared with uart0.

[quote userid="4240" url="~/f/nordic-q-a/126763/ssd1306-oled-display-fails-for-nrf52840-boards-using-nrf-connect-sdk-3-2-1/560012"]Are you using the same overlay as you were using for your thingy53/nrf5340/cpuapp build? If not, please make sure you are not using the i2c1 instance while also having logging enabled in TF-M: https://devzone.nordicsemi.com/f/nordic-q-a/109959/i2c-problems-in-sdk-v2-6-0-on-nrf5340dk. [/quote]

With CONFIG_TFM_SECURE_UART0=y selected in your case (you can see this in the app's .config build output), the application will trigger a secure fault as soon as it writes the pins to the TWIM0 pin registers since the same registers belong to UART0 reserved to the TF-M image.

Best regards,

Vidar

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

zpm1066 — Fri, 20 Feb 2026 05:47:29 GMT

Hi Vidar,

I'm getting a little further as to why the NS applications may be bus faulting when a TF-M configurable build is run.

On Thingy53, as TF-M logging is output to UART0, I'm able to observe the TF-M logs using P0.12 (Tx) and P0.11 on the “Current Measurement & Debug Board” connected to the Thingy53.

With the "cfb" sample and using the following "thingy53_nrf5340_cpuapp_ns.conf" & TF-M size of 96kB, TF-M throws a BusFault.

# 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

# Enable TF-M logging on UART0
CONFIG_TFM_SECURE_UART0=y
CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=n
CONFIG_TFM_LOG_LEVEL_SILENCE=n
CONFIG_TFM_EXCEPTION_INFO_DUMP=y
CONFIG_TFM_SPM_LOG_LEVEL_DEBUG=y

Thingy53 Console output:

Nothing as a BUsFault occurs and the console is not available.

TF-M Log output on Thingy53 UART0:

[Disconnected]
[Connected]
All pins have been configured as non-secure
Booting TF-M v2.2.0
[Sec Thread] Secure image initializing!
TF-M isolation level is: 0x00000001
TF-M Float ABI: Hard
Lazy stacking enabled
FATAL ERROR: BusFault
Here is some context for the exception:
    EXC_RETURN (LR): 0xFFFFFFBD
    Exception came from non-secure FW in thread mode.
    xPSR:    0x80000005
    MSP:     0x20002BF8
    PSP:     0x2000AEC8
    MSP_NS:  0x2003F018
    PSP_NS:  0x20040098
    Exception frame at: 0x20040098
       (Note that the exception frame may be corrupted for this type of error.)
        R0:   0x0006A9B4
        R1:   0x00000000
        R2:   0x00072240
        R3:   0x00000008
        R12:  0x00000000
        LR:   0x000649E5
        PC:   0x0004D3F6
        xPSR: 0x81000000
    Callee saved register state:
        R4:   0x00000005
        R5:   0x20032E58
        R6:   0x40008000
        R7:   0x00000000
        R8:   0x0006A9BC
        R9:   0x000001FF
        R10:  0x0006A9B4
        R11:  0xFFFCF0F0
    CFSR:  0x00008200
    BFSR:  0x00000082
    BFAR: 0x4000850C
    MMFSR: 0x00000000
    MMFAR: Not Valid
    UFSR:  0x00000000
    HFSR:  0x00000000
    SFSR:  0x00000000
    SFAR: Not Valid

The BusFault appears to occur in the pinctrl driver at "/opt/nordic/ncs/v3.2.1/zephyr/drivers/pinctrl/pinctrl_nrf.c:274"

case NRF_FUN_TWIM_SDA:
NRF_PSEL_TWIM(reg, SDA) = psel;
if (drive == NRF_GPIO_PIN_S0S1) {
drive = NRF_GPIO_PIN_S0D1;
}
dir = NRF_GPIO_PIN_DIR_INPUT;
input = NRF_GPIO_PIN_INPUT_CONNECT;
break;

pioneer15@pioneer15 ~ % /opt/nordic/ncs/toolchains/5c0d382932/opt/zephyr-sdk/arm-zephyr-eabi/bin/arm-zephyr-eabi-addr2line  -e /Volumes/PioneerD/2026_dev/2026_zephyr_dev/original/cfb/build/thingy53_nrf5340_cpuapp_ns/cfb/zephyr/zephyr.elf 0x00032462 

/opt/nordic/ncs/v3.2.1/zephyr/drivers/pinctrl/pinctrl_nrf.c:274

Here is the "thingy53_nrf5340_cpuapp_ns.overlay" overlay being used for the SSD1306.

/ {
	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>;
	};
};

As mentioned before, the "cfb" (and all my other NS applications" run successfully if the TF-M logs are silenced or if I share the TF-M with the application console. Is the latter the same as TF_M silenced since the USB console isn't using UART0 at all?

Do you mind looking into why the bus fault occurs? Thank you.

Best Regards,
Ravi

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

zpm1066 — Thu, 19 Feb 2026 05:15:39 GMT

HI Vidar,

Thank you for the explanation regarding USB logging being not available in TF-M, and also for the link to the hardcoded TF-M pin assignments for the nRF5340DK. Much appreciated.

1. The Thingy53 has several GPIO pins on the "Current Measurement & Debug" interface board, including pins that can be used for a UART.

I would think that 2 of the TRACE pins (TRACE0 - TRACE03, TRACECLK) could be assigned to UART1 in the Thingy53 overlay to enable TF_M logging. Would that work?

2. In order to get the NS applications to run successfully, I've had to configure TF-M to share with the application console, otherwise I get bus faults. The other alternative is to simple silence the TF_M log output.

Best Regards,
Ravi

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

Vidar Berg — Wed, 18 Feb 2026 06:44:42 GMT

Hi Ravi,

I only tried the TF-M Hello World sample. I was looking for one specific sample and exact steps to reproduce the problem.

[quote userid="108657" url="~/f/nordic-q-a/126763/ssd1306-oled-display-fails-for-nrf52840-boards-using-nrf-connect-sdk-3-2-1/561409"]"k_msleep(1000);" doesn't quite work of rme. Instead, "CONFIG_SHELL=y" worked consistently without the delay.[/quote]

When you enable the logger module with or without the shell, the logs will not be printed immediately (provided LOG_MODE_IMMEDIATE is not selected), but instead placed in a buffer and processed in a separate logger thread that is run once every second. The original sample is only using console output and prints everything immediately.

[quote userid="108657" url="~/f/nordic-q-a/126763/ssd1306-oled-display-fails-for-nrf52840-boards-using-nrf-connect-sdk-3-2-1/561409"]1. Why is it that for the Thingy53, we do not observe the "Booting TF-M v2.2.0" TF-M messages similar to what is observed with nRF5340-DK output when both TF-M and application share the same output device?[/quote]

Because it does not have UART logging. USB logging is not available in TF-M. Supporting a USB stack in TF-M is entirely different from supporting a UART driver.

[quote userid="108657" url="~/f/nordic-q-a/126763/ssd1306-oled-display-fails-for-nrf52840-boards-using-nrf-connect-sdk-3-2-1/561409"]2. For the nRF5340-DK v2.0.0 , the TF-M Logging docs state that to get the UART output from the TF-M, one can either physically connect pins P0.25/P0.26 to P0.20/P0.22 or change the pins used by TF-M.

Where is it defined that TF-M logging output uses pins P0.25 and P0.26? I cannot find it anywhere, other than the brief mention in the "TF_M Logging" docs. I would like to try using the nRF5340-DK UART1 to output TF-M logs.[/quote]

TF-M is getting the pin assignments from the devicetree except for the nRF5340DK and other nordic boards where it is hardcoded here: https://github.com/nrfconnect/sdk-trusted-firmware-m/commit/70abd66a1225a89312a8e6775c09d18873ff0579. Anyway, logging on the nRF5340 DK is now using UART1. So when you are not using the network core, you will have one com port available just for the TF-M and another for the application so the application and TF-M does not need to share the same uart instance.

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

zpm1066 — Wed, 18 Feb 2026 04:17:41 GMT

HI Vidar,

I'm a little unclear what you were not able to reproduce.

Did you try running the sample "cfb" with a SSD1306 & TF-M size 96kB on a Thingy53 (and also a nRF5340-DK), with the TF-M configuration that I used below?

I used a Thingy53 and also a nRF4340-DK, sample "cfb" with a SSD1306 & TF-M size 96kB. The NS "cfb" application ran sucessfully provided the following configuration gets used. TF-M logging shared with application console.

# 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

CONFIG_TFM_SECURE_UART0=y
CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y

Thingy53 console output:

[Connected]
Initialized ssd1306@3c
font width 10, font height 16
font width 15, font height 24
font width 20, font height 32
x_res 128, y_res 64, ppt 8, rows 8, cols 128

[00:00:00.000,885] <inf> udc_nrf: Preinit
*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.012,542] <inf> udc_nrf: Initialized
[00:00:00.012,969] <dbg> cfb: cfb_framebuffer_init: number of fonts 3
[00:00:00.016,784] <inf> udc_nrf: SUSPEND state detected
[00:00:00.115,142] <inf> udc_nrf: Reset
[00:00:00.115,203] <inf> udc: ep 0x80 is not halted|disabled
[00:00:00.115,203] <inf> udc_nrf: RESUMING from suspend

nRF4350-DK output:

Writing random Hardware Unique Keys to the KMU.
Success
All pins have been configured as non-secure
Booting TF-M v2.2.0
[Sec Thread] Secure image initializing!
Initialized ssd1306@3c

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.412,933] <dbg> cfb: cfb_framebuffer_init: number of fonts 3
uart:~$ font width 10, font height 16
font width 15, font height 24
font width 20, font height 32
x_res 128, y_res 64, ppt 8, rows 8, cols 128

If TF-M logging is disabled with "CONFIG_TFM_LOG_LEVEL_SILENCE=y", then the NS applications also run successfully.

Regarding "tfm_hello_world" sample with Thingy53:

"k_msleep(1000);" doesn't quite work of rme. Instead, "CONFIG_SHELL=y" worked consistently without the delay.

Questions:

1. Why is it that for the Thingy53, we do not observe the "Booting TF-M v2.2.0" TF-M messages similar to what is observed with nRF5340-DK output when both TF-M and application share the same output device?

Is it because the TF_M logs get output before the Thingy53 USB gets attached?

How do I get the TF-M messages to show up on the Thingy53?

2. For the nRF5340-DK v2.0.0 , the TF-M Logging docs state that to get the UART output from the TF-M, one can either physically connect pins P0.25/P0.26 to P0.20/P0.22 or change the pins used by TF-M.

Where is it defined that TF-M logging output uses pins P0.25 and P0.26? I cannot find it anywhere, other than the brief mention in the "TF_M Logging" docs. I would like to try using the nRF5340-DK UART1 to output TF-M logs.

Thank you.

Best Regards,
Ravi

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

Vidar Berg — Tue, 17 Feb 2026 10:32:34 GMT

Hi Ravi,

I have tried with the TF-M hello world sample as well now and I did not manage to reproduce the behaviour you observed. I did however have to add "k_msleep(1000);" at the beginning of main to allow the USB to attach before the messages were printed.

Best regards,

Vidar

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

zpm1066 — Tue, 17 Feb 2026 01:25:58 GMT

HI Vidar,

I've found out that the TF-M configuration and logging is slightly different on the nRF5340-DK.

According to log output from TF-M on the nRF5340-DK, one option is to wire the secure and non-secure UART peripherals to the same pins, i.e. physically wire together the pins P0.25 and P0.26 to P0.20 and P0.22, respectively.

After wiring together P.025 -> P0.20 & P0.26 -> P0.22, plus using the following TF-M configuration (same as what was used on the Thingy53) worked for NS applications.

# 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

# Set TF-M to share the default console
CONFIG_TFM_SECURE_UART0=y
CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y

Console output (shared by application and TF-M):

All pins have been configured as non-secure
Booting TF-M v2.2.0
[Sec Thread] Secure image initializing!
TF-M Float ABI: Hard
Lazy stacking enabled

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:05.421,661] <inf> app: Board target: nrf5340dk/nrf5340/cpuapp/ns

[00:00:05.421,691] <inf> app: bme688x_iaq_ssd1306 - App started
[00:00:05.421,691] <inf> app: Init ssd1306
[00:00:05.421,875] <dbg> cfb: cfb_framebuffer_init: number of fonts 2
[00:00:05.449,005] <inf> oled: Index[0] font dimensions  5x8
[00:00:05.449,035] <inf> oled: Index[1] font dimensions  8x8
[00:00:05.449,035] <inf> oled: Selected font: index[0]
[00:00:05.449,066] <inf> oled: x_res 128, y_res 64, ppt 8, rows 8, cols 128

Do you know where it is specified that TF-M uses P.25 & P.26 on the nRF5340DK for logging? I couldn't find any reference to it in the nRF5340-DK Hardware Guide or the nRF5340-DK devicetree.

Also, What pins are used on the Thingy53 for TF-M logging, as I do not see the shared TF-M / application outputs in the Thing53 console output as in nRF5340-DK?

Thank you.

Best Regards,
Ravi

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

zpm1066 — Mon, 16 Feb 2026 01:18:56 GMT

Hi Vidar,

I had another look at the Thingy53 NS builds for non-BT applications.

After making the following Kconfig change, the non-BT applications now run on the Thing53.

# Set TF-M to share the default console
CONFIG_TFM_SECURE_UART0=y
CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y

The Thingy53 uses the USB cdc_acm_uart for the application console and UART0 by default is disabled.

It seems that although UART0 is disabled, TF-M logging still requires UART0 configuration and to share TF-M's UART instance with the NS application.

Earlier, without the above configuration, NS applications on Thingy53 worked only if the TF-M logging was disabled via "CONFIG_TFM_LOG_LEVEL_SILENCE=y".

I've verified the resolution using the Zephyr sample "/zephyr/samples/subsys/display/cfb" with TF-M Configurable builds.

TF-M size set to 96kB using static partitioning file "pm_static_thingy53_nrf5340_cpuapp_ns.yml" in the project folder.

thingy53_nrf5340_cpuapp_ns.conf:

# 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

# Set TF-M to share the default console
CONFIG_TFM_SECURE_UART0=y
CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y

Console output:

[Disconnected]
[Connected]
Initialized ssd1306@3c
font width 10, font height 16
font width 15, font height 24
font width 20, font height 32
x_res 128, y_res 64, ppt 8, rows 8, cols 128

[00:00:00.000,885] <inf> udc_nrf: Preinit
*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.012,756] <inf> udc_nrf: Initialized
[00:00:00.013,153] <dbg> cfb: cfb_framebuffer_init: number of fonts 3
[00:00:00.016,967] <inf> udc_nrf: SUSPEND state detected
[00:00:00.114,532] <inf> udc_nrf: Reset
[00:00:00.114,562] <inf> udc: ep 0x80 is not halted|disabled
[00:00:00.114,593] <inf> udc_nrf: RESUMING from suspend

Also, I've ran the sample NS build of sample "tfm_hello_world" on the Thingy53. I noticed an unexpected behaviour.

Initially, I got the following console output below. Some messages seem to have been dropped for some reason.

[Connected]
84--- 16 messages dropped ---
dfde2b22388088bd36ccfbcdd9aab068e63105303997eb0d5a
Example finished successfully!
[00:00:00.005,279] <inf> udc_nrf: SUSPEND state detected
[00:00:00.103,698] <inf> udc_nrf: Reset
[00:00:00.103,729] <inf> udc: ep 0x80 is not halted|disabled
[00:00:00.103,759] <inf> udc_nrf: RESUMING from suspend

If I set "CONFIG_SHELL=y", then the console output is:

[Connected]
*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
Hello World! thingy53/nrf5340/cpuapp/ns
Reading some secure memory that NS is allowed to read
Approximate IPC overhead us: 174
FICR->INFO.FLASH: 0x00000400
Generating random number
0xf1663a5d54a3d23924674a231407b1e44908755aad87a0f8a8c364e5986025ca
Hashing 'Hello World! thingy53/nrf5340/cpuapp/ns'
SHA256 digest:
0x8d062694d91c7504ce428d05b015fb1bfcb3437cf5a2fab6ec5db63830751c1e
Example finished successfully!

I don't understand why the SHELL configuration resolves the dropped messages.

Can you please run the "tfm_hello_world" sample on a Thingy53 to see if you get the same behaviour. Thank you.

Best Regards,
Ravi

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

Vidar Berg — Fri, 13 Feb 2026 16:26:46 GMT

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

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

zpm1066 — Fri, 13 Feb 2026 13:33:13 GMT

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

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

Vidar Berg — Thu, 12 Feb 2026 13:50:37 GMT

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

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

zpm1066 — Thu, 12 Feb 2026 13:40:03 GMT

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

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

Vidar Berg — Thu, 12 Feb 2026 08:23:26 GMT

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

[quote user="zpm1066"]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.[/quote]

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

Best regards,

Vidar

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

zpm1066 — Thu, 12 Feb 2026 05:43:42 GMT

HI Vidar,

Thank you for the TF-M Kconfig. Using the minimal set of option for TF-M, I can now build and run my BT applications (including peripheral_lbs) for thingy53/nrf5340/cpuapp/ns. Your help is much appreciated.

What minimal TF-M configuration should be used to build & successfully run thingy53/nrf5340/cpuapp/ns applications that do not use BT?

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.

Regards,
Ravi

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

Vidar Berg — Wed, 11 Feb 2026 06:25:17 GMT

Hi Ravi,

I thought you were getting the same warning on nrf5340DK. Have now tried to build for the thingy53 as well after making the following changes in the board directory:

diff --git a/boards/nordic/thingy53/pm_static_thingy53_nrf5340_cpuapp_ns.yml b/boards/nordic/thingy53/pm_static_thingy53_nrf5340_cpuapp_ns.yml
index 70ffe6d9c12..b05346273bd 100644
--- a/boards/nordic/thingy53/pm_static_thingy53_nrf5340_cpuapp_ns.yml
+++ b/boards/nordic/thingy53/pm_static_thingy53_nrf5340_cpuapp_ns.yml
@@ -8,20 +8,20 @@ mcuboot_pad:
   size: 0x200
 tfm_secure:
   address: 0x10000
-  size: 0xc000
+  size: 0x18000 
   span: [mcuboot_pad, tfm]
 tfm_nonsecure:
-  address: 0x1c000
-  size: 0xd4000
+  address: 0x28000
+  size: 0xc8000
   span: [app]
 tfm:
   address: 0x10200
   region: flash_primary
-  size: 0xbe00
+  size: 0x17e00
 app:
-  address: 0x1c000
+  address: 0x28000
   region: flash_primary
-  size: 0xd4000
+  size: 0xc8000
 mcuboot_primary:
   address: 0x10000
   orig_span: &id001
diff --git a/boards/nordic/thingy53/thingy53_nrf5340_cpuapp_ns_defconfig b/boards/nordic/thingy53/thingy53_nrf5340_cpuapp_ns_defconfig
index f831ec5148e..aeb0691df9d 100644
--- a/boards/nordic/thingy53/thingy53_nrf5340_cpuapp_ns_defconfig
+++ b/boards/nordic/thingy53/thingy53_nrf5340_cpuapp_ns_defconfig
@@ -6,6 +6,17 @@ CONFIG_ARM_MPU=y
 # Enable TrustZone-M
 CONFIG_ARM_TRUSTZONE_M=y
 
+# 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

I did not see any warnings or errors in the log.

Best regards,

Vidar

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

zpm1066 — Tue, 10 Feb 2026 15:11:00 GMT

Hi Vidar,

No modification to the original peripheral_lbs sample was made when building for thingy53/nrf5340/cpuapp/ns. Building the sample for nrf5340dk/nrf5340/cpuapp/ns works, and it runs fine. The issue is with the Thingy53 NS.

I have just taken another copy of peripheral_lbs from the NCS 3.2.1 samples and attempted to build for thingy53/nrf5340/cpuapp/ns.

Again, I get the FLASH overflow error, as below.

Can you please try to build peripheral_lbs for thingy53/nrf5340/cpuapp/ns? Thank you.

On Github nrfconnect sdk, for the peripheral_lbs, I noticed that there was a change in the Kconfig.sysbuild last week. PM was disabled for the Thingy53.

config PARTITION_MANAGER
	default n if !BOARD_THINGY53 && !BOARD_IS_NON_SECURE

config NRF_DEFAULT_IPC_RADIO
	default y

config NETCORE_IPC_RADIO_BT_HCI_IPC
	default y

source "share/sysbuild/Kconfig"

I haven't updated NCS 3.2.1 to the latest but will later today.

Also, from the sample.yml history, the Thingy53 non secure target got removed because of BT_CRYPTO support.

Anyway, I've ended up the path of modifying TF_M size for the Thingy53 NS applications because of the additional space required to support BT_CRYPTO.

As mentioned before, if I silence (CONFIG_TFM_LOG_LEVEL_SILENCE=y) the TF-M logs, the Thingy NS applications run fine.

I like to know what's causing TFM Log bus faults and if here is a way to have TFM logs enabled for Thing NS builds.. Thank you.

Best Regards,
Ravi

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

Vidar Berg — Tue, 10 Feb 2026 10:57:42 GMT

Hi Ravi,

Have you made any other changes modifications to the peripheral_lbs sample? I do not get any build errors if I build the original version from from SDK v3.2.1 for nrf5340dk/nrf5340/cpuapp/ns. It also seems to run without issues.

Best regards,

Vidar

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

zpm1066 — Mon, 09 Feb 2026 18:46:33 GMT

Hi Vidar,

For both the Thingy53 and nRF5340-DK, when building BLE applications, I've extended the TF-M size to get successful non-secure builds. A “pm_static_thingy53_nrf5340_cpuapp_ns.yml” in the local project folder with TF_M size extended to 96kB was used.

These applications (peripheral_lbs sample and a few migrated BLE applications) run fine provided if I silence (CONFIG_TFM_LOG_LEVEL_SILENCE=y) the TF-M logs. Otherwise, I get “<err> flash_nrf: invalid address: 0x100feff8:8”.

Clearly this address is outside the 1MB address range for Thingy53 internal FLASH. I'm not sure what TF-M logging generates the error. Any suggestions on how to debug the TF-M logs? Thanks.

I need to debug further and also us the addr2line utility to isolate the cause of the issue.

Have you seen this type of error before?

Best Regards,
Ravi

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

Vidar Berg — Fri, 06 Feb 2026 08:20:37 GMT

Hi Ravi,

The thingy53 board includes a static memory partition file to ensure consistent memory layout for all samples built for this board and keep compatibility with the version of the bootloader that comes pre-programmed on the board. But when you have an external debugger you can safely change the memory layout without worrying about bricking the device.

[quote user="zpm1066"]How do I configure CONFIG_PM_PARTITION_SIZE_TFM correctly? Thank you.[/quote]

The static partitioning file takes precedence. If you want to allow dynamic allocation, you need to remove this partitioning file from the board directory: https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.2.1/boards/nordic/thingy53/pm_static_thingy53_nrf5340_cpuapp_ns.yml

Best regards,

Vidar

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

zpm1066 — Thu, 05 Feb 2026 21:31:22 GMT

Hi Vidar,

I tried the following.

Added CONFIG_RESET_ON_FATAL_ERROR=n to prj.conf
Built a debug version of thingy53/nrf5340/cpuapp/ns target
Got build errors with TFM FLASH overflow

/nordic/ncs/v3.2.1/nrfxlib/crypto/nrf_oberon/lib/cortex-m33/soft-float/liboberon_3.0.17.a && :
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1c300 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH'
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1fc40 of bin/tfm_s.axf section `.gnu.sgstubs' is not within region `FLASH'
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.TFM_DATA' will not fit in region `FLASH'
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1c300 of bin/tfm_s.axf section `.TFM_UNPRIV_CODE' is not within region `FLASH'
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: address 0x1fc40 of bin/tfm_s.axf section `.gnu.sgstubs' is not within region `FLASH'
/opt/nordic/ncs/toolchains/322ac893fe/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 15856 bytes
Memory region         Used Size  Region Size  %age Used
           FLASH:       64496 B      48640 B    132.60%
             RAM:       14560 B        32 KB     44.43%
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

CONFIG_PM_PARTITION_SIZE_TFM suggests TFM FLASH size can be increased.

Resolved TFM overflow by disabling TFM logging and increased TFM partition size to 256kB (0x40000)

CONFIG_TFM_PROFILE_TYPE_MINIMAL=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y
CONFIG_PM_PARTITION_SIZE_TFM=0x40000

Build was successful.
Disabling TFM logging was enough to prevent TFM FLASH overflow in this "cfb" sample
However, the TFM partition size remained the same.
Why hasn’t the FLASH region size changed to 320KB (0x40000) as per link above? Thanks.

RTT output:

SEGGER J-Link V8.96 - Real time terminal output
SEGGER J-Link (unknown) V1.0, SN=<xxxxxxxxxxxx>
Process: JLinkExe

rtt:~$ Initialized ssd1306@3c
font width 10, font height 16
font width 15, font height 24
font width 20, font height 32
x_res 128, y_res 64, ppt 8, rows 8, cols 128
[00:00:00.001,617] <inf> udc_nrf: Preinit
*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.012,725] <inf> udc_nrf: Initialized
Zephyr v4.2.99
Board target: thingy53/nrf5340/cpuapp/ns
[00:00:00.013,153] <dbg> cfb: cfb_framebuffer_init: number of fonts 3
[00:00:00.016,937] <inf> udc_nrf: SUSPEND state detected
[00:00:00.115,203] <inf> udc_nrf: Reset
[00:00:00.115,264] <inf> udc: ep 0x80 is not halted|disabled
[00:00:00.115,295] <inf> udc_nrf: RESUMING from suspend

The sample "cfb" for NS build runs successfully. However, for a typical NS application with BT, the TFM size would be greater than the default ~47.5KB.

How do I configure CONFIG_PM_PARTITION_SIZE_TFM correctly? Thank you.

Best Regards,
Ravi

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

zpm1066 — Thu, 05 Feb 2026 03:57:10 GMT

Hi Vidar,

I'll try your suggestion of disabling CONFIG_RESET_ON_FATAL_ERROR for the Thingy53 debugging. I'll sync up with you on the findings.

For thingy53/nrf5340/ns targets where the TF-M overflows FLASH significantly, can we not use the external FLASH?

Best Regards,
Ravi

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

Vidar Berg — Wed, 04 Feb 2026 08:24:41 GMT

Hi Ravi,

[quote user="zpm1066"]I've tried to debug with Segger's Edu Mini probe and also the nrf54l15dk debug with Thingy53, with debug info to RTT. In both cases, I never get to a point where there is any output to RTT. Weird! [/quote]

This suggests that there may be an error occurring during startup before the logger is available. To troubleshoot this further I would disable the CONFIG_RESET_ON_FATAL_ERROR symbol in the project configuration and attach the debugger to see if the program entered the error handler.

[quote user="zpm1066"] It seems Nordic is deprecating thingy53/nrf5340/cpuapp/ns[/quote]

The Zephyr Bluetooth Host switched to using PSA Crypto instead having crypto support from tinycrypt built into the stack. For /ns targets this requires building TF-M with these crypto services enabled, which significantly increases its memory footprint compared to the minimal TF-M builds used previously. The Thingy53 board uses static memory partitions that do not allocate sufficient memory to the secure region. For this reason, we have removed this board target from the BLE samples.

Best regards,

Vidar