The input range of the SAADC is not as expected.

[TML_YT]

Hellow

We are in trouble. Please tell me what to do.

The input range of the SAADC is not as expected.

I use:
・nrf52840
・VDD=3.3V by Regulator
・nRF5_SDK_17.1.0
・Sample program Unmodified　\examples\peripheral\saadc

Therefore:
・gain=1/6
・Resolution=10bit
・Reference internal =0.6V
-->The Voltage input range should be 3.6v.

Situation & The problem
Vin=1.0V->0x011e (ok)
Vin=1.5V->0x01ab (ok)
Vin=2.0V->0x0239 (ok)
Vin=2.2V->0x024f (NG)
Vin=2.3V->0x01e1(NG)
Vin=2.4V->0x017e(NG)

If the input voltage exceeds about 2.2V, the output code is not as
expected, and if the input voltage is higher than that, the output code
value becomes smaller.

What are the causes and what can be done about it?

Please help me.

[TML_YT]

Actually, after examining the SAADC problem, I realized that the problem is not only with the input range of the ADC, but also with the output level of the GPIO, which is not restored by the sample program that was working fine before.

Here's the story again.

(Background)
I'm trying Raytac MDBT50Q-DB. The development environment is SEGGER.
For each function, I am trying the sample program provided by SEGGER.
The power supply is USB 5V converted to 3.3V by regulator.
RF operation, simple GPIO function, external ADC control via SPI, internal SAADC...
It worked fine up to a point.

(Problem)
---When we were verifying the SAADC, at first, it was actually working fine up to 3.3V when initially configured to have an analog input range of 3.6V. We did not tell you about this.
However, at some point, the problem started to occur where the input was only up to 2.1V, and even after reloading the first program, it did not return to normal, which is why we posted this on the web.
---Yesterday, I noticed the other problem. In other sample programs, the GPIO's
output H level was not 3.3V but around 2V. If I reload a program that was working fine before, it does not return to normal.

Therefor It seems that my problem is not only with the input range of the SAADC.
--The problem is not only with the input range of the SAADC, but also with the output level of the GPIO.
--I don't know when these problems occurred.

(I have an idea).
I don't know the details of the expected startup program for the Raytac module.
I don't know, because there is no documentation.
Regarding your question about the power supply, the Raytac datasheet says that the　power supply is below 3.3V and the regulator is LOD, but I don't know where it is set.

So I thought, why not?
I've been trying out some of the sample programs ”nd I've run "Erase All" a few times along the way.
In fact, Raytac's original important startup program ”Erase All" may have erased, even though they were loaded. We have already discussed this issue with Raytac.

We have already contacted Raytac about this and are waiting for a response.
We will update this page when we have more information.

Thanks you.

[haakonsh]

One possible scenario is that the ESD protection diodes on the GPIO is damaged, that could explain the observations. When the ESD diodes blow they tent to make a partial short to either GND or VDD, depending on which of the ESD diodes who blows. 

Can you read out the state of the UICR registers? 
'nrfjprog -f nrf52 --readuicr uicr.txt'

And can you try another analog input and see if you get the same result?

[TML_YT]

Thanks for the reply

I too am beginning to think that the device has been damaged.

(1) Attached is the state of the UICR register.
I loaded the sample program "blinky_FreeRTOS" and monitored it with the view-Registers function of SEGGER. In the SAADC program, the contents of the register are exactly the same.
I hope you can find out the cause from this.

(2) As for SAADC, the result is similar for AIN0 and AIN1.
As for GPIO output, I tried some other ports, but H level was 1.8V as well.

By the way, as for my concern about Erase-All, I asked Raytac about this, and I found that there is no problem in using it.
I still think that the device might have been damaged by the wrong power-on sequence of the evaluation board or debugger, or by static electricity.

Fullscreen blinky_FreeRTOS_pca10056 Registers - 01-3-22 at 08h56.txt Download

UICR                                  
    NRFFW[0]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[1]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[2]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[3]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[4]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[5]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[6]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[7]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[8]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[9]            0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[10]           0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[11]           0xffffffff    
        NRFFW           0xffffffff    
    NRFFW[12]           0xffffffff    
        NRFFW           0xffffffff    
    NRFHW[0]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[1]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[2]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[3]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[4]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[5]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[6]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[7]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[8]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[9]            0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[10]           0xffffffff    
        NRFHW           0xffffffff    
    NRFHW[11]           0xffffffff    
        NRFHW           0xffffffff    
    CUSTOMER[0]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[1]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[2]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[3]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[4]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[5]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[6]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[7]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[8]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[9]         0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[10]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[11]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[12]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[13]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[14]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[15]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[16]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[17]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[18]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[19]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[20]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[21]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[22]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[23]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[24]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[25]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[26]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[27]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[28]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[29]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[30]        0xffffffff    
        CUSTOMER        0xffffffff    
    CUSTOMER[31]        0xffffffff    
        CUSTOMER        0xffffffff    
    PSELRESET[0]        0x00000012    
        PIN             0x12          
        PORT            0             
        CONNECT         0             
    PSELRESET[1]        0x00000012    
        PIN             0x12          
        PORT            0             
        CONNECT         0             
    APPROTECT           0xffffffff    
        PALL            255           
    NFCPINS             0xffffffff    
        PROTECT         1             
    DEBUGCTRL           0xffffffff    
        CPUNIDEN        255           
        CPUFPBEN        255           
    REGOUT0             0xffffffff    
        VOUT            7             

[haakonsh]

REGOUT0 is set to 1.8V. When you apply a voltage of 2.1V and above (1.8V + 0.3V) the ESD diodes will start conducting from the analog input into VDD. If the signal source has more than ~100ohm internal impedance the voltage on the input pin will drop closer to VDD. 

See the I/O pin voltage specs in Absolute maximum ratings. 

[TML_YT]

A series of problems were solved by writing a '5' to the UICR->REGOUT0 register in high voltage mode, setting it to 3.3V.

The output level of the GPIO is now about 3V and the input voltage range of the SAADC is the same as the set value.

However, this register should only be enabled when operating in VDDH mode. The circuit was wired in such a way that it would work in VDDH mode, but the question remains: why?

(1) Then, why was VH=3.3V sometimes observed in the beginning?
The waveform recorded by the oscilloscope at the time was about 3V, so I don't think I'm mistaken.

(2) Also, why the return value of "nrf_power_dcdcen_get();" or "nrf_power_dcdcen_vddh_get();" is "false" in both cases?

I didn't change the power supply, and I didn't apply the current to the regulator to make the voltage drop significantly.Incidentally, the revision for the 52480 was NRF52480_xxAA_REV2.

Do you know the reason for these questions?