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.

[haakonsh]

That's strange. Are you using our DK, or are you using a custom board? 

What's you regulator configuration? 

[TML_YT]

Sorry it took me so long to get back to you. I accidentally clicked on
'verified answer' and couldn't reply.

I use DK of other manufacturers.

And then Regulator conditions in the DK board, as follows
5V→Regulator(3.3V)→nrf52840

As for the DK, it is made by another company, but the other functions
are normal and there does not seem to be any problem with it.
We are also concerned about the fact that similar questions have been
asked in the past and no clear answers have been given.

Is this an unusual situation?

[haakonsh]

TML_YT said:

We are also concerned about the fact that similar questions have been
asked in the past and no clear answers have been given.

Is this an unusual situation?

No, this is far outside of spec and not something that i've come across before. 


The first thing I would suspect was the root cause is some grounding issues in the PCBA. Can you replicate the issue on our DK? And can you share any info about the PCBA that you're using? 

[TML_YT]

The NORDIC DK does not seem to be readily available.
The module we are currently testing is the RAYTAC MDBT50Q (with nRF52840), which is further mounted on their MDBT50Q-DB evaluation board.

The USB 5V power supply is converted to 3.3V by a regulator on the evaluation board and fed to the MDBT50Q, and the GND seems to be common to all.

I also tried the following:
(a)When the gain is 1/4 and the reference supply is 4/VDD(VDD=3.3V), the input range should be the same as the gain 1/6 and the internal reference 0.6V, but the output code decreases after about 2.1V as well.

(b)Also, if I set the internal reference 0.6V and gain 1/3, the code is 2^10 at input 1.8V, and if I set the internal reference 0.6V and gain 1/2, the code is 2^10 at input 1.2V, which seems to be working properly.

(c)In addition, I tried to use differential mode and connect the neg pin to the same GND as the board, gain 1/6, internal reference 0.6V, but the same result as the first, the code decreases when the input voltage exceeds 2.1V.

In any case, the hardware is the most likely cause of the problem.
The information about the module MDBT50Q (with nRF52840) and the evaluation board MDBT50Q-DB of the company is certainly not enough, so I will ask RATAC about this matter.

[haakonsh]

I don't think there's a problem with the Raytac DK design at least, but it could be a QA issue.  

TML_YT said:

(a)When the gain is 1/4 and the reference supply is 4/VDD(VDD=3.3V), the input range should be the same as the gain 1/6 and the internal reference 0.6V, but the output code decreases after about 2.1V as well.

I don't understand your argument. The input range is always 0V to VDD+0.3V. You can scale the input range with the gain stage to fit the voltage reference. 

TML_YT said:

(b)Also, if I set the internal reference 0.6V and gain 1/3, the code is 2^10 at input 1.8V, and if I set the internal reference 0.6V and gain 1/2, the code is 2^10 at input 1.2V, which seems to be working properly.

That looks like the correct behavior. 

TML_YT said:

(c)In addition, I tried to use differential mode and connect the neg pin to the same GND as the board, gain 1/6, internal reference 0.6V, but the same result as the first, the code decreases when the input voltage exceeds 2.1V.

The SAADC is always operating in differential mode, when single-ended mode is selected the negative input is tied to GND internally, so you should get the exact same result when manually connecting the negative input to GND. 

I have a few questions: 

1. Do you use the high-voltage regulator (REG0), and if so, what is it's output voltage? 
   
   
2. Can you share your code, at least what's relevant to the SAADC configuration, sampling, and how you read the data?
   
   
3. Can you share some raw data from the SAADC? I need some 10-20 samples from when the SAADC is operating as expected and the same for when it is not operating as expected, and also the input voltage. 

[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?

[haakonsh]

1. The UICR->REGOUT0 register was likely set to 5(3.3V) at some point, then an nrfjprog eraseall command reset the UICR->REGOUT0 to its default state, 7 (1.8V). 
   
   
2. You check for the state of the DCDC regulators, If false it means that they are operating in LDO mode. 

I hope this clears things up. Most likely Raytac ships their dk's with UICR->REGOUT0 set to 5, we do the same for our nRF52840 dongles.