SAADC on nRF52840 rev2 chips does sample internal VDD channel

[GeorgiD]

Working with Fanstel BT840 module we have discovered that ADC channel VDD reads as zero or produces small mV level result.
nRF52840 chip revision on these modules is QIAA-Dx0.

Please note that same ADC code perfectly samples VDD on Laird BL654 modules built on QIAA-Cx0 chip revision.

ADC configuration is ADC channel 0 setup for Single ended, Internal Reference, 1/6 Gain :

NRF_SAADC->CH[0].PSELP = 0x09;
NRF_SAADC->CH[0].PSELN = 0;
NRF_SAADC->CH[0].CONFIG = 0x00050000;

Best Regards,
Georgi Danielyan

[Jørgen Holmefjord]

Hi,

Do you power the chip through VDD, and what voltage is the chip powered with?

Have you tested on other rev. 2 chips than this module?

Best regards,
Jørgen

[Jørgen Holmefjord]

CONFIG set to 0x00050000 should give a GAIN of 1, not 1/6, see the PS.

I tested this using the SAADC example in SDK 15.3.0, with only the channel changed to NRF_SAADC_INPUT_VDD. I get expected result when running this on the nRF52840 DK rev 1.1.0. I also tested with GAIN set to 1 (channel_config.gain = NRF_SAADC_GAIN1;). This gives maximum result (1023), which is expected due to the VDD being outside the input range of the SAADC.

Can you test out the example from the SDK on you module?

[GeorgiD]

Yes, SDK example works on both chip revisions we have.

Let me clarify about chip revisions I was referring:

INFO.VARIANT FICR register read as 0x41414441 for part where we have issue with VDD channel sampling.

INFO.VARIANT FICR register read as 0x41414330 for part where we have no issue with VDD channel sampling.

[Jørgen Holmefjord]

Did the SDK example work with input changed to VDD on both boards? Can you provide the full application that fails on your board?

0x41414441 (AADA) is an Engineering D chip according to the compatibility matrix. The one I tested on is 0x41414430 (AAD0), which is a Rev 2 chip.

I do not have any AADA chip available to test with, but I would expect these chips to be the same.

[GeorgiD]

Sorry, I did not mention it:

Yes, SDK example works with input channel changed to VDD on both boards.
Application is huge running proprietary 802.15.4 PHY compliant mesh.

However, SADC configuration is very same as in SDK example with input changed to VDD.
Application samples VDD at ~2 seconds rate.
Also, I have tested this example with the system entering different power modes. No issues had been observed.

Now it is clear that standalone SADC application (SDK example changed to VDD) works on both AADA and AAD0 chip revisions.

The problem seems to be complex then and may somehow relate to the other peripherals activity.
That can be great help for us if we may give us recommendations where to look for the possible cause.

BTW: these two chip revisions are not same: AADA has several earlier issues resolved. But, also has some new issues introduced.

[Jørgen Holmefjord]

Thank you for confirming that. I would recommend that you check how you set the buffers, are they global, static, etc? How do you sample the SAADC? Are you using interrupts or are you blocking while waiting for the sample? You sample a single channel and a single sample each interval?

[GeorgiD]

It is single conversion where DMA is set up for single transfer to global buffer.
Conversion is started triggering NRF_SAADC->TASKS_START = 1; and interrupt is enabled for conversion end event: NRF_SAADC->INTENSET = (1 << 1);
Note that, external AIN input channels conversions are working without any issues (ADC configuration is same but input channel. DMA buffer is same too).

Blocking mode conversion on VDD channel does not produce correct result too.

Also, I would like to remind that we have no issues with AAD0 revision chips running very same code.

Anyway, I am keeping digging and will post results here if any solution is found 

[GeorgiD]

Forgot to mention:
DMA buffer is at address 0x20000000, which is very beginning of RAM
Conversion starting code below:

NRF_SAADC->TASKS_START = 1;
while (NRF_SAADC->EVENTS_STARTED == 0);
NRF_SAADC->TASKS_SAMPLE = 1;

[Jørgen Holmefjord]

Unfortunately, I do not have any AADA chips to test on. Since the SDK example works, it sounds like this must be related to the application. 

If you are able to reproduce this issue on rev 2 production chip, with SDK example, I can report it internally and do some further investigation.