tfm_ns_fault_handler_callback when adding I2C to the devicetree

[Uri Rotshtein]

Title: nrF9160 NS: Enabling any TWIM (I2C) peripheral causes SecureFault at boot — SFAR=0x20000418 (TF-M secure SRAM), SFSR INVEP+AUVIOL

Environment:

• NCS v3.2.2
• Board: custom nRF9160 NS (TrustZone non-secure image with TF-M)
• CONFIG_TFM_LOG_LEVEL_SILENCE=y (disables TF-M secure UART, frees Serial-Box 1)
• Zephyr I2C driver: i2c_nrfx_twim

Symptoms: Adding &i2c3 { status = "okay"; } (or any TWIMx) to the device tree overlay causes a crash immediately at boot, before reaching main(). The fault is caught by tfm_ns_fault_handler_callback in nrf/modules/trusted-firmware-m/fault.c.

Fault registers:

SFSR = 0x49  (bits: INVEP=1, AUVIOL=1, SFARVALID=1)
SFAR = 0x20000418  (inside TF-M secure SRAM: 0x20000000–0x20015FFF)
CFSR = 0

INVEP means NS code attempted to branch to a secure address that is not a valid NSC veneer. AUVIOL means attribution unit violation. The address 0x20000418 is in TF-M's secure SRAM region — not in NS flash, not in a veneer.

What was verified:

• TWIM3 (Serial-Box 3) is correctly set to NS by TF-M SPU (NRF_SPIM3_S_BASE is in the spu_peripheral_config_non_secure list in target_cfg_53_91.c)
• TWIM1 (Serial-Box 1) is also NS when SECURE_UART1=OFF (which happens when CONFIG_TFM_LOG_LEVEL_SILENCE=y sets CONFIG_TFM_SECURE_UART=n)
• SAU is disabled (SAU_CTRL_ALLNS set) — SPU is the sole gatekeeper
• NS VTOR is correct (0x10000)
• Crash happens with any TWIMx, with or without child devices (no ADS1115 driver loaded)
• Crash happens during Zephyr POST_KERNEL I2C driver SYS_INIT, before main()
• Without &i2cX { status = "okay"; } the application boots and runs correctly

Suspected cause: Something in the i2c_nrfx_twim driver SYS_INIT path (i2c_nrfx_twim_common_init → nrfx_twim_init → nrfx_prs_acquire / IRQ_CONNECT / pre_init) results in a branch to 0x20000418 in secure SRAM. This could be a function pointer in the NS interrupt vector that was not initialized correctly, or a linker issue placing a symbol at a secure address.

Question: Is there a known issue with i2c_nrfx_twim on nRF9160 NS in NCS 3.2.2? Is there a required board-level DTS property (e.g. memory-regions, zephyr,concat-buf-size) needed for TWIM to initialize correctly from NS context?

[Simon D-M]

Hi,

I just tried to use TWI / I2C on a nRF9160 DK with the config CONFIG_TFM_LOG_LEVEL_SILENCE=y and it worked fine.

I based my application on the DevAcademy example and added the config to the prj.conf.

Are you using the default Zephyr I2C API or are you trying to make your own? If you use the Zephyr API, you shouldn't need to use any "nrfx functions". 

If you are not using the default Zephyr API, can you send me some code snippet so that I can try to build it on a nRF9160 DK to reproduce the issue.

Best regards,

Simon D-M

[Uri Rotshtein]

I thing the problem is when working with debug and breakpoints. can you try on you system?

[Simon D-M]

Hi,

I just tried, and I didn't have any problem debugging it. Where are you putting your breakpoints?

If you put your breakpoints in time-sensitive places, it is expected that something bad will happen, as the timings are not respected.

Does it work fine when you don't debug the application ?

Also, if you want to share some confidential code, I can change this ticket to a private one. (ask me to change the visibility before uploading the confidential code)

Best regards,

Simon D-M

[Uri Rotshtein]

Technical Summary: Resolving Boot-Time Exceptions in I2C Subsystem

Overview

The integration of the ADS1x1x ADC initially resulted in a critical system exception during the boot sequence, causing a complete kernel hang. To resolve this, I implemented a bottom-up validation strategy, moving from raw signal control back to the Zephyr RTOS sensor framework.

Phase 1: Isolation via Bit-Bang Implementation

To decouple the hardware from the Zephyr driver stack, I temporarily disabled the Nordic TWIM peripheral and the ADS1x1x driver. I implemented a manual Bit-Bang I2C protocol to verify the physical layer. This confirmed:

• Hardware Viability: The ADC was powered correctly and responding to its I2C address.

• Bus Health: Confirmed no electrical shorts or pull-up voltage mismatches were present on the SDA/SCL lines.

Phase 2: Incremental Restoration

After verifying the hardware, I reintroduced the TWIM peripheral and finally the ADS1x1x driver via the Device Tree. This phased approach allowed the system to initialize the sensor subsystem successfully without triggering the previous boot-time exception.

Current Status and Root Cause Analysis

The system is now fully operational, supporting standard sensor sampling and full debug logging.

Technical Note on Exception: While the system is now stable, the exact root cause of the initial boot-time exception remains unidentified. It is suspected that a race condition or an invalid peripheral state existed during the driver's init function—likely involving the TWIM configuration or a bus-clearance issue—which was effectively "reset" by the manual validation process.

[Simon D-M]

Hi,

Good to hear that it works now.

If that happens again, I would recommend using the normal Zephyr I2C API. It is quite proven and reliable.

Best regards,

Simon D-M