ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

Karl Ylvisaker — Tue, 14 Nov 2023 15:20:01 GMT

Hello,

[quote user="snoopy20"]Datasheet - "Scan mode and oversampling cannot be combined. "
Outcome - Not true, it works. It may not work for repeated scans (I haven't tested) but for a single loop of multiple channels it works fine.[/quote]

Are you here also using BURST?
If not, then the samples will be averaged over the full scan (across channels), which will produce samples, but they will be averaged over different inputs.
When BURST is used it will collect all the samples in one channel, average, and then move on to the next, which is why this combination works as expected.

[quote user="snoopy20"]The 5us, I was looking at #150 within v1 by mistake. I'm unlikely to have these chips in my inventory, likely v2 where it appears it was resolved.[/quote]

Thank you for clarifying! :)

hmolesworth
I concur that this sounds like it could be a likely scenario, but I unfortunately do not have enough prior knowledge of the easyDMA/AHB architecture to provide much insight here unfortunately.

Best regards,
Karl

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Sun, 12 Nov 2023 00:09:18 GMT

My thinking is a stalled DMA write has a write transaction which will complete but before doing so the DMA ptr hardware register is triggered to increment in the peripheral hardware (no DMA memory AHB or process APB interaction completion required for this increment, it's just a hardware "counter" inside the peripheral) and writes the value at this updated memory address. This write completion triggers another hardware counter increment, so now there has been a shift. There is no information on how this hardware pointer register (counter) works, though the likelihood is that it uses the 16MHz clock and a stalled AHB bus write may address the physical memory just before or just after the 16MHz clock edge triggers. Speculation, of course. Worst case two bytes may be written, one at the old required address and another (unwanted) value at the next address which in turns triggers a hardware counter address update; that's even more speculative. The real issue is incorrect synchronisation between the 3 busses: cpu to peripheral via AHB2APB, peripheral DMA AHB to RAM which is shared by the higher priority cpu, and the peripheral innards which is where the DMA address memory pointer is incremented. Both cpu code and cpu data transactions can lead to a stall, so this stall is of an indeterminate period. I understand the Cortex-M7 has fixed this Cortex-M4 issue.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Sat, 11 Nov 2023 15:22:22 GMT

Cool, I'll revert the code to doing calibration once per loop, thanks. I also read the temperature of the die so will likely add some skipping code at the same time.

Other matters

Datasheet - "Scan mode and oversampling cannot be combined. "
Outcome - Not true, it works. It may not work for repeated scans (I haven't tested) but for a single loop of multiple channels it works fine.

The 5us, I was looking at #150 within v1 by mistake. I'm unlikely to have these chips in my inventory, likely v2 where it appears it was resolved.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

Karl Ylvisaker — Fri, 10 Nov 2023 11:43:42 GMT

Hello again,

A very useful discussion indeed! :)

[quote user="snoopy20"]So my implementation was based on another post on this forum by a nordic engineer saying the calibration values are retained until power reset, which doesn't appear to be the case according to Karl (probably because it wasn't factoring in the errata code).[/quote]

I dug deeper into this, and I stand corrected: You will fortunately not have to perform a new calibration each time the Errata 212 workaround is ran.

Part of the workaround from the errata is to power cycle the peripheral - which means resetting all the internal registers, thus warranting a new calibration - but closer examination on my part has revealed that the previous calibration is actually carried over in the rest of the errata workaround.
The easiest thing here is of course to abide by the Errata text and set up all registers again, but as it turns out for the specific offset calibration results this value will be carried over. Apologies for the confusion here.

[quote user="hmolesworth"]Avoiding data shift can be improved by reducing the underlying cause (this affects SPIM as well). This example is for the nRF52810.[/quote][quote user="hmolesworth"]Reduce likelihood further[/quote]

Could you clarify on what you mean when you say that you can 'reduce likelihood' here?
I agree with your analysis of the AHB priorities and the potential impact of the timing, but you should not see a buffer shift if you implement the workarounds (for each errata as they apply to your project) + the PPI channel described by my colleague Jørgen in the post you referenced earlier, and so you should not need to take actions to 'further reduce likelihood' - perhaps I am misunderstanding something here.

[quote user="snoopy20"]The errata says that a TASK_STOP should be used, this is not true as one of my posts above shows, however the delay it introduces may change the timing upon which easydma fails and perhaps gave the impression of such.[/quote]

Which errata are you referring to here?
Since we are discussing multiple ones it would be great if you could reference their number is possible.

[quote user="snoopy20"]Another errata says that 5us channels can't be used with timer+PPI. This is untrue, I'm doing it and have never seen an issue.[/quote]

Are you here referring to the Errata 212? If so, it only comes into effect when you are also switching from multiple channels to single channel input.
If not, please specify which errata this is in relation to.

[quote user="snoopy20"]And in the datasheet it says burst can't be combined with scan mode. This is not true, I do it just fine. But it may be the case that it can only be one sweep.[/quote]

Could it be that you are here referring to that 'scan + oversampling' should not be combined? It is also true that you may in fact do this if you also enable BURST on all channels.
As per the Product specification you can use scan + burst so long as burst is enabled on all channels.

Best regards,
Karl

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Fri, 10 Nov 2023 09:06:30 GMT

So my implementation was based on another post on this forum by a nordic engineer saying the calibration values are retained until power reset, which doesn't appear to be the case according to Karl (probably because it wasn't factoring in the errata code).

This means I have to do calibration on every step, of which there are 4 in a continuous loop running at around 5Hz. I'm unsure if it's worth the overhead.

Regarding the buffer shift, the buffer always moves forwards not backwards, which I believe indicates a false signal (double or noise) not a missing one. The shift is also retained across all adc reconfiguration which indicates there's state held somewhere.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Wed, 08 Nov 2023 16:26:37 GMT

Really useful discussion :-) Adding to this note a couple of additional ways to improve the SAADC. Instead of calibration another way is to read the temperature and apply a correction based on that, simple to characterise to get a good curve fit and the sort of thing done frequently on (say) the 32kHz crystal for better timekeeping.

Avoiding data shift can be improved by reducing the underlying cause (this affects SPIM as well). This example is for the nRF52810.

"EasyDMA is an AHB bus master similar to CPU and is connected to the AHB multilayer interconnect for direct access to Data RAM. AHB multilayer enables parallel access paths between multiple masters and slaves in a system. Access is resolved using priorities.

Each bus master is connected to the slave devices using an interconnection matrix. The bus masters are assigned priorities. Priorities are used to resolve access when two (or more) bus masters request access to the same slave device. The following applies:
• If two (or more) bus masters request access to the same slave device, the master with the highest priority is granted the access first.
• Bus masters with lower priority are stalled until the higher priority master has completed its transaction.
• If the higher priority master pauses at any point during its transaction, the lower priority master in queue is temporarily granted access to the slave device until the higher priority master resumes its activity.
• Bus masters that have the same priority are mutually exclusive, thus cannot be used concurrently."

nRF52810 Priorities
Bus master name Description
CPU
SPIM0/SPIS0 Same priority and mutually exclusive
RADIO
CCM/ECB/AAR Same priority and mutually exclusive
SAADC
UARTE0
TWIM0/TWIS0 Same priority and mutually exclusive
PDM
PWM

CPU, RADIO and SPIM0 are likely to cause a stall on the SAADC DMA which can lead to a data shift; with a fixed streaming rate over DMA this is a problem. Reduce this likelihood by dedicating an AHB Bus Master-Slave to a single RAM segment reserved for the SAADC and low-usage cpu data.

READERBUFFER_SIZE 5
WRITERBUFFER_SIZE 6
uint8_t readerBuffer[READERBUFFER_SIZE] __at__ 0x20000000; <== choose dedicated RAM segment
uint8_t writerBuffer[WRITERBUFFER_SIZE] __at__ 0x20000005;
// Configuring the READER channel
MYPERIPHERAL->READER.MAXCNT = READERBUFFER_SIZE;
MYPERIPHERAL->READER.PTR = &readerBuffer;
// Configure the WRITER channel
MYPERIPHERAL->WRITER.MAXCNT = WRITEERBUFFER_SIZE;
MYPERIPHERAL->WRITER.PTR = &writerBuffer;

Reduce likelihood further by scheduling SAADC reads between RADIO and CPU and SPIM0 events (more tricky if streaming lots of ADC measurements).

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Wed, 08 Nov 2023 14:43:40 GMT

There are three erratas for 810 adc at least:

1. when using calibration a sample may be taken, so one should configure the channels and dma after calibration.
2. when using calibration if a task_sample is invoked the reads will be garbage from that point forth. Really this is misconfiguration of running a timer and ppi event and not exactly errata per say.
3. when re-configuring adc registers (config,dma) after a multi-scan (not just one pass) then easydma will eventually buffer shift.

The errata says that a TASK_STOP should be used, this is not true as one of my posts above shows, however the delay it introduces may change the timing upon which easydma fails and perhaps gave the impression of such.

I actually use the 810 in another project where the adc is pushed to it's max computing real/apparent wattages for a generator. I don't have to reset there because I don't reconfigure the channels.

Also...

Another errata says that 5us channels can't be used with timer+PPI. This is untrue, I'm doing it and have never seen an issue.

And in the datasheet it says burst can't be combined with scan mode. This is not true, I do it just fine. But it may be the case that it can only be one sweep.

A.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

Karl Ylvisaker — Wed, 08 Nov 2023 14:21:08 GMT

[quote user="snoopy20"]It's not an issue in this application and to be honest if it were I'd monitor the internal temperature of the die and skip the step if the delta isn't high enough. There's always a way![/quote]

Yeah, if it had been an issue for you we'd have to turn some rocks to see what the possible solutions could be, but I am glad to hear that this is not an issue! :)

[quote user="snoopy20"]I do think however that some work is needed on the errata. For the 810 at least there are two around the calibration, which are the same thing, and as I've shown in this thread the errata applies at any time configuration changes between scans and not just calibration.[/quote]

To me it looks like you are seeing the effects of Errata 212 paired with the buffer-shift issue explained by my colleague Jørgen in the other thread, could you elaborate what you mean when you say 'the errata applies at any time configuration changes between scans and not just calibration?

I do agree that Errata 237 and Errata 252 perhaps should have been a single errata as I am not sure if their distinction is clear enough. I will check internally to see if what the background for this is.

Best regards,
Karl

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Wed, 08 Nov 2023 09:59:27 GMT

It's not an issue in this application and to be honest if it were I'd monitor the internal temperature of the die and skip the step if the delta isn't high enough. There's always a way! 🙂

I do think however that some work is needed on the errata. For the 810 at least there are two around the calibration, which are the same thing, and as I've shown in this thread the errata applies at any time configuration changes between scans and not just calibration.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

Karl Ylvisaker — Wed, 08 Nov 2023 09:25:43 GMT

Hello A,

I am glad to hear that it now functions as expected! :)
I understand that it is not ideal to have to go through the calibration so often, but unfortunately it is no way around the reset of the SAADC peripheral between the configurations you are using in this case.

Alternatively, if the repeated calibration is effecting the performance of other components in your system you could also run some tests on the feasibility for your application not to perform the offset calibration at all - as mentioned in the Product Specification the SAADC has a temperature dependent offset, but if what you are after in your application is the relative change in voltage over time, and the device is operating in a small temperature range - less than 10 degrees change in ambient temperature - it could also be feasible for you to run without the calibration. At least I do not know enough about your applications requirements and constraints to rule this possibility out.

Best regards,
Karl

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 07 Nov 2023 14:21:52 GMT

Hi Karl,

I'm in production with it, it's working well.

I perform a number of steps in a adc-interrupt-loop with calibration being the first. Each step does a full reset of the adc using the errata code. It's not the fastest or the most optimal (i.e calibration every ~100ms) but it works and is fast enough!

A.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

Karl Ylvisaker — Tue, 07 Nov 2023 14:15:18 GMT

Hello,

[quote user="snoopy20"]So after much testing yesterday it occasionally would skip, which in my case is a fatal flaw that can damage hardware. I literally exhausted everything and then finally went the whole hog and used the errata code before any adc operation to do a full reset and reconfig. This has solved it.[/quote]

I am sorry to read the struggles you've had to get this working as expected, which no doubt was a frustrating experience!

My general suggestion for your setup would be to use the SAADC driver and to have the sampling triggered through PPI with the addition described in this answer by my colleague Jørgen referenced by hmolesworth earlier, but you would of course also need to pay heed to the erratas also mentioned by hmolesworth, which sounds close to what you are doing currently.

[quote user="snoopy20"]My understanding (be good if someone from Nordic can verify) is that this will also reset internal calibration values if ran.[/quote]

Correct, adding this code will reset the entire SAADC peripheral, as mentioned in the workaround description. The offset calibration would indeed have to be run again, which should be done before you have started sampling (or after the END event, as described in the erratas), or anytime the ambient temperature has changed more than 10 degrees to counteract changes in the measurements caused by temperature.
Are there anything else than the offset calibration you are referring to here, when you say 'internal calibration values'?

Best regards,
Karl

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Fri, 03 Nov 2023 10:53:18 GMT

Similar, a generator.

So after much testing yesterday it occasionally would skip, which in my case is a fatal flaw that can damage hardware. I literally exhausted everything and then finally went the whole hog and used the errata code before any adc operation to do a full reset and reconfig. This has solved it.

  volatile uint32_t temp1;
  volatile uint32_t temp2;
  volatile uint32_t temp3;
  temp1 = *(volatile uint32_t *)0x40007640ul;
  temp2 = *(volatile uint32_t *)0x40007644ul;
  temp3 = *(volatile uint32_t *)0x40007648ul;
  *(volatile uint32_t *)0x40007FFCul = 0ul; 
  *(volatile uint32_t *)0x40007FFCul; 
  *(volatile uint32_t *)0x40007FFCul = 1ul;
  *(volatile uint32_t *)0x40007640ul = temp1;
  *(volatile uint32_t *)0x40007644ul = temp2;
  *(volatile uint32_t *)0x40007648ul = temp3;

My understanding (be good if someone from Nordic can verify) is that this will also reset internal calibration values if ran.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Wed, 01 Nov 2023 15:03:15 GMT

Nice! Is this for off-grid solar, by any chance? I'll keep an eye out for more exciting problems ..

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Wed, 01 Nov 2023 10:09:47 GMT

I am simply delighted to say this is resolved!

I hope the Nordic team can create an errata and use the two PPI solution above not only for calibration but for scan operations.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Wed, 01 Nov 2023 10:02:46 GMT

I have used DSB() in the past, I tried a smattering after all the SAADC registers but to no avail.

After debugging and waiting for a while I managed to capture the failure. The reads have shifted one in ram.

I then checked all the PELP registers upon this occurrence and they're all correct.

Given there is some shift errata around the calibration (although I've disabled calibration) I decided to try wiring END to STOP.

NRF_PPI->CH[CFG_PPI_ADC_ENDAUTOSTOP].EEP = (uint32_t) &NRF_SAADC->EVENTS_END;
NRF_PPI->CH[CFG_PPI_ADC_ENDAUTOSTOP].TEP = (uint32_t) &NRF_SAADC->TASKS_STOP;
NRF_PPI->CH[CFG_PPI_ADC_CALIBRATEAUTOSTOP].EEP = (uint32_t) &NRF_SAADC->EVENTS_CALIBRATEDONE;
NRF_PPI->CH[CFG_PPI_ADC_CALIBRATEAUTOSTOP].TEP = (uint32_t) &NRF_SAADC->TASKS_STOP;

I then switched the interrupt to STOP.

I'm still running and praying but so far no further shifting!

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Wed, 01 Nov 2023 03:57:24 GMT

I tried to run the code but my test setup is using a different SDK version not recognising some of the SAADC defines, maybe I'll get another look tomorrow.

Regarding the PSEL taking a while, all peripheral operations take a while and code access to registers may be delayed wrt hardware event access. Two issues, one the peripherals use a 16MHz clock instead of the CPU 64MHz clock and two the AHB bus priority instigates unquantifiable delays. Here's a simple example from personal experience. A single SPIM DMA transaction event should generate a single interrupt, and mSpiInterruptCounter should therefore be equal to 1 after the event. Here are 3 example interrupts, all correct; the first generates a count of 2, the second 2 examples generate a count of 1. Multiple interrupts from a single event is ridiculous, but it happens because the interrupt tail-chains and repeats before the AHB/register clear transaction completes as the CPU has both higher priority and a 4x faster clock than the peripheral. This is a known Cortex-M4 bug. Is this an issue with the SAADC here? Dunno .. the hardware event - which does not have to traverse the stalled AHB bus - can in some cases happen before a delayed cpu transaction. __DSB(); fixes this issue in some cases. Nordic engineers might step in here :-)

volatile uint32_t mSpiInterruptCounter = 0UL;

void SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler(void)
{
  mSpiInterruptCounter++;
  if (NRF_SPIM0->EVENTS_END) NRF_SPIM0->EVENTS_END = 0;  // Subtle Bug here
}

void SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler(void)
{
  if (NRF_SPIM0->EVENTS_END) NRF_SPIM0->EVENTS_END = 0;  // Ok
  mSpiInterruptCounter++;
}

void SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler(void)
{
  mSpiInterruptCounter++;
  if (NRF_SPIM0->EVENTS_END) NRF_SPIM0->EVENTS_END = 0;  // Ok
  // Clear pending hardware register bus operations - Cortex-M4 issue
  __DSB();
}

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Wed, 01 Nov 2023 00:11:17 GMT

Tasks Stop are supposed to be like an 'Abort', they shouldn't be required once an End Event has fired, so I am led to believe.

You're right, it's step1,2,3,4 repeat and (4) is actually running (1) atm, but was there for looping purposes.

I'll try and get a breakpoint on step 2 to inspect the voltages tomorrow once it's gone pair shaped and see if they've shifted. It's possible as most the voltage if not all the others are very low, which is what the main voltage I'm primarily interested switches to (voltage.storage).

I haven't read anything around PSEL taking a while to set, is that something you've seen before?

Regards, Andrew

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Tue, 31 Oct 2023 23:34:52 GMT

Edit: I see the sequence is repeat step1-2-3-4-1-2 ..If a PSEL is slow getting disabled, then the steps immediately go out of sequence so instead of input0-1-2-3-4-5-0 ... input6-7-6-7 it ends up maybe being input0-1-2-3-4-5-0 ... input0-1-0-1... Do the measured voltages look like that?

Also there is no TASKS_STOP and EVENTS_STOPPED check prior to a TASKS_START; I wonder if that would help ..

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 31 Oct 2023 23:16:39 GMT

Interesting find that link. So regarding the START operations which I am indeed performing in the interrupt...

1. for one scenario the SAMPLE is fired by PPI on the STARTED event, so I don't believe the SAMPLE can fire before STARTED.

2. for the second scenario I am calling START and then enabling the PPI channel to allow the timer tick to come through. I actually already added code (step3) to check if STARTED event has fired before enabling the PPI channel, just to make sure no SAMPLE event comes through prior.

There's potentially the case where the ADC will receive a SAMPLE from the timer while easydma is operating but the END event hasn't yet been fired. In the case of a unique timer it would be possible to use PPI to stop the timer on END, but in the case of my RTC I have to use an interrupt to do the dirty, which potentially is much slower. I'm unsure however if it makes any difference. There's nothing to indicate that a timer can't in fact be left running.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 31 Oct 2023 23:02:25 GMT

Hello!

In my current working case I've disabled calibration. I think many of the 832 errata also apply to the 810 even if not specified. For one, I have used 10us sampling or more due to the PPI issues.

Some of the extra defines are

  NVIC_SetPriority(CFG_SCHEDULER_TIMER_IRQn, CFG_INTERRUPT_PRIORITY_SCHEDULER);
  NVIC_EnableIRQ(CFG_SCHEDULER_TIMER_IRQn);
  CFG_SCHEDULER_TIMER->EVTENSET = RTC_EVTENSET_TICK_Set << RTC_EVTENSET_TICK_Pos;
  CFG_SCHEDULER_TIMER->PRESCALER = CFG_SCHEDULER_TIMER_PRESCALER-1;
  CFG_SCHEDULER_TIMER->TASKS_START = RTC_TASKS_START_TASKS_START_Trigger << RTC_TASKS_START_TASKS_START_Pos;

#define CFG_ADC_FRONT_PSEL SAADC_CH_PSELP_PSELP_AnalogInput0
#define CFG_ADC_REAR_PSEL SAADC_CH_PSELP_PSELP_AnalogInput1
#define CFG_ADC_USB_PSEL SAADC_CH_PSELP_PSELP_AnalogInput2
#define CFG_ADC_LIGHTSENSE_PSEL SAADC_CH_PSELP_PSELP_AnalogInput4
#define CFG_ADC_STORE_PSEL SAADC_CH_PSELP_PSELP_AnalogInput5
#define CFG_ADC_MPPT_VOLTAGE_PSEL SAADC_CH_PSELP_PSELP_AnalogInput6
#define CFG_ADC_MPPT_CURRENT_PSEL SAADC_CH_PSELP_PSELP_AnalogInput7

#define pinDisconnectInputBuffer (GPIO_PIN_CNF_INPUT_Disconnect << GPIO_PIN_CNF_INPUT_Pos)

#define CFG_SCHEDULER_TIMER_PRESCALER 8

The current workings are

#include <stdint.h>


#define ADC_RESOLUTION SAADC_RESOLUTION_VAL_12bit
#define ADC_SAMPLETIME_CFG_SLOW SAADC_CH_CONFIG_TACQ_40us
#define ADC_SAMPLETIME_CFG_MPPT_VOLTAGE SAADC_CH_CONFIG_TACQ_10us
#define ADC_SAMPLETIME_CFG_MPPT_CURRENT SAADC_CH_CONFIG_TACQ_10us

// ADC takes 2us per channel, 4us + 10us + 10us = 24us

// 4096Hz = 244us
// 350 (fit into ram)*244 = 85.4ms
#define MPPT_SAMPLES 700

// 200ms total / 81ms
#define MPPT_LOOP 1

enum {
  ADC_CH_USB,
  ADC_CH_FRONT,
  ADC_CH_REAR,
  ADC_CH_STORE,
  ADC_CH_LIGHTSENSE,
  ADC_CH_MPPT_VOLTAGE,
  ADC_CH_MPPT_CURRENT
};

struct mpptReadProto {
  int16_t voltage;
  int16_t current;
};

static struct {
  int16_t usb;
  int16_t front;
  int16_t rear;
  int16_t storage;
  int16_t lightsense;
} voltages;

static struct {
  int16_t usb;
  int16_t front;
  int16_t rear;
} currents;

static void step4 (void);
static void step3 (void);
static void step2 (void);
static void step1 (void);

static void (*step)(void);
static uint8_t loop;
static struct mpptTrackProto track;
static struct mpptReadProto banks[MPPT_LOOP > 1? 2 : 1][MPPT_SAMPLES];
static uint8_t bank;

extern struct statusProto status;

static void step1 (void) {

  step = &step2;

  NRF_GPIO->OUTCLR = 1 << CFG_PIN_ADC_MUX;
  NRF_PPI->CHENSET = 1 << CFG_PPI_ADC_SAMPLEONSTART;

  NRF_SAADC->CH[ADC_CH_USB].PSELP = CFG_ADC_USB_PSEL;
  NRF_SAADC->CH[ADC_CH_FRONT].PSELP = CFG_ADC_FRONT_PSEL;
  NRF_SAADC->CH[ADC_CH_REAR].PSELP = CFG_ADC_REAR_PSEL;
  NRF_SAADC->CH[ADC_CH_STORE].PSELP = CFG_ADC_STORE_PSEL;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].PSELP = CFG_ADC_LIGHTSENSE_PSEL;

  NRF_SAADC->RESULT.PTR = (uint32_t) &voltages;
  NRF_SAADC->RESULT.MAXCNT = sizeof(voltages) / 2;

  //NRF_SAADC->EVENTS_STARTED = 0;
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
  //while (!NRF_SAADC->EVENTS_STARTED) {}
  //NRF_SAADC->TASKS_SAMPLE = 1;
}

static void step2 (void) {

  step = &step3;

  NRF_GPIO->OUTSET = 1 << CFG_PIN_ADC_MUX;

  NRF_SAADC->RESULT.PTR = (uint32_t) &currents;
  NRF_SAADC->RESULT.MAXCNT = sizeof(currents) / 2;
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
}

static void step3 (void) {

  step = &step4;
  NRF_PPI->CHENCLR = 1 << CFG_PPI_ADC_SAMPLEONSTART;

  NRF_SAADC->CH[ADC_CH_USB].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_FRONT].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_REAR].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_STORE].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].PSELP = CFG_ADC_MPPT_VOLTAGE_PSEL;
  NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].PSELP = CFG_ADC_MPPT_CURRENT_PSEL;

  NRF_SAADC->RESULT.PTR = (uint32_t) &banks;
  NRF_SAADC->RESULT.MAXCNT = MPPT_SAMPLES * 2;

  NRF_SAADC->EVENTS_STARTED = 0;
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
  while (!NRF_SAADC->EVENTS_STARTED) {}
  NRF_PPI->CHENSET = 1 << CFG_PPI_ADC_SAMPLEBYTIMER;
}

static void trackAssess () {

  for(struct mpptReadProto *pCur = &banks[bank][0]; pCur < &banks[bank][0] + sizeof(banks[0]); pCur++) {
    if (pCur->voltage > track.voltage && pCur->current > track.current) {
      track.voltage = pCur->voltage;
      track.current = pCur->current;
    }
  }
}

static void step4 (void) {

  NRF_PPI->CHENCLR = 1 << CFG_PPI_ADC_SAMPLEBYTIMER;

  #if MPPT_LOOP > 1

  if (loop == MPPT_LOOP-1) {

  #endif

    NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].PSELP = SAADC_CH_PSELP_PSELP_NC;
    NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].PSELP = SAADC_CH_PSELP_PSELP_NC;
    trackAssess();
    MPPT_Track(&track);
    track.voltage = 0;
    track.current = 0;
    loop = 0;
    bank = 0;
    step1();
    return;

  #if MPPT_LOOP > 1

  }

  NRF_SAADC->RESULT.PTR = bank? (uint32_t) &banks[0] : (uint32_t) &banks[1];
  NRF_SAADC->EVENTS_STARTED = 0;
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
  while (!NRF_SAADC->EVENTS_STARTED) {}
  NRF_PPI->CHENSET = 1 << CFG_PPI_ADC_SAMPLEBYTIMER;
  
  trackAssess();
  bank = bank? 0:1;
  loop++;

  #endif
}

void SAADC_IRQHandler (void) {

  NRF_SAADC->EVENTS_END = SAADC_EVENTS_END_EVENTS_END_NotGenerated << SAADC_EVENTS_END_EVENTS_END_Pos;
  step();
}

uint32_t ADC_TaskCalibrate (void) {

  NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Enabled << SAADC_ENABLE_ENABLE_Pos;
  //NRF_SAADC->TASKS_CALIBRATEOFFSET = SAADC_TASKS_CALIBRATEOFFSET_TASKS_CALIBRATEOFFSET_Trigger << SAADC_TASKS_CALIBRATEOFFSET_TASKS_CALIBRATEOFFSET_Pos;
  return 0; //CFG_SCHEDULER_TIMER_MINIMUM;
}

uint32_t ADC_TaskStart (void) {

  NRF_SAADC->EVENTS_END = SAADC_EVENTS_END_EVENTS_END_NotGenerated << SAADC_EVENTS_END_EVENTS_END_Pos;
  NRF_SAADC->INTENSET = SAADC_INTENSET_END_Enabled << SAADC_INTENSET_END_Pos;
  step1();
  return CFG_SCHEDULER_TIMER_MINIMUM;
}

uint32_t ADC_TaskCalc (void) {

  return 0;
}

inline void ADC_Init (void) {

  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_STORE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_USB] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_FRONT] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_REAR] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MPPT_VOLTAGE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MPPT_CURRENT] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_LIGHTSENSE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MUX] = pinDisconnectInputBuffer | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos);
  NRF_GPIO->OUTSET = 1 << CFG_PIN_ADC_MUX;

  NRF_SAADC->RESOLUTION = SAADC_RESOLUTION_VAL_12bit << SAADC_RESOLUTION_VAL_Pos;
  NRF_SAADC->CH[ADC_CH_USB].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_FRONT].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_REAR].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_STORE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_2 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain2 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_MPPT_VOLTAGE << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_MPPT_CURRENT << SAADC_CH_CONFIG_TACQ_Pos;
  
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEONSTART].EEP = (uint32_t) &NRF_SAADC->EVENTS_STARTED;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEONSTART].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEBYTIMER].EEP = (uint32_t) &NRF_RTC1->EVENTS_TICK;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEBYTIMER].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;
  
  NVIC_SetPriority(SAADC_IRQn, CFG_INTERRUPT_PRIORITY_ADC);
  NVIC_EnableIRQ(SAADC_IRQn);
}

void ADC_Shutdown (void) {

  NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos;
}

Effectively I'm using two methods both PPI, one wires STARTED to SAMPLE, where I want to use scan for n amount of channels once, and then an alternative second PPI wires the RTC tick to SAMPLE, where I scan 2 channels multiple times.

Due to RAM limitations I was using multiple banks, so easydma would fill one and processing would occur while it began filling the other one. Currently given the prescaler is so high I don't need the loop and am running just the one bank, 750 x 2 channels.

I'm using various interrupts, no code occurs within the main loop it's just an idle there. For some reason the ADC must run with priority 3 or greater when the softdevice is running. This suggested the softdevice was overwhelming the cpu to service higher interrupts, but then the scheduler and other higher interrupts I have are being serviced ok. It's odd!

enum {
  CFG_INTERRUPT_PRIORITY_ADC = 3,
  CFG_INTERRUPT_PRIORITY_GPIOTE = 3, // must come before scheduler
  CFG_INTERRUPT_PRIORITY_EGU = 5,
  CFG_INTERRUPT_PRIORITY_SCHEDULER = 4
};

It shouldn't make any difference I believe with the CPU jumping out of the ADC interrupt and back-in since none of the code that I can see needs to be atomic.

At this point I have **** all idea why it randomly crashes. Also when I say crash I mean the ADC peripheral; the ADC values randomly transform to low garbage and only a power reset clears it.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

hmolesworth — Tue, 31 Oct 2023 22:29:23 GMT

Such fun .. some years ago I had a similar issue and made these notes; if you post the sequence of calls to these functions (and more of the #defines as it's tedious creating them) I could do some independant testing, as I don't see where you are checking things like cal finished before starting a scan, and there is an SAADC errata where cal breaks things unless issued prior to a START or following an END. nRF52810 errata 237 and errata 252. Also note errata 212.

// Problem when the SAADC is configured in continuous mode using PPI to trigger the SAMPLE task at a regular interval,
// while the END event and START task is handled by CPU interrupt. When the SAMPLE task is triggered, each channel is
// sampled and written to RAM with DMA as fast as possible. When the buffer have been filled, the DMA transfer will be
// delayed until the START task have been triggered. You are triggering the START task in the interrupt handler after
// receiving the END event. If you receive the END event when IRQ is disabled or an interrupt with higher priority is
// executing, the triggering of the START task can get delayed until after the SAMPLE task have been triggered using
// PPI. Triggering of the SAMPLE task will generate a DMA transfer request, but this request will not be acknowledged
// until the START task have been triggered. The scan cycle of the SAADC will however expect the DMA transfer to finish,
// and will sample next channel. When the START task is triggered, the pending DMA transfer will be executed, but the
// transferred sample will correcpond to the latest sampled channel. Samples from previous channels will have been lost.
//
// There are two possible solutions to this problem:
//
// Use PPI to trigger START task on an END event. This will avoid the delayed triggering og the START task due to a
// queued interrupt generated by the END event, but in the case of high sample frequency and long delays, it can cause
// your buffer to be overwritten before you are able to process the buffer. In case of using this solution, it is
// neccessary to use double buffering and large enough buffers to avoid data loss.
// Trigger sampling from CPU interrupt. If the SAMPLE task is triggered from an interrupt with lower priority than the
// SAADC IRQ handler, the START task will always be triggered between an END event and a new SAMPLE task. This solution
// will make the sampling vary a bit in time, as higher priority tasks can cause the triggering of SAMPLE task to be delayed.

I think the following post might have some useful info: offset-in-saadc-samples-with-easy-dma-and-ble

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 31 Oct 2023 22:05:22 GMT

Nope it's crashed again, just took a lot longer. F**** sake!

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 31 Oct 2023 22:04:08 GMT

I appear to have stability. Max RTC prescaler is 8, or 4096Hz.

To resolve the instability disable calibration completely. It appears to be linked to the channel so reconfiguring them as I do will result in bad data eventually.

So far the ADC hasn't crashed so fingers crossed its sorted.

RE: ADC Infuriating Behaviour With Multi-channel Scan Using PPI to RTC

snoopy20 — Tue, 31 Oct 2023 21:27:08 GMT

Right, so I've determined that it will mostly work with an RTC prescale of 9, but mostly the ADC will eventually fail and start giving crap out. At a prescale of 8 it will mostly not work and at 7 it's crap out all the time.

A prescale of 9 equals 3631Hz, which is 274us.

Something is interfering with the operation and it worsens as load increases (i.e run softdevice).

#define ADC_RESOLUTION SAADC_RESOLUTION_VAL_12bit
#define ADC_SAMPLETIME_CFG_SLOW SAADC_CH_CONFIG_TACQ_20us
#define ADC_SAMPLETIME_CFG_MPPT_VOLTAGE SAADC_CH_CONFIG_TACQ_20us
#define ADC_SAMPLETIME_CFG_MPPT_CURRENT SAADC_CH_CONFIG_TACQ_10us

// ADC takes 2us per channel, 4us + 40us + 40us = 84us

// 3641Hz = 274us
// 667 (fit into ram)*274 = 182ms
#define MPPT_SAMPLES 350

// 200ms total / 81ms
#define MPPT_LOOP 3

enum {
  ADC_CH_USB,
  ADC_CH_FRONT,
  ADC_CH_REAR,
  ADC_CH_STORE,
  ADC_CH_LIGHTSENSE,
  ADC_CH_MPPT_VOLTAGE,
  ADC_CH_MPPT_CURRENT
};

struct mpptReadProto {
  int16_t voltage;
  int16_t current;
};

volatile static struct {
  int16_t usb;
  int16_t front;
  int16_t rear;
  int16_t storage;
  int16_t lightsense;
} voltages;
volatile static struct {
  int16_t usb;
  int16_t front;
  int16_t rear;
} currents;
static struct mpptReadProto banks[2][MPPT_SAMPLES];

static void step4 (void);
static void step3 (void);
static void step2 (void);
static void step1 (void);

static void (*step)(void);
static uint8_t loop;
static struct mpptTrackProto track;
static uint8_t bank;

static void step1 (void) {

  step = &step2;

  NRF_GPIO->OUTCLR = 1 << CFG_PIN_ADC_MUX;
  NRF_PPI->CHENSET = 1 << CFG_PPI_ADC_SAMPLEONSTART;

  NRF_SAADC->CH[ADC_CH_USB].PSELP = CFG_ADC_USB_PSEL;
  NRF_SAADC->CH[ADC_CH_FRONT].PSELP = CFG_ADC_FRONT_PSEL;
  NRF_SAADC->CH[ADC_CH_REAR].PSELP = CFG_ADC_REAR_PSEL;
  NRF_SAADC->CH[ADC_CH_STORE].PSELP = CFG_ADC_STORE_PSEL;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].PSELP = CFG_ADC_LIGHTSENSE_PSEL;

  NRF_SAADC->RESULT.PTR = (uint32_t) &voltages;
  NRF_SAADC->RESULT.MAXCNT = sizeof(voltages) / 2;

  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
}

static void step2 (void) {

  step = &step3;

  NRF_GPIO->OUTSET = 1 << CFG_PIN_ADC_MUX;

  NRF_SAADC->RESULT.PTR = (uint32_t) &currents;
  NRF_SAADC->RESULT.MAXCNT = sizeof(currents) / 2;
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
}

static void step3 (void) {

  step = &step4;
  NRF_PPI->CHENCLR = 1 << CFG_PPI_ADC_SAMPLEONSTART;

  NRF_SAADC->CH[ADC_CH_USB].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_FRONT].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_REAR].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_STORE].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].PSELP = SAADC_CH_PSELP_PSELP_NC;
  NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].PSELP = CFG_ADC_MPPT_VOLTAGE_PSEL;
  NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].PSELP = CFG_ADC_MPPT_CURRENT_PSEL;

  NRF_SAADC->RESULT.PTR = (uint32_t) &banks;
  NRF_SAADC->RESULT.MAXCNT = MPPT_SAMPLES * 2;

  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
  NRF_PPI->CHENSET = 1 << CFG_PPI_ADC_SAMPLEBYTIMER;
}

static void trackAssess (uint8_t bankId) {

  for(struct mpptReadProto *pCur = &banks[bankId][0]; pCur < &banks[bankId][0] + sizeof(banks[0]); pCur++) {
    if (pCur->voltage > track.voltage && pCur->current > track.current) {
      track.voltage = pCur->voltage;
      track.current = pCur->current;
    }
  }
}

static void step4 (void) {

  if (loop == MPPT_LOOP-1) {
    loop = 0;
    bank = 0;

    NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].PSELP = SAADC_CH_PSELP_PSELP_NC;
    NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].PSELP = SAADC_CH_PSELP_PSELP_NC;
    NRF_PPI->CHENCLR = 1 << CFG_PPI_ADC_SAMPLEBYTIMER;
    
    trackAssess(bank);
    MPPT_Track(&track);
    track.voltage = 0;
    track.current = 0;
    step1();
    return;
  }

  NRF_SAADC->RESULT.PTR = bank? (uint32_t) &banks[0] : (uint32_t) &banks[1];
  NRF_SAADC->TASKS_START = SAADC_TASKS_START_TASKS_START_Trigger << SAADC_TASKS_START_TASKS_START_Pos;
  trackAssess(bank);
  bank = bank? 0:1;
  loop++;
}

void SAADC_IRQHandler (void) {

  NRF_SAADC->EVENTS_END = SAADC_EVENTS_END_EVENTS_END_NotGenerated << SAADC_EVENTS_END_EVENTS_END_Pos;
  step();
}

uint32_t ADC_TaskCalibrate (void) {

  NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Enabled << SAADC_ENABLE_ENABLE_Pos;
  NRF_SAADC->TASKS_CALIBRATEOFFSET = SAADC_TASKS_CALIBRATEOFFSET_TASKS_CALIBRATEOFFSET_Trigger << SAADC_TASKS_CALIBRATEOFFSET_TASKS_CALIBRATEOFFSET_Pos;
  return CFG_SCHEDULER_TIMER_MINIMUM;
}

uint32_t ADC_TaskStart (void) {

  NRF_SAADC->EVENTS_END = SAADC_EVENTS_END_EVENTS_END_NotGenerated << SAADC_EVENTS_END_EVENTS_END_Pos;
  NRF_SAADC->INTENSET = SAADC_INTENSET_END_Enabled << SAADC_INTENSET_END_Pos;

  step1();
  return CFG_SCHEDULER_TIMER_MINIMUM;
}

inline void ADC_Init (void) {

  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_STORE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_USB] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_FRONT] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_REAR] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MPPT_VOLTAGE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MPPT_CURRENT] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_LIGHTSENSE] = pinDisconnectInputBuffer;
  NRF_GPIO->PIN_CNF[CFG_PIN_ADC_MUX] = pinDisconnectInputBuffer | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos);
  NRF_GPIO->OUTSET = 1 << CFG_PIN_ADC_MUX;

  NRF_SAADC->RESOLUTION = SAADC_RESOLUTION_VAL_12bit << SAADC_RESOLUTION_VAL_Pos;
  NRF_SAADC->CH[ADC_CH_USB].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_FRONT].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_REAR].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_STORE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_2 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_LIGHTSENSE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain2 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_SLOW << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_MPPT_VOLTAGE].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_MPPT_VOLTAGE << SAADC_CH_CONFIG_TACQ_Pos;
  NRF_SAADC->CH[ADC_CH_MPPT_CURRENT].CONFIG = SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos | SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos | ADC_SAMPLETIME_CFG_MPPT_CURRENT << SAADC_CH_CONFIG_TACQ_Pos;
  
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEONSTART].EEP = (uint32_t) &NRF_SAADC->EVENTS_STARTED;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEONSTART].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEBYTIMER].EEP = (uint32_t) &NRF_RTC1->EVENTS_TICK;
  NRF_PPI->CH[CFG_PPI_ADC_SAMPLEBYTIMER].TEP = (uint32_t) &NRF_SAADC->TASKS_SAMPLE;
  
  NVIC_SetPriority(SAADC_IRQn, CFG_INTERRUPT_PRIORITY_ADC);
  NVIC_EnableIRQ(SAADC_IRQn);
}

void ADC_Shutdown (void) {

  NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos;
}

Here's an example of when it switches to crap out. High reads are valid.

<info> app: Store 625
<info> app: Store 633
<info> app: Store 626
<info> app: Store 628
<info> app: Store 627
<info> app: Store 632
<info> app: Store 632
<info> app: Store 5
<info> app: Store 7
<info> app: Store 11
<info> app: Store 12