Hello Devzone Community,
I am writing to ask whether there is any special or obscure setting (device tree or Kconfig) to enable run-time changes to accelerometer output data rate of nRF9160 based dev boards, with one or both of IIS2DH and LIS2DH sensors attached?
Have spent a few days now working with sparkfun_thing_plus_nrf9160 development board. I have a small Zephyr app which depends upon Nordic Semi sdk-nrf v1.6.1. The app is so far a sandbox space in which I am learning how to talk to sensors, and how to use Zephyr in-tree and out-of-tree drivers. I have one out-of-tree driver working. In study of sdk-nrf sample app for LIS2DH I see that this sensor's driver code is also out-of-Zephyr-tree, written by STMIcoro team. (IIS2DH and LIS2DH API codes are located in sdk-nrf/modules/hal/...)
For accelerometers I am using the on-board LIS2DH, and optionally an attached IIS2DH on the [MKI68V1 carrier board](www.st.com/.../steval-mki168v1.html). I have the MKI68 wired for I2C protocol and a peripheral address of 0x19. This is to avoid collision with the LIS2DH peripheral I2C address of 0x18 on the Sparkfun board itself.
Borrowing a few lines of sensor fetching and getting code from [sdk-nrf](github.com/.../src) I'm able to obtain acceleration readings from LIS2DH sensor, but not the IIS2DH sensor. Readings from the second sensor all return as zero, but there is no bus error given over UART0 to which printk() messages appear.
With both sensors, attempts to set Output Data Rate (ODR) at run time result in error -143, "minus ENOTSUP", an "error not supported" message. I am attempting to set ODR values in the range of the 1..9. These are Kconfig enumerated values for each of these very similar accelerometer sensors. In my app's prj.conf file I enable the following kernel configurations related to this run time settings activity:
```
# run time diagnostics
CONFIG_CBPRINTF_FP_SUPPORT=y
# Sensors
CONFIG_I2C=y
CONFIG_SENSOR=y
CONFIG_KX132_1211=y
# 2021-10-16 SAT . . . note this alone does not inform `cmake` where
# to find STMicro's driver sources in sdk-nrf modules/hal/...:
CONFIG_IIS2DH=y
CONFIG_IIS2DH_RANGE=0
CONFIG_IIS2DH_ODR=0
# 2021-10-17 SUN
CONFIG_LIS2DH=y
CONFIG_LIS2DH_ODR_RUNTIME=y
```
As a double check I run `west build -t menuconfig` from my application's top level folder. Menuconfig shows these options selected.
I've traced out the call stack from the LIS2DH driver API routine:
```
rc = sensor_attr_set(sensor,
SENSOR_CHAN_ACCEL_XYZ, //trig.chan,
5, // SENSOR_ATTR_SAMPLING_FREQUENCY,
&odr
);
```
all the way to Zephyr's in-tree I2C API, the routines `i2c_write_read()` and `i2c_write()`. There are seven or eight routine calls to reach, in this case, the final I2C communications routines. These lowest level routines don't know or care about 'ENOTSUP'. It is a test somewhere in the middle of this call stack to set ODR, where if a non-zero value gets returned by in-tree I2C API, then a higher level routine decides that that value is not supported. And yet I am sending an output data rate value that's presented in Kconfig files of both IIS2DH and LIS2DH.
If helpful I can share the project github URL for this work. The branch name in which these accelerometer tests are underway is `driver-iis2dh-integrating-stmicro-hal-api`.
Electrically the I2C bus is wired sufficiently to carry qualitatively correct, changing acceleration values from the on-board LIS2DH to the nRF9160 M33 MCU. A Kionix KX132-1211 returns accelerations simultaneously through another thread of test code (it is attached by hand like the MKI68V1). The MKI68V1 reports only zero values for its readings, and neither IIS2DH there nor LIS2DH are accepting new output data rates at run time.
How further may I trouble-shoot this problem, in configuration, code, and on the hardware side?
- Ted
