SAADC internal timer setup requirements for continuous mode

[Christopher Hunt]

Hi there,

I'm using the product specification of the nRF52840 to program the SAADC in continuous mode using its internal timer. I'm not able to use your SDK. Unfortunately, I'm having difficulty in getting a repeated sampling to occur. I can get one-shot sampling working very well.

I'm doing everything per https://infocenter.nordicsemi.com/topic/ps_nrf52840/saadc.html?cp=4_0_0_5_22_3#saadc_easydma and Figure 4, sans firing the SAMPLE task. My expectation is that the SAMPLE task is fired by the internal timer of the SAADC. I see the STARTED event but then nothing else. I then read https://devzone.nordicsemi.com/f/nordic-q-a/73186/nrf52840-saadc-continuous-sampling-not-started-with-task_start and saw that a SAMPLE task should be issued after the first START task to kick things off (there being an omission in the product specification). When I do issue an initial SAMPLE task, I see the STARTED event and then an END event with samples... At this point, I issue another START task (as per Figure 4), but I don't see any more END events.

Here's the logging of events with the initial SAMPLE task included:

0 INFO Started
1 INFO Done
2 INFO Result done
3 INFO Done
4 INFO Result done
5 INFO Ended
6 INFO sample len=500
7 INFO Started

I'm logging Stopped events also, but not seeing them (which is good).

My sample rate is specified as 1600 and I also set TIMER mode. I'm using double-buffering, each buffer sized for 500 samples, and swap buffers on processing the Started event. There is just one channel configured.

Thanks for any help or guidance.

Kind regards,
Christopher

[Christopher Hunt]

Additional info: if I drive the TASK_SAMPLE from a timer via PPI instead of the internal clock on the SAADC then I get the same behaviour i.e. the first sample is performed, but no more. I've verified that the PPI and timer is set up correctly by toggling an LED instead. This suggests that the behaviour I'm observing perhaps isn't due to the lack of TASK_SAMPLE being fired.

[Karl Ylvisaker]

Hello Christopher,

I'm using the product specification of the nRF52840 to program the SAADC in continuous mode using its internal timer. I'm not able to use your SDK.

Just to clarify, what do you mean when you say you are not able to use our nRF5 SDK? Do you mean that there is a requirement or constraint in your application that prevents you from utilizing it, or are you saying that you are having some trouble using it? In case of the latter please let me know and I will try to assist you in getting it up and running.
The SDK is very useful, as it saves you the trouble of having to reimplement a lot of the peripheral procedures. The nrfx_saadc_v2 driver in particular makes the SAADC a lot easier to work with.

I then read https://devzone.nordicsemi.com/f/nordic-q-a/73186/nrf52840-saadc-continuous-sampling-not-started-with-task_start and saw that a SAMPLE task should be issued after the first START task to kick things off (there being an omission in the product specification).

Yes, unfortunately it seems that the product specification does not document the continuous mode of the SAADC with enough depth. I have asked our technical writers to have a look at this.

Here's the logging of events with the initial SAMPLE task included:

So, the main issue is that you do not get another end event, following the started one?
How are you providing the second buffer to the SAADC? If possible, it would be helpful if I could see how you have implemented this.
Are you triggering any SAMPLE tasks after the initial one? Do you perform any calibrations in your program?
Could I ask you to share the entire log, along with the SAADC configuration and code you are running?
If you would not like to share any code publicly please let me know and I will convert the ticket to Private so that it is only viewable by yourself and the support staff here at Nordic.

My sample rate is specified as 1600 and I also set TIMER mode. I'm using double-buffering, each buffer sized for 500 samples, and swap buffers on processing the Started event. There is just one channel configured.

Christopher Hunt said:

Additional info: if I drive the TASK_SAMPLE from a timer via PPI instead of the internal clock on the SAADC then I get the same behaviour i.e. the first sample is performed, but no more. I've verified that the PPI and timer is set up correctly by toggling an LED instead. This suggests that the behaviour I'm observing perhaps isn't due to the lack of TASK_SAMPLE being fired.

Thank you for elaborating on this. I concur that this then do not sound like a missing TASK_SAMPLE. Instead, I suspect that there might be an issue with the SAADC buffers, and I'd like for us to take a closer look at how the double buffering is implemented.

Best regards,
Karl

[Christopher Hunt]

Hi Karl, thanks so much for the reply! Responses:

Karl Ylvisaker said:

Just to clarify, what do you mean when you say you are not able to use our nRF5 SDK? Do you mean that there is a requirement or constraint in your application that prevents you from utilizing it, or are you saying that you are having some trouble using it? In case of the latter please let me know and I will try to assist you in getting it up and running.

Apologies for being elusive here. I'm using Rust and extending the Embassy HAL. Here's my PR in its entirety: https://github.com/embassy-rs/embassy/pull/425

Karl Ylvisaker said:

The SDK is very useful, as it saves you the trouble of having to reimplement a lot of the peripheral procedures. The nrfx_saadc_v2 driver in particular makes the SAADC a lot easier to work with.

Thanks, yes. I'm reading the SDK code for further understanding of the product specification. I appreciate the complexity of this area and what the SDK brings. The nfx code hasn't yet yielded the glue to what I'm doing wrong. :-)

Karl Ylvisaker said:

Yes, unfortunately it seems that the product specification does not document the continuous mode of the SAADC with enough depth. I have asked our technical writers to have a look at this.

Happy to review anything they draft, so please reach out if required. I'm keen that we're able to operate from the product specifications. We've been able to do so with a great deal of success for the other peripherals as the documentation is excellent in general.

Karl Ylvisaker said:

So, the main issue is that you do not get another end event, following the started one?

Yes.

Karl Ylvisaker said:

How are you providing the second buffer to the SAADC? If possible, it would be helpful if I could see how you have implemented this.

Hopefully, the Rust code makes sense to you. Here's the particular line associated with handling the events and setting up the buffers:

https://github.com/embassy-rs/embassy/pull/425/files#diff-06f997ccc5fc674f9b7ee5ee33a9106546a758dad843c63ee6a7c3ceb5c2b89fR292

https://github.com/embassy-rs/embassy/pull/425/files#diff-06f997ccc5fc674f9b7ee5ee33a9106546a758dad843c63ee6a7c3ceb5c2b89fR341

Karl Ylvisaker said:

Thank you for elaborating on this. I concur that this then do not sound like a missing TASK_SAMPLE. Instead, I suspect that there might be an issue with the SAADC buffers, and I'd like for us to take a closer look at how the double buffering is implemented.

Thanks Karl. I appreciate you taking a look at this.

-C

[Christopher Hunt]

Another bit of info: we're not calibrating the SAADC. I don't know if this makes a difference.

[Christopher Hunt]

Hey Karl - we found the problem. It was of our own making. :-) We simply forgot to re-enable the END and STARTED interrupts. Sorry for the noise here. The PR with the fixes is at: github.com/.../425