ICM42670P IMU - “Device not ready” on nRF5340 DK

Platform:

  • Board: nRF5340 DK (Application core)

  • SDK & Toolchain version: 3.0.2 

  • Toolchain: west + Zephyr SDK

  • Sensor: ICM42670P (connected via SPI4)

Problem Description:

I am integrating the ICM42670P IMU sensor with my nRF5340 DK using Zephyr RTOS over the SPI4 peripheral. I’ve created a board overlay where the sensor is defined under &spi4, I’ve also configured the CS and SPI pins as follows:



The corresponding SPI pinctrl block is:


I’m using DEVICE_DT_GET(DT_NODELABEL(icm42670p)) In the application, and at runtime, I get the following log:


Enabled required Kconfig flags in prj.conf:



Question:
What could be the root cause of this “device not ready” issue for the ICM42670P on SPI4? Are there any extra steps required for nRF5340 or SPI4 in Zephyr?

Any suggestions for debugging or confirming SPI4 peripheral activation would be greatly appreciated.



Parents
  • I'm getting the same issue with my NRF52840DK and ICM42670P. I've tried several different pin combinations that should all be valid and I can't get it to properly initialize. I have noticed that if I unplug MISO from the DK, I get data on the line, but if I plug it back into the DK, I get invalid blips at best. The first picture is with MISO plugged in, the second is with it unplugged. It should return 0x00 or 0x80 but I can never get 0x80 on its own. I'm pretty stumped. It looks like there are problems with the Zephyr/NRF implementation as well as the IMU itself, seeing that I'm getting values that use reserved bits as well as other behavior not shown in the datasheet. I've been trying to trace through the commands sent on the Arduino example where the chip properly initializes with everything connected, but I'm still seeing data sent that goes against the datasheet.

    With MISO plugged in to the NRF52840DK (its the same with P0.03, P1.00, P1.09, P0.02, etc etc)
     

    With MISO unplugged from the NRF52840DK

  •   the problem persists. I've tried different pins and also a custom driver.

  • I’m encountering the same issue: the data doesn’t match the datasheet. The WHO_AM_I register returns 0x4C instead of the expected 0x67

  • I'm still dealing with this and while I've been able to talk to the chip reliably now, I'm also getting 0x4C on the WHO_AM_I. The only way I can get it to return 0x67 is by copying the output that the arduino sample code sends but I feel like it isn't the best way to do things (it repeats a lot of things). 

Reply Children
Related