S110 Soft Device and Analog Inputs

[Jarmo]

I have an application that reads an nRF51822 pin configured as analog input and then sends that value using "ble uart" (included in Nordic's sdk). Analog input is read in an interrupt 250 times per second, but only a few of those values are sent from my main loop (not from interrupt). However, when the connection is established, the analog input stops working but just gives a fixed value (218).

The problem can be solved by initializing analog input in my main loop all the time as follows:

nrf_adc_init(ADC_RES_10bit, ADC_INPUT_AIN3_P02, ADC_INT_DISABLED);

But if I do so, then the BTLE connection hangs up within a half a minute, and actually the whole system probably crashes.

How should I handle ADC when using soft device? Is the soft device using ADC in some way?

[Stefan Birnir Sverrisson]

Perhaps you can look at this thread in order to realize better how to operate the UART when the softdevice is enabled.

For the ADC, why are you re-initializing it? Are you using perhaps multiple analog input pins. Perhaps you can share more about your scenario.

[Jarmo]

Thanks for all replies! Now it looks like the problem with ADC might be here:

uint32_t nrf_adc_read(void) { uint32_t adc_data; NRF_ADC->TASKS_START = 1; while(NRF_ADC->EVENTS_END == 0); // note the loop! NRF_ADC->EVENTS_END = 0; adc_data = NRF_ADC->RESULT; return adc_data; }

I am using the above function from an interrupt running 250 times a second. At the same time there is S110 BLE connection ("UART" ) active and I am sending data over that. It is done in the main loop and not from interrupt, indeed. Also, the data is printed out using wired UART.

The system works from ten seconds to several minutes before getting stuck. I have been debugging this issue now several days and finally found a modification that seems to solve the issue: when I comment away the while() -loop in the above function the stucking does not happen any more (at least it hasn't been happening yet).

// while(NRF_ADC->EVENTS_END == 0); // it seems that stucking happens here?!?

Any explanations for this behaviour?

[Stefan Birnir Sverrisson]

Hi Jarmo

I am not certain why this is failing actually. However, if you are getting stuck on that loop, it may be because the ADC END event flag is cleared somewhere else in your code.

Make sure you explicitly set the interupt priority to LOW for the interrupt that you call this ADC handler from. You can see how to set interrupt priority low in the example I posted earlier on this thread, in the ADC init routine.

I have implemented the example above in a non polling way, i.e. I start the ADC sampling with a timer and then handle the ADC result in the ADC interrupt handler. With that implementation I have not come across any problems. Perhaps you can consider that if the problem persists.

[Jarmo]

Yes, logically thinking there must either be a higher priority interrupt running that clears the ADC END event, or the event doesn't always work as it should.

I switched to the solution you proposed, using ADC interrupt, and it seems to work. Thank you for helping!