Running the LSM6DLS (IMU) zephyr example with nrf52840 based Xiao BLE Sense

Hi all,

I've been trying to get the samples/sensor/lsm6dsl example working with the nrf52840-based Xiao BLE Sense and have had no luck.

I guess that it's due to the power line for the sensor being connected to the P1.08

I dug into the xiao_ble_sense.dts and I can indeed see:

Fullscreen
1
2
3
4
5
6
7
lsm6ds3tr-c-en {
compatible = "regulator-fixed-sync", "regulator-fixed";
enable-gpios = <&gpio1 8 (NRF_GPIO_DRIVE_S0H1 | GPIO_ACTIVE_HIGH)>;
regulator-name = "LSM6DS3TR_C_EN";
regulator-boot-on;
startup-delay-us = <3000>;
};
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

However no matter how I try and drive it from the code the sensor refuses to initialize with the console output:

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

My code to run is based of the sample code for the sensor with the lsm6ds3tr_c_en modifications:

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


And my prj.conf:
Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I am trying to drive this the proper way but am I missing something obvious?

Should I just ignore the config and drive P1.08 manually?

Thanks for taking a look!
I'm using nRF Connect SDK v2.6.0 (latest available at the time of posting)

Parents
  • I have exacly the same problem. ncs v2.6.1, nrf52840_xxAA_rev2, example lsm6dsl. The device_is_ready statement fails, state 5. I tried to enable pullup in pnctrl for i2c, adjusted delay. Would be really nice to get this running, especially because it does with Arduino.

Reply
  • I have exacly the same problem. ncs v2.6.1, nrf52840_xxAA_rev2, example lsm6dsl. The device_is_ready statement fails, state 5. I tried to enable pullup in pnctrl for i2c, adjusted delay. Would be really nice to get this running, especially because it does with Arduino.

Children
  • "I suppose it could be a non initialized variable somewhere, or a strange timing issue". On another post we spent a lot of time discovering an errata item on the nRF52832 not shown as an errata on other devices causes the i2c transaction to fail in the manner described here. See nrf52832-i2c-clock-pulse-issue

  • If the silicon causes the issue then why it does work with Arduino

  •  .. ah, did you mean the Arduino code works on the nRF52? If so they must have a different startup sequence which avoids the clock stretch issue

    Edit: You can easily prove this one way or another; use a 'scope to capture the very first TWIM transaction and look at the first clock pulse - is it short? Compare with the same first clock pulse with Arduino - is the latter not short?

  • Yes except the chips are unreachable underneath their metal casing, and no test points are exposed (tough could use other exposed pins instead).

  • Has anyone else tried to move back to nRF Connect SDK V2.5.0? You all seem to be using 2.6.1?

    As mentioned above, it seems to work for me using SDK 2.5.0. I did finally install SDK V2.6.1 and do indeed see the reported  "not ready" message when building with 2.6.1.

    2.5.0 works,  2.6.1 does not.

    I do see a difference in one of the board files, xiao_ble_defconfig.  "CONFIG_PINCTRL=y" was removed in the 2.6.1 version.

    At this point my build environment workspace is giving me trouble ( lost ability to switch SDK versions within VSCode nRFConnect extension) so I cannot see if adding it back into the 2.6.1 version will solve the issue. I'm sure there are other changes between the two versions as well, I only compared the sample and the board files.

    Again, I would give SDK V2.5.0 a shot, see what happens.