Secure fault on i2c in one thread, but not another

RE: Secure fault on i2c in one thread, but not another

StefanG — Wed, 05 Mar 2025 22:34:48 GMT

Ok!

The problem was that the API call i2c_reg_read_byte() was fed a SENSOR device struct, NOT the actual i2c DEVICE struct, causing the segfault.

Here is the solution:

 // Get the I2C bus controller that the BME280 is connected to
    const struct device *i2c_dev = DEVICE_DT_GET(DT_BUS(DT_NODELABEL(bme280)));
    if (!device_is_ready(i2c_dev)) {
       LOG_ERR("I2C bus not ready");
       return;
    }
    // Now use the I2C controller to read the register
    ret = i2c_reg_read_byte(i2c_dev, BME280_I2C_ADDR, BME280_REG_ID, &bme280_chip_id);

RE: Secure fault on i2c in one thread, but not another

Håkon Alseth — Fri, 28 Feb 2025 15:37:49 GMT

Glad to hear that things started working without it.

Hope you have a wonderful weekend!

Kind regards,

Håkon

RE: Secure fault on i2c in one thread, but not another

StefanG — Thu, 27 Feb 2025 18:12:59 GMT

I will check,

Commenting out these and only keeping Sensor_API works fine.

readbyte is indeed the offending line.

/Stefan

RE: Secure fault on i2c in one thread, but not another

Håkon Alseth — Tue, 25 Feb 2025 09:04:29 GMT

Hi Stefan,

Is this the line that causes the fault?

ret = i2c_reg_read_byte(bme280_dev, BME280_I2C_ADDR, BME280_REG_ID, &bme280_chip_id);

The BME280_REG_ID define, which is a constant define, ie. located in flash. DMA requires that buffers are located in RAM, but the driver itself should provide a returned error if that is the case:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.7.99-ncs2/drivers/i2c/i2c_nrfx_twim.c#L81-L94

Will commenting out the first i2c_read_reg_byte() call will make the subsequent sensor_ API call fault as well?

Kind regards,

Håkon

RE: Secure fault on i2c in one thread, but not another

StefanG — Mon, 24 Feb 2025 14:45:46 GMT

Hej,

Unfortunately, these were already set to the values above. So no difference, it still crashes.

The difference between these threads is that the one crashing also uses the sensor API, any chance of a security mismatch?

/Stefan

RE: Secure fault on i2c in one thread, but not another

Håkon Alseth — Mon, 24 Feb 2025 09:19:17 GMT

Hi,

Could this be due to the TFM logging being enabled?

Can you try to set the following in your prj.conf:

CONFIG_TFM_SECURE_UART=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y

And then re-generate the build folder?

Kind regards,

Håkon

RE: Secure fault on i2c in one thread, but not another

StefanG — Fri, 21 Feb 2025 15:13:30 GMT

Hej Håkan,

The security warning threw me off, I was used to seeing segfaults :)

I doubled the tread stack, same issue.

Traced down the function that segfaults

static inline int z_impl_i2c_transfer(const struct device *dev,
				      struct i2c_msg *msgs, uint8_t num_msgs,
				      uint16_t addr)
{
	const struct i2c_driver_api *api =
		(const struct i2c_driver_api *)dev->api;

	if (!num_msgs) {
		return 0;
	}

	msgs[num_msgs - 1].flags |= I2C_MSG_STOP;

	int res =  api->transfer(dev, msgs, num_msgs, addr);

	i2c_xfer_stats(dev, msgs, num_msgs);

	if (IS_ENABLED(CONFIG_I2C_DUMP_MESSAGES)) {
		i2c_dump_msgs_rw(dev, msgs, num_msgs, addr, true);
	}

	return res;
}

and this line causes the crash and the CPU is stuck on "Fatal Errors" loop.

	int res =  api->transfer(dev, msgs, num_msgs, addr);

The thread is run in user mode, and so is the working thread.

All calling data looks ok, and this line cannot be stepped into, it crashes immediately. To me, this does look like a security issue. The user thread is not able to call this that transfers the data.

Another clue is this:

[00:01:56.467,987] <err> os: ***** SECURE FAULT *****
[00:01:56.467,987] <err> os: Invalid entry point

RE: Secure fault on i2c in one thread, but not another

Håkon Alseth — Fri, 21 Feb 2025 12:24:22 GMT

Hi,

Which thread is this wrt. your code?

Current thread: 0x20008388 (bme280_tid)

Based on the faulting instruction, my first guess would be that you are executing a null pointer, which triggers a secure fault.

If you use addr2line on the LR content, it can help pin-point where the null pointer was called from.

Have you ensured that your thread has enough stack allocated?

Kind regards,

Håkon