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]

Hello,

I don't have this sensor to test with, unfortunately. However, if you haven't tried it already, please try changing the bitrate from 400K to 100K by switching from 'I2C_BITRATE_FAST' to 'I2C_BITRATE_STANDARD' in your devicetree overlay. Additionaly, please try to enable CONFIG_NRFX_TWI_LOG to see if you get any log messages from the I2C driver.

Best regards,

Vidar

[Bryan]

Thanks for the fast response.   Sorry for my slow response.  We had a company emergency that I was pulled into.  I understand it is hard to debug remotely and without the setup, so I appreciate your patience. 

1. I had already tried the standard speed with the same result.  I forgot to mention it.

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

2. I had to upgrade to NCS 2.5.0 to get the CONFIG_NRFX_TWI_LOG option.  I started getting stack overflow errors, so I increased the main stack size.  Here are my proj.conf settings.

CONFIG_PRINTK=y

CONFIG_GPIO=y

CONFIG_I2C=y

CONFIG_NRFX_TWI_LOG=y

CONFIG_SENSOR=y

CONFIG_LOG=y

#CONFIG_SENSOR_LOG_LEVEL_INF=y

#CONFIG_I2C_LOG_LEVEL_INF=y

CONFIG_I2C_LOG_LEVEL_ERR=y

CONFIG_APDS9960_TRIGGER_GLOBAL_THREAD=n

CONFIG_PM_DEVICE=n

CONFIG_MAIN_STACK_SIZE=16384

3. I am not seeing any errors on the I2C bus.  In the image you can see the first I2C transaction to get the correct  APDS9960 device ID in the first read returning (0xAB).

4.  Here is the output log.  It always locks after three I2C transfers the second time through the loop.  The first time there are six.

[00:00:00.359,008] <inf> NRFX_TWI: Function: nrfx_twi_init, error code: NRFX_SUCCESS.
[00:00:00.366,333] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
--- 124 messages dropped ---
[00:00:00.376,098] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:00.376,159] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.376,373] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:00.376,403] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:00.376,434] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.376,647] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:00.376,678] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:00.376,739] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:00.376,739] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:00.376,800] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.377,014] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:00.377,044] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:00.377,105] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.377,319] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:00.377,349] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:00.377,380] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:00.377,410] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:00.377,441] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.377,685] <inf> NRFX_TWI: Transfer type: XFER_RX.
[00:00:00.377,685] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:00.377,746] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.377,990] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:00.377,990] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:00.378,051] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:00.378,051] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:00.378,112] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:00.378,448] <inf> NRFX_TWI: Instance disabled: 0.
*** Booting nRF Connect SDK v2.5.0 ***
APDS9960 sample application
here i am
start sleep
end sleep
[00:00:05.378,570] <inf> NRFX_TWI: Instance enabled: 0.
--- 13 messages dropped ---
[00:00:05.378,692] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:05.378,692] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:05.378,723] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,723] <inf> NRFX_TWI: Transfer type: XFER_RX.
[00:00:05.378,723] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:05.378,753] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,753] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:05.378,753] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:05.378,784] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:05.378,784] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:05.378,784] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,814] <inf> NRFX_TWI: Transfer type: XFER_RX.
[00:00:05.378,814] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:05.378,814] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,814] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:05.378,845] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:05.378,845] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:05.378,845] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:05.378,845] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,875] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:05.378,875] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:05.378,875] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:05.378,875] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:05.378,906] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:05.378,906] <inf> NRFX_TWI: Instance disabled: 0.
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
[00:00:10.378,967] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:10.378,967] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:10.378,967] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:10.378,967] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:10.378,967] <inf> NRFX_TWI: Transfer type: XFER_RX.
[00:00:10.378,967] <inf> NRFX_TWI: Transfer buffers length: primary: 1, secondary: 0.
[00:00:10.378,967] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:10.379,028] <inf> NRFX_TWI: Instance disabled: 0.
[00:00:10.379,028] <inf> NRFX_TWI: Instance enabled: 0.
[00:00:10.379,028] <inf> NRFX_TWI: Transfer type: XFER_TX.
[00:00:10.379,028] <inf> NRFX_TWI: Transfer buffers length: primary: 2, secondary: 0.
[00:00:10.379,028] <wrn> NRFX_TWI: Function: nrfx_twi_xfer, error code: NRFX_SUCCESS.
[00:00:10.379,028] <inf> NRFX_TWI: Instance disabled: 0.

[Vidar Berg]

Hello,

No problem. However, I don’t have a good explanation for this behavior. It's strange that it reads the device ID correctly but fails to get a valid sensor reading. As a test, could you try using the TWIM driver to see if it makes any difference? You can do this by replacing 'compatible = "nordic,nrf-twi";' with 'compatible = "nordic,nrf-twim";'.

[Bryan]

Unfortunately, that did not help.  I am really surprised this doesn't simply work since it is originally based off the nRF52840-based reel board.

Do you have any idea why the k_sleep is so messed up?  

The k_sleep(K_MSEC(5000)) isn't five seconds.  It is more than 1 minute.  I am wondering if this is a symptom of the underlying problem.

[Bryan]

There is something fundamentally wrong with the NCS (using 2.5.0) Zephyr sensor library for the APDS9960.  

I determined that the cause of the huge one minute sleep was that debugging was enabled in the build configuration and I flashed the device instead of debugging.  I disabled debug optimization and the k_sleep was better, but was still five seconds instead of the expected one second.

I even went so far as to create an entirely new project based off blinky and created a separate thread for the ADPS9960.  The blinky flash rate went down dramatically.

The higher ups really want to use this device in our system.  I am stumped.   Any suggestions?  I really don't want (or have time) to write a custom device driver.

[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 

[dev_2004_se]

Hi Bryan,

I am having the same problem. Have you solved it?

regards