NCS APDS9960 Sample Failure

[Bryan]

OS: Windows 10

NCS: 2.4.2

We are evaluating adding the APDS9960 to our existing nRF52833 based application, but can not get the APDS9960 functioning.

We are interfacing an nRF52833 DK to the Adafruit APDS9960 board (https://www.adafruit.com/product/3595)

Vin is connected to the DK's VDD supply.



I made minimal changes to the original project.  Added debug statements and removed sample.yaml.

The nRF52 detects the APDS9960 correctly by reading the device ID from the SPDS9960, calls sensor_sample_fetch() without error, but then never returns from the next sensor_sample_fetch().


*** Booting Zephyr OS build v3.3.99-ncs1-1 ***
APDS9960 sample application
here i am
start sleep
end sleep
sensor_sample fetch PASSED
start SENSOR_CHAN_LIGHT
start SENSOR_CHAN_PROX
ambient light intensity 0, proximity 0
here i am
start sleep
end sleep

Besides it never returning on the second pass, it also is returning zeros for values.

Does anyone have any insight into what is going on?


apds9960.zip

[Vidar Berg]

A colleague of mine was able to run the apds9960 sample on his Reel board without any issues:

This was done using SDK v2.5.0 with no modifications to the sample application. This does not really help explain the problem you are facing, but it does indicate that the driver is not broken.

Bryan said:

2. First, there is an odd behavior.  The k_sleep(K_MSEC(5000)) isn't five seconds.  It is more than 1 minute.

Have you tried pausing execution during debugging to see where the program hangs when the delay exceeds a minute? I don't see anything in this sample that should block the main thread.

[Bryan]

Again switched off this for other tasks.   

After you stated that the project ran on the reel board, I built for that build configuration.  As expected, it built without errors.   I wondered where the "avago_apds9960"  device tree definition referenced in main() was located.

dev = DEVICE_DT_GET_ONE(avago_apds9960);

When I searched for it in the NCS v2.5.0 directory, it returned...

C:\Users\Bryan\ncs>findstr /s avago_apds9960 .\v2.5.0\*
.\v2.5.0\zephyr\drivers\sensor\apds9960\apds9960.c:#define DT_DRV_COMPAT avago_apds9960
.\v2.5.0\zephyr\samples\boards\reel_board\mesh_badge\src\periphs.c: DEVICE_DT_GET_ONE(avago_apds9960),
.\v2.5.0\zephyr\samples\sensor\apds9960\src\main.c: dev = DEVICE_DT_GET_ONE(avago_apds9960);

None of these have any device tree definition for "avago_apds9960".

What I suspect is causing my application on the nRF52833 DK to behave like this is because I created my own "avago_apds9960" definition in the nrf52833dk_nrf52833.overlay file.  It builds without error, but something 

    apds9960@39 {

        compatible = "avago,apds9960";

        reg = <0x39>;

        interrupt-parent = <&gpio0>;

//      interrupts = <16 1>;

        int-gpios = < &gpio0 0 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;

    };

My two questions are:

Where is the device tree definition in the reel board project?
What do I need to do in my nRF52833 DK based project to point to the avago_apds9960 device tree def?
 

[Vidar Berg]

Bryan said:

I wondered where the "avago_apds9960"  device tree definition referenced in main() was located.

Special characters in the value assigned to the comptatible property, such as commas, are replaced with underscores to enable the symbol to be used in C. Therefore, if you want to find DT board files with this compatible property, you need to search for files containing 'avago,apds9960' instead of 'avago_apds9960'.

Here is where it is defined for the reel board: https://github.com/nrfconnect/sdk-zephyr/blob/883c3709f9c8fd845a8dfa39d2583d5c665a915b/boards/arm/reel_board/dts/reel_board.dtsi#L151 

[Bryan]

Thanks for the help, but I am giving up and simply writing my own driver.

[Vidar Berg]

Thanks for the update. It is strange that the SDK driver did not work with your setup but worked fine with the reel board. I wish I knew why, but I understand you may not want to continue spending time on this. 

Note that if you plan to implement the driver without using the Zephyr API (i.e. nrfx TWIM driver or with direct register access), you must connect TWIM IRQ vector to your TWIM IRQ handler with the IRQ_CONNECT() macro like in this example: https://github.com/nrfconnect/sdk-zephyr/blob/c2784307ce7f6016105eddf47f786b913ec1cfb3/samples/boards/nrf/nrfx/src/main.c#L40C2-L40C13