Wrong battery voltage measurements after migrating from SDK v3.1.1 to v3.2.1

[timofey]

I'm using custom board based on nrf9160 SoC. After migrating from SDK v3.1.1 to v3.2.1 two issues (but they are likely related) began to happen:

1. Battery measurements started to produce values 1.5-2 times lower than actual voltage value. The board is supplied with 12V. See nrf9160_custom.log attached below.
2. After calling adc_read during battery measurement, all consecutive transfers on spi1 fail with the following error: spi_nrfx_spim: Timeout waiting for transfer complete. This issue only happens with spi1 (spi2 and spi3 work fine).

I've created minimal reproducible example project and when I tested it on nrf9160dk, situation is the opposite: the exact same issue with adc measurements and spi1 happens on previous SDK versions (I've tested on v3.1.1 and v2.9.2), but everything is fine on v3.2.1, see nrf9160dk.log

I haven't found anything related to this problem in latest migration guides and release notes for the SDK itself and nrfx, so I would like to get some help understanding is it a bug on our side (and if so, what needs to be changed to restore the correct behavior from previous SDKs or where can I find the appropriate documentation) or is it a subtle regression in the SDK?
adc-spi-minimal-proj.zip

Fullscreen nrf9160_custom.log Download

*** Booting nRF Connect SDK v2.9.2-4ab7b98fc76f ***
*** Using Zephyr OS v3.7.99-aa34a5632971 ***
[00:00:00.406,829] <inf> main: board: nrf9160_custom
[00:00:00.406,951] <inf> main: spi_transceive_dt: ok
[00:00:00.407,043] <inf> main: spi_transceive_dt: ok
[00:00:00.455,261] <inf> main: battery: 11419mV
[00:00:00.455,383] <inf> main: spi_transceive_dt: ok

*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
[00:00:00.385,894] <inf> main: board: nrf9160_custom
[00:00:00.386,016] <inf> main: spi_transceive_dt: ok
[00:00:00.386,138] <inf> main: spi_transceive_dt: ok
[00:00:00.435,272] <inf> main: battery: 11401mV
[00:00:00.435,424] <inf> main: spi_transceive_dt: ok

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.378,784] <inf> main: board: nrf9160_custom
[00:00:00.378,936] <inf> main: spi_transceive_dt: ok
[00:00:00.379,058] <inf> main: spi_transceive_dt: ok
[00:00:00.428,161] <inf> main: battery: 7359mV
[00:00:00.628,295] <err> spi_nrfx_spim: Timeout waiting for transfer complete
[00:00:00.628,753] <err> main: spi_transceive_dt: -116

Fullscreen nrf9160dk.log Download

*** Booting nRF Connect SDK v2.9.2-4ab7b98fc76f ***
*** Using Zephyr OS v3.7.99-aa34a5632971 ***
[00:00:00.524,658] <inf> main: board: nrf9160dk
[00:00:00.524,780] <inf> main: spi_transceive_dt: ok
[00:00:00.524,902] <inf> main: spi_transceive_dt: ok
[00:00:00.573,883] <inf> main: battery: 8628mV
[00:00:00.774,017] <err> spi_nrfx_spim: Timeout waiting for transfer complete
[00:00:00.774,505] <err> main: spi_transceive_dt: -116

*** Booting nRF Connect SDK v3.1.1-e2a97fe2578a ***
*** Using Zephyr OS v4.1.99-ff8f0c579eeb ***
[00:00:00.520,477] <inf> main: board: nrf9160dk
[00:00:00.520,629] <inf> main: spi_transceive_dt: ok
[00:00:00.520,721] <inf> main: spi_transceive_dt: ok
[00:00:00.570,800] <inf> main: battery: 8612mV
[00:00:00.770,965] <err> spi_nrfx_spim: Timeout waiting for transfer complete
[00:00:00.771,423] <err> main: spi_transceive_dt: -116

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.505,767] <inf> main: board: nrf9160dk
[00:00:00.505,889] <inf> main: spi_transceive_dt: ok
[00:00:00.506,011] <inf> main: spi_transceive_dt: ok
[00:00:00.556,060] <inf> main: battery: 6mV
[00:00:00.556,182] <inf> main: spi_transceive_dt: ok

[Kenneth]

Hello,

Based on the description and your testing I think this a configuration of hardware issue. I suspect the adc and spi configuration on your board need adjustment to account for changes in newer SDK. I suggest to look in specific at (1) reference/gain configuration difference and (2) possible pin conflicts usage between adc/spi.

1. Check devicetree for reference and gain settings between the builds (check both are defined, e.g. that reference is not by default internal in one build and VDD1/4 in another), also check that the adc channel is configured in code using this configuration. Also check if both positive and negative input is correct and defined in devicetree and used in code. Maybe you can compare the zephyr.dts file in the output build folder between versions to check they are the same, maybe also compare the .config file between two builds for possible changes to spi configuration.

2. About the spi timeout: Double check that you are not by accident configured an analog input pin (positive or negative) that may overlap with your spi pins. All spi instances should be using the same underlying spim driver, so I can't see any reason why one instance should fail, unless the pins in question by accident are also configured by other peripheral.

Also, to test you can try to test adc and spi by themself, before you test them in sequence. You can also just double check that CONFIG_SPI_COMPLETION_TIMEOUT_TOLERANCE is a large value (e.g. though I would expect default of 200ms should be sufficient though). Also possible measure the spi interface pins, to check if the pins are "toggling" as expected in all cases (e.g. that nothing is keeping the CLK or MOSI pins low, and if there are any apparent difference between two build try to explain what it is (e.g. which pin in specific)), also you can try to set CONFIG_SPI_NRFX_RAM_BUFFER_SIZE to 255.

Hope that helps,
Kenneth

[timofey]

Hello, Kenneth, thanks for your suggestions. Both issues were resolved after I moved adc_channel configuration from c code to devicetree.