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
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.

  • 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.

  • Thank  for the hint!

    I just tried the following code on these ncs versions:

    SDK Toolchain LSM6DSL Works?
    2.5.0 2.5.0 YES
    2.5.3 2.5.3 YES
    2.5.3 2.6.1 YES
    2.6.0 2.6.0 NO
    2.6.1 2.6.1 NO

     main.c:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Note: the k_msleep(100) is not required, its just to show the status on builtin-led.

    prj.conf:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I also tried adding CONFIG_PINCTRL=y to ncs/v2.6.1/zephyr/boards/arm/xiao_ble/xiao_ble_defconfig in SDK 2.6.1 but still does not work, and has the same issue.

    This clearly means something has changed and unset in 2.6.x which is not directly related to xiao_ble as per quick diff.

    Time to investigate the ncs SDK now!

        This should be somewhat helpful.

Reply
  • Thank  for the hint!

    I just tried the following code on these ncs versions:

    SDK Toolchain LSM6DSL Works?
    2.5.0 2.5.0 YES
    2.5.3 2.5.3 YES
    2.5.3 2.6.1 YES
    2.6.0 2.6.0 NO
    2.6.1 2.6.1 NO

     main.c:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Note: the k_msleep(100) is not required, its just to show the status on builtin-led.

    prj.conf:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I also tried adding CONFIG_PINCTRL=y to ncs/v2.6.1/zephyr/boards/arm/xiao_ble/xiao_ble_defconfig in SDK 2.6.1 but still does not work, and has the same issue.

    This clearly means something has changed and unset in 2.6.x which is not directly related to xiao_ble as per quick diff.

    Time to investigate the ncs SDK now!

        This should be somewhat helpful.

Children
  • Great to hear you have progress.

  • Thank you for putting time in it. Bugs like this in the framework are really frustrating and time consuming. Hopefully Nordic will fix this soon. And indeed switching back to a previous framework is a headache too, for instance, when I set the SDK to 2.5.3 and make a new build configuration, the debugger does not do anything.

    (debug with SDK 2.5.3)

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    (debug with SDK 2.6.1)

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Might verify the Toolchain version required for v2.6.1??

    I was having some trouble debugging v2.6.1 with Segger Ozone. I noticed when I switched SDK versions from 2.5.0 to 2.6.1 there were a number of "outdated" messages for various tools reported in the VSCode output view.

    So I updated the nrf toolchain version to 2.6.0. The issue with Ozone seemed to clear up, though it could be for unrelated reasons.

  • So with the debugger behaving properly I may have a work around. 

    It seems if I put a small k_sleep() at the entrance to   lsm6dsl_init() it would start behaving. 

     $InstallDir/v2.6.1/zephyr/drivers/sensor/lsm6dsl/lsm6dsl.c

    <

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    You might give it a shot. I don't know why at this point.

    SDK: 2.6.1
    ToolChain: 2.6.0
    Then again, not always work. Some sort of timing issue I guess.
  • In trying to debug this  (V2.6.1) the only thing I've found is that when setting breakpoints at various points through the sensor init processing, it will then work from then on. Nothing consistent enough to run down. Could be timing with the i2c xfers, new thread interactions seen with 2.6.1, debugger changing timing, etc...

    It's beyond my ability to look at it further.