DTS for sensor example using NRF_PSEL fails to build

Hi,

I'm trying to get up and running using the PMW3360 sensor driver (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/pmw3360.html) using the NRF52840 DK.

I'm using the sample DTS provided on that page:

&pinctrl {
    spi1_default_alt: spi1_default_alt {
        group1 {
            psels = <NRF_PSEL(SPI_SCK, 0, 16)>,
                    <NRF_PSEL(SPI_MISO, 0, 15)>,
                    <NRF_PSEL(SPI_MOSI, 0, 17)>;
        };
    };

    spi1_sleep_alt: spi1_sleep_alt {
        group1 {
            psels = <NRF_PSEL(SPI_SCK, 0, 16)>,
                    <NRF_PSEL(SPI_MISO, 0, 15)>,
                    <NRF_PSEL(SPI_MOSI, 0, 17)>;
            low-power-enable;
      };
    };
};

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = <&spi1_default_alt>;
    pinctrl-1 = <&spi1_sleep_alt>;
    pinctrl-names = "default", "sleep";
    cs-gpios = <&gpio0 13 0>;

    pmw3360@0 {
            compatible = "pixart,pmw3360";
            reg = <0>;
            irq-gpios = <&gpio0 21 0>;
            spi-max-frequency = <2000000>;
            label = "PMW3360";
    };
};

To my eye (I've spent quite a few hours over the course of a few days reviewing/learning about DTS) I don't see anything obviously wrong. However, building the project fails:

-- Application: /Users/max/Documents/my_project/mouse/ptx
-- Cache files will be written to: /Users/max/Library/Caches/zephyr
-- Zephyr version: 3.0.99 (/Users/max/Documents/nrfconnect/zephyr)
-- Found west (found suitable version "0.12.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Found dtc: /opt/nordic/ncs/v1.9.1/toolchain/bin/dtc (found suitable version "1.6.1", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/opt/nordic/ncs/v1.9.1/toolchain)
-- Found BOARD.dts: /Users/max/Documents/nrfconnect/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Found devicetree overlay: /Users/max/Documents/my_project/mouse/ptx/boards/nrf52840dk_nrf52840.overlay
devicetree error: /Users/max/Documents/my_project/mouse/ptx/boards/nrf52840dk_nrf52840.overlay:4 (column 66): parse error: expected number or parenthesized expression
CMake Error at /Users/max/Documents/nrfconnect/zephyr/cmake/modules/dts.cmake:213 (message):
  gen_defines.py failed with return code: 1
Call Stack (most recent call first):
  /Users/max/Documents/nrfconnect/zephyr/cmake/modules/zephyr_default.cmake:121 (include)
  /Users/max/Documents/nrfconnect/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:51 (include)
  /Users/max/Documents/nrfconnect/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:81 (include_boilerplate)
  /Users/max/Documents/my_project/mouse/ptx/build/CMakeLists.txt:8 (find_package)

Note that 1) the overlay is discovered and 2) there is no column 66 on line 4 in my overlay. I went to the `zephyr.dts.pre` to see if I could spot the issue, where my overlay was present at the bottom:

# 1 "<command-line>" 2
# 1 "/Users/max/Documents/my_project/mouse/ptx/boards/nrf52840dk_nrf52840.overlay" 1
&pinctrl {
    spi1_default_alt: spi1_default_alt {
        group1 {
            psels = <((((((0) * 32U) + (16)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_SCK & 0xFFFFU) << 16U))>,
                    <((((((0) * 32U) + (15)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_MISO & 0xFFFFU) << 16U))>,
                    <((((((0) * 32U) + (17)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_MOSI & 0xFFFFU) << 16U))>;
        };
    };

    spi1_sleep_alt: spi1_sleep_alt {
        group1 {
            psels = <((((((0) * 32U) + (16)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_SCK & 0xFFFFU) << 16U))>,
                    <((((((0) * 32U) + (15)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_MISO & 0xFFFFU) << 16U))>,
                    <((((((0) * 32U) + (17)) & 0x3FU) << 0U) | ((NRF_FUN_SPI_MOSI & 0xFFFFU) << 16U))>;
            low-power-enable;
      };
    };
};

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = <&spi1_default_alt>;
    pinctrl-1 = <&spi1_sleep_alt>;
    pinctrl-names = "default", "sleep";
    cs-gpios = <&gpio0 13 0>;

    pmw3360@0 {
            compatible = "pixart,pmw3360";
            reg = <0>;
            irq-gpios = <&gpio0 21 0>;
            spi-max-frequency = <2000000>;
            label = "PMW3360";
    };
};

Line 4 col 66 is where `NRF_FUN_SPI_SCK` is referenced, at the first character. I'm assuming that -- based on the parse error -- the macro for `NRF_FUN_SPI_SCK` isn't able to be resolved.

A few questions:

- I can't find any documentation for `NRF_FUN_*` definitions via search and I'm not sure where I should be looking.

- Is there something obviously wrong with my DTS overlay?

- Are there any examples that set up a similar sensor which I should take a look at?

Thanks,

Max



  • maxg said:
    I believe should instead be:

    Thanks for pointing out. I will forward this information. 

    maxg said:
    I switched my MOSI to P0.27 and all started to work correctly with the sensor. I have a feeling that the  GPIO pins I was trying for MOSI are hooked up to other peripherals on the DK and some interaction there was resulting in the voltage difference on just MOSI, but I'm not 100% sure.

    Based on the nRF52840DK HW User Guide it seems that you have tried to use the LEDs for SPI communication. Have you disconnected these (If intentionally used)?

    Also, P0.17 is connected to the external memory on the DK. To use this pin, please see the Solder Bridge Configuration

    This is also visible on the back of the board. 

    Kind regards,

    Øyvind

  • That makes a lot of sense, and explains the behavior I was seeing with MOSI and the LEDs.

    From devboards I've used in the past, my assumption was that "if it's on the headers, it's not bound to anything else and is ready to use", but clearly the NRF52840 DK is more flexible than that (which I think is a really good thing) and I should've perused the documentation for it more carefully.

    Appreciate you taking the time to troubleshoot this with me Øyvind, I'm sure I'm not the only NRF learner to make issues for themselves like this but I was having trouble finding similar issues to point me in the right direction.

  • No problem at all. 

    maxg said:
    'm sure I'm not the only NRF learner to make issues for themselves like this but I was having trouble finding similar issues to point me in the right direction.

    No, you are definitely not the first or the last. It happens to everyone Slight smile There might be more on the issue in nRF5 SDK cases. 

Related