SAADC internal timer setup requirements for continuous mode

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

Parents
  • 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.

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

    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

    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. :-)

    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.

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

    Yes.

    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

    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

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

  • 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

  • Hello again, Christopher

    Christopher Hunt said:
    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.

    No need to apologize, I am happy to hear that you were able to identify and resolve the issue so quickly! :) 

    Christopher Hunt said:
    The PR with the fixes is at: github.com/.../425

    Thank you for providing the PR for completeness - this will be helpful for other forum-users using Rust and the SAADC.

    Christopher Hunt said:
    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.

    Thank you for saying that - I too absolutely think that this should be an option just as viable as using the provided drivers. The Product Specification should contain any and all relevant information about the SAADC needed to create a driver, no doubt.

    As mentioned in the other ticket you referenced, you could also take a look at the SAADC documentation for the nRF52832 since it currently is more fleshed out wrt. the different operating modes of the SAADC. I have already opened an internal ticket on this as well, to have the technical writers include this section in the nRF52840's SAADC documentation as well. The previously mentioned missing required SAMPLE task trigger for continuous mode is unfortunately not present here either. 

    Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

    Good luck with your development!

    Best regards,
    Karl

Reply
  • Hello again, Christopher

    Christopher Hunt said:
    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.

    No need to apologize, I am happy to hear that you were able to identify and resolve the issue so quickly! :) 

    Christopher Hunt said:
    The PR with the fixes is at: github.com/.../425

    Thank you for providing the PR for completeness - this will be helpful for other forum-users using Rust and the SAADC.

    Christopher Hunt said:
    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.

    Thank you for saying that - I too absolutely think that this should be an option just as viable as using the provided drivers. The Product Specification should contain any and all relevant information about the SAADC needed to create a driver, no doubt.

    As mentioned in the other ticket you referenced, you could also take a look at the SAADC documentation for the nRF52832 since it currently is more fleshed out wrt. the different operating modes of the SAADC. I have already opened an internal ticket on this as well, to have the technical writers include this section in the nRF52840's SAADC documentation as well. The previously mentioned missing required SAMPLE task trigger for continuous mode is unfortunately not present here either. 

    Please do not hesitate to open another ticket if you should encounter any issues or questions in the future.

    Good luck with your development!

    Best regards,
    Karl

Children
No Data
Related