SAADC VDDHDIV5 input on nRF52840 rev. 1

Hello,

I got two PCA10056 1.0.0 DKs equipped with an nRF52840 rev. 1 (code AC0). Both do not measure the VCCH voltage correctly (displayed voltage ~2.4V instead of 3.0V). The setup is based on the peripheral->saadc example with the only modification being:

//      NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN0);
        NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_VDDHDIV5);
        channel_config.gain = NRF_SAADC_GAIN1_2;

I chose to increase the input voltage swing on the ADC by configuring the gain stage from 1/6 to 1/2. This should normally give better results.

The displayed result is around 410: 410/1023 * 0.6V * 5 * 2 = 2.4V. I got the same result with the gain stage set to 1/6. The result is consistent across the two boards. Using NRF_SAADC_INPUT_VDD with gain 1/6 yields the correct result. A custom board with a rev. 2 chip works correctly with VDDHDIV5.

Can you confirm this behaviour? I did not see any erratum against explaining this. I can only guess that this behaviour (if confirmed) is a side-effect of erratum 197.

Thanks,

Norbert

Parents
  • Hi Karl,

    Changing the gain to 1/2 will affect your input range - with this configuration you should really only be able to measure values between 0 - 1.2 V. 

    VDDHDIV5 should provide 3.0V/5 = 0.6V at the input of the gain stage (ref. to PS1.5, fig. 148), so according to the PS this is fine.

    Where do you see that the input range is limited to 2* 1.2V? The link you provided says the same thing as the PS, i.e. that AINx have to be between VSS and VDD (up to 3V, here). The input of the SAADC code after the gain stage should not be larger as VREF (0.6V), else the value is clipped.

    That sounds strange to me. Are you getting the same output regardless of gain stage?

    The result is the measured voltage, not the raw integer value from the SAADC.So factoring in the changed gain stage, the result if the same.

    Could you share with me the code you are running when this happens?

    As I said, it is the SDK 17.1.0 saadc example with the modifications in the original post (main.c, line 153). No other modifications.

    Could you try this again with the DCDC disabled, to see if it makes any difference to the values you are measuring?

    To the best of my knowledge, the saadc example does not enable DCDC0. It does not make much sense on the DK as VDDH = VDD = 3.0V by the DK's HW architecture.

    Do you have any possibility of externally measuring or scoping the VDDH of the devices, such as through an oscilloscope?

    Yes. VDDH is rock stable at 2.98V.

    Best regards,

    Norbert

  • Hello again, Norbert

    Thank you for your patience with this.

    Norbert said:

    VDDHDIV5 should provide 3.0V/5 = 0.6V at the input of the gain stage (ref. to PS1.5, fig. 148), so according to the PS this is fine.

    Where do you see that the input range is limited to 2* 1.2V? The link you provided says the same thing as the PS, i.e. that AINx have to be between VSS and VDD (up to 3V, here). The input of the SAADC code after the gain stage should not be larger as VREF (0.6V), else the value is clipped.

    Norbert said:
    To the best of my knowledge, the saadc example does not enable DCDC0. It does not make much sense on the DK as VDDH = VDD = 3.0V by the DK's HW architecture.

    Ah, yes of course, you are completely right. The DCDC is also indeed not enabled by default in the examples.
    The input range will still be limited by the chosen gain and reference, but it does indeed not matter for this case since you are measuring on VDDHDIV5.

    Norbert said:
    Yes. VDDH is rock stable at 2.98V.

    Thank you for confirming this. I assumed that you already knew, but from experience I still had to ask.

    Norbert said:
    The result is the measured voltage, not the raw integer value from the SAADC.So factoring in the changed gain stage, the result if the same.

    Right, I was under the impression that you were talking about the raw integer value, which definitely would have been strange if it had been the case.

    I do not immediately see any good explanation for this behavior.
    I will try to replicate this behavior at my end tomorrow, I will update you as soon as I have got something.

    Best regards,
    Karl

  • Hello again, Norbert

    Norbert said:
    Power supply is USB. SW9 is in middle position (VDD power), the coin cell battery removed. The 3V are generated on-board from the buck regulator.

    Oh, it seems I have misunderstood your configuration earlier.
    I did my measurements with a supply of 3V directly on the VDDH input - with the SW9 switch set to Li-Po, for High Voltage mode. If the SW9 is in the VDD position the nRF52840 will enter Normal voltage mode as opposed to high-voltage mode. In normal voltage mode you should not use the VDDHDIV5 to measure your VDD bus voltage, but instead use the _VDD input directly. In your test, do you see the expected SAADC measurements if you configure the SAADC to measure _VDD instead of _VDDHDIV5 (while keeping SW9 in the VDD position)?

    For all the details about the DK's power supply circuitry you could download the nRF52840 DK's schematics here, to take a closer look.
    Fair warning, the power circuitry of the DK is not the easiest to familiarize with due to the array of power switches utilized for the different configurations.

    Best regards,
    Karl

  • Hello Karl,

    I checked once more the boards and still got the same results. The board's HW looks fine. I also found a third V1.0.0 DK which behaves exactly like my other two boards. Then, I used bare-metal programming to configure and read the SAADC, totally avoiding the SDK. Still the same results.

    I am completely at a loss here. Would you please do me a favor and check the markings of the chip on your V1.0.0 DK, just to make sure you have a legit DK and not an upgraded version? It should read 'AC0'. Alternatively, you could also read FICR->INFO.VARIANT which should give 0x41414330 (= "AAC0").

    If you find that your chip is really a rev. 1, I suggest to give up and file it under great unresolved mysteries of the universe.

    Thanks,

    Norbert

  • Hello Norbert,

    Norbert said:
    I also found a third V1.0.0 DK which behaves exactly like my other two boards.

    Could you confirm that you tested this with the SW9 switch in the Li-Po position, while powering the device with 3.0 V through the J6 or P27 port?

    Norbert said:
    I am completely at a loss here. Would you please do me a favor and check the markings of the chip on your V1.0.0 DK, just to make sure you have a legit DK and not an upgraded version?

    Sure thing - I just checked my board, and I do indeed have a AAC0 version of the chip.

    Best regards,
    Karl

  • Could you confirm that you tested this with the SW9 switch in the Li-Po position, while powering the device with 3.0 V through the J6 or P27 port?

    No, as I said earlier, SW9 is in middle position (VDD). The power is coming from the USB I/F.

    Thanks,

    Norbert

  • Norbert said:
    No, as I said earlier, SW9 is in middle position (VDD). The power is coming from the USB I/F.

    Yes, but as mentioned this will not supply the device through VDDH, which means that your SAADC's measurement of the VDDHDIV5 might be correct even still. If you wish to supply the device through the VDDH pin you will need to have the nRF52840 in High Voltage mode, which can be achieved by switching the SW9 to Li-po. In this case you will have to supply the nRF through the J6 or P27 port.

    Best regards,
    Karl

Reply
  • Norbert said:
    No, as I said earlier, SW9 is in middle position (VDD). The power is coming from the USB I/F.

    Yes, but as mentioned this will not supply the device through VDDH, which means that your SAADC's measurement of the VDDHDIV5 might be correct even still. If you wish to supply the device through the VDDH pin you will need to have the nRF52840 in High Voltage mode, which can be achieved by switching the SW9 to Li-po. In this case you will have to supply the nRF through the J6 or P27 port.

    Best regards,
    Karl

Children
No Data
Related